The point of the field list at admin/reports/fields is to give a single overview of all fields on the site. For example, using my browser's find, I can cycle through all image fields, or find if a field with a particular name exists.

Except that because this list uses a pager, I can't: past a certain number of fields, they're not all visible at once.

This admin list shouldn't be using a pager: performance is not that important here as it's an admin page.

CommentFileSizeAuthor
#12 2726881-list-fields-no-limit.patch627 bytesjcisio

Comments

joachim created an issue. See original summary.

vinay15’s picture

vinay15
he/him
Primary language Marathi
Location Navi Mumbai
commented

Hi joachim,

Shouldn't this be in feature request or plan category? It is obviously not affecting any functionality. Let me know more about this.

Thanks,
Vinay

joachim’s picture

joachim commented

That page's help text says "This list shows all fields currently in use for easy reference."
Currently, it doesn't, and reference is not easy -- so that's a bug I think.

sagar ramgade’s picture

sagar ramgade commented

I think its better to provide filters like Field type, bundles and Show 'X' items per page rather than removing the pager. Allow users to select what they would like see and filter.

joachim’s picture

joachim commented

Filters would be nice, but I don't think adding filters means we shouldn't also remove the pager. And also that's rather changing the scope of this issue.

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

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now 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.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now 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.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now 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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now 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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now 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.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

jcisio’s picture

jcisio commented
Status: Active » Needs review
StatusFileSize
new 2726881-list-fields-no-limit.patch627 bytes

There is no input yet from the maintainers, but we can start with a simple patch.

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

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). 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.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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.

tanubansal’s picture

tanubansal commented

Tested #12, and its working fine on version 8 as well 9
This can be moved to RTBC

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Needs review » Reviewed & tested by the community

+1 to this, it's much easier to open the listing and use ctrl+F to find a field than it is to click through all the pages on even a medium sized site.

catch’s picture

catch
he/him
Primary language English
commented
Status: Reviewed & tested by the community » Needs review

General +1 to this but it would be useful to get an idea of memory usage for this page on a complex site (and compare it to another big page like admin/people/permissions) before and after the patch.

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

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

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

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

joachim’s picture

joachim commented
Status: Needs review » Reviewed & tested by the community

On a site with:

- 248 field.storage config files
- 476 field.field config files

I used https://www.drupal.org/project/memory_profiler to show maximum memory on the admin/reports/fields page.

Without patch: 32 MB - /en/admin/reports/fields
With patch: 26 MB - /en/admin/reports/fields

(And the admin/reports/dblog page is 32 MB)

I suspect that the way that config is queried from the DB means that all of them are getting loaded anyway.

Based on that result, I'm setting back to RTBC.

catch’s picture

catch
he/him
Primary language English
commented

@joachim seems a bit odd that the patch would cause less memory usage rather than more, can you confirm you hit the pages a few times each before checking the memory limit to rule out cold caches? Or maybe we're saving some from having the pager itself, but can't think how.

joachim’s picture

joachim commented

Multiple reloads of the page without the patch show a range of values, from most recent:

12 MB - /en/admin/reports/fields
8 MB - /en/admin/reports/fields
12 MB - /en/admin/reports/fields
14 MB - /en/admin/reports/fields
26 MB - /en/admin/reports/fields -- that one was probably a cache warm up

With the patch:

30 MB - /en/admin/reports/fields
12 MB - /en/admin/reports/fields
22 MB - /en/admin/reports/fields
10 MB - /en/admin/reports/fields

In conclusion, computers are weird.

catch’s picture

catch
he/him
Primary language English
commented
Status: Reviewed & tested by the community » Fixed

lol yes. Well from those numbers the worst case looks 4mb larger, and the best case looks 2mb larger, which is more inline with what I'd expect.

Given this is an admin-only page, and if a site has memory limit trouble from the number of fields, they'll probably have it on a different page first, I think that's fine.

Committed a6ee84d and pushed to 9.3.x. Thanks!

  • catch committed a6ee84d on 9.3.x 
    Issue #2726881 by jcisio, joachim: Remove pager from admin field list
catch’s picture

catch
he/him
Primary language English
commented

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.