Problem/Motivation

#1909474: Use light (lite) pager by default changed the default pager to use the mini pager, which doesn't have to do an expensive count() query.

However, most existing default views, like the frontpage, admin/content and so on still use the normal pager.

Proposed resolution

Change them to use the mini pager and update the exported default views.

Remaining tasks

User interface changes

API changes

Comments

dawehner’s picture

Issue tags: +Novice, +VDC

Some tags ...

anavarre’s picture

Status: Active » Needs review
StatusFileSize
new3.13 KB

In its most basic form, I *think* this is what we want to do here. But if all views are now using the mini pager, should tests continue to test for the full pager?

Status: Needs review » Needs work

The last submitted patch, 2: views_litepager.patch, failed testing.

berdir’s picture

We should have tests anyway for different pagers, I doubt those are using those views.

Yes, that's the basic change, but you need to make additional changes to the configuration of those as they have less/different options.

olli’s picture

I think we could also just drop the pager in feed displays (like the frontpage rss.xml and #2375773: Remove pager from default taxonomy term feed). Not sure about changing admin/* views to use the mini pager.

berdir’s picture

I'm pretty sure :)

I have 550k nodes, the normal pager executes a query that takes 1.5s+ (because of the join on the user table), by using the mini pager by default, the page is twice as fast.

Removing the pager completely from aggregator_rss_feed sounds like a good idea and just display a fixed amount of entries.

dawehner’s picture

We have both a mini pager and a normal full pager test, so as long we don't replace the usage of those:
'test_store_pager_settings', 'test_pager_none', 'test_pager_some', 'test_pager_full', 'test_view_pager_full_zero_items_per_page',
we should be fine.

I'm also fine to not switch over all test views in general, it doesn't give us any big advantage to do it.

Note: There is a RFC about paged feeds, see http://tools.ietf.org/html/rfc5005 but we don't provide support for that

For now we maybe should replace the pager from a limit of items per page.

anavarre’s picture

StatusFileSize
new6.56 KB

So, here's hopefully a better version to change from full to mini pager. No interdiff provided because there's nothing to really compare against.

I haven't yet addressed changes that haven't been confirmed for sure, such as no pager for aggregator_rss_feed or even replacing the mini pager by a fixed number of items.

anavarre’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 8: 2469157-7.patch, failed testing.

anavarre’s picture

Status: Needs work » Needs review
StatusFileSize
new8.06 KB
new1.38 KB

Making the tests pass by removing lines for the full pagers? Doesn't seem right to me :-/

What are we supposed to do here?

berdir’s picture

Strange, can we maybe switch that test to use one of the test views?

anavarre’s picture

StatusFileSize
new70.27 KB
new62.16 KB
new30.63 KB

@berdir: I'm sorry but I'm not sure I parsed what you said correctly or know what to do.

What I see is that we have PagerTest.php and MiniPagerTest.php and what is failing in PagerTest.php is that we no longer have a full pager to test against. This is why removing the corresponding lines as in #11 made the tests pass. See Simpletest verbose message screenshot below:

I did try to add the below line to add back the full pager only in the realm of the test:

$display['display_options']['pager']['type'] = 'full';

But this keeps throwing failed tests while we now have a full pager:

Note that the pager links, while being displayed in english, work fine when we remove the full pager lines. Odd since we're defining a 'nl' langcode.

In testPagerLocale() we do set the same langcode and the pager terms in NL are displayed/detected just fine.

dawehner’s picture

Status: Needs review » Needs work

So what I think we should do is to not replace that test, but rather have a test not using the default content view, but instead have a dedicated test for full pager view with configuration translation and a dedicated test for mini pager with config translation, so basically swap out the usage of the content view to custom test views.

Does that make sense?

jp.stacey’s picture

This still seems to be in the specification stage and I don't think it's currently suitable for novices. I'm therefore untagging it for now.

If the issue can be clearly scoped, and the issue summary updated with tasks, it could be suitable for novices again!

jp.stacey’s picture

Issue tags: +SprintWeekend2016

(Triaged as part of Sprint Weekend 2016.)

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

dkmishra’s picture

I have tried to apply patch #11 but it failed on drupal version 8.9.3.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.