Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Updated: Comment 0
Problem/Motivation
There are usecases in Drupal which require to get routes for an actual pattern like /block/{custom_block}
not for a congrete path.
This works fine until you have a regular expression in the route requirements.
Proposed resolution
Regular expressions in the route requirements are a totally valid feature, though the route provider validates the regular expression.
Maybe we could just skip it.
Remaining tasks
User interface changes
API changes
Related Issues
Comment | File | Size | Author |
---|---|---|---|
#41 | routing-2116111-41.patch | 6.9 KB | ekl1773 |
#38 | routing-2116111-38.patch | 6.94 KB | kvoelker |
#38 | routing-2116111-38-interdiff.txt | 6.94 KB | kvoelker |
#33 | routing-2116111.patch | 6.57 KB | dawehner |
#28 | interdiff.txt | 1.76 KB | dawehner |
Comments
Comment #1
pwolanin CreditAttribution: pwolanin commentedThis seems to be clearly a bug, since the doxygen for getRoutesByPattern() in the interface says that it expects them to have placeholders.
Comment #2
dawehnerLet's see whether this passes everything.
Comment #3
pwolanin CreditAttribution: pwolanin commentedHere's a possible fix.
Comment #4
pwolanin CreditAttribution: pwolanin commentedOh, cross - posted. But I think the current code is totally wrong - it should not call getRoutesByPath($path) at all.
Comment #5
pwolanin CreditAttribution: pwolanin commentedso, then we should make the path one public also.
Comment #6
pwolanin CreditAttribution: pwolanin commentedAs a side note - it seems the only real use case for getRoutesByPattern($pattern) is because of the re-definition of entity paths patterns in their annotation instead of using route names, so that's the *real* other bug.
There is little use case otherwise where you'd have the route pattern but not the route name or a concrete path.
Comment #8
Crell CreditAttribution: Crell commentedUm. I'm entirely confused as to what we're doing here. Regex route requirements are a feature of Symfony/UrlMatcher that we inherited, and are using in a few places. That's actually the primary use of requirements in the Symfony-native code. Can someone explain what the actual problem is?
Comment #10
pwolanin CreditAttribution: pwolanin commented@Crell - updated the title.
The problem is when we have a route path pattern with slugs, it doesn't make any sense (and fails) to apply validation to the slug.
Instead we need to jsut look up that directly in the DB as the patch tries to do.
Comment #11
pwolanin CreditAttribution: pwolanin commentedLooks like there is one test case to be fixed. Not sure why the testbot didn't run.
Comment #13
pwolanin CreditAttribution: pwolanin commentedIn IRC Crell says the
preg_match($route->compile()->getRegex(), $path, $matches))
could potentially be totally removed, that's it's there as an un-benchmarked optimization(?), but I think the code still doesn't meet our needs since we effectively already know the 1 outline we want.Comment #14
dawehnerI don't really get where this failure is coming from by we should extend the test coverage.
Comment #15
juanolalla CreditAttribution: juanolalla commentedI don't know If I'm getting it right, but if we don't validate the regex of the slug, how can we avoid problems like this: http://symfony.com/doc/current/book/routing.html#adding-requirements ?
Comment #16
dawehner@juanolalla
We still validate the arguments when you have an actual request coming in.
Let's add a bit more explanation of the difference of this two methods.
Comment #17
dawehnerWrong interdiff.
Comment #19
dawehnerThere we go.
Comment #20
dawehner19: route_provider-2116111-19.patch queued for re-testing.
Comment #22
dawehnerJust a normal reroll.
Comment #24
dawehnerLet's have a look at this rerole.
Comment #26
dawehnerThere we go.
Comment #28
dawehnerThat was the wrong fix.
Comment #29
Crell CreditAttribution: Crell commented26: route_provider-2116111.patch queued for re-testing.
Comment #32
damiankloip CreditAttribution: damiankloip commentedCan we just have getRoutesByPattern and getRoutesByPath, or too vague?
Otherwise, generally looking pretty good IMO.
Comment #33
dawehnerWell, the thing you store on the route is the pattern, so we path should be the non-vague part, though people use it like it would be vague, even if it is not.
Comment #35
dawehner33: routing-2116111.patch queued for re-testing.
Comment #37
kvoelker CreditAttribution: kvoelker commentedGoing to work on this one now...
Comment #38
kvoelker CreditAttribution: kvoelker commentedRe-rolled! resolved conflicts
Comment #40
ekl1773I'm working on this for Sprint weekend!
Comment #41
ekl1773There were several conflicts.
I left the function shortcut_valid_link in the patch even though it's no longer in shortcut.module in HEAD, just to test. If testbot freaks out then that function should be removed, I think. (lines 237-260 in the module)
There is no longer a "try" in RouteProviderTest.php, so I removed that.
Just going to see what happens here...
Comment #57
catchThis looks like a micro-optimisation of a method that's only called once in core - in Drupal\views\Plugin\Derivative\ViewsLocalTask, and the patch doesn't update that one usage to the new method, so it would be dead code as far as core's concerned and there's no indication where contrib needs it. Moving to a task, but needs an issue summary update.
Comment #58
quietone CreditAttribution: quietone at PreviousNext commentedThis was a bugsmash group triage issue and discussed with lendude and myself, who were unsure what to do with it. Later, catch joined and replied above. Adding tag.
Comment #59
smustgrave CreditAttribution: smustgrave at Mobomo commentedSince there hasn't been followup or response to #57 going to close out for now.
If still a valid task please reopen updating issue summary.
Thanks all!