[Neos] MultiColumn Cache Issue

nikos nick at jamalade.com
Sun Feb 22 16:41:27 CET 2015


Ok problem solved - there is a bug in TYPO3\TypoScript\Core\Runtime.php
This occurs when a cahched Nodetype overrides the context in it's TS using @override.

This affects uses of TYPO3.Neos:ContentCollection when a contained item is cached and uses @override ge if you nest a TYPO3.Neos.NodeTypes:TwoColumn 
or if you placed another cached Node that uses @override.

The problem is in the Runtime.php in method :
protected function evaluateInternal($typoScriptPath, $behaviorIfPathNotFound, $contextObject = NULL)

And happens because if @override is specified a new copy of the context is pushed onto the rendering stack, however if the tsObject is found to be 
cached there is a (early) return out of the method (evaluateInternal) without popping the context. The early return byspasses a check later which pops 
the stack and messes up the rendering stack and leads to unspected rendering as in earlier post and the disabling of  edits on effected nodes in the 
neos back end.

[php]
   // Here is the code currently
   if (isset($typoScriptConfiguration['__meta']['override'])) {
     $contextArray = $this->getCurrentContext();
     foreach ($typoScriptConfiguration['__meta']['override'] as $overrideKey => $overrideValue) {
       $contextArray[$overrideKey] = $this->evaluateInternal($typoScriptPath . '/__meta/override/' . $overrideKey, self::BEHAVIOR_EXCEPTION, $tsObject);
     }
     $this->pushContextArray($contextArray);
   }

   list($cacheHit, $cachedResult) = $runtimeContentCache->preEvaluate($cacheCtx, $tsObject);
   if ($cacheHit) {
     $finallyClosure();
     return $cachedResult;
   }
   ...
[/php]

The proposed bugfix if the tsObject is in the cache test for the override and pop the context ie.
[php]
if ($cacheHit) {
     // if the tsObject is in the cache and @override is specified we have to pop the context
     if (isset($typoScriptConfiguration['__meta']['override'])) {
       $this->popContext();
     }
     $finallyClosure();
     return $cachedResult;
   }
[/php]

I have tested the above which works with no unexpected side effects.

I will report this on Jira, but as I am not a committer I will not be able to submit the change - but would really appreciate if this fix could be 
pushed through. Maybe one of the core team could advise me of the best way forward with this.

Many thanks

Nikos


On 17/02/2015 12:08, nikos wrote:
>
>
> I have hit a Neos backend  cache/rendering problem which seems to occur with TYPO3.Neos.NodeTypes:MultiColumn using any of:
>    TYPO3.Neos.NodeTypes:TwoColumn
>    TYPO3.Neos.NodeTypes:ThreeColumn
>    TYPO3.Neos.NodeTypes:FourColumn
>
> The problem seems only occur when one of the above has two or more content elements which are separately cached. I can reproduce it by nesting the
> above or with separately cached nodetypes eg
> TYPO3.Neos.NodeTypes:TwoColumn -> column0 -> TYPO3.Neos.NodeTypes:TwoColumn , TYPO3.Neos.NodeTypes:TwoColumn
> TYPO3.Neos.NodeTypes:TwoColumn -> column1 -> empty
>
> or
> TYPO3.Neos.NodeTypes:TwoColumn -> column0 -> MyCachedNodeType, MyCachedNodetype
> TYPO3.Neos.NodeTypes:TwoColumn -> column1 -> empty
>
>
> The problem occurs if anything is edited from the outer TYPO3.Neos.NodeTypes:TwoColumn down. It appears that the wrong node is used to wrap the outer
> TYPO3.Neos.NodeTypes:TwoColumn, for the backend, more specifically the nodedata for TYPO3.Neos.NodeTypes:TwoColumn -> column0 is used. The result is
> that the Ember overlay is displayed which makes it impossible to do any further edits.
> An example showing correct and incorrect html output can be seen here [uri]http://pastebin.com/Brxb49bQ[/uri].
>
> I have tried debugging the code to try and pinpoint the problem, but because of the deep nesting it is quite difficult to keep track of whats going
> on. The problem manifests between TYPO3\Neos\Service\ContentElementWrappingService.php TYPO3\Neos\TypoScript\ContentElementWrappingImplementation.php
> But I can't figure why it's the wrong 'node'.
>
> I would really appreciate
> 1) if someone could confirm that the problem is reproducible (to rule out my setup, Neos 1.2.1 & 1.2.2) although I have tried on two different
> platforms centos & macos)
> 2) if someone could help me better understand the rendering process so that I can identify and fix the problem assuming 1) above.
>
> Many thanks
>
> Nikos



More information about the Neos mailing list