-
Notifications
You must be signed in to change notification settings - Fork 744
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
excluded parameters from cacheHash which change frontend output #145
Comments
I am using this now in my site package's
Currently, that adds cHashes to many URLs. I'll have a look what can be done. But rather cHashes than a misconfigured TYPO3 IMHO. |
The cHash stuff in TYPO3 is pretty problematic at all because it easily leads to frontend error pages if the cHash is wrong or no cHash is included in the URL, especially when redirecting to a payment provider at the end of a checkout or passing a f_search value for full text search. Wrong canonical URLs and wrong language switch URLs are only a minor problem in total. |
The solution without cHash is already available since 9.5. The rule is simple, if all aspects and requirements are defined fully, no cHash gets added:
A detailed description can be found at the change log https://docs.typo3.org/c/typo3/cms-core/master/en-us/Changelog/9.5/Feature-86365-RoutingEnhancersAndAspects.html?highlight=chash |
We are aware of that but things aren't that easy as described in the TYPO3 docs |
I agree that it's problematic and even that cHash is conceptually flawed. IMHO it was added to TYPO3 for the wrong reasons and in an unnecessary complex way. Yet there is one base cHash concept that holds true since the beginning: parameters are used by the Core to decide if that page's content is unique. Most of us have run into trying to just add parameters to We can remove the cHash through route parameter requirements in site config. If not possible (missing slug field or similar), it would be saner to add a custom RouteEnhancer. |
All ai[...] parameters are transparent to TYPO3 because all Aimeos plugins are marked as non-cachable and maintain their own cache using the caching framework. So whenever these parameters change, the cachable parts of the TYPO3 page are still the same. The exception may be the language menu because to switch the language and stay on the same Aimeos list or detail page, the Aimeos parameters are relevant. If we tell TYPO3 that e.g. the product ID and name for the detail page are relevant, TYPO3 will create a cache entry for each detail page even if it's always the same and this is a problem if you have a lot of products. Don't know if the canonical URLs are a problem because in TYPO3 9.5+ you only have the option to use the TYPO3 canonical URLs which are totally independent of the Aimeos plugin content or the Aimeos canonical URLs for list and detail views only (because TYPO3 canonical URLs can only be disabled completely and not at a per page level). |
I have the same problem of the cHash. I get the error "404 The page did not exist or was inaccessible. Reason: Request parameters could not be validated (&cHash empty)", in the frontend after being redirected from paypal back to the page. ( shop/confirm?action=confirm&code=demo-paypal&controller=Checkout&token=...). How can i fix this? |
Does it work if you add aimeos-typo3/ext_localconf.php Lines 313 to 331 in 359101f
|
Thank you for the suggestion. I added it to the ext_localconf.php of the aimeos extension. Performed Database update, but sorry same error. |
To make TYPO3 use a changed ext_localconf.php, you have to clear all TYPO3 caches or delete the ./typotemp/cache/ resp. ./var/cache/ directory |
I deleted the cache directory typo3temp and cleared all caches from , but same error. |
After applying this changes, also all the other payment methods like invoice are affected by the error too. |
This is a really bad idea and should be avoided at all costs:
aimeos-typo3/ext_localconf.php
Line 313 in 359101f
TYPO3 uses parameters as indication for the page's content. cHash-exclusion signals that these parameters do not change frontend output.
Excluding everything here leads to (among others):
Most probably without this a lot of other workarounds wouldn't be necessary either.
The text was updated successfully, but these errors were encountered: