The matching mechanism for pretty URLs should only include page documents and objects

[alexej-d]

I have created an issue (#16420) because I have found an odd behavior in the DocumentRouteHandler where a pretty URL is not matched correctly to a page or object, when a snippet, link or directory with the same internal key exists.

@mattamon suggested opening a poll to see what the others think about this behavior.

[muratbinerbay]

Hey,

I read over the original issue you created and I think the current behaviour is correct.

We ran into a similar issue while working, but realised what we were trying to do was pointless (I think we also had a controller in there or something, can't really remember anymore).

The error message is correct because the system really should go ever all possible paths while checking your pretty URL value. Not sure what your exact use-case is but from the video you posted, can't you just change the key of the Link element and give it a pretty URL too if needed?

[alexej-d]

The thing is, links, snippets and folders cannot have a pretty URL. Still, they are considered by the system, when matching a pretty URL to a document or object. I do not find this behavior intuitive at all. At the very least, the matching should first find docs and objects using the pretty URL that is matched against -> if no matching element with the exact pretty URL is found, use the element keys for matching. Right now, the logic is the other way around.

[muratbinerbay]

Sorry it is kind of hard to grasp the whole thing without a concrete example/use-case. But Pimcore trying to render documents first feels intuitive to me.

For example: the video you posted in the other thread looks like the link document shouldn't be needed, or could be fixed by renaming. Maybe some sort of priority field in matching could be helpful? Although I guess any change to behaviour would break many systems that relied on the current logic.

[fashxp]

I'm also more in the favor of keeping the behavior as it is.

I like @muratbinerbay 's suggestion though.
Could you try to share an actual use case with explanation why you wanna create a pretty-url pointing to an existing document in the structure.

[alexej-d]

It's as @dpfaffenbauer says. When creating documents programmatically, there are no error messages preventing you from doing things like that

[fashxp]

... and for that we have the warning when applying the pretty-url so that the user is warned about it?

When it just happens, then I'm a bit concerned about the opposite perspective.
Someone could 'hijack' parts of a website (which they don't have permissions to edit for) by defining pretty-urls and so overwriting existing pages.
Or someone creates a document and wonders, why it is never delivered (because there is a pretty url defined for it's path).

Is that something should happen?

One can argue if it would be a problem for folder documents, but for link documents it definitely is.

[fashxp]

It's as @dpfaffenbauer says. When creating documents programmatically, there are no error messages preventing you from doing things like that

fair enough ... my examples for problematic consequences still apply.

[alexej-d]

... and for that we have the warning when applying the pretty-url so that the user is warned about it?

When it just happens, then I'm a bit concerned about the opposite perspective. Someone could 'hijack' parts of a website (which they don't have permissions to edit for) by defining pretty-urls and so overwriting existing pages. Or someone creates a document and wonders, why it is never delivered (because there is a pretty url defined for it's path).

Is that something should happen?

One can argue if it would be a problem for folder documents, but for link documents it definitely is.

As far as I have seen there are no warnings, when creating documents and pretty URLs programmatically

[fashxp]

yes, that is true.