Closed (outdated)
Project:
Drupal core
Version:
9.5.x-dev
Component:
routing system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
20 Oct 2013 at 08:26 UTC
Updated:
29 Aug 2023 at 14:32 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
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 commentedHere's a possible fix.
Comment #4
pwolanin commentedOh, cross - posted. But I think the current code is totally wrong - it should not call getRoutesByPath($path) at all.
Comment #5
pwolanin commentedso, then we should make the path one public also.
Comment #6
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 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 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 commentedLooks like there is one test case to be fixed. Not sure why the testbot didn't run.
Comment #13
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 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 commented26: route_provider-2116111.patch queued for re-testing.
Comment #32
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 commentedGoing to work on this one now...
Comment #38
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 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 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!