Cache problems using the type parameter

[weberdigital]

Hi Dmitry,

using the realurl version 2.0.15 we faced the problem that the USER plugins, e.g. news plugin, don’t deliver the correct cached content in every situation.

When we deploy the realurl version 2.1.4 the problems concerning that issue was gone. Yeah!. But now we faced a new problem which is probably related to this.

When we request the page which has a USER plugin on it with the type-parameter the cached content won't be correct in any case.

We've done some debugging's here: https://github.com/dmitryd/typo3-realurl/blob/2.1.4/Classes/Decoder/UrlDecoder.php#L1500 When we request the page with the type-parameter the cHash won't returned. Maybe that's the case and helps solving the issue. E.g.: https://www.example.com/news/article/news-title/ => id=22&tx_news_pi1[news]=123&cHash=14b0dfd61b9ff96f875774db29d3ca7d https://www.example.com/news/article/news-title/?type=42 => id=22&tx_news_pi1[news]=123&type=42

Or maybe the realurl cache entry should contain the type parameters?!

Can you please check this? It's really important, because we can't use our pages without the feature of the TYPO3-type-parameter.

Thx.

[droomdre]

I have the same problem using parameter like "utm_source". This ist automatically configured in [FE][cHashExcludedParameters] but calling a url with this param, the chash is missing too. Can u confirm please if u also have issue using "utm_source"? Changing to "utm_sourrrrce" should normally throws a 404 which is not the case.

[dmitryd]

Realurl does not create cHash. cHash is created by TYPO3 and passed to realurl. However type is excluded from cHash calculation. There is nothing that realurl can do about it.

For the https://www.example.com/news/article/news-title/?type=42 => id=22&tx_news_pi1[news]=123&type=42, you should remove such URLs manually from the cache. They could be added by realurl versions 2.0.15-2.1.4 during decoding. Now decoding does not add any cache entries and such problem should not appear.

[nixahnung]

We had the same problem after upgrade to version 2. It seems that following happens:

table tx_realurl_urldata: original_url: id=123 speaking_url: somepage.html

same time 2nd entry: original_url: id=123&type=343 speaking_url: somepage.html

i think this is the problem. So we never get original pagetype again after the other entry is created.

my Workaround quick and dirty was to add

'cache' => array (
	'ignoredGetParametersRegExp' => '/^(?:utm_[a-z]+|pk_campaign|pk_kwd|type)$/',
),

to my realurlconfig.

Maybe you can say more about it? Thanks for feedback.

[neufeind]

The fix with ignoredGetParametersRegExp to ignore "type" works for me as well, in a somewhat related case. That prevents generating new url-cache-entries with one or the other "type"-parameter. And the cHash still works since type (as well as id, L, MP, ...) is a core-parameter (see isCoreParameter()) in the cHash-calculation. So those calls with different type=... get cached independently by the FE-cache and the cHash is still valid.

[neufeind]

PS: Problem appeared here with 2.1.5 and with the url-cache cleared.

[weberdigital]

We also could confirm that using the config "cache/ignoredGetParametersRegExp" with the additional parameter "type" solves our cases. So maybe the "type" parameter should be added in that default configuration in the extension?!

[dmitryd]

Different types should generate different URLs. If it generates the same URL for different types, it means something is missing in the configuration.

This is not possible to solve unless I have more information.

[mario-naether]

@nixahnung @dmitryd Thank you, the "cache/ignoredGetParametersRegExp" fix works also with me perfectly. Which more information to you need to solve the issue?

[dmitryd]

Problem appeared here with 2.1.5 and with the url-cache cleared.

When you clear realurl cache, you make realurl blind and it has to work hard to guess what the actual url was. So fi you think you clear cache and it will do anything good, you are seriously mistaken :) You should never clear realurl tables unless you are 101% know why you do this.