Closed (fixed)
Project:
Drupal core
Version:
11.x-dev
Component:
search.module
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
5 May 2026 at 06:21 UTC
Updated:
11 Aug 2026 at 21:20 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #3
quietone commentedFix Drupal\Tests\search\Functional\GenericTest::testModuleGenericIssues. The error is related to routes but I am not sure what the proper fix is. Anyone?
Comment #4
quietone commentedAdding more detail for the error.
PHPUnit
browser output
The route search.view is used in search.links.menu.yml. It is setup in \Drupal\search\Routing\SearchPageRoutes::routes() but only if there there is a defined default search page. For some reason there is no default search page.
Comment #6
gábor hojtsyI researched this with LLM assistance.
The problem seems to be that
core/modules/user/src/Plugin/Search/UserSearch.phpattempts to extend theDrupal\search_user\Plugin\Search\SearchUserclass without requiring that module. I pushed a temporary attempt to conditionally define the class only if the base class is available (since the user module should not depend on thesearch_usermodule).Why is the
UserSearchplugin not in thesearch_usermodule?Comment #7
gábor hojtsyI see it is kept for BC. Is keeping the
UserSearchplugin in user module (where it is) an API?Comment #8
gábor hojtsyThe
search.viewproblem is that the route is defined as disabled by default. Thencore/modules/search/src/Routing/SearchPageRoutes.phpmakes it work if there was a default search provider. But in the test there is no search provider by default, so the link does not work in the help hook.I proposed a fix with conditional help text based on whether the route exists. I'm not sure the text is good now, that needs more review, but this passes the text for me locally.
(Analysis was LLM assisted).
Comment #9
gábor hojtsyOnly test that seems to fail is search update test not finding the dump file. The dump file is there though, and it passes fine locally even. I've also seen the same test pass on CI without modifying anything around it. However now it failed in several times in a row on CI. I am out of ideas on that. Why is this failing on CI and passing locally when it is about a location of a dump file?!
Comment #10
quietone commentedI did a bit of a tidy on the recent changes. I removed the getting the route provider only because I found it easier to read without separating out a part of a paragraph.
Adding a try/catch in hook help for the case when the route search.view doesn't exists works for this case. But what of the uses of the route in contrib?
Would it be better to go to a page with a message like 'no search pages available'?
Comment #11
gábor hojtsyMaybe for admins? I don't think its good for anonymous visitors to see a page with this. While there are many ways to fingerprint Drupal, I would generally avoid adding more such pages :)
Comment #12
smustgrave commentedSo only open question is if core/modules/user/src/Plugin/Search/UserSearch.php needs a CR or can point to the search module being deprecated.
Comment #13
smustgrave commentedTalked to catch and he mentioned a CR so I went ahead and added a simple one and added it inline to the MR. Rest LGTM.
Comment #14
catchNeeds another rebase.
Comment #15
quietone commentedThe following FuncationalJavascript test failed but, by the names, they are not related.
Setting to needs review because of the change to the update hook and the update test.
Comment #16
dcam commentedI hadn't ever reviewed this MR before, so I did a complete review. I found a couple of issues and left comments for them.
Comment #17
quietone commented@dcam, thanks for the review.
I updated the MR per the suggestions from @dcam. There are 2 failing random tests.
Comment #18
dcam commentedMy feedback was addressed. All MR comment threads have been resolved. It looks good to me.
Comment #19
quietone commentedPostponing until #3587564: Move search functionality from node to Search module is sorted.
Comment #20
gábor hojtsy#3587564: Move search functionality from node to Search module landed on main. I assume this needs the same search index update logic now.
Comment #21
quietone commentedComment #22
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #23
quietone commentedThe test failures are unrelated,
Settings Tray Block Form (Drupal\Tests\settings_tray\FunctionalJavascript\SettingsTrayBlockForm)
Layout Builder Disable Interactions (Drupal\Tests\layout_builder\FunctionalJavascript\LayoutBuilderDisableInteractions)
Comment #24
quietone commentedComment #25
dcam commentedI found an issue with the update function name. It looks like it was copied as-is from the Search module.
Comment #26
quietone commented@dcam, thanks I have fixed that.
I also looked further into the failing tests and they are related. They both enable the search module. I had thought all the tests were taken care of but clearly these were missed. They will need a separate issue.
Comment #27
quietone commentedComment #28
smustgrave commentedBoth JS failures seem unrelated to this change. #26 not sure the issue this was referring to when postponed, could we link? But know there were some issues in 11.4 around the search sub-modules that have since been resolved, #3608912: Move search updates back to search module and fix missing plugin errors. So believe this one is good to go
Comment #29
catchPretty sure the plugin deprecation won't work.
We need the plugin to be available before the update runs, but before it runs search_user won't exist - it can't inherit from the new module.
Also it either needs to have the the plugin attribute itself so that it's discovered.
With node and help we had the advantage that the new search modules were alphabetically later so that module precedence meant the new plugin would win if both were available. This isn't the case with user so probably something somewhere is going to need to alter to make sure the right plugin is picked up when search_user is enabled.
Comment #30
quietone commentedA bit of local testing and this seems to work.
Comment #31
dcam commentedIt's working for me. Starting from a clean install I enabled the Search module and then visited
/search/user. I applied the MR and cleared the cache without updating the database. Access was forbidden, which I expected due to the updatedaccess()function in the original Search module's plugin. Afterward I ran the database updates which executed without any issue. I then refreshed the user search page again. Access was restored. There were no errors throughout the process.I'm not sure if there was a better way to test this. But it looks good to me.
Comment #33
catchThe alter looks right to me, hopefully we'll get some manual testing of this prior to 11.5.0 on real sites.
Committed/pushed to main and 11.x, thanks! I rebuilt the phpstan baseline locally for the 11.x commit.
Comment #36
godotislateI think this broke 11.x. https://git.drupalcode.org/project/drupal/-/pipelines/901959
Comment #38
larowlanDiscussed with @godotislate and decided revert was cleanest approach
Comment #39
quietone commentedThe test failures are in
The first is a known random failure. The other two pass tests locally for me on 11.x
Comment #41
catchThis is also a known random test failure, although I committed a fix for it an hour or so ago. Would be good to fully rule out the migrate one though given that's search related. Let's open an 11.x backport MR and see whether we get a green run on CI?
Comment #43
quietone commented#39 is wrong. I didn't realize it, but I was on 11.x HEAD, with the revert.
I've made an MR for 11.x with a fix for d7/MigrateSearchPageTest. The only failing test is core/modules/settings_tray/tests/src/FunctionalJavascript/SettingsTrayBlockFormTest.php.
Comment #44
quietone commentedComment #45
dcam commentedThe test failure on GitLab CI is another known, intermittent failure.
The only difference between the 11.x MR and what went into main is the addition of the changes to
MigrateSearchPageTest. These changes are limited to enabling and installing config fromsearch_user. I verified that they're all necessary and fix legitimate test failures. The backport looks good.Comment #47
larowlanCommitted and pushed 97a38a4c825 to 11.x. Thanks!