Change Archive-Page-behaviour for better caching

[onli]

We're getting there. Thanks again for testing, didn't realize that.
Did I get the last sentence right, that it was also about the wrong sort-order onpage?

Don: Hm, that could surely be mixed up.

[garvinhicking]

Hi!

Hm, not sure if the array_reverse thing might have issues. "Sticky entries" not working comes to my mind, can you try that?

Also, the categorytemplates plugins allows to define custom sort order (ASC/DESC) for entries of a categorie, I think that if using array_reverse there this could screw up the ordering?

Also I think we should not make this new ordering the default setting because of issues like these that may not be foreseen currently...

Plus, better use serendipity_db_bool($serendipity['flatArchive']) istead of a === false comparison, I think otherwise it might not work on postgresql instances...

Regards,
Garvin

[Timbalu]

Hmmm, may I just drop in...
If I try this in Garvins blog, I found it extremly confusing.... (it is nothing I - as a human - would expect it to happen, trying to walk page by page through a blog!)
First, it falls down to page 133 instead of 134 and then saying 'next' to a reverting view from last to previouses pages and so on... until now. Is this really how it is expected to work? I still don't get the real use of it... If I want to read someones blog entries, I do not want to start paging from the very end.
If that is how it is achieved, please set default to false.

[onli]

First, it falls down to page 133 instead of 134 and then saying 'next' to a reverting view from last to previouses pages and so on... until now.

This is not what happens on Garvins blog when I visit it.

Is this really how it is expected to work?

Garvins blog is missing the last patch, which changes the order on an archive-page to descending, unsurprisingly because he is right with the missing sticky posts and the plugin-issues due to the hack. What is expected is simply the normal archive-view with urls from Pn to P1.

I still don't get the real use of it...

Explained it in the first post of the thread. A stable order, improving the web and search-results for blog-visitors.

If I want to read someones blog entries, I do not want to start paging from the very end.

That is not what this is about...

Garvin: I will try to send in a proper patch soon. I really want this change - in my judgement the benefits are huge - and will try to circumvent the issues you described (probably adding code to the fetch_entries to do this right). Please see the current situation as a hacky way to show what is wanted with the change, to get approval of the target.

[Timbalu]

Oh yes, I see: "(Seite 134 von 134, insgesamt 1335 Einträge) » nächste Seite - (P133)" - never mind. I expected to be on page 1. I now can imagine the benefits you see in there.
(Keeping default to false will still be better, since there sure are plugin injections to entry paging... or upgraders don't want to change the old behaviour, o.e.)

[garvinhicking]

Hi!

Garvin: I will try to send in a proper patch soon. I really want this change - in my judgement the benefits are huge - and will try to circumvent the issues you described (probably adding code to the fetch_entries to do this right). Please see the current situation as a hacky way to show what is wanted with the change, to get approval of the target.

No problem. I set the default to "false", so it shouldn't do harm to anyone. Take your time, I also think the benefits of this are worth it!

Regards,
Garvin

[onli]

I now included the stable-archive-pattern in fetchEntries. It's a different approach, instead of messing with the sort-order it's changing the limits. Tried to be more careful now, that approach worked in my test with categories and sticky entries. Changing the sort-order with the categorytemplates-plugin worked, though it makes the option useless, but that's not worse than currently without the option.

I had to refine the pattern: We always need to have a shrinking and growing page, and i missed at first that this is an issue here. The most natural option for that would be the frontpage, page n. But as we are used to have a frontpage with a stable amount of entries, the archive copies that on page n, and instead page n-1 is the one with the chaning amount of entries on it. All following should have always the same and the same amount of entries on them.

Hope i didn't miss a file again, the commit seemed fine, though i had to merge garvins commit because i forgot to pull first (which hopefully broke nothing).

[garvinhicking]

Hi!

Great, both code and the updated view on my blog looks very promising, couldn't find a problem so far. Thanks a lot!

Regards,
Garvin