Bug #63776
closed
PageRenderer Hooks are called to late with uncached objects
0%
Description
Currently there are some Hooks in PageRenderer to modify values like JavaScript, CSS and Favicon:
render-preProcess
render-postProcess
render-postTransform
I wanted to use on of them to add a cache-buster to the favicon. This works without a problem, if there are no _INT objects on the page, because these hooks are called BEFORE getPreparedMarkerArray is called, which creates the marker for the favicon.
But when there are _INT objects on the page, these hooks get called AFTER getPreparedMarkerArray was called. Then changes to the favIcon (and some other fields like baseURL) are useless, because the markers were already created.
Solution would be to ensure that these hooks are called before getPreparedMarkerArray is called. Maybe this is not possible. Then it would be nice to have another hook, which always will be called before the markers are generated and the params should be removed from the render-postProcess, because they cannot be used reliably.
Updated by Markus Klein over 9 years ago
Please push a patch to Gerrit with a suggestion.
Updated by Alexander Opitz about 6 years ago
- Status changed from New to Needs Feedback
Hi,
as this issue is very old. Is this feature still missing in newer versions of TYPO3 CMS (8.6.10)?
If yes, can you provide a patch against master by using Gerrit? https://docs.typo3.org/typo3cms/ContributionWorkflowGuide/
Updated by Robert Vock about 6 years ago
- TYPO3 Version changed from 6.2 to 8
This is still missing (or working unexpectedly) in TYPO3 8.7.10.
I am not sure, how to fix this correctly without breaking something else. I think, the main problem is, that the hooks are called at different times of the page generation, depending if the page has uncached objects or not. Also: Depending of *_INT-objects, different page-content will be saved to the page-cache.
When there are no uncached objects (no COA_INT and no USER_INT), then the hooks get called before getPreparedMarkerArray is called: PageRenderer.php#L1752
But when there are *_INT objects, getPreparedMarkerArrayForPageWithUncachedObjects is called before the hooks are called: PageRenderer.php#L1775.
Regarding the different cache entries:
Case 1 (No *_INT objects): The Markers are replaced BEFORE the page gets written to the cache:
<link rel="shortcut icon" href="/fileadmin/favicon.ico" type="image/x-icon">
<title>Publications: Example Page</title>
<link rel="apple-touch-icon" sizes="57x57" href="/apple-icon-57x57.png">
<link rel="apple-touch-icon" sizes="60x60" href="/apple-icon-60x60.png">
<link rel="apple-touch-icon" sizes="72x72" href="/apple-icon-72x72.png">
<link rel="apple-touch-icon" sizes="76x76" href="/apple-icon-76x76.png">
<link rel="apple-touch-icon" sizes="114x114" href="/apple-icon-114x114.png">
<link rel="apple-touch-icon" sizes="120x120" href="/apple-icon-120x120.png">
<link rel="apple-touch-icon" sizes="144x144" href="/apple-icon-144x144.png">
<link rel="apple-touch-icon" sizes="152x152" href="/apple-icon-152x152.png">
<link rel="apple-touch-icon" sizes="180x180" href="/apple-icon-180x180.png">
<link rel="icon" type="image/png" href="/favicon-32x32.png" sizes="32x32">
<link rel="icon" type="image/png" href="/favicon-96x96.png" sizes="96x96">
<link rel="icon" type="image/png" href="/android-icon-192x192.png" sizes="192x192">
<link rel="icon" type="image/png" href="/favicon-16x16.png" sizes="16x16">
<link rel="manifest" href="/manifest.json">
<meta name="generator" content="TYPO3 CMS">
<meta name="viewport" content="width=device-width,initial-scale=1">
<link rel="stylesheet" href="/fileadmin/example.css?1519038072">
<script src="/fileadmin/script/lib/modernizr-3.5.0.min.js?1508489033"></script>
Case 2 with a single *_INT-objects:
page.20 = USER_INT
You get the markers within the cached code and everytime the page is shown from cache, the markers again:
<link rel="shortcut icon" href="/fileadmin/favicon.ico" type="image/x-icon">
<!-- ###TITLE8338e3386b101f1e83037c18ea41f85c### -->
<!-- ###META8338e3386b101f1e83037c18ea41f85c### -->
<!-- ###CSS_LIBS8338e3386b101f1e83037c18ea41f85c### -->
<!-- ###CSS_INCLUDE8338e3386b101f1e83037c18ea41f85c### -->
<!-- ###CSS_INLINE8338e3386b101f1e83037c18ea41f85c### -->
<!-- ###JS_LIBS8338e3386b101f1e83037c18ea41f85c### -->
<!-- ###JS_INCLUDE8338e3386b101f1e83037c18ea41f85c### -->
<!-- ###JS_INLINE8338e3386b101f1e83037c18ea41f85c### -->
I think it would be better to always cache a page with the unreplaced markers but to call the hooks before replacing the markers. That way it's possible to update the cache buster when getting a page from cache. But: It will be a bit slower, because the markers are replaced everytime a page is requested.
Currently the Cache-Buster of Scripts and CSS does not get updated, if a page is loaded from cache and had no *_INT-objects. But it's possible to change the shortcutTag or favIcon in hooks called from executePostRenderHook:
PageRenderer.php#L2761
But if a page had *_INT-objects, the cache buster of Scripts and CSS gets updated BUT the favIcon or shortcutTag of executePostRenderHook cannot be replaced...
Updated by Riccardo De Contardi about 6 years ago
- Status changed from Needs Feedback to New
Updated by Robert Vock over 5 years ago
- Related to Feature #86012: Indexing of meta-tags not possible when *_INT-objects are on the page added
Updated by Christian Kuhn over 5 years ago
- Related to Bug #86234: Missing Meta Tags on Pages with *_INT objects added
Updated by Benni Mack about 4 years ago
- Status changed from New to Needs Feedback
Hey Robert,
check out this extension and its explanation for the time being: https://github.com/b13/assetcollector/blob/master/Classes/Hooks/AssetRenderer.php#L19-L35
I think most things can be done with other hooks as well, and see the ordering of the hooks when having USER_INT/COA_INT.
We will however change this part massively in TYPO3 v11, to overcome the rest of the issues related. Is that OK?
Updated by Christian Kuhn over 2 years ago
- Status changed from Needs Feedback to Closed
Closing for now: If there are action points left that can not be done using other solutions, please re-open or create fresh tickets.