Use Full Page on Files View Page

Added tests, please review

The last submitted patch, 14: 3157557-14-tests-only.patch, failed testing. View results →

Ahmad Smhan → made their first commit to this issue’s fork.

Still needs upgrade path

Added upgrade path and test, please review

Removing credit for Ahmad Smhan for the empty commit.

For committer can file_update_10100 be updated file_update_101021

So, for a change like this there we should look at the history to see if there is a reason that the mini page was used. That should be done before working on a patch.

I decided to see if I could find some history. It took some time to find it because the file has moved several times. I finally found that the pager was changed from full to mini in this issue, #2049479: File usage views should be combined → . Comments #2 -> #6 is the relevant part about the full and mini pager. An error was pointed out in the mini pager and another issue was opened. Once that was fixed, the paged was changed to mini. There is not other discussion about why 'mini' was preferred.

The only question I see is the one in #20 for committers. I suggest that be asked in #contribute so more people can participate.

I did not adjust credit or look at the changes.

It looks like the views used in the admin UI have a mix of full pager and mini pager. I'm wondering if we have a specific strategy on how we have decided which one to use? The key difference between the full pager and the mini pager is that full pager may provide a better user experience, but is less performant than the mini pager. I think we should try to come up with a strategy on how we decide which pager to use for the admin views. I don't think we necessarily need to choose one or another if there are strong reasons to do so.

The mini pager might offer better performance per page, but when administrators have to click the 'Next' button 20 times, that added performance is overshadowed by inconvenience. In this scenario, prioritizing a good user experience becomes more crucial. We're considering administrators here, who constitute a small portion of the site's users. They would likely be willing to trade the negligible difference in performance per page for a smoother data access experience.

Sorry if my comment was unclear. I'm not against changing the Files view pager. 😅 I was trying to say that we may have other pages too that we should update to use the full pager. In order to do that, we need to decide which ones we want to update. I think a sensible default could be to use the full pager for all admin facing views, and use mini pager for front-end facing views.

+1 for defaulting all admin views to the Full pager

Just want to comment that

For sites with many files, a full pager is preferable

to me is false. The mini pager doesn't do a count query, hence it better performance and for really large data sets it is the only way to get your page to load.

when administrators have to click the 'Next' button 20 times

So to me, that use case is not something we should try to solve with a better pager, but with better filters

But since all sites start empty and people can update these views when needed, defaulting to the full pager seems logical.

Restoring status but opened 📌 Check if all admin views are using full pager Needs review for checking existing views. There may be no others and that could be closed but didn't fully check.

I recalled an old issue about slow to view file, #2610126: admin/content/files is slow with many files →

The last submitted patch, 14: 3157557-14.patch, failed testing. View results →

The last submitted patch, 14: 3157557-14.patch, failed testing. View results →

The last submitted patch, 14: 3157557-14.patch, failed testing. View results →

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

Hiding files and converted #18 to an MR.

Please do not credit me if I did not other wise earn it as all I did was convert this.

Restoring status

I'm not sure if having an upgrade path here is correct -- generally, once we install configuration like a view, the site owns it and can alter it, so we should no longer mess with it at that point. Asked for a second opinion.

xjm → credited larowlan → .

xjm → credited longwave → .

Discussed with @larowlan and @longwave. Let's remove the update hook implementation. New sites will get the updated view; existing sites can manually fix it if the admins like (unlike with actual data model changes). If we want, we can instead add a CR to inform site owners about the improvement so they can add it themselves. Thanks!

@tripurari Screenshots of the actual view would be more helpful than screenshots of the view configuration. :) That would illustrate the UX improvement.

The only reason not to make this change would be performance, but given that the content and comment listings already have pagers, it's fair for this to as well.

Saving issue credits.

Thanks everyone!