Bug #44270
closedwrong result in substituteMarkerArrayCached
100%
Description
After some usage of the function it ends up in an error message.
Core: Error handler (FE): PHP Warning: Invalid argument supplied for foreach() in /var/www/mydomain/typo3_src-4.7.7/typo3/sysext/cms/tslib/class.tslib_content.php line 1727
Which is the line:
foreach ($storeArr['k'] as $n => $keyN) {
The debug information is:
class.tslib_content.php 1678:
$storeArrDat = $GLOBALS['TSFE']->sys_page->getHash($storeKey);
a:2:{s:1:"c";b:0;s:1:"k";N;}
$storeArrDat after sys_page->getHash (string)
So the $storeArr is an array of k and c with empty values. This causes the next foreach to crash.
In such a case the "if (!isset($storeArrDat)) {" branch should have been reached.
However this still won't work because after some modification it ends up in:
Core: Error handler (FE): PHP Warning: preg_split(): Compilation failed: regular expression is too large at offset 32848 in /var/www/mydomain/typo3_src-4.7.7/typo3/sysext/cms/tslib/class.tslib_content.php line 1708
So for this issue: It should not throw the foreach error but another details error message in order to know about the wrong preg_split function.
Files
Updated by Mathias Schreiber almost 10 years ago
- Status changed from New to Needs Feedback
- Assignee set to Mathias Schreiber
- Is Regression set to No
Hi Franz,
I have next to noone still using the ### logic.
Are you up to supplying a patch so we get this one figured out?
Updated by Franz Holzinger over 9 years ago
This bug is still present in TYPO3 6.2
Core: Error handler (FE): PHP Warning: preg_match_all(): Compilation failed: regular expression is too large at offset 32814 in /path/typo3_src-6.2.11/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php line 1881 Core: Error handler (FE): PHP Warning: Invalid argument supplied for foreach() in /path/typo3_src-6.2.11/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php line 1896
I will try to add a patch to this bug tracker.
Updated by Alexander Opitz about 9 years ago
Hi Franz,
what's the state of this issue?
Updated by Franz Holzinger about 9 years ago
I will write a patch in September 2015.
Updated by Franz Holzinger about 9 years ago
- File patch-44270.diff patch-44270.diff added
This patch solves this issue for most cases. In a normal case this error message occurs because the TYPO3 extension calls substituteMarkerArrayCached with a big array $markContentArray. Many markers shall be replaced if found. However most of those markers will never be existent on the page.
The solution checks for the list of really existing markers in the content. Then only those are used for the following regular expression call. The other markers won't be needed on this page or for the output of this TYPO3 extension. By this way the problematic preg_split will now have a much smaller regular expression: about 100 markers instead of 1200 before.
If there is a case which has more than 1024 used markers on a page, then this patch would still fail. I could write another patch if this is really necessary. Then the content must be divided into several parts.
Updated by Alexander Opitz about 9 years ago
- Assignee changed from Mathias Schreiber to Franz Holzinger
Can you please push this patch to Gerrit?
Updated by Gerrit Code Review almost 9 years ago
- Status changed from Needs Feedback 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/45097
Updated by Gerrit Code Review almost 9 years ago
Patch set 1 for branch TYPO3_6-2 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/45132
Updated by Markus Klein almost 9 years ago
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
Applied in changeset ac77e26331d94ed0521b30fdb5e70fe67fd1fffa.
Updated by Franz Holzinger almost 9 years ago
I have found a case, where the function runs into a PHP warning.
Core: Error handler (FE): PHP Warning: Invalid argument supplied for foreach() in /var/www/web50/web/typo3_src-6.1.12/typo3/sysext/frontend/Classes/ContentObject/ContentObjectRenderer.php line 1823
$storeArrDat = $GLOBALS['TSFE']->sys_page->getHash($storeKey);
$storeArrDat:
a:0:{}
// Traversing the keyList array and merging the static and dynamic content
foreach ($storeArr['k'] as $n => $keyN) {
$storeArr is empty in this case.
No PHP warning should be given in this case.
Updated by Franz Holzinger almost 9 years ago
I have found another error related to the last patch.
If you have a $content parameter for substituteMarkerArrayCached which has no marker at all, then an empty result is given back. This is wrong. The full $content must be returned.
Do not store into the cache with substMarkerCache if the result of preg_match_all is 0 or FALSE or $usedMarkers is empty. This will solve this issue.
$storeArr['c'] = preg_split($regex, $content);
$storeArr['k'] = $keyList[0];
}
if (!empty($storeArr)) {
// Setting cache:
$this->substMarkerCache[$storeKey] = $storeArr;
// Storing the cached data:
$GLOBALS['TSFE']->sys_page->storeHash($storeKey, serialize($storeArr), 'substMarkArrayCached');
$GLOBALS['TT']->setTSlogMessage('Parsing', 0);
}
}
} else {
// Unserializing
$storeArr = unserialize($storeArrDat);
// Setting cache:
$this->substMarkerCache[$storeKey] = $storeArr;
The $content must be returned without any change if no marker is inside of it.
if (
isset($storeArr['k'])
) {
$content = '';
// Traversing the keyList array and merging the static and dynamic content
foreach ($storeArr['k'] as $n => $keyN) {
$content .= $storeArr['c'][$n];
if (!is_array($valueArr[$keyN])) {
$content .= $valueArr[$keyN];
} else {
$content .= $valueArr[$keyN][intval($wSCA_reg[$keyN]) % 2];
$wSCA_reg[$keyN]++;
}
}
$content .= $storeArr['c'][count($storeArr['k'])];
$GLOBALS['TT']->pull();
}
return $content;
}
Updated by Alexander Opitz almost 9 years ago
Please create a new issue and referee to this one. Thanks.
Updated by Morten Haggren over 8 years ago
Markus Klein wrote:
Applied in changeset ac77e26331d94ed0521b30fdb5e70fe67fd1fffa.
This patch has the unfortunate side effect of requiring markers to be wrapped in ###, where as before you were free to use any or none.
Not only does this break old addons using that feature with no warning, but the requirement does not appear in the API