Problem/Motivation

There is search functionality from the Search module in User.

Steps to reproduce

Proposed resolution

Remaining tasks

Postponed on #3587564: Move search functionality from node to Search module

Fix Drupal\Tests\search\Functional\GenericTest::testModuleGenericIssues
Review

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3588379

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

quietone created an issue. See original summary.

quietone’s picture

Issue summary: View changes
Status: Active » Needs work

Fix Drupal\Tests\search\Functional\GenericTest::testModuleGenericIssues. The error is related to routes but I am not sure what the proper fix is. Anyone?

Symfony\Component\Routing\Exception\RouteNotFoundException: Route "search.view" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 214 of core/lib/Drupal/Core/Routing/RouteProvider.php).

Drupal\Core\Routing\UrlGenerator->getRoute() (Line: 281)
quietone’s picture

Adding more detail for the error.

PHPUnit

1) Drupal\Tests\search\Functional\GenericTest::testModuleGenericIssues
Behat\Mink\Exception\ExpectationException: Current response status code is 500, but 200 expected.

/var/www/html/vendor/behat/mink/src/WebAssert.php:888
/var/www/html/vendor/behat/mink/src/WebAssert.php:145
/var/www/html/core/modules/system/tests/src/Functional/Module/GenericModuleTestBase.php:79
/var/www/html/core/modules/system/tests/src/Functional/Module/GenericModuleTestBase.php:50


browser output

The website encountered an unexpected error. Try again later.

Symfony\Component\Routing\Exception\RouteNotFoundException: Route "search.view" does not exist. in Drupal\Core\Routing\RouteProvider->getRouteByName() (line 214 of core/lib/Drupal/Core/Routing/RouteProvider.php).

Drupal\Core\Routing\UrlGenerator->getRoute() (Line: 281)
Drupal\Core\Routing\UrlGenerator->generateFromRoute() (Line: 105)
Drupal\Core\Render\MetadataBubblingUrlGenerator->generateFromRoute() (Line: 776)
Drupal\Core\Url->toString() (Line: 33)
Drupal\search\Hook\SearchHooks->help() (Line: 301)
Drupal\Core\Extension\ModuleHandler->invoke() (Line: 119)
Drupal\help\Controller\HelpController->helpPage()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->{closure:Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::wrapControllerExecutionInRenderContext():121}() (Line: 619)
Drupal\Core\Render\Renderer::{closure:Drupal\Core\Render\Renderer::executeInRenderContext():619}()
Fiber->start() (Line: 620)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->{closure:Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber::onController():96}() (Line: 183)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 36)
Drupal\Core\Test\StackMiddleware\TestWaitTerminateMiddleware->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 30)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 199)
Drupal\page_cache\StackMiddleware\PageCache->fetch() (Line: 136)
Drupal\page_cache\StackMiddleware\PageCache->lookup() (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 61)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 54)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 753)
Drupal\Core\DrupalKernel->handle() (Line: 19)

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.

gábor hojtsy made their first commit to this issue’s fork.

gábor hojtsy’s picture

Status: Needs work » Needs review

I researched this with LLM assistance.

The problem seems to be that core/modules/user/src/Plugin/Search/UserSearch.php attempts to extend the Drupal\search_user\Plugin\Search\SearchUser class 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 the search_user module).

Why is the UserSearch plugin not in the search_user module?

gábor hojtsy’s picture

I see it is kept for BC. Is keeping the UserSearch plugin in user module (where it is) an API?

gábor hojtsy’s picture

The search.view problem is that the route is defined as disabled by default. Then core/modules/search/src/Routing/SearchPageRoutes.php makes 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).

gábor hojtsy’s picture

Only 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?!

quietone’s picture

I 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'?

gábor hojtsy’s picture

Would it be better to go to a page with a message like 'no search pages available'?

Maybe 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 :)

smustgrave’s picture

So 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.

smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Talked 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.

catch’s picture

Status: Reviewed & tested by the community » Needs work

Needs another rebase.

quietone’s picture

Status: Needs work » Needs review

The following FuncationalJavascript test failed but, by the names, they are not related.

  1. MediaLinkabilityTest::testWithEntityLinkSuggestions
  2. SettingsTrayBlockFormTest::testBlocks
  3. LayoutBuilderDisableInteractionsTest::testFormsLinksDisabled

Setting to needs review because of the change to the update hook and the update test.

dcam’s picture

Status: Needs review » Needs work

I hadn't ever reviewed this MR before, so I did a complete review. I found a couple of issues and left comments for them.

quietone’s picture

Status: Needs work » Needs review

@dcam, thanks for the review.

I updated the MR per the suggestions from @dcam. There are 2 failing random tests.

  • SettingsTrayBlockFormTest::testBlocks
  • LayoutBuilderDisableInteractionsTest::testFormsLinksDisabled
dcam’s picture

Status: Needs review » Reviewed & tested by the community

My feedback was addressed. All MR comment threads have been resolved. It looks good to me.

quietone’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Postponed
gábor hojtsy’s picture

Status: Postponed » Needs work

#3587564: Move search functionality from node to Search module landed on main. I assume this needs the same search index update logic now.

quietone’s picture

Status: Needs work » Needs review
needs-review-queue-bot’s picture

Status: Needs review » Needs work
StatusFileSize
new1.31 KB

The 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.

quietone’s picture

Status: Needs work » Needs review

The test failures are unrelated,
Settings Tray Block Form (Drupal\Tests\settings_tray\FunctionalJavascript\SettingsTrayBlockForm)
Layout Builder Disable Interactions (Drupal\Tests\layout_builder\FunctionalJavascript\LayoutBuilderDisableInteractions)

quietone’s picture

dcam’s picture

Status: Needs review » Needs work

I found an issue with the update function name. It looks like it was copied as-is from the Search module.

quietone’s picture

Status: Needs work » Postponed

@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.

quietone’s picture

Status: Postponed » Needs review
smustgrave’s picture

Status: Needs review » Reviewed & tested by the community

Both 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

catch’s picture

Status: Reviewed & tested by the community » Needs work

Pretty 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.

quietone’s picture

Status: Needs work » Needs review

A bit of local testing and this seems to work.

dcam’s picture

Status: Needs review » Reviewed & tested by the community

It'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 updated access() 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.

  • catch committed dc2a1d8d on 11.x
    task: #3588379 Move search from user module to Search
    
    By: quietone
    By:...
catch’s picture

Version: main » 11.x-dev
Status: Reviewed & tested by the community » Fixed

The 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.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

  • catch committed d97ade05 on main
    task: #3588379 Move search from user module to Search
    
    By: quietone
    By:...
godotislate’s picture

Status: Fixed » Needs work

  • larowlan committed c4a180b9 on 11.x
    Revert "task: #3588379 Move search from user module to Search"
    
    This...
larowlan’s picture

Discussed with @godotislate and decided revert was cleanest approach

quietone’s picture

The test failures are in

  • core/modules/settings_tray/tests/src/FunctionalJavascript/SettingsTrayBlockFormTest.php
  • core/modules/search/tests/src/Kernel/Migrate/d7/MigrateSearchPageTest.php
  • core/tests/Drupal/KernelTests/KernelTestHttpRequestTest.php

The first is a known random failure. The other two pass tests locally for me on 11.x

catch’s picture

KernelTestHttpRequestTest

This 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?

quietone’s picture

#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.

quietone’s picture

Status: Needs work » Needs review
dcam’s picture

Status: Needs review » Reviewed & tested by the community

The 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 from search_user. I verified that they're all necessary and fix legitimate test failures. The backport looks good.

  • larowlan committed 0c28f882 on 11.x
    task: #3588379 Move search from user module to Search
    
    By: quietone
    By:...
larowlan’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed 97a38a4c825 to 11.x. Thanks!

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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