Save REQUEST_URI into tx_realurl_urldata and tx_realurl_pathdata

[webian]

Hello @dmitryd, as a feature request, could be a good idea to save into tx_realurl_urldata and tx_realurl_pathdata the REQUEST_URI of the page that generated a Realurl cache entry? It could be useful to understand how a certain malformed url as been generated.

[dmitryd]

This can be useful for debugging only but for production it will only make table grow larger and slow down the whole thing. There was a similar feature for v1: tx_realurl_chashcache had a field, which was null by default but could also get source url if a special flag was activated. Vut I am not sure how you want to diagnose "malformed" URLs and what you mean by malformed URLs.

[webian]

Maybe "malformed" is not the right word but I mean those URLs that have an unexpected entry in tx_realurl_chashcache. By instance I have some url with an original_url like: id=98&tt_products[product]=631 and it's speaking_url like: path/of/page/prod/product-name/ this entry has tt_products[product] set but not the cHash and this, as far as I understood and seen, leads to unpredictable Realurl behaviors like wrong detail page of a product. Also I found that there are duplicated entries equal but with the cHash, this lead to even more confusion for Realurl. Sometimes I'm able to understand how this URL has been generated but lately it has become more hard because the culprit is less obvious. So I quickly implemented this new field request_uri in tx_realurl_chashcache that is filled in method putUrlToCache and enabled it in production and it helped me understand where the problem is. I know and agree with you that it can worsen a little the performances, but I also find it useful.

[dmitryd]

this entry has tt_products[product] set but not the cHash and this, as far as I understood and seen, leads to unpredictable Realurl behaviors like wrong detail page of a product.

Yes but this should be mitigated by recent changes in the development version for plugins that call $TSFE->reqCHash().

Also I found that there are duplicated entries equal but with the cHash, this lead to even more confusion for Realurl.

Yes, one of them (without cHash) is created by the decoder and a proper one (with cHash) is creted by the encoder. Again, it should be better in the current development version, though it may still happen.

[webian]

I'm investigating the problem and I will open an issue with a better description if I find out that could be caused or better mitigated by Realurl, but atm I think that is more a tt_products problem than Realurl.

This issue was just for this feature request but if you find that it's not a good idea then no problem, we can close this :)