Bug #44825
closedPagerenderer / page.headerData + USER_INT is not working
Added by Bas van Beek almost 12 years ago. Updated over 6 years ago.
100%
Description
This does not work (USER_INT):
page.headerData.2002 =< plugin.tx_multishop_pi1
page.headerData.2002 {
userFunc = tx_multishop_pi1->main
method=meta_tags
}
Outputs:
Apparently the marker is not replaced with the dynamic content.
Below example works, but is obvious a cached version and that is not desired:
page.headerData.2002 < plugin.tx_multishop_pi1
page.headerData.2002 = USER
page.headerData.2002 {
userFunc = tx_multishop_pi1->main
method=meta_tags
}
Will USER_INT work again on page.headerData in the next TYPO3 update?
Updated by Bas van Beek almost 12 years ago
I tried it with the official TYPO3 6.0 and the latest version of 6.1, both downloaded today. The latest commit hash of 6.1 is:
[root@baslaplinux Core]# git rev-parse --short HEAD
43ade89
Updated by Bas van Beek almost 12 years ago
Do you need additional feedback to reproduce this missing feature?
Updated by Christian Buelter almost 12 years ago
I could reproduce this on a TYPO3 6.0.0 Government package using the extension ke_stats.
Adding
page.headerData.100 < plugin.tx_kestats_pi1
to the Typoscript Setup results in
<!--INT_SCRIPT.6fb024cc290a3d12e287e3fe414af811-->
in the frontend while it should normaly output nothing but count the page view.
Updated by Bas van Beek almost 12 years ago
Excellent Christian,
What are the next steps to solve this issue? Cause without this fixed feature Multishop will not work on TYPO3 6.X.
Thanks!
Updated by Stefan Galinski almost 12 years ago
- Status changed from New to Accepted
- TYPO3 Version changed from 6.1 to 6.0
Updated by Jonathan Heilmann almost 12 years ago
By accident, i found a workaround for ke_stats 1.1.1, tested within TYPO3 CMS 6.0.2 and 6.0.4
Just replace the line
page.headerData.100 < plugin.tx_kestats_pi1
by
page.100 < plugin.tx_kestats_pi1
Updated by Jelle Groenendal almost 12 years ago
Confirmed workaround on 6.0.2 for plugin.tx_kestats_pi1
Updated by Bas van Beek almost 12 years ago
Yeah I also confirm. Multishop 3 is working flawless in TYPO3 6.0.4, so this issue can be updated to resolved!
Updated by Bas van Beek almost 12 years ago
I cheered to early.
It's not yet working well in TYPO3 6.0.4. The problem is that we want the USER_INT output to be processed by pagerenderer as headerData, so the output gets inside the <head> of the document.
In your tweak the output is just printed in the body of the document. For stats that don't need to print anything that's fine. But for plugins that want to add content to the head it's no solution.
Updated by Arek van Schaijk over 11 years ago
I also run into this problem. I tested it with TYPO3 6.0.5rc1, this ticket is now open for a couple of months why isnt it solved yet?
I use the following work around for my extbase extension wich also works fine in earlier versions of TYPO3:
page.100 < plugin.tx_myext
And in my controller:
$this->response->addAdditionalHeaderData('header content');
Updated by Bas van Beek over 11 years ago
No idea why this issue cannot be resolved.
I asked one of the TYPO3 development team members, he said he did not know whether the team is still working on this issue or not.
Updated by Mario Beiser over 11 years ago
I only can second that. Not able to inject USER_INT objects. Is this planned to remove?
Didn't found any info on that.
Updated by Georg Ringer over 11 years ago
a start to debug
This is a simple TS for testing
page = PAGE page.10 = TEXT page.10.value = HELLO WORLD! page.20 = TEXT page.20.data= date:U page.20.strftime = %H:%M:%S page.30 = COA_INT page.30 { 10 < page.20 stdWrap.wrap = ....|.... } page.headerData.10 = COA page.headerData.10 { 10 = COA_INT 10 { stdWrap.wrap = coa_int: | ---------- 10 < page.20 } 20 = COA 20 { stdWrap.wrap = coa: | ---------- 10 < page.20 } }
Problem is that TypoScriptFrontendController
got a function INTincScript_process
to process the INT_SCRIPT snippets but only $this->content is checked which is just the body and not the header. therefor it stays unsubstituted.
I really don't know if that is such simple but changing in PageGenerator
from
$pageRenderer->addBodyContent(LF . $pageContent);
if (!empty($GLOBALS['TSFE']->config['INTincScript']) && is_array($GLOBALS['TSFE']->config['INTincScript'])) {
// Store the serialized pageRenderer in configuration
$GLOBALS['TSFE']->config['INTincScript_ext']['pageRenderer'] = serialize($pageRenderer);
// Render complete page, keep placeholders for JavaScript and CSS
$GLOBALS['TSFE']->content = $pageRenderer->renderPageWithUncachedObjects($GLOBALS['TSFE']->config['INTincScript_ext']['divKey']);
} else {
// Render complete page
$GLOBALS['TSFE']->content = $pageRenderer->render();
}
// Ending page
if ($GLOBALS['TSFE']->pSetup['frameSet.']) {
$GLOBALS['TSFE']->content .= LF . '</noframes>';
}
to
$pageRenderer->addBodyContent(LF . $pageContent);
if (!empty($GLOBALS['TSFE']->config['INTincScript']) && is_array($GLOBALS['TSFE']->config['INTincScript'])) {
// Store the serialized pageRenderer in configuration
$GLOBALS['TSFE']->config['INTincScript_ext']['pageRenderer'] = serialize($pageRenderer);
// Render complete page, keep placeholders for JavaScript and CSS
$GLOBALS['TSFE']->content = $pageRenderer->renderPageWithUncachedObjects($GLOBALS['TSFE']->config['INTincScript_ext']['divKey']);
# ---------
$GLOBALS['TSFE']->content = $pageRenderer->render();
# ---------
} else {
// Render complete page
$GLOBALS['TSFE']->content = $pageRenderer->render();
}
// Ending page
if ($GLOBALS['TSFE']->pSetup['frameSet.']) {
$GLOBALS['TSFE']->content .= LF . '</noframes>';
}
makes it working.
all tested with current master
Updated by Markus Klein over 11 years ago
The problem here is some sort of chicken-egg.
At the point in time where the INT_SCRIPTs are processed the page content does not yet contain the header and footer data, to allow the scripts to dynamically add these.
Unfortunately these header data might again contain INT_SCRIPTs which are not processed then.
A solution would be to repeatedly insert the header and footer data into the page content and run the INT_SCRIPT processing.
Updated by Gerrit Code Review over 11 years ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/23788
Updated by Gerrit Code Review over 11 years ago
Patch set 2 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/23788
Updated by Gerrit Code Review over 11 years ago
Patch set 3 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/23788
Updated by Gerrit Code Review over 11 years ago
Patch set 4 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/23788
Updated by Gerrit Code Review over 11 years ago
Patch set 5 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/23788
Updated by Helmut Hummel over 11 years ago
Bas van Beek wrote:
It's not yet working well in TYPO3 6.0.4. The problem is that we want the USER_INT output to be processed by pagerenderer as headerData, so the output gets inside the <head> of the document.
In your tweak the output is just printed in the body of the document. For stats that don't need to print anything that's fine. But for plugins that want to add content to the head it's no solution.
An easy way to go would be to not return the wanted headerData as content but use the following in the code:
$GLOBALS['TSFE']->additionalHeaderData['your_plugin_asset'] = $dynamicHaderContent;
This worked in 4.0 already and will also work in 6.x
But I agree that using COA_INT in page.headerData should also work, so I created a patch which enable this functionality again.
Please test the latest patch if it works for you.
However please note, that
$GLOBALS['TSFE']->additionalHeaderData['your_plugin_asset'] = $dynamicHaderContent;
in a PHP method added to page.headerData as USER_INT will not work. It never worked before and we will not make it work as it introduces a chicken/egg problem which is not easily fixable and not worth the overhead.
Updated by Helmut Hummel over 11 years ago
- Assignee set to Helmut Hummel
- Target version changed from 6.1.0 to next-patchlevel
- % Done changed from 0 to 90
OK. Can anybody of the 44 voters of this issue please test and comment the patch?
Thanks.
Updated by Helmut Hummel over 11 years ago
- Status changed from Under Review to Needs Feedback
- Is Regression changed from No to Yes
Helmut Hummel wrote:
OK. Can anybody of the 44 voters of this issue please test and comment the patch?
No Feedback?
Updated by Gerrit Code Review over 11 years ago
- Status changed from Needs Feedback to Under Review
Patch set 1 for branch TYPO3_6-1 has been pushed to the review server.
It is available at https://review.typo3.org/23981
Updated by Gerrit Code Review over 11 years ago
Patch set 1 for branch TYPO3_6-0 has been pushed to the review server.
It is available at https://review.typo3.org/23982
Updated by Helmut Hummel over 11 years ago
- Status changed from Under Review to Resolved
- % Done changed from 90 to 100
Applied in changeset be4627f5651a74847f9920a35d0ddfdc22bec4a9.