Using the module filter on the module list page a module can only be found by system name if the description ends with a period

This is still an error in 10.1. The javascript has changed but the fault was replicated.
@kingdutch - this issue is assigned to you. Would you like to work on it? If not then I will.

I ran into this as well, coming from 📌 Add optional parameter to Nightwatch drupalInstallModule command to enable module dependencies Fixed .

New patch, so no interdiff. Test-only, then test + fix.

Updating the issue summary a bit.

I want to add that we could certainly add a test module that is dedicated to testing this type of case, and I can do so if requested rather than arbitrarily using comment_base_field_test.

The last submitted patch, 16: core-2978498-16-testonly.patch, failed testing. View results →

Verified the issue by removing the period from the description of dblog
Searching for dblog didn't return anything.

Apply patch
Searching for dblog returns the module even without a period at the end of the description.

Now that this is marked as RTBC there's a flag by the test-only patch saying it will be retested every two days. But that's not going to help anything, as we know it fails (by design). So I'm hiding that patch, just to see if the good one gets tagged with automated retesting instead.

Thanks for the fix @Cottser. Happy to see you in the queues again! 👋😊

Committed 753eef8 and pushed to 10.1.x. Thanks!

Thanks for the commit. Would you consider backporting to 9.x? This is such a simple fix to make and I'd be happy to do a MR with the same changes if no one else wants to? (can't be cherry-picked directly because the js file is very slightly different)

I didn't originally backport this because I thought there could be a small risk of some Nightwatch tests failing in contrib because this might make modules visible in the searches that weren't visible before. That said, I don't think this is huge risk and there aren't that many contributed modules using Nightwatch. Based on that, I think we could backport this.

Adding patch for 9.5.x

@Rishabh Vishwakarma I had just created a new issue branch and was working on this. The implication from #24 was that I would do this work unless someone volunteered. So I have just wasted my time now. I guess I should have assigned this issue to myself before starting it. Or you should have.

Re-rolled patch #16, for 9.5.x

@jonathan1055 what MR? If there is one we should be doing the fix there.

Patch #28 dropped the test cases.

Patch #28 dropped the test cases.

We don't have test case file in 9.5.x core/modules/system/tests/src/FunctionalJavascript/ModuleFilterTest.php

We don't have test case file in 9.5.x core/modules/system/tests/src/FunctionalJavascript/ModuleFilterTest.php

That's correct, and it is what I was doing as a follow-up to #24 and #25 when the new patch was uploaded in #26. I had created the issue branch and was working locally but had not pushed it up to d.o. so not made a MR yet. But I stopped work when I thought that @Rishabh Vishwakarma was taking on the tasks.

Also, just a quick question for @Gauravvvv, patch #28 is not precisely a re-roll of #16.
In #16 the change for core/modules/system/js/system.modules.js has

           sources.forEach((item) => {
-            sourcesConcat += item.textContent;
+            sourcesConcat += ` ${item.textContent}`;
           });

but in patch #28 this is became

           sources.forEach(function (item) {
-            sourcesConcat += item.textContent;
+            sourcesConcat += " ".concat(item.textContent);
           });
 

There may be a good reason for this, but I just want to know. We should aim to keep 9.x code in line with 10.x code where possible as that makes future maintainance and backporting easier.

Also, just a quick question for @Gauravvvv, patch #28 is not precisely a re-roll of #16.
In #16 the change for core/modules/system/js/system.modules.js has

I have not made any chnages manually into core/modules/system/js/system.modules.js file. All these changes are compiled by yarn.

Also both of these lines of code achieve the same result, which is concatenating a space character and the text content of the item variable to the sourcesConcat variable