Add exposed filters and sorts to field list report

Every time I use the field report, I think to myself exactly this issue. Glad it’s in the works.

I have added filters for entity type and field type. I tried to add sorting functionality in getEntityIds() of FieldStorageConfigListBuilder but seems like QueryInterface tableSort doesn't work with this type of entities.

Previous patch is wrong.
I have fixed it and updated it to the latest version of core 8.8.x-dev

I have added new patch with small fixes of code standards.

@andypost could you clarify what should be done in scope of tag needs change record ?

@artemboiko That's a way to announce changes https://www.drupal.org/contributor-tasks/draft-change-record
So when patch commited everyone will get notification

Also more about tags you can find in Issue tags description in sidebar block about issue state

Interdiffs for:

1. #5 and #8
2. #8 and #10

Thanx @voleger.

I've updated tests for checking that two form elements with needed options are exist. And I've added code for testing submit form and filtering of results. Also, I've created change record.
Pls review @andypost @colan.

What is the next step?

1. +++ b/core/modules/field_ui/src/Form/FieldConfigListForm.php
   @@ -0,0 +1,182 @@
   +  /**
   +   * Build entity types options for select list.
   +   *
   +   * @param array $fieldStorageConfigs
   +   *   The array of field storage configs.
   +   *
   +   * @return array
   +   *   The array of options.
   +   */
   

   To improve DX change the type of the parameter from the array to <ProperInterface>[].
   Also, update return type of the method from array to string[] to show the type of the elements of the array.

2. +++ b/core/modules/field_ui/src/FieldStorageConfigListBuilder.php
   @@ -136,4 +136,50 @@ class FieldStorageConfigListBuilder extends ConfigEntityListBuilder {
   +  /**
   +   * Loads entity IDs using a pager sorted by the entity id.
   +   *
   +   * @return array
   +   *   An array of entity IDs.
   +   */
   

   The same as 1.

3. +++ b/core/modules/field_ui/src/Form/FieldConfigListForm.php
   @@ -0,0 +1,182 @@
   +  /**
   +   * Build field types options for select list.
   +   *
   +   * @param array $fieldStorageConfigs
   +   *   The array of field storage configs.
   +   *
   +   * @return array
   +   *   The array of options.
   +   */
   

   The same as 1.

Thanx @voleger.
Added this changes.

Much better, set to RTBC

@colan
Yes It would be great and I investigated it.

But views designed to work with entities and their database table. I mean user entity has it’s own table in db. In our case field_storage_config is stored in one table with other configs. So for implementing it with views we need to write tons of harcode. And I am not sure that it will work right.

Correct me if I am wrong.

@colan Nice idea, there was 2 attempts to add additional backends for config entities
- https://www.drupal.org/project/efq_views
- https://www.drupal.org/project/config_views

Sadly both looks forgotten so at this stage we can just improve UI a bit by hardcoding filters into list builder

1. +++ b/core/modules/field_ui/field_ui.routing.yml
   @@ -1,7 +1,7 @@
   -    _entity_list: 'field_storage_config'
   +    _form: '\Drupal\field_ui\Form\FieldConfigListForm'
   

   in summary not clear why list_builder no longer used and new form object added

2. +++ b/core/modules/field_ui/src/Form/FieldConfigListForm.php
   @@ -0,0 +1,182 @@
   + * Implements an example form.
   ...
   +class FieldConfigListForm extends FormBase {
   

   docs

3. +++ b/core/modules/field_ui/src/Form/FieldConfigListForm.php
   @@ -0,0 +1,182 @@
   +  public function getFormId() {
   +    return 'field_config_list_form';
   

   why it is not list builder like "draggable" one we have for vocabularies

@andypost please check, I have added form to the list_builder.

Looks great, but now a question of tests!
Views integration needs separate issue, I bet one exists in efq/config-views contrib

Closed #3054321: Filters on top of the field list report page. as a duplicate issue.

Has anyone applied this to 8.8?

I have applied patch #17, It's working for me.
I am attaching a screenshot after applying a patch.

Rerolled from #27

Re-rolling patch against 9.1.x-dev , kindly review a patch.

Another re-roll. Also addressing failed test cases, handling deprecations and fixing some CS issues

The above patch works fine ,it creates two select box filters Entity type , Field type and also the filters works fine.
Before patch

After patch

RTBC

#39 is still failing tests.

We should open a follow-up for views support and conversion, looks like https://www.drupal.org/project/config_views has some work towards this.

Resolving rest of the deprecations

FYI I was not able to use patch #43 with D9.2.1
Composer failed with
Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2020-12-18/2959299-43.patch

Then I tried to patch it manually:
patching file core/modules/field_ui/src/FieldStorageConfigListBuilder.php
Hunk #4 succeeded at 90 with fuzz 2 (offset 2 lines).
Hunk #5 succeeded at 113 (offset 2 lines).
Hunk #6 succeeded at 193 (offset 2 lines).
patching file core/modules/field_ui/tests/src/Functional/ManageFieldsFunctionalTest.php
Hunk #1 FAILED at 752.
1 out of 1 hunk FAILED -- saving rejects to file core/modules/field_ui/tests/src/Functional/ManageFieldsFunctionalTest.php.rej

Thanks

Applied patch #10 working fine and applied successfully
After patch file exposed filters added successfully
Thanks for the patch ....

Patch #43 fails to apply for Drupal 10.1.x

This might not be as configurable as a view would be, but it will already help a lot with sitebuilding and with checking module upgrades, by reducing the very long list of fields on more complex sites.

This page is not used by content editor etc. on a production site, but purely a reference used in the development and maintenance of the site, so adding these filters is not breaking any customized functionality.

@vikashsoni why did you test #10?

Seems issue is being addressed in MR but have CI failures

Hiding files to avoid confusion and noise.

This is looking good to me and works as expected, however I don't know enough to mark it RTBC.

With the latest commit passing, I'll set it to needs review for now.

Before:

After:

Left some comments on the MR.

Also the CR will need some updates.

Added tests for form elements and filtering functionality by submit of form.

don't think that needs to be included in the CR.

CR doesn't mention the new parameter needed.

CR could use some before/after screenshots.

I'm happy to continue working on this. But what is "CR"?

CR ist change record, the way to add it is https://www.drupal.org/node/add/changenotice?field_project=3060&field_is...