Error when added to 404 pages

Hi @adrianopulz,
I have fixed this issue and also created MR for this issue . please replace The 'internal:/' URL is a reference to the internal path '/', which typically represents the homepage of your Drupal site. In other words, it's setting the fallback URL to the site's homepage.

Thank you!

Thanks for your fork @shreya_th!

The problem is for URLs created from the Request, URLs from the route will not be a problem. You added try/catch to the URL created from the route when the display['display_options']['path'] is set. We need the fallback only in the createFromRequest() call.

I've added a patch with the change example. I don't think we need to change the block of code using the UrlFromRoute.

What about other system paths?

That snippet of code has been removed in another fix. Can you confirm this is still an issue.

Hate to be reopening this issue, but the issue is still there using the latest 7.x release.

We worked around the issue for now by modifying the code to be as follows:

use Symfony\Component\Routing\Exception\ResourceNotFoundException;

protected function getExposedFormActionUrl(FormStateInterface $form_state): Url {
    $request = \Drupal::request();
    try {
      $url = Url::createFromRequest(clone $request);
      $url->setAbsolute();
      return $url;
    }
    catch (ResourceNotFoundException $e) {
      return Url::fromRoute('<front>')->setAbsolute();
    }
  }

A patch will follow, I expect this code needs some better attention.

Alex Bukach → made their first commit to this issue’s fork.

Created MR!86, here's the respective patch.

MR should be against 7.0.x but let’s add test coverage also

Could the steps be flushed out.

I added a view block that's used better exposed filters to 404 page and not getting any error.

On 10.3

I've got the same issue. I've defined a global "search" exposed form in block, which is added to the header of the website. Then on all 404 pages it shows the same error.

I've tried the patch in #12 and it went nicely, even if I'm still using the 6.x version. The patch fixed the issue, at least there is now no more errors.

smustgrave → closed merge request !49

Still needs step to reproduce fully or going to close out

We started seeing this issue recently with better_exposed_filters 6.0.6 after upgrading core

As with #15, we have an exposed search form in the header block which shows on all pages.

From our tests so far, the patch in #12 seems to fix the issue, but we will test further.

I've updated the steps to reproduce.

Let’s open an MR for 7.0.x and add a simple test case

Having tested further, it seems like the patch fixes the problem for logged-in users, but not anonymous.

With this patch included, we observed a strange issue where BEF checkboxes showed 0 instead of the expected markup.

In our case, this seems to relate to facets, as mentioned in #20

The mention of better_exposed_filters in the stack trace isn't the root of the problem for us.

When a facets block appears on a 404 page, it causes problems with URL generation.

I think that the appropriate fix relates to one of these issues:

#3291943: When rendering facets on non search page, it throws error instead of 404 on 404 pages →
🐛 ResourceNotFoundException with ajax facets when site running in subfolder Needs review

In \Drupal\facets\Plugin\Block\FacetBlock::build, if we add a condition to stop the block rendering on 404 pages, the problem goes away.

@idflood, @alex.bucach, @adrianopulaz, @johan den hollander - do the stack traces you see also mention facets?

Even with our patch to facets in place, we encountered this error again, although in a slightly odd scenario that came up via a penetration test, with some special characters in the URL.

Our search results page is at /search-content - the security scanner managed to trigger this exception at /search-content%22%3bexpr%20268409241%20-%2028291%3b%22?search= (and some other similar URLs).

When we apply the patch in #12, it addresses the issue.

The error mentioned in #21 seems to have been happening because we were using an incorrect patch for 🐛 Links with "Show hierarchy in dropdown" disabled gives "Deprecated function: range(): Passing null to parameter #1" Active

We have the same problem with global search block on core 10.2.* and better_exposed_filters 6.0.6. and patch #12 solves it. We also have facets but not the problems as reported by @malcomio.

So is this a facets issue?

I enabled the bef_test module which has a view with an exposed block.
I placed the block on every page
I visited some gibberish url
Got the 404 page not found and my block just fine.

7.0.x and 11.1.x

Sorry if I'm missing something just trying to replicate so I can merge and add test coverage.

The patch #12 does not work on pages with invalid route parameters, e.g. /node/[nid] for a non-existent node ID. Here's an updated patch (the PR !86 is updated respectively).

MR should be against 7.0.x

alex.bukach → changed the visibility of the branch 3396769-resource-not-found-7 to hidden.

alex.bukach → changed the visibility of the branch 3396769-resource-not-found-7 to active.

Good point, thanks @smustgrave, I have also created a MR!137 against 7.0.x. The patch in #27 works for both 6.x and 7.x.

Thanks! Think only thing now we will need is simple test coverage

And I can help with that but I for some reason can’t trigger the error

For tests

So really need steps to reproduce this, I generally can't replicate

Following up on steps to reproduce this. Don’t plan on merging without test coverage

So I'm tempted to close this one out as there doesn't seem to be clear steps to reproduce.

I was able to reproduce this issue using Better Exposed Filters 6.0.6 in combination with Facets Exposed Filter 3.0.0.

My scenario involves a Search API view configured for a global search, where the exposed filters are exposed as a block. One of these is a hidden facet exposed filter intended to filter by content type, visible only on the global search page. It seems this hidden facet exposed filter may trigger the issue because once I remove it the error is gone.

Patch #27 resolves the error for me.

I'm adding testing instructions and have an example spun up on Simplytest me:

https://master-uhi4uwa9bmelorwgegltd8a44czbxuul.tugboatqa.com/
https://master-uhi4uwa9bmelorwgegltd8a44czbxuul.tugboatqa.com/kljadsf

Since the patch solves the issue, I'd. usually set this to "Reviewed & tested by the community", but since the last maintainer request before the one for testing instructions was to add test coverage (in https://www.drupal.org/project/better_exposed_filters/issues/3396769#com... 🐛 Error when added to 404 pages Postponed: needs info ), I'll set to "Needs work"

The patch #27 fixes this issue for us as well. For us it is caused by the search404 → module.

Our bug:

1. Visit a non-existent page
2. Search404 suggests other pages (1+ of these must have an exposed form block on the page)
3. NodeSearch.php renders each result in isolation $rendered = $this->renderer->renderInIsolation($build);
4. This leads to getExposedFormActionUrl() trying to create a URL from the request, but that fails as the request is a non-existent page

The key part of the problem is having a view with an exposed form block on the 404 page (our view has "Exposed form in block:
Yes"). I have just tested without search404 and the issue still occurs (the patch still fixes it).

The exposed filter needs to be using the Links widget to trigger the error. This might be why you cannot recreate @smustgrave.
I am working on some tests now. Hopefully I will be able to upload tomorrow.

Rock on!

I have added a test to a new branch, but must have done the process wrong, as I cannot create an MR.
https://git.drupalcode.org/issue/better_exposed_filters-3396769/-/tree/3...

I am now thinking something like this would be better:

protected function getExposedFormActionUrl(FormStateInterface $form_state): Url {
    $request = \Drupal::request();
    try {
      $url = Url::createFromRequest(clone $request);
    }
    catch (MatchingRouteNotFoundException | ResourceNotFoundException | ParamNotConvertedException $e) {
      // If the route is not found or a route parameter is not valid,
      // fallback to the 404-page URL.
      $uri = \Drupal::configFactory()->get('system.site')->get('page.404') ?? $request->getRequestUri() ?? '<front>';
      $url = Url::fromUserInput($uri);
    }

    $url->setAbsolute();

    return $url;
  }

Otherwise the bef_links filter will take you to the homepage, instead of applying the filter on the 404 page as expected. This new way will redirect you to the 404 page and apply the filter (which is what all the other filter plugins do).

If so, then the tests should probably be expanded to make sure the BEF filters actually work on the 404 page.

Tests should be added to the main MR please.

smustgrave → closed merge request !86

Added test to the MR and cleaned up.