Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#1 2013-01-15 15:32:11
- etc
- Developer
- Registered: 2010-11-11
- Posts: 3,418
- 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,418
- Website
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,834
- 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,418
- 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.
Me | f/rwetzlmayr | Repos
Offline
#9 2013-01-21 17:00:57
- etc
- Developer
- Registered: 2010-11-11
- Posts: 3,418
- 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,374
- 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