[TYPO3-core] RFC: #15094: Refactor of content objects of tslib_content

[Ernesto Baschny [cron IT]]

Hi Ingo,

nice explanation, thanks a lot for investigating this issue. Takes some
brainwork to understand the lifecycle of the contentObjects, but it
looks ok: On the clone they are then recreated (on demand) and will
point to the new cObject as expected.

It reads ok, and if it made that extension work again without changing
its code, I would say, go ahead and commit!

Cheers,
Ernesto

Ingo Renner schrieb am 25.11.2010 15:46:

> as I found out this refactoring can cause major trouble when cloning
> tslib_cObj instance.
> 
> Bug tracker reference: http://bugs.typo3.org/view.php?id=16568
> 
> Thanks to Joey for pointing me to PHP's reference on cloning objects and
> having it read again I stumbled over the important points:
> 
> http://php.net/__clone :
> 
> "When an object is cloned, PHP 5 will perform a shallow copy of all of
> the object's properties. Any properties that are references to other
> variables, will remain references."
> 
> This means that, when cloning an instance of tslib_cObj, PHP (in the
> nature of a clone) copies all the properties of the original instance to
> the clone instance.
> 
> $original->contentObjects contains references to instances of
> tslib_content_*, these instances of tslib_content_* have back references
> to their parent tslib_cObj instance. Now when cloning, instead of
> pointing to the new $clone tslib_cObj instance, these tslib_content_*
> instances still point the $original tslib_cObj. This causes major
> problems resulting in rendering of the frontend hitting maximum
> execution time or memory limits and still not rendering the expected
> content.
> 
> 1)
> ==============================================================================
> 
> $cObjA (tslib_cObj) <------------------------|
> |                                            |
> |$cObjA->contentObjects[]                    |
> |--------------> CASE (tslib_content_Case) --|
> |--------------> USER (tslib_content_User) --|
> |--------------> HTML (tslib_content_Html) --|
> |--------------> TEXT (tslib_content_Text) --|
> 
> 2)
> ==============================================================================
> 
> $cObjB = clone $cObjA;
> 
> 3)
> ==============================================================================
> 
> $cObjA (tslib_cObj) <------------------------|
> |                                            | $cObjA->contentObjects[]!
> |                                            |             ^
> |--------------> CASE (tslib_content_Case) --|  XXX  <-----|
> |--------------> USER (tslib_content_User) --|  XXX  <-----|
> |--------------> HTML (tslib_content_Html) --|  XXX  <-----|
> |--------------> TEXT (tslib_content_Text) --|  XXX  <-----|
>                                                            |
> $cObjB (tslib_cObj) ---------------------------------------|
> 
> I hope the sketch makes it a little easier to understand.
> 
> Notes:
> You can test the issue with EXT:kb_nescefe v1.1.1 from TER f.e.
> The attached patch solves the issue by introducing a __clone() helper
> method in tslib_cObj to reset $clone->contentObjects.
> 
> "Once the cloning is complete, if a __clone() method is defined, then
> the newly created object's __clone() method will be called, to allow any
> necessary properties that need to be changed."
> 
> 
> 
> best
> Ingo
>