TYPO3 Core

Correct. I recently had to implement a UidMapper, because I simply wanted the uid. (okay I could have used the PersistedPatternMapper, but this would really be overkill)

Any class that implements StaticMappableAspectInterface will help to get rid of cHash.

Simply implement this empty interface in your own classes and that's it.

Funny to see how old good realurl was able to do it for years and new shiny routing can't... Well, I guess this is how it is now.

Dmitry Dulepov wrote in #note-5:

Funny to see how old good realurl was able to do it for years and new shiny routing can't... Well, I guess this is how it is now.

This is not helpful, and it is not true that this is not possible with the core routing - it just has to be explicit.

There have been so many issues with "good old RealURL" and cHash "handling" - URL params were stored in a big database table during generation, with that implication that those links did NOT work without cHash when a corresponding page has not been rendered before. As a consequence people used ?no_cache=1 (the famous /nc/ segment in RealURL) everywhere on these sites.

There have been so many issues with "good old RealURL" and cHash "handling" - URL params were stored in a big database table during generation, with that implication that those links did NOT work without cHash when a corresponding page has not been rendered before. As a consequence people used ?no_cache=1 (the famous /nc/ segment in RealURL) everywhere on these sites.

This all was true for RealURL 1.x but none of this is true for RealURL 2.x. It still stores urls in the database but it is far more compact and I believe it is better to cache them then resolve them each time. But opinions can vary, of course.

What I observed in RealURL 2.x is the following - cHash stored in database, in a cache (which never must be cleared)

MariaDB [db]> SELECT * FROM tx_realurl_urldata WHERE uid=1867181\G
*************************** 1. row ***************************
          page_id: 48
      rootpage_id: 1
     original_url: cHash=3cb40abf128b705d2737fb9db1a9a201&id=48&no_cache=1&tx_news_pi1[action]=detail&tx_news_pi1[controller]=News&tx_news_pi1[news]=1860
     speaking_url: nc/details/redacted-news-title/
request_variables: {"id":"48","no_cache":"1","tx_news_pi1[news]":"1860","tx_news_pi1[controller]":"News","tx_news_pi1[action]":"detail","cHash":"3cb40abf128b705d2737fb9db1a9a201"}
           expire: 0
original_url_hash: 426435945
speaking_url_hash: 3535921288

With TYPO3 v9 it is possible to omit the intermediate cache layer, however it has to be configured explicitly by using mappers that implement StaticMappableAspectInterface. That's it, being explicit about the application behavior.

What I observed in RealURL 2.x is the following - cHash stored in database, in a cache (which never must be cleared)

Yes, this is correct but it is only a part of the picture.

RealURL 1.x had a separate table for cHash and we observed it could grow to huge sizes (like 20Gb) and contain values completely unrelated to actual urls. There were also separate tables for encoding and decoding where URLs were duplicate and could also go out of sync.

RealURL 2.x had a different way. It stored complete URLs there in more compact format, without duplicates and it took care to clean up. There was also a version, which tried to resolve cHash if it was missing but this part was banned by the security team and crippled RealURL a lot.

What I am saying is: a new framework should definitely be better than the old framework. RealURL did not have any support from the core in its work, it was outside of the core. But it was fast at resolving URLs and it handled cHash automatically. Routing is deeply integrated into the core but cHash handling is not automatic. I see this as a step back that should be improved. This is why this ticket was created. Customers hate cHash. So I believe TYPO3 should handle it automatically without asking every dev to create explicit config to get rid of cHash. Is it not natural to want the new system be better than the previous one in all features?

Sorry if my expectations are not realistic.

Oliver Hader wrote in #note-8:

What I observed in RealURL 2.x is the following - cHash stored in database, in a cache (which never must be cleared)

And by the way, that configuration with `nc` was not needed and it is incorrect anyway. If people explicitly say "no_cache", it is not a fault of RealURL, it is a choice of a certain person and the person is responsible for this, not the code. Absolutely nothing stops you from doing the same useless thing with new routing.

I myself never used did not use `no_cache` in projects since 6.x. No idea why people do it. Everything works fine without it.

This discussion is not taking us anywhere, I think we're done here. Anyway, thanks for sharing your thoughts.