Parameter "arg_0" must match "[^/]++"

Patch did also the job for me. Issue triggered using views_field_view module 1.0-beta5 and drupal 9.5.2

I am able to reproduce the issue with the attached view in the patch.
- Added a simple test case to visit the page after placing block with an appropriate view.
- Updated issue summary.
- Test case that i wrote is passing with the fix and failing on latest 10.1.x head. However, I have doubt that it might crease regreation.

I also noticed one more error when there is null argument

messageDeprecated function: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 204 of core/lib/Drupal/Core/Routing/UrlGenerator.php).

For now, I've added a check to ensure that it is not null.

Let's see how it goes for other test cases

The last submitted patch, 16: test-only-3239685-16.patch, failed testing. View results →

Removing test tag as #16 added them and shows they are covering the issue.

Reviewing the code fix and seems fine but will ask the committer

catch (InvalidParameterException $e) {

Should we log the exception?

Triaging the RTBC queue.

The first thing I notice is that the issue title isn't telling us what is being fixed here. Setting to NW for an issue title that tells us what is being fixed so it will make sense in 5 years when searching the git log.

I then see that the issue summary look complete. The remaining task states, 'Further community discussion about possible solution approach.' I then read the comments but I do not see any discussion on the solution. Leaving that in the remaining tasks.

Since I have some time, I looked at the patch. I applied it and played with the test. I discovered that this is about a deprecation relating to preg_match. That means, that the changes to ViewsExposedForm may not be neeeded. And indeed, when I remove those changes the test still passes.

So, instead of passing 'bad' data to preg_match can this be fixed in views? And further, is it possible to use a Kernel test instead of a Functional test.

Came across this pair of errors today on a Drupal 9.5.9 install and wanted to shed more light on when these errors were triggered and how I stopped them with no patches.

1. Create a view and configure a block with contextual filter (user/author of content to display, in my case).
2. Add this block to the user "view" page using Layout Builder
3. Load user page without issue
4. Add a page to the existing view with a path wildcard
5. Saving view triggers preg_match error and when trying to load user page and get the "parameter 'arg_0'" error with WSOD.
6. Changing how the dynamic value is found between user from route or raw value from URL (in contextual filter settings) does not fix anything, but removing the wildcard from the path fixes the errors temporarily

The fix was to remove the block from Layout Builder and then add back the dynamic path to the page. Luckily I don't need the block, but the block seems to be fully out of commission now, as I cannot add it back to the Layout Builder view and trying to silently triggers the preg_match error.

So it makes me wonder, even though the error is indeed a deprecation in preg_match, why is the second parameter empty? This block was working just fine before I added the page to the view, and the dynamic page is also working fine once I removed the block, so it seems there might be some other strange behavior taking place? Still pretty new to all the changes from D7, so hopefully this is helpful.

In my case, this error : Symfony\Component\Routing\Exception\InvalidParameterException: Parameter "arg_0" for route (view name) must match "[^/]++" ("/" given) to generate a corresponding URL. in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 203 of core/lib/Drupal/Core/Routing/UrlGenerator.php).

appears only when "Glossary mode" is activated on Views + Page + Block activated (Contextual filters parameters)

D9 / PHP 8.0 / Drupal Commerce

All current issues need to target 11.x, and then they will be backported.

https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-... →

The relevant code after the changes is this:

          if ($mergedParams[$token[3]] !== NULL && !preg_match('#^' . $token[2] . '$#', $mergedParams[$token[3]])) {
            $message = sprintf('Parameter "%s" for route "%s" must match "%s" ("%s" given) to generate a corresponding URL.', $token[3], $name, $token[2], $mergedParams[$token[3]]);
            throw new InvalidParameterException($message);
          }

          $url = $token[1] . $mergedParams[$token[3]] . $url;

$mergedParams[$token[3]] will be NULL, and will be concatenated strings, making a weird/invalid URL. The test and code still works, but I'm not sure if that's what should happen in this case.

Also, I agree with @quietone, I don't know why ViewsExposedForm.php was modified.

Should be converted to MR and rerolled.

So, instead of passing 'bad' data to preg_match can this be fixed in views? And further, is it possible to use a Kernel test instead of a Functional test.

The changed code no longer passes "bad" data to preg_match(). And the actual issue that was reported here is tested, and it requires a bootstrapped Drupal. I think it's better to test that the actual, desired functionality is working.

Believe test coverage was lost

Oop, yeah. I created the files, but they didn't get added to the commit.

Mind fixing the phpcs issue

Thanks!

Appears to have test failures

It appears that the failures for missing schema are due to the fact that this was removed in 11.x. See function views_removed_post_updates()

'views_post_update_remove_default_argument_skip_url' => '11.0.0',

If I remove that from the view, will it break the test for Drupal 10.3?

I think it shouldn't be a problem. If its deprecated then should be safe to remove

Let's see if this fixes the failures, then.

That did it. Believe this is probably ready now.

Hello, I have updated the patch to Drupal Core 10.3.2. Please check the attachment.

I skimmed through this issue and this still needs a title update asked for in #21. The title should be a description of what is being fixed or improved. The title is used as the git commit message so it should be meaningful an concise. See List of issue fields → .

#21 and #26. Why is ViewsExposedForm.php modified? I ran the test without the changes to this file and the test passes.

The proposed resolution include discussion the solution but I don't see that.

The patch #16 🐛 Parameter "arg_0" must match "[^/]++" Needs work worked for me!