Support last page pattern in PAGINATION_PATTERNS

[arty-name]

I want to be able to specify the URL pattern for the last page using -1 as identifier like this: (-1, '{base_name}/last/', '{base_name}/last/index.html'). Currently, only special handling of the first page is possible.

Here’s the background for this feature request.

I want the page numbers to go in the different direction, so that page 1 would always contain the same set of articles: the oldest ones. The same applies to other pages as well: their content will not change over time. The original version of the PR was calling it fixed pagination or static pagination. Among other things this is good for SEO. I implemented that in my current weblog: https://blog.arty.name/. The current default on pelican and most websites on the internet is the opposite: the items on a page could be pushed to another page over time, and it is unfortunate.

Having ARTICLE_ORDER_BY = 'date' and NEWEST_FIRST_ARCHIVES = True I could use object_list[::-1] in index.html and tag.html of my theme to almost reach my goal. With this PR merged I can do the following:

PAGINATION_PATTERNS = (
    (1, '{base_name}/page-1/', '{base_name}/page-1/index.html'),
    (2, '{base_name}/page-{number}/', '{base_name}/page-{number}/index.html'),
    (-1, '{base_name}/', '{base_name}/index.html'),
)

[justinmayer]

Any comments on this contribution? cc: @kylef @smartass101 @avaris

[coveralls]

Coverage decreased (-0.2%) when pulling ea07257 on arty-name:PAGINATION_FIXED into cb11bea on getpelican:master.

[arty-name]

Wow that thing is old

[justinmayer]

Indeed. Very sorry for neglecting your pull request, Artemy. One of my goals is to handle this better in the future.

With that said, are these changes still relevant? Please let me know.

[arty-name]

Yes, they are still relevant, and I am still using that branch for my blog.

Looking at the big picture, I think this approach to pagination is good for the Internet overall, and should be even considered for a default. But obviously it is too much to ask, so I will be happy just to see that small patch included.

[justinmayer]

@avaris / @ingwinlu / @iKevinY: Do you have a moment to review this pull request?

[iKevinY]

These changes look alright to me, though I'm thinking it might make more sense to describe this feature as 'reversed pagination' rather than 'fixed pagination'. It would be a nice bonus to have a test or two confirming that this setting alters the pagination as expected to avoid regressions.

[arty-name]

Thank you, @iKevinY!

I’d argue that "fixed" tries to describe the point of having this kind of pagination, while "reversed" merely describes the means. "Fixed" is not doing a very good job at that, however I cannot come up with a better alternative, except for "static" maybe. I guess it would be easier for a native English speaker.

I will try to write tests as well.

[Scheirle]

IMHO static and dynamic pagination sound right, where dynamic is the current default behavior.
dynamic -> articles move back in the stack to make room for newer ones.
static -> articles do not change their position.

---

Instead of a Boolean setting (PAGINATION_FIXED) you could also use a string/enum setting (PAGINATION_MODE), which would either be static or dynamic (default).

[arty-name]

Okay, I have updated my commits with tests. Tests for Paginator class were effectively non-existent, so I tried to come up with something by myself.

Regarding proper names, I do like the proposal by @Scheirle to use Enum for PAGINATION_MODE being static or dynamic, however I do not see any other enums in Setting, so I am not sure if it is okay to have them. @justinmayer, @iKevinY: do you agree?

[arty-name]

Hey there! Believe it or not I have been using this branch of Pelican all these years. Now I took a fresh look at Pelican and noticed ARTICLE_ORDER_BY, which suits my purpose nicely. Having ARTICLE_ORDER_BY = 'date' I could use object_list[::-1] in index.html and tag.html of my theme to almost reach my goal.

The only part missing would be this small change to allow that usage of the PAGINATION_PATTERNS.

What do you think, should I rather create a new PR in favor of this minimal change or update the current PR?

[avaris]

@arty-name reusing this PR would be OK. Just to make sure I understand correctly, your changes would be adding a way (-1) to PAGINATION_PATTERS to reference the last page, right?

[arty-name]

This way is already included in the current PR, I can just undo the rest of the changes since they are not strictly required anymore.

[arty-name]

Okay, now this PR is much smaller: +12 −2. Maybe this would help it to get through the review!

[avaris]

How about some tests? :)

[arty-name]

I’ve added a test

[iKevinY]

This PR looks good to me; can the PR title & description be updated to reflect the new (smaller) set of changes (ie. the current commit message)?

[avaris]

Thanks! Good to go 👍

[justinmayer]

Thanks for your patience, Tom, as well as for being willing to update the endeavor for 2021. Much appreciated! Looks good to me.

@iKevinY: Any last thoughts before merging?

[iKevinY]

LGTM! Thank you for the PR and your patience @arty-name; glad we can finally get this merged in! 😄

[justinmayer]

Many thanks to @arty-name for the enhancement and to everyone here who helped review it. 🥇

[arty-name]

Yay! Thanks everyone for reviewing and accepting this PR and for all your work on Pelican!