Pager should start counting from 1, not 0

I think we have two problems here.

1. One Problem is the logic of starting a count at 0 or at 1. This a kind of philosophical question and similar to counting floors which is handled different in different countries: http://en.wikipedia.org/wiki/Storey
When I started with drupal I was also confused by this. But this is something to learn. Maybe this could be optional but because of existing projects and a kind of upgrade path for content and content lists from drupal 7 to drupal 8 (in logic of bookmarks) I don't like a hard change in the URL logic of paging lists.

2. The other problem is a difference of what the URL and the pager is showing. This is really confusing. But because of problem 1 I think it's not the best way to solve this with changing the counting logic. I think it would be better to add the "page 0" logic to the pager.

We get regular client "bug" reports about this. I would love to have an option to just bump the number by one. Page 0 logic doesn't makes sense in my opinion. But I guess not everyone is the same ;)

AFTER reading the linked issues I don't think it's a good idea after all because there will be mismatch between core and views pagers.

@aspilicious: As I understand merlinofchaos and dawehner is views following the logic of the core. And since views is part of the core there would be no difference because any change of this (if we want to) has to be also a change of views.

Well, you could for sure use url outbounding and inbounding to change the URL if you like.

The question really is whether we should change that logic given that we still show node IDs for example.

Absolutely agree with @earnie's #5.

In terms of the disruption this would introduce, I added a note about changes to links to specific pages in the pager.

Starting to work on this.

Marked #294449: Match URL parameters to logical page numbers as duplicate of this issue

I'm not sure that this patch completely fixes the issue but that's a start.
I'll spend more time on this later. Please do not wait to start reviewing.

I've found that the common pager was used in the following places:
- all views pagers (easy to test on the defaut home page)
- user admin interface
- url aliases admin interface

I've found no automated tests and that include files does not seem to be tested anywhere so I'll probably need to ask out on #drupal-contribute if there is a way to automate tests on these functions or not.

Wow, this issue makes so much sense. Yes please, let's be nice to humans, not robots!

My patch was not working 7 months ago.
I think it's going to need a deep reroll before anything can be done.

There is no way that this could land in 8.0.x so I just changed the target version.
I'm not even sure it could be done in 8.x as it's probably going to break BC of some contrib modules.

I'm afraid this is even 9.x, unless we have a setting to make sure existing sites don't get this. Otherwise URLs would break…

If we could do at least #2044435: Convert pager.inc to a service in a 8.x minor, then contrib may override the pager service and do whatever. But yes, entire sites could break :) - it's not a setting that could be changed lightheartedly.

Triagging this for 9.x as mentioned in #22 and #23

I'm not surprised, but that is freaking infuriating. The issue by itself exemplifies how seriously Drupal people DON'T take usability, and the fact that this has been tagged d8ux for months and no one even checked it until it was too late shows it even more.

I blame myself for not agitating more about this, but it's really discouraging that such a horrible blemish is going to remain for three or four more years.

unless we have a setting to make sure existing sites don't get this. Otherwise URLs would break…

Back to 8.x.1.x-dev because of that.

#25: this is the kind of thing that is not noticed that often. And it's easy to get used to. If this would have gotten on my radar in 2013 or 2014, I totally would've pushed for this. We do care about usability. But the usability impact of this is far lower than that of other things. Software is never finished. We always need to prioritize things, and that means not doing certain things, unfortunately! :(

@75th Trombone you can totally help this type of thing get in to core. This needed to be completed, tested and set to RTBC. Even if you can't contribute with code you can bring it up in the #drupal-contribute or #drupal-usability channels and get attention to people that can help push this forward. Or look in core/MAINTAINERS.txt to see who to discuss this part of core with.

I 100% agree with what @Wim Leers said and thanks @Wim Leers for giving some hope for 8.1.x inclusion.

We do care but this is the first I've noticed this issue too and would have also tried to help get this in if I knew about it. I don't actively triage the "base system" component or usability tag because I've had my hands full with Twig. I just happened upon this while looking for WSCCI stuff.

Thanks for the encouragement, guys, and sorry I got upset for a minute — the prospect of waiting for a change for years made my stomach turn a bit. :)

I'll follow your advice as best I can, and thanks, @joelpittet, for pointing me to #drupal-usability, which I was unaware of!

Isn't this addressed here? https://www.drupal.org/node/385270

#30: yes that seems a duplicate of this one. Latest comments here are definitely fresher, though. Will add a reference to #385270: Make the GET page variable consistent with the real page number in the plan issue #2547833: Pager.inc -- add tests, clean it up, convert to a service, use it!, for completeness.

Whoops this shouldn't be postponed.

This could probably use Browser tests or Functional tests to ensure this isn't changed by accident.

I am not sure why having some URL is really adding usability. Who is seriously navigating using query parameters.

Note: For REST API you would certainly get confused by pagers starting with 1.

I am not sure why having some URL is really adding usability. Who is seriously navigating using query parameters.

I ranted a bit about the page number problem on the related issue

Note: For REST API you would certainly get confused by pagers starting with 1.

Agreed. The internal number should still be 0 for developers, but all user-facing displays (and the URL is a user-facing display) should start with 1.

@dawehner it's usability because it's visible to the end user in typically a prominent position (location bar) and indicates the page they are on, and is associated by the pager links for correlation and assurance. Also one reason why we have URL aliases in the same sense, it's user friendly.

Well, we cannot change the behaviour by default now. URLs point to those sites already, so changing those might break existing links out there in the wild.

Are there any update on this issue on Drupal8.x ?
Is the patch file from DuaelFr working with Drupal8 ?

Patch does not apply cleanly. But from the above comments, it seems this change might break some existing links.

I do not want to discourage people on this issue. If you can work out a way to not break URLs on existing sites, and is not burdensome to maintain, try it. See #2751325: All serialized values are strings, should be integers/booleans when appropriate for a similar compatibility situation.

Why not just add a setting to views to allow setting the starting index? The seems like a safer approach then trying to make a non breaking change.

This could be solved if we could turn the pager into a service as per #2547833: Pager.inc -- add tests, clean it up, convert to a service, use it!.

DuaelFr can you update your patch for Views please?

@neibo Sadly, no. My patch never worked and is really outdated so it would need a huge investment to make it work. Plus, as told in #47, there is some work in progress to convert pagers to services so they are going to be more manageables.

Any update on this?

I am trying to implement this in the contrib Pagerer module, see #3091945: Allow Pagerer to override the pager querystring part in URLs and count pages from 1, not 0. Reviews, tests, suggestions would be appreciated there.

Pagerer 8.x-2.0-beta1 now allows to change the index base from zero to one, still keeping compatibility with the standard format.

I'm taking a look at this feature from the perspective of 8.9.x because it's the version I'm currently working in.

I wanted to share my thoughts regarding the plan to see if anyone has feedback before I dig too far into this.

Does this make sense or is there a better place to put a Pager configuration setting since it doesn't only affect views?

• A checkbox in the Views > Settings > Advanced form with the label "Start pager index at 0".
• A new boolean configuration setting for views: pager_index_base_zero
• An update function in the views module that sets this config value to true, to protect existing sites.

The harder part is finding the right place to implement. If the setting is stored within the views module, I'm looking for a way to pass the configuration setting to the Pager service logic so that it will work as expected for views and using the Pager outside of views will also allow an optional base index setting.

I think this is a cool problem to solve, so I want to make sure I'm heading down the right path to increase the chances the patch will be merged.

Any update on this?

Thisis fixed ITMT.

The pager starts with 1, whereas the URL starts with 0.

This is still an issue as of the URL argument. Also involves every paging, not only views. Reopening.

I am triaging all pager issues. But need ot organize the first.
Since not all agree on the necessity, let's move this to Bug report, not Task,
And move to Views module, even though is is change din Database lib.

Not all pagers are in views, are you sure this issue is about the views pager?

There is mention for both core prayer and views it probably belongs in base.

Do you have an issue to discuss what your plan is for pagers?

At the moment it just seems like you are bulk renaming issues that have not been touched in years and have no patches or work.

If there is a planning issue it would be nice if you could link to it.

If not please create one and link to it, so we can discuss process.