Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2013-01-15 15:32:11

etc
Developer
Registered: 2010-11-11
Posts: 3,356
Website

Better (?) <txp:link_to_prev/next />

Current (4.5.4) <txp:link_to_prev/next /> tags do not respect advanced sort orders, like sort="Section, Posted desc" or sort="DATE(LastMod)". Following this discussion, I have made some modifications in getNextPrev() and getNeighbour() functions to fix this issue.

It seems to work and is even faster than before on my server (but slower on my laptop). If someone is interested, the code (wrapped in a plugin) is below.

Last edited by etc (2013-03-16 11:17:45)

Offline

#2 2013-01-21 14:41:01

etc
Developer
Registered: 2010-11-11
Posts: 3,356
Website

Re: Better (?) <txp:link_to_prev/next />

OK, let it stay in the territory of plugins for the moment.

Offline

#3 2013-01-21 14:48:38

jstubbs
Moderator
From: Hong Kong
Registered: 2004-12-13
Posts: 2,394
Website

Re: Better (?) <txp:link_to_prev/next />

Hasn’t Robert confirmed it as a defect? Did you send in a patch?

Offline

#4 2013-01-21 14:52:17

jstubbs
Moderator
From: Hong Kong
Registered: 2004-12-13
Posts: 2,394
Website

Re: Better (?) <txp:link_to_prev/next />

Mmmm. My own “issue” regarding if_section problems on 4.5.4 seems to have been removed..

Offline

#5 2013-01-21 14:59:01

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,787
Website

Re: Better (?) <txp:link_to_prev/next />

jstubbs wrote:

Mmmm. My own “issue” regarding if_section problems on 4.5.4 seems to have been removed..

Seems it was invalid markup that might have been causing it.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#6 2013-01-21 15:06:16

etc
Developer
Registered: 2010-11-11
Posts: 3,356
Website

Re: Better (?) <txp:link_to_prev/next />

jstubbs wrote:

Hasn’t Robert confirmed it as a defect? Did you send in a patch?

He did, and I have proposed a patch, but this is a new, more powerful solution, that respects any sort order. I have not submitted it as a patch because it needs some performance testing before. On fast servers its faster than the native one, but slower on my laptop. If some dev people are reading, I find that retrieving all IDs with

SELECT ID FROM textpattern ORDER BY some_sort

in some sorted_list takes about the same time that

SELECT ID, other_stuff FROM textpattern WHERE some_field>threshold ORDER BY some_sort

Seeking for the current article position $pos with array_seek and for its neighbors with SELECT ... WHERE ID IN ($sorted_list[$pos-1], $sorted_list[$pos+1]) is lightning fast, using the primary index.

But many testers are better than one.

Offline

#7 2013-01-21 15:13:52

jstubbs
Moderator
From: Hong Kong
Registered: 2004-12-13
Posts: 2,394
Website

Re: Better (?) <txp:link_to_prev/next />

Bloke wrote:

Seems it was invalid markup that might have been causing it.

That’s funny, changing the status of an issue to invalid renders it invisible, so I never saw Jukka’s reply. Some markup may have been invalid but I had strange results even with a very basic if - else scenario. Maybe I’m getting old! Anyway, back on topic. Sorry Oleg.

Offline

#8 2013-01-21 15:56:59

wet
Developer
From: Lenzing, Austria
Registered: 2005-06-06
Posts: 3,267
Website

Re: Better (?) <txp:link_to_prev/next />

etc wrote:

because it needs some performance testing before.

You might want to try your approach for varying amounts of articles.

If I’ve read your code correctly, it employs array_search to lookup neighbours in an array of all articles matching the current list criteria like section, time, keywords.

It seems that array_search’s runtime depends on the size of the $haystack array and grows linear with the size of the haystack. I.e., more articles, less performance.

It might be interesting how the current core approach compares to your plugin when it has to look into large article sets.

Offline

#9 2013-01-21 17:00:57

etc
Developer
Registered: 2010-11-11
Posts: 3,356
Website

Re: Better (?) <txp:link_to_prev/next />

wet wrote:

It seems that array_search’s runtime depends on the size of the $haystack array and grows linear with the size of the haystack.

Probably, but isn’t that true for SELECT ... WHERE ... ORDER BY ... query? The core approach uses two of them, the plugin takes one SELECT and one array_search.

It might be interesting how the current core approach compares to your plugin when it has to look into large article sets.

I did some testing, in a “typical” case (good LAMP server, about 250 articles) the plugin is ~25% faster, but slower on my laptop site copy. In average, the runtimes are of the same magnitude, but I have no very large site at hand to test.

Offline

#10 2013-01-21 17:27:48

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 7,342
Website

Re: Better (?) <txp:link_to_prev/next />

etc wrote:

… but I have no very large site at hand to test.

Hi Oleg, one of my sites has over 1500 entries. If you want and promise you will not bring it to its knees I can grand you access. The problem is that it is not using the latest txp due to the postmaster plugin.

Last edited by colak (2013-01-21 17:29:50)


Yiannis
——————————
neme.org | hblack.net | LABS | State Machines | Respbublika! | NeMe @ github

Offline

Board footer

Powered by FluxBB