previous/next pages change too often.

[petree2]

Ok, at the bottom of the index page there is a next page link.

This links /archives/P2.html. This page links to P3 and you get the idea.

This means that if someone links to an archive page (P8.html for example) the content they were linking to will likely slide off that page after 15 (or whatever you specified) more entries have been posted.

Wouldn't it make more sense to reverse the numbering order?

So the page number would count down as the entries got older?

I would imagine this would improve google rankings as the pages would stay constant and thus be more linkable. It would certainly increase the likelyhood of someone whose come in from a link actually finding what they are looking for.

Oh and it has the added benefit of in the future allowing easy generation of static pages (MT style) reducing load. With the current scheme, your entire archive would have to be rebuilt every time you posted an entry.

[garvinhicking]

In fact having this ordering is one of the Google-benefits, as it spiders the pages more often and treats them as more up to date.

Linking to an archive page like this is not clever at all. Instead you should link to a Month or Week archive link, which will stay consistent forever.

The other paging also changes if you change the number of frontend entries, and users might find it strange to page backwards and be told "You are on page 29 of 29" instead of being on page 1.

And we will never have MT-style archive pregeneration because of lots and lots of dynamic processing directives in many areas. That option is out of reach for us.

Thanks for your feedback though - I hope you can understand my reasoning.

Regards,
Garvin

[petree2]

Yeah, I hadn't thought about that page X of Y issue.

Hmm...I just really hate it when google links to a page that when the user goes there doesn't have the content they were looking for.

Just curious, what sort of directives are you talking about? I understand that the way things are setup now you use mod_rewrite to build the whole url structure, but is there any reason you couldn't pre-cache pages somewhere?

[garvinhicking]

I currently don't have a good suggestion on how to order the pages in reverse order without needing to patch core code. The page ordering is scattered throughout at least 2 places (include/functions_entries.inc.php function serendipity_printEntryFooter(), function serendipity_fetchEntries()) and a bit harder to abstract. But not impossible, though I'm really lacking the motivation to code this. Maybe you're willing to look into the two functions and see how/if an plugin event hook could mangle data there so that you can create a plugin to reverse it?

The core problem as I see it is that you cannot create a SQL Limit statement with reverse paging order, if you do not know the amount of maximum pages. Thus, you would first need to fetch the amount of pages and then "reverse engineer" the limit statement for the current page.

About the static generation: I am talking about sidebar plugins. Those have often real dynamic output depending on loginstate, date and dynamic data. Added to that, certain event plugins which deal with formatting an entry, need to be called dynamically (like the search highlight plugin, coming first to my mind).

Using the entryproperties plugin we do some caching so that the "static" event plugins only apply their transofmrations once and not on each call. But there remain quite a few event plugins which need to be executed over and over again. You could create a PEAR::Cache_Lite container for many of that, but this is a real cumbersome task and still will not give you real static pages, as their content needs to be regenerated every now and then. We really think that this dynamic rendering is a huge benefit against the static pregeneration problem MT introduced (see page load times and regeneration times when someone submits a comment to a MT page)

Regards,
Garvin