According to the Symfony documentation, a route defined as below should trigger the specified controller for both /hello/bob
and /hello/bob/bobby
:
_hello:
path: /hello/{names}
defaults: { _controller: \Drupal\mymodule\Controller\Main::Controller }
requirements:
_access: 'TRUE'
names: .+
In the case of a request to /hello/bob/bobby
the {names}
param would be "bob/bobby" (slash intact) and it would be up to the controller to break that down into multiple variables or to leave it as a single string. The trick to that is the altered regex (".+") used to filter that {names}
param.
This stackoverflow post also implies that custom regex can be used to allow slashes in a route param (at least in Symfony 2).
If I try this against Drupal 8.0.0-beta15 it does not work and the specified controller is only triggered for a request to /hello/bob
. However, I can confirm that this used to work in previous betas (I think up until ~beta13).
Has something changed in the way Drupal integrates with the Symfony routing component that would explain this? Perhaps there is an alternate way to accomplish the passing of slashes in routing params? I know there is a movement toward Symfony 3.0 in core, but I'm not sure if that could explain things.
I also know that route subscribers are available to manage dynamic route structures. However the case I am working on requires an almost infinite combination/number of dynamic parameters at the end of a base path (but which are trivial to parse in my controller). I'm also trying to avoid query strings (e.g. /hello?names[]=bob&names[]=bobby
) for this case.
Mainly I'm just confused as to the disconnect with the Symfony documentation, which seems to state that this should be possible.
Additional Notes
After posting this question I discovered this discussion in the D8 core queues: [Discussion] Drop automated passing of extra argument: Y/N. It seems to conclude that "menu tail" support (which is essentially what I am after) will officially be dropped in D8. That discussion ended 3 years ago and so I can only guess that some of the more generalized implementation specifics were not fully realized until recently (~beta13). This may explain why I've only now noticed this change.
I'm guessing that Drupal (not Symfony) is now generating a 404 response based on the raw slash-delimited request before any of the Symfony-specific routing logic further dissects the route (and it's param-specific regex, etc.). If this is the case it could explain why technique above stopped working. I am still wondering however if there are alternative ways to deal with this need that avoid using query params and custom route subscribers.
path: /hello/{names}
andusername: .+
have to do with each other.