MissingMandatoryParametersException error on views with menu tab and % in the path

Sounds like a problem of the devel module ...

does this issue need re-assignment?

No. I'm able to reproduce this with the latest core and without Devel installed. The error is different:

Symfony\Component\Routing\Exception\MissingMandatoryParametersException: Some mandatory parameters are missing ("arg_0") to generate a URL for route "view.test.page_1". in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 174 of core\lib\Drupal\Core\Routing\UrlGenerator.php).

(export to reproduce attached).

Updated title and clarified STR in the issue summary.

Ack! Somehow managed to delete the original report when updating the issue summary. Replaced it from revisions.

Sorry about that...

No. I'm able to reproduce this with the latest core and without Devel installed. The error is different:

MH :(

Downgrading priority to normal as the view will render correctly if you use a named route parameter: node/%node/test. The % placeholder is supposed to be used for contextual filters.

However, even if you add a contextual filter you end up with the same exception as above. So some part of this bug remains.

Updated title, STR, and exported view based on #7.

I have got the same error on RC1. Using named parameter as was suggested in #7 resolved the problem.

I can confirm it's still there as of 8.0.1.

#7 worked for me, thanks sir

However, even if you add a contextual filter you end up with the same exception as above. So some part of this bug remains.

So yeah the problem is basically that views would have to allow to name the parameters of generated routes, much like it currently allows to name its routes.

I have the same error at drupal 8.0.4
I tried to make a tab in the user's profile with his materials.
I use path: "user/%/posts".
Tab and urls like site/user/12/posts works, but i open any profile - i have the error:

Symfony\Component\Routing\Exception\MissingMandatoryParametersException: Some mandatory parameters are missing ("arg_0") to generate a URL for route "view.userposts.page_1". in Drupal\Core\Routing\UrlGenerator->doGenerate() (line 177 of core/lib/Drupal/Core/Routing/UrlGenerator.php).

I see this problem occurs with many people.
Is there any way to solve it?

Having had the same error whilst trying to show a view at /user/%/my-travel-stories, I can confirm that simply changing that path to /user/%user/my-travel-stories fixed the exception and the view displayed correctly. So, yes, we need better documentation on this.

I’m not quite sure how to describe the differences between %, %node, %user etc. Anyone with better understanding?

Thanks Rachel! Your solution worked for me too, in my case this worked: crm-core/organization/%crm_core_organization/events

Hi fomenkoandrey (#14),

Your issue got fixed? Can you please tell me what was the fix? Even I also want to add a tab in user profile page.

Thanks,
ARUN AK

Arun - note that, when adding a tab to the user profile, you’ll probably want a path in the view of

/user/%user/my-tab

rather than

/user/%/my-tab

Hope that helps.

It would be nice if we could come up with some form of validation for that.

Okay, I believe that the reason people are hitting this error is more down to D8 being different to D7 but people still assuming everything in D8 views is just the same.

As long as a named parameter is used, as described in #7, #16 #17, all is well and works as expected. We just need to better hint at the expectation for a named parameter.

Attached is a patch that adds another example to the already-existing text mentioning named parameters in the views module.

(Interestingly, why was this a patch to views and not views_ui???)

Moved to 8.2.x

rachel_norfolk,

I need to add a custom tab in user profile page. I defined my route like below:

mymodule.routing.yml

mymodule.account:
    path: '/user/{user}/custom'
    defaults: 
      _form: '\Drupal\mymodule\Form\MyModuleUserSettingsForm'
      _title: 'Custom Settings'
      user: \d+
    requirements:
      _permission: 'access content'

mymodule.links.task.yml

    mymodule.account:
      title: Mymodule Settings
      route_name: mymodule.account
      base_route: entity.user.canonical

mymodule.links.menu.yml

    mymodule.account:
      title: My module Settings
      parent: entity.user.canonical
      route_name: mymodule.account

Then after clear cache, tab is appearing in profile page. But when I opens the url /user/1/custom getting page not found.

That’s not something you are doing in views, though, Arun?

I'm not 100% sure the documentation is clear still, the extra example doesn't stop me doing /node/%/test because it mentioned node/%/feed earlier on.

Maybe the text could be something more like...

This view will be displayed by visiting this path on your site. You may use "%" in your URL to represent values that will be used for contextual filters: For example, "node/%/feed". Sometimes, you may need to specify named route parameters. Examples of named route parameters include "taxonomy/term/%taxonomy_term", "custom_path/%node" and "user/%user/custom-view"

Would that help?

The problem, IMHO, is that no one reads until the end of the sentence for the example. When I got this error, I read the comment again but never made it till the end. I then just went to search and found this issue.

Also, it is worth considering that most use cases for placeholders will be to use in paths like user/%/... or node/%/.... It would be worth bringing up the named parameters earlier.

How about something like this?

This view will be displayed by visiting this path on your site. You may use "%" or named route parameters like "%node" in your URL to represent values that will be used for contextual filters: For example, "node/%node/feed" or "view_path/%". The named route parameters are necessary when used within paths used by entities such as "taxonomy/term/%taxonomy_term" or "user/%user/custom-view"

Attaching a patch with above.

Hussainweb in #27 has done a far better job of providing explanatory text here. I think it makes much better sense now and causes me to read the relevant info.

I think it is now a good, simple change. Pity we can’t squeeze it into 8.2!!

Screenshot:

+1 for #27, much better wording.

Thanks, @hussainweb!

Back to RTBC after random failure.

Placing this in front of the Usability Team as it makes a very useful usability improvement to views.

I’ve updated the Issue Summary to make this more amenable to committers.

I believe this SHOULD be included in the 8.2 release:

• It’s a bug (if it’s causing people to do the wrong thing, it’s a bug)
• It causes no/minimum disruption
• It is a string, user interface, or render array change

I'm not sure about 'within paths used by entities'.

Isn't the issue that user/%user is an existing path, so we're adding user/%user/foo. But then user/%user/foo isn't "within an entity path".

Maybe something like 'matches an existing entity path. For example adding a view at user/%user/foo when user/%user already exists'.

I also wonder whether we could validate this i.e. look for that exception when validating and show an error if so.

Isn't the issue that user/%user is an existing path, so we're adding user/%user/foo. But then user/%user/foo isn't "within an entity path".

Well the main point is that its an existing path with a certain slug, which has a certain name. On the other hand the really common case is that the slug will have an entity in there, especially in the context of views.

I also wonder whether we could validate this i.e. look for that exception when validating and show an error if so.

We could maybe indeed try to. Good idea.

This seems like it's at least related to #2489940: Views path with menu tab does not validate and results in fatal error (might be duplicates)

How do I add a tab to a store ?

On top of that I believe it would be helpful to allow /node/{node}/example, because well, %node is really not anymore the recommended way. For example the routing system uses {node} under the hood.

I am able to add the path node/%/stuff but I cannot make it a tab.

I understand the issue now
adding % is just for contextual links and adding %someword is for node tabs.

The attached patch is based on #27 and applies on Drupal 8.8.x and also tries to emphasize the need for named route parameters.

I got this error while working on a contrib module, took me quite some time to figure out that it needed a named route parameter.

The patch is fine @bserem! I just tested it on simplytest.me and follows exactly the issue description's proposal. The only change I would suggest is to replace necessary with required which is more common as a word and for a reason I believe.

@vensires thanks for the feedback, it actually sounds/looks nicer the way you suggested.

Attached is the new patch, screenshot and interdiff.

Good to go for me.

I'm trying to add Vensires in the credit list but apparently I can't.

The help text looks OK to me, but the original report here is describing a situation where just configuring a site via the UI you're able to trigger an exception. I think ideally we'd add some validation here too as well. Tagging for subsystem maintainer review - although we could possibly look at the validation in a separate issue.

+++ b/core/modules/views/src/Plugin/views/display/PathPluginBase.php
@@ -440,7 +440,11 @@ public function buildOptionsForm(&$form, FormStateInterface $form_state) {
-          '#description' => $this->t('This view will be displayed by visiting this path on your site. You may use "%" in your URL to represent values that will be used for contextual filters: For example, "node/%/feed". If needed you can even specify named route parameters like taxonomy/term/%taxonomy_term'),
+          '#description' => $this->t('This view will be displayed by visiting this path on your site.
+            You may use "%" or named route parameters like "%node" in your URL to represent values that
+            will be used for contextual filters: For example, "node/%node/feed" or "view_path/%". The
+            named route parameters are <strong>required</strong> when used within paths used by entities
+            such as "taxonomy/term/%taxonomy_term" or "user/%user/custom-view".'),

We can't break this translatable string into many lines. That makes it impossible for POTX to work this it all needs to be on one line.

@alexpott didn't know about that, re-rolled a new patch.

@catch the validation would be tricky because the problem happens if you add a tab with a non-named route parameter. So, the validation should check both the menu settings and the path. It would have to be a validation on the view-level and not these particular settings, because both of them might be correct on their own. It is the combination that triggers the exception.

I will have a look at it, but I do suggest the follow-up issue, as this is gonna be way more complex.

@catch I also vote for a separate issue on handling the error. Or, at least, making sure that we provide a better DX on why the error occurs (like we did in #2959445: Entity querying config entities does not work, so neither does JSON API collection filtering: provide helpful DX). Validation should be done, in my opinion, in views entity when saved (a constraint maybe?) in order to also catch configuration imports too. But let's not talk too much on this here.

The problem of letting developers discover the same issue again and again (if they find it) is very time-consuming. If it's properly documented in-site just below the field, even simple site builders will be able to resolve it if it occurs to them. Patch is fine again for me, so setting to RTBC; hoping it will land in Drupal core as soon as possible.

We need that followup filed to go ahead with this change. Thanks!

Also, I think the correct status is NR for the subsystem maintainer review. I'd suggest reaching out to one of the (other) views maintainers for feedback (@dawhener or @tim.plunkett, in this case).

And a UX review would be good too.

I am inclined to set this to RTBC as it was in comment #54, for two reasons:
1. I am stumbling upon this every couple of months and I suppose I am not the only one
2. It is stuck in review, waiting for the subsystem maintainer, even though it is a simple wording change.

It applies to 8.9.x and all tests pass.
It doesn't apply to 9.x.x but if this gets a green light we can easily port it.

#2489940: Views path with menu tab does not validate and results in fatal error will do as a 'follow-up' here I feel (it's actually older then this issue).

Since that issue is pretty hard to solve, I think it's a great idea to move ahead with this documentation change first, hopefully helping some people avoid fatal errors.

But in reply to #59, we port the other way around, this needs to go into 9.2.x first and then we backport it to other versions, so we need something that applies to 9.2.x to start with

Attached is the patch for drupal 9.2.x (also applies to 9.1.0) as suggested in #60 by Lendude

Patch in #53 stilll applies to drupal 8.9.x and can be used to backport this.

There is no interdiff, since the patch is actually the same.

Following latest updates, a gitlab MR has been created instead of patches.
Hiding patches from the overview.

This MR: https://git.drupalcode.org/project/drupal/-/merge_requests/125 is the same as #61

Okay -

1. I have used the preview on tugboat to check that the correct text is appearing when building a view, as below:

2. We have already confirmed that we are happy with the updated language.

I think it is time to mark this as RTBC!

+++ b/core/modules/views/src/Plugin/views/display/PathPluginBase.php
@@ -437,7 +437,7 @@ public function buildOptionsForm(&$form, FormStateInterface $form_state) {
+          '#description' => $this->t('This view will be displayed by visiting this path on your site. You may use "%" or named route parameters like "%node" in your URL to represent values that will be used for contextual filters: For example, "node/%node/feed" or "view_path/%". The named route parameters are <strong>required</strong> when used within paths used by entities such as "taxonomy/term/%taxonomy_term" or "user/%user/custom-view".'),

I still agree with @catch that the within paths used by entities feels tricky. I think we can be more explicit here. For example we could say...

This view will be displayed by visiting this path on your site. You may use "%" or named route parameters like "%node" in your URL to represent values that will be used for contextual filters: For example, "node/%node/feed" or "view_path/%". Named route parameters are required when this path matches an existing path. For example, paths such as "taxonomy/term/%taxonomy_term" or "user/%user/custom-view".

The one issue with the above is that it only covers the partial matching of user/%user and user/%user/custom-view - but I think that this is okay because we have the example. Maybe someone else has an idea about how to make this even clearer but given the point of this issue is to improve the text I think it is worth refining until we have something that someone new to Drupal can think "yep I get that".

Made changes as per comment #66.

Thanks Alex and Ravi for the updates to the language. It is a lot better now.

Confirming that the latest patch does indeed reflect the language suggested in #66

Setting back to RTBC

Saving issue credits and updating tags

Committed b796e37 and pushed to 9.3.x. Thanks!

I didn't backport this to 9.2.x because there's a string change, and that would break existing translations. We only do that in minor versions. Tagging as such.

The patch doesn't seem to work with commerce products. I get the following errors:

/product/%/mytab
Some mandatory parameters are missing ("arg_0") to generate a URL for route "view.myview.page_1"

/product/%product/mytab
Some mandatory parameters are missing ("product") to generate a URL for route "view.myview.page_1"

@iamfredrik you should check what the entity declares as route in its annotation. Check Product.php and you will see that the canonical URL is /product/{commerce_product}. As a result, you should use /product/%commerce_product/mytab.

Closed #2883266: RuntimeException: Callable "Drupal\contact\Access\ContactPageAccess::access" requires a value for the "$user" argument. in Drupal\Component\Utility\ArgumentsResolver->handleUnresolvedArgument() as a duplicate, adding credit.

Does anyone know what was actually added to core to resolve this? I'm on a d8 site with commerce, so looking to backport this functionality if i need to. I have setup a view with url /products/%commerce_product/variations-bulk and am getting this error:

TypeError: Argument 1 passed to Drupal\Core\Entity\EntityRepository::getTranslationFromContext() must implement interface Drupal\Core\Entity\EntityInterface, string given, called in /modules/contrib/commerce/modules/product/src/ProductVariationListBuilder.php on line 73 in Drupal\Core\Entity\EntityRepository->getTranslationFromContext() (line 99 of core/lib/Drupal/Core/Entity/EntityRepository.php).

As views is passing a string for "product_id" rather then the product object. Any ideas how to fix?

Yeah, we improved the help message so that it is clear for users what to do.
See: https://git.drupalcode.org/project/drupal/-/commit/b796e3779b21e1f62f9e5...

@bserem thanks, per the description I think i'm using the correct syntax for my url (/products/%commerce_product/variations-bulk) but am still getting an error. Is that a commerce issue? Or a views/core issue?