Updated: Comment #N

Problem/Motivation

One of the drawbacks of no longer providing URL paths for generating links, but route names, is that we can link to less URLs than we could before, as a lot of routes need parameter replacement values if links are to be made of them. One example of this is #2147689: [regression] Support route parameters for *info.yml files' "configure" route name. Another one is base_route_name in *.config_translation.yml files. This effectively is a regression since Drupal 7.

Proposed resolution

Whenever a link is generated based on a route, there must be the possibility to provide values for route parameters.

Remaining tasks

Decide on this policy.

User interface changes

None.

API changes

None. The policy enforces non-BC-breaking API additions only.

Comments

Crell’s picture

At first blush this seems reasonable. In order to link to a route, you need to be able to provide its parameters. Where you used to have a path, you now need a route/parameters.

Xano’s picture

One concern that was raised by timplunkett is that we cannot provide dynamic parameter values. Within the context of a statically defined route name (just we defined static URL paths in Drupal 7) this is true. This is, however, no regression. Example: just like *.info files in D7 provided a configure route path with the (static) placeholder values filled in, in D8 that value would be a route name, with an additional array of static route parameters. Instead of entering them into the URL directly, we provide a map, but the values in questions have been and will remain static, as long as the context is static as well.

Xano’s picture

Title: [policy, no patch] Route parameters must be able to be provided along with route names » [regression][policy, no patch] Route parameters must be able to be provided along with route names

This hasn't manifested itself as a regression in Drupal core (yet), but it has in contrib.

dawehner’s picture

Can someone explain here the actual "regression"?

Xano’s picture

The regression is that if route parameters are unsupported, we can no longer link to URL paths with placeholders/wildcards/parameters.

tim.plunkett’s picture

The configure link has its own issue. The config_translation does not, AFAIK.

Xano’s picture

tim.plunkett’s picture

Yes. The config_translation routing code has many many more problems than just that, I will be opening a critical in the morning when I can think straight.

Xano’s picture

Regardless of any Configuration Translation issues, what are your thoughts on this issue in general?

tim.plunkett’s picture

I think that each are a case-by-case basis, and no policy needs to exist.
In 90% of places in core they are a pair.

Xano’s picture

Can I ask why you think this does not to be done everywhere? The way I see it, anything that needs to do something with a route has no right to impose any limitations on that route.

Xano’s picture

Bump.

dawehner’s picture

Yes, we should make it possible in most places. for the rare edge case we can always tell people that they can also generate routes with different default values.

dawehner’s picture

Status: Active » Fixed

With the appearance of the url object we have fixed this issue. It bundles the information together and we are fine.

Status: Fixed » Closed (fixed)

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