Bug #53352
Template Analyzer produces wrong results
Status: | Resolved | Start date: | 2013-11-05 | |
---|---|---|---|---|
Priority: | Should have | Due date: | ||
Assigned To: | - | % Done: | 100% |
|
Category: | - | Spent time: | - | |
Target version: | next-patchlevel | |||
TYPO3 Version: | 4.7 | Is Regression: | Yes | |
PHP Version: | Sprint Focus: | |||
Complexity: |
Description
Running through the Template Analyzer I noticed some weird and unexpected results.
Selecting an included template on the top does show Constants plus Setup from the corresponding template.
The Content of the Constants is fine and does match the Template.
The Content of the Setups is borked. It seems to contain the content of the previous template. Seems like some index is used wrong and introduces a -1 offset.
As I have just noticed it on one installation I am not sure wether it needs something else to trigger this.
Related issues
Associated revisions
[BUGFIX] Add defaultTypoScript to hierachyInfo
Fixes a problem with the TemplateAnalyzer introduced by #43540
- Always add both defaultTypoScript_setup and defaultTypoScript_constants.
- Add information for defaultTypoScript into hierarchyInfo.
Change-Id: I15ad5f268eb167d6c8f027e1891409d9ead64539
Resolves: #53352
Releases: 6.2, 6.1, 4.7
Reviewed-on: https://review.typo3.org/26738
Reviewed-by: Markus Klein
Reviewed-by: Michiel Roos
Tested-by: Michiel Roos
Reviewed-by: Stefan Neufeind
Reviewed-by: Benjamin Mack
Tested-by: Benjamin Mack
[BUGFIX] Add defaultTypoScript to hierachyInfo
Fixes a problem with the TemplateAnalyzer introduced by #43540
- Always add both defaultTypoScript_setup and defaultTypoScript_constants.
- Add information for defaultTypoScript into hierarchyInfo.
Resolves: #53352
Releases: 6.2, 6.1, 6.0, 4.7, 4.5
Change-Id: I5d76bd092b1a8f509c90849774e916c7fd83b438
Reviewed-on: https://review.typo3.org/26804
Reviewed-by: Benjamin Mack
Tested-by: Benjamin Mack
[BUGFIX] Add defaultTypoScript to hierachyInfo
[BUGFIX] Add defaultTypoScript to hierachyInfo
Fixes a problem with the TemplateAnalyzer introduced by #43540
- Always add both defaultTypoScript_setup and defaultTypoScript_constants.
- Add information for defaultTypoScript into hierarchyInfo.
Resolves: #53352
Releases: 6.2, 6.1, 6.0, 4.7, 4.5
Change-Id: I97d8237a9d665188eb9f5db06d47d8403ba5aca5
Reviewed-on: https://review.typo3.org/26805
Reviewed-by: Benjamin Mack
Tested-by: Benjamin Mack
History
#1 Updated by Christian Kuhn over 1 year ago
Seen that too, tried to dig into it. Seems to be a weird behavior in the parser itself.
#2 Updated by Peter Niederlag over 1 year ago
[UPDATE: this is irrelevant for the bug! ~pn]
don't know if that is related but I just noticed that single line of comment followed by multiline comment the multiline comment is not recognized as comment and evaluated as typoscript
// fix/change innerWrap /* tt_content.stdWrap.innerWrap.cObject.default.20.10 > tt_content.stdWrap.innerWrap.cObject.default.20.10 = COA tt_content.stdWrap.innerWrap.cObject.default.20.10 { 10 = CASE 10 { default.field = CType key = CType stdWrap.noTrimWrap = || | } } */
also the code is in multiline comment it will be "executed"
#3 Updated by Christian Kuhn over 1 year ago
This is getting more weird.
On one system i can reproduce this by loading felogin, if unloading, the issue is gone, on another system that does not work.
At the moment I either suspect something with packages and states or with Peters idea of a broken comment parser.
#4 Updated by Torben Hansen over 1 year ago
I can also reproduce this on TYPO3 4.7. When I click on an extension template in the template analyzer, the constants seem to show correctly, but the setup is wrong and always shows the TS setup from the previous element.
#5 Updated by Torben Hansen over 1 year ago
The bug came with #43540. In this change $this->addDefaultTypoScript() has been added at the end of to the function runThroughTemplates().
When I remove $this->addDefaultTypoScript() in line 419, everything seems to work fine again. IMHO this line has been added by mistake and should be removed again, since the default TS is added later by generateConfig().
This bug affects all supported TYPO3 versions.
#6 Updated by Peter Niederlag over 1 year ago
just FYI, I am still digging into it and probably come up with a patch today
#7 Updated by Matthias Süncksen over 1 year ago
I'm seeing it in 4.7.17 where I believe the bugfix for #43540 is included. Is it a regression bug with the TS-caching fix breaking the template analyzer ?
In the original report of #43540 it is said that the Install tool may set $GLOBALS['TYPO3_CONF_VARS']['FE']['defaultTypoScript_setup']. But it appears much more being dynamically filled by class.t3lib_extmgm.php:addTypoScript() through some installed extensions (i.e. fe_login), so it's no option trying to clear the variable.
#8 Updated by Ernesto Baschny over 1 year ago
- Status changed from New to Accepted
- Target version set to next-patchlevel
- TYPO3 Version changed from 6.2 to 4.7
- Is Regression changed from No to Yes
This is indeed a regression introduced by #43540 (included in 4.7, 6.0, 6.1 and master). So this has to be fixed in master and the fix backported to 4.7.
Note that the performance enhancement hasn't been merged in 4.5 yet.
#9 Updated by Peter Niederlag over 1 year ago
I have spent days on this matter already. The basic problem is that the count of the arrays with typoscript and template-information don't match any longer due to the patch of #43540.
$GLOBALS['tmpl']->hierarchyInfo // array with template information $GLOBALS['tmpl']->constants // array with constants per template $GLOBALS['tmpl']->config // array with setup per template
- The BE TypoScript Tools always expect a corresponding pair of setup[config]/constants. If the content of these are checked for empty string individually then it happens that information doesn't match. Solution would be to always add both when one of it is not empty.
- As we now prepend entries to ->constants and ->config in addDefaultTypoScript() we should also prepend proper information to ->hierarchyInfo (adding the default TypoScript to the templates shown in the template analyzer) or ignore the first template in template tools.
I am also working on fixing some anoying problems with wrong line-numbers that's why it is taking rather long time in these dark parts of the code.
The patch/patchs will be ready soon.
#10 Updated by Gerrit Code Review over 1 year ago
- Status changed from Accepted to Under Review
Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26738
#11 Updated by Gerrit Code Review over 1 year ago
Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26738
#12 Updated by Gerrit Code Review over 1 year ago
Patch set 3 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26738
#13 Updated by Gerrit Code Review over 1 year ago
Patch set 4 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26738
#14 Updated by Gerrit Code Review over 1 year ago
Patch set 1 for branch TYPO3_6-1 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26804
#15 Updated by Gerrit Code Review over 1 year ago
Patch set 2 for branch TYPO3_6-1 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26804
#16 Updated by Gerrit Code Review over 1 year ago
Patch set 1 for branch TYPO3_6-0 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26805
#17 Updated by Gerrit Code Review over 1 year ago
Patch set 1 for branch TYPO3_4-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26806
#18 Updated by Anonymous over 1 year ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset df52d4a8ca1dd193e04fc7c7ea751dd3d7bf7fb5.