[UX] Make the GET page variable consistent with the real page number

[yorkshire-pudding]

Description of the need

From: https://www.drupal.org/project/drupal/issues/385270
Backdrop's Drupal's pagination is a bit geeky: it starts from 0 instead of 1. If we are on the first page and we click on the number 2 (or on the "next" link) in the navigation bar, we're displaying the second page, but the $_GET['page'] variable on the url is ?page=1.

$_GET['page'] variable is one lower than the real page number marked in the navigation bar. For most people, I think that it's a bit disconcerting and not user-friendly ergonomics.

Proposed solution

The page parameter in the URL will match the active number on the pager link

Alternatives that have been considered

None

Is there a Drupal or Backdrop contributed module that accomplishes this?
No

Additional information

This was raised as a D7 issue but never merged:
https://www.drupal.org/project/drupal/issues/385270

There is a patch by azovsky at:
https://www.drupal.org/project/drupal/issues/385270#comment-11982646

While the line numbers are different, the changes can apply to Backdrop's code mostly the same (small change to accommodate newer PHP versions). I also needed to modify the tests to reflect the page numbers now delivered.

Draft of feature description for Press Release (1 paragraph at most)

Backdrop's pagers will now show the same page in the URL as is shown in the pager link.

---

PR: backdrop/backdrop#5292

[indigoxela]

@yorkshire-pudding I belief, that's a duplicate, see #5566 (although the other issue only mentions Views).

Again, I doubt that such a change is backwards compatible re existing links (and bookmarks).

The numbering (zero-based or not) should be consistent across Backdrop.

[yorkshire-pudding]

@indigoxela - I did search multiple phrases because I thought there must be someone who had raised this before. Thanks for linking to the other one.

The numbering (zero-based or not) should be consistent across Backdrop.

This one covers Views and other Pagers including comments (on page and the Manage Comments screen), search results.

Again, I doubt that such a change is backwards compatible re existing links (and bookmarks).

I want to question the whole idea of backwards compatibility for links and bookmarks in this case.

Firstly, how many people will share a link to a page of results? That result set can and often does change so why would people expect a link to a page of results to remain static? Maybe the page of comments on a node would stay static, but then comments have a permalink so you can link to the comment, whatever page it is on.

Secondly, is there a defined scope of what backwards compatibility we should keep? Will this break someone's code? Or are links the only "backwards compatibility" issue here?

The Drupal issue I linked to was originally for D7. That issue was eventually closed in favour of this issue for modern Drupal, which is raised as a bug:
https://www.drupal.org/node/1818040

They list the potential disruption:

This change should not disrupt the internal behaviors of the paging system if the internal counter is unaltered, but will change hardcoded links to specific pages of content, which might require updates to some existing sites.

And it is discussed as a blocker but I still don't get it: why are people sharing links to a page of results?

[avpaderno]

Those links can be shared, but they should be expected to be temporarly valid. Once the number of results changes, the results shown in each page change.
That would even happen when the pager is changed, for example, to show 50 results per page instead of 20.

[argiepiano]

These changes are likely to break views_infinite_scroll and views_litepager, and, possibly, views_load_more.

[docwilmot]

Re backwards compatibility, can we make the page start number (0 vs 1) a config variable and only set for new sites?

[yorkshire-pudding]

Re backwards compatibility, can we make the page start number (0 vs 1) a config variable and only set for new sites?

Yes, it probably could be a config setting. I think the relevant tests might then need a version with (like PR) and without (current) the setting, but should be do-able.

To me it seems like the setting should be under Configuration > User interface but that menu item only appears for some contrib modules; there are no existing core settings under there. Is there another suitable place it would belong?

[indigoxela]

My suspicion is, that with a setting we'd introduce even more inconsistencies, that contrib couldn't handle. Or they'd all need an immediate update, so they could deal with both settings - on and off. Which is not what I'd consider "backwards compatible". But maybe I'm missing something.

To me this still looks like a big pitfall for very little gain.

[yorkshire-pudding]

To me this still looks like a big pitfall for very little gain.

As has been pointed out in the Drupal queue and in #5566 this is a Drupalism and Backdropism. It is not user friendly and could well be confusing. Comments from the Drupal queues include:

• Other systems have 1 based paging so it is confusing coming to Drupal
• Clients have raised bug reports about the inconsistency

[laryn]

It might be worth testing to see if it breaks any of those contrib modules. I agree that it seems not to make sense to someone who isn't familiar with the code and (my opinion) if the only thing that breaks is a bookmark to a certain page of results might come back differently, I'm not sure that's a deal breaker.