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.