Follow-up to #2418139: Add a toUriString method to Url class and add a route: scheme
Problem/Motivation
There may be a bug in handling a fragment of #0
Copying comment from Wim Leers:
I think there's one actual bug in the code plus 3 nitpicks that aren't worth a follow-up unless the first is going to require a follow-up:
+++ b/core/lib/Drupal/Core/Url.php @@ -240,21 +241,37 @@ public static function fromRouteMatch(RouteMatchInterface $route_match) { + if (!empty($uri_parts['fragment'])) { + $uri_options += ['fragment' => $uri_parts['fragment']]; + } + unset($uri_parts['fragment']);Why is the
unset()happening outside of the if-statement? That doesn't seem to make any sense?Before I file a follow-up for this tiny thing, I'd like confirmation from someone else that this is a problem.
+++ b/core/lib/Drupal/Core/Url.php @@ -280,38 +302,68 @@ public static function fromUri($uri, $options = array()) { + protected static function fromEntityUri(array $uri_parts, $options, $uri) {Nit: This
$optionsdidn't get typehinted.+++ b/core/lib/Drupal/Core/Url.php @@ -358,6 +410,32 @@ protected function setUnrouted() { + * Return a URI string that represents tha data in the Url object.Nit: Returns.
+++ b/core/lib/Drupal/Core/Url.php @@ -358,6 +410,32 @@ protected function setUnrouted() { + * constructed using an entity: or user-path: scheme. A user-path: URI + * that does not match a Drupal route with be returned here with the base: + * scheme, and external URLs will be returned in their original form.Nit: Double space after period, 80 col formatting a bit off.
But actually - this may be a different and more real bug - should probably really use isset($uri_parts['fragment'])> there in case we are trying to jump to #0
Proposed resolution
Fix #0, add a test, fix code nits from Wim.
Remaining tasks
do it
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | increment.txt | 1.44 KB | pwolanin |
| #9 | 2418613-9.patch | 6.83 KB | pwolanin |
| #5 | increment.txt | 6.69 KB | pwolanin |
| #5 | 2418613-5.patch | 6.74 KB | pwolanin |
| #3 | 2418613-3.patch | 1.77 KB | pwolanin |
Comments
Comment #1
wim leersNow that there is an issue, one more thing.
It was technically wrong before, but now that we have
toUriString(), it definitely doesn't make sense anymore.toString()is for generating URLs.toUriString()is for generating URIs.This is logical (because they are methods on the
Urlclass), but the docs should reflect this.Comment #2
pwolanin commentedworking on the patch
Comment #3
pwolanin commentedQuick 1st pass at fixing the bug - doesn't address other doc/type hint concerns.
Comment #5
pwolanin commentedI think this fixers most of the rest and adds some more test cases.
Comment #6
wim leersDown to comment nits; this patch is RTBC codewise. Those comment nits are important here, because they affect the DX.
The wording of these should be consistent.
"option value" sounds a bit strange? Perhaps just me.
"path relative to the Drupal base URL" — why not say "'user-path: URI" instead of that?
And that'd still omit 'entity:' URIs, even though they get the same treatment.
So what about
?
Comment #7
pwolanin commentedre: #3 that's actually the
base:case, which might have come from auser-path:but fell back to the former since there was no route.The
entity:case is not distinct since it's converted to route name and params. So basically there are 2 situations for the Url object instance for an "internal" URL - it's a route name + params, or it's usingbase:Comment #8
wim leersYou're right of course. But I'd say that's an implementation detail. I think the docs should explain it to the user from either the A) "route name + params" or B) "internal URI schemes" perspective. Because that's easy to understand. Knowing how those internal URI schemes are resolved exactly is not something every developer *must* know.
Comment #9
pwolanin commentedok, how's this?
Comment #10
wim leersPerfect!
Comment #11
webchickCommitted and pushed to 8.0.x. Thanks!
Comment #12
webchick