Child of #2417567: Rename user-path: scheme to internal:
Beta phase evaluation
| Issue category | Task; there is no functional bug. |
|---|---|
| Prioritized changes | The main goal of this issue is improving DX. The issue is a prioritized change because it is a followup from critical and major work in #2407505: [meta] Finalize the menu links (and other user-entered paths) system. |
| Disruption | API addition and (in itself) BC-compatible. Some minor disruption as this refines what is considered "best practice" for handling paths from user input. |
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | interdiff.txt | 4.32 KB | effulgentsia |
| #19 | url-2426181-19.patch | 18.78 KB | effulgentsia |
| #17 | interdiff-11-17.txt | 17.7 KB | xjm |
| #17 | url-2426181-17.patch | 18.08 KB | xjm |
| #11 | interdiff.txt | 1.05 KB | effulgentsia |
Comments
Comment #1
xjmUpdating the @todos and moving some documentation from the protected method.
Comment #2
dawehnerIs that really the only thing we can assert? For example fragment/options extracting could be tested.
Comment #3
xjmGood idea; I'll look into that too.
Comment #4
mpdonadioSorry @xjm, the 2/18 deadline on the parent is looming. Few additional assertions.
Comment #5
mpdonadioAssert all the things! Not sure why ::assetEmpty() didn't work here.
Comment #6
effulgentsia commentedUpdated the docs to not use the word "path" for strings that are more than just paths. Also added a few more exceptions to make the implementation match the docs.
Comment #8
effulgentsia commentedOh, PHP and the NULL/FALSE/empty syndrome.
Comment #10
effulgentsia commentedYes, since this is the value of a field, we need to treat it as user input, so we can remove the question from the @todo.
AFAICT, we have no test coverage for
guid_field_is_permalinkbeing set to true. I'm not clear on what the use case for it is. When set to true, is it still expected to be a guid, or do we need to allow for it to be a user-entered path? If it's still expected to be a guid, should we assume that all guids are system generated and therefore NOT user entered / modified? In which case, we might want to leave this one as not using the fromUserInput() wrapper and open a dedicated followup issue to figure out and document these questions/expectations.Comment #11
effulgentsia commentedThe test failures in #8 are due to me having added an exception for protocol-relative user input in #5, but us having pre-existing bugs in HEAD that incorrectly use that. Fixing those bugs is out of scope for this issue, so removing that check.
Comment #12
hussainwebI checked through the patch and the code and found all invocations to fromUri are changed to fromUserInput wherever user-path was used. I think everything else looks good too. All the todos should be handled in a follow-up (including the todo in the doc for
fromUserInputmethod.Comment #13
alexpottAll the @todo should be accompanied d.o link
Comment #14
xjmRerolling to add the link to the existing followup issue, move the documentation from the protected method, and use the data providers added in #2423579: Url::fromUrl('user-path:/') should throw an exception when a path component without a slash is given.
Not sure about putting all this in there. It's not just about conforming to blah blah RFC blah, it's also about supporting the user interaction pattern of these characters indicating the user wants to enter a path instead of autocompleting a title.
I also disagree with these exceptions. The messages are too technical. We already added an exception in #2423579: Url::fromUrl('user-path:/') should throw an exception when a path component without a slash is given and this is not about malformed URIs. This method should be about supporting user input.
Also still concerned about the leading slashes here. I think maybe we need another followup issue about destinations?
It also concerns me that literally every use is also needing to append a leading slash. Is this method accomplishing our goal here?
Comment #15
xjmAlso realized that the exceptions themselves are now in several different code paths and thrown in other cases. I think this is incorrect. This method should define what's valid as user input, not what's valid as a URI. #2423579: Url::fromUrl('user-path:/') should throw an exception when a path component without a slash is given and
fromUri()already take care of validating URIs.Comment #16
xjmDiscussed with @effulgentsia. For #14 points 1 and 2, we agreed to rename the parameter to
$user_input, to make it explicit that this is an unvalidated user string. We will remove the first two exceptions as they are redundant with the third, but include a comment explaining why it's sufficient to require the leading / # ? and append the scheme. For point 3, we will fix that in #2418219: Deprecate destination URLs that don't include the base path. @effulgentsia is also filing a related followup for the path alias storage.Comment #17
xjmHere we are; sorry for the delay. Two things are still outstanding: One, we still need the followup for path alias storage (see #16), and two, there's some docs on
fromUserPathUri()that I was intending to move but now I'm not sure about. That could easily also be a followup.Other than that, I think this is probably ready.
Comment #18
effulgentsia commentedAdding some newly filed issues to the related issues list. Will followup with a patch reroll referencing them shortly.
Comment #19
effulgentsia commented+1 to RTBC if someone other than me approves this interdiff.
Comment #20
xjmAll those changes look great to me.
Comment #21
xjmBeta eval.
Comment #22
alexpottCommitted 8d87f7f and pushed to 8.0.x. Thanks!
Thanks for adding the beta evaluation to the issue summary.
Fixed on commit.
Comment #24
xjm