URLs with parent "menu seperator" are not decoded when logged in into Backend

[ervaude]

If one is logged in to the backend, realurl will use the NullCache and thus not find anything in any cache. This leads the decoding process of any URL to decodePath() where the currentPid is set to the rootPid. See: https://github.com/dmitryd/typo3-realurl/blob/development/Classes/Decoder/UrlDecoder.php#L435

Then the searchPages() method is called (https://github.com/dmitryd/typo3-realurl/blob/development/Classes/Decoder/UrlDecoder.php#L445) where essentially the URL path is checked against the page titles of pages that have the rootPid as parent (https://github.com/dmitryd/typo3-realurl/blob/development/Classes/Decoder/UrlDecoder.php#L1216-L1218). Pages further down in the page tree are not checked and therefor not found.

So a link to a page on the third level in the page tree can never be decoded if you are logged in the backend.

[dmitryd]

Pages further down in the page tree are not checked and therefor not found.

Wrong: https://github.com/dmitryd/typo3-realurl/blob/development/Classes/Decoder/UrlDecoder.php#L445

The line you found is executed just once: when processing the root page.

Just tested, decoding deep in the tree works fine.

[ervaude]

It turned out the failing decoding was caused by the parent of some pages being a doktype "menu seperator". The URLs to those pages are not decoded when I am logged into the backend. So I was indeed wrong with my initial issue. But thanks for your investigation anyways. Maybe you can check the behavior with the "menu seperator" doktype as well?

[dmitryd]

Menu separators are not supposed to have subpages. They are just visual separators that can have rendering in menu as a non-linkable separator, that's all. If you need subpages, you should use folders instead.

[ervaude]

Whether or not you want subpages of a menu seperator is rather a matter of taste. I've seen it in some projects. I am not a huge fan of it but I do think URL decoding should work here. Don't you?

[dmitryd]

Well, it is not a matter of taste. It is a matter of doing it right or wrong. If people do it wrong, it is not a good idea to endorse it.

Change to folder.

[dmitryd]

For example, you can say that include($_GET['file']); or 'select * from pages where uid=' . $_GET['uid'] is a matter of taste but it is not. It is about quality. Spacer is spacer, it is not a container for anything else. People should think when they make decisions. There are too many bad implementation out there just because of "matter of taste". I had to spend hours in the past fixing those "matter of taste" and customers had to pay twice: once for implementation, once for fixing it. Just do it right from start!

[ervaude]

I dont know how your examples are helping.

Thing is: Subpages of the separator doktype are not decoded if there is no cache in realurl v2. The core has no problem with URLs to those pages. Same goes for realurl v1 and even for v2 with present caches.

I just stumpled over this in a project where I cannot just change the page types. I am personally not using the separator for structuring my page tree but I know some projects that do. I thought this breaking behavior of your extension might be of interest for you.

If you don't care you may close this ticket.

[dmitryd]

You'll need to go to extension properties in 2.0.5 (in the extension manager):

There you set the checkbox to enable bad behavior 😏

I know, name is provocative but I really want people to get good habits and get rid of bad ones.

[klodeckl]

Hm, funny discussion. I think it is not well enough described, “Menu separator“ can be used for both, to separate a menu in different groups like Dmitry meant and to separate a tree into submenus. I also used it e.g. for a topnavigation because it separates a menu and it just looks better and you can better differ it from other folders for records storage. So maybe bad behavoir is not exactly correct ;-)