Filter on module description (module_filter)

In addition to filtering on description on the modules page, it would also be good to filter on permission text on the permissions page. Currently, entering 'admin' shows no permissions at all. This is becuase there are no permissions for a module with 'admin' in the name.

Updated the issue summary to only use core modules in the examples, to make it simpler for others to test and verify.

Tested the MR and it works exactly as required, using my STR in the issue summary. Perfect! what a simple solution. Proof in the attached screen grab

Can this also get ported back to 8.x-3.x?

I have also created #3331723: Filter permissions on description not just module name to investigate the equivalent filtering on the permission description

Before you commit, I will try to write a functional test to prove the changes work.

We have so few tests, but hard to know where to start. #3328058: Expand the phpunit test coverage for module_filter Maybe when we make any code changes, we can consider adding test coverage for that at the time of the change.

First draft of a javascript test to cover the filtering. Adding this as a patch, so that it can run without the changes in the MR. It should therefore fail.

That's good. I have added a javascript test for the uninstall page too. This is not working locally (I have not discovered why, as it is virtually the same as the install test) but adding it here to see if drupalci runs it better. This patch will fail, of course.

Fixed it. It's a bug in core, I will update more tomorrow.

The problem with the uninstall page test not working correctly is that the core uninstall form fails to add $form['#attached']['library'][] = 'core/drupal.tableresponsive';, whereas this is added to the install form. My guess is that interactively it is still working because some other process is covering it, but in the pared-down javascript test that missing library causes the filtering to simply not work. I will raise a core issue for that, then we can patch the core file via drupalci so that the module filter tests can run.

Kinda still leaning on removing though as I can't see any added benefit that isn't already there.

Well, yes I was wondering what that filter was giving us. But I have found a second core bug, which may have been the the reason why that filter on uninstall was added to this module. Core allows filtering on the description, but it ignores the first word of the description text and only filters on the remaining text. The module filter does it correctly and uses the full description text. Same bug on the install and uninstall pages. For example, enter 'provides' using the core filter (module filter not enabled) and you get two or three core modules. With module filter enabled you get 14 core modules. The extras all have 'Provides' as the first word.

So we can raise a core issue for this too, and until it is fixed we keep the properly working filter in this module. I will update the MR with changes I made, and get the tests passing here.

I have raised #3331975: Uninstall form does not add drupal.tableresponsive library and uploaded a patch which I'll use here to demonstrate that the tests now pass. Also uploaded screen recordings of the failing and passing javascript tests.

ha ha, the test failed because I had suppress-deprecations: false in drupalci.yml and the tracker module used in the test is deprecated!

Remaining self deprecation notices (1)
  1x: The module 'tracker' is deprecated. See https://www.drupal.org/about/core/policies/core-change-policies/deprecated-and-obsolete-modules-and-themes#s-activity-tracker

Could simply change to suppress-deprecations: true as this was obviously the default before I added the drupalci.yml file. But in future we may want to run with deprecations not suppressed, at least temporarily. So I will find another module to use in the tests which has a module displayed name which does not appear in the machine name nor in the description.

Changed to use the non-deprecated page_cache module, and updated the issue summary.

Also linked to the core issue which may add machine name to the uninstall page.

So, the new addition of Block passes at 9.5 (which is what I was using locally to write the test) but fails at D10, in both tests. The Block module is available, as shown by the fact that the text is found at the start of the test. All other filtering is working. The generated html from drupal.org does not really help, as that is fixed. Going to get phpunit running locally on D10 to debug this.

The tests pass locally and on d.o. at core 9.5 and 10.0 but fail at 10.1. Going to get phpunit javascript running on 10.1 locally to see what is going on.

Simple answer - Block module changed its description between 10.0 and 10.1. I will use a different module.

Or to prevent this in future we could create test modules within the project.

Tests pass at 9.5 and 10.0 and 10.1. Ready for your review.

In answer my own question in #22

Or to prevent this in future we could create test modules within the project.

I have created three test modules and changed the tests, so that we are immune to any core chnages. The modules can be expanded when we add more testing, such as adding permissions. It's better this way.

Edit title to make it distinct, when linking to other issues on the same problem.