TYPO3 Core

If you use an image collection in your model for the collection is configured as "@cascade remove", the assigned images will get lost as soon as you edit an existing data set and save without any changes.

1. Install the TYPO3 introduction package
2. Install https://github.com/helhum/upload_example extension
3. Create the folder "content" in your file storage so that uploads are possible in your extension
4. Create the plugin on one page, open the page in the frontend and create an upload example with both images (image & imageCollection)
5. Edit the example and save it - everything is ok (this step is not necessary)
6. Edit your model and add cascade remove to line 56 of Domain\Model\Example.php:

/**
 * Image
 *
 * @var \TYPO3\CMS\Extbase\Persistence\ObjectStorage<\TYPO3\CMS\Extbase\Domain\Model\FileReference>
 * @cascade remove
 */

7. Clear all caches
8. Edit your created upload example and save it without changes. Only one image will be left. $imageCollection will be null, $image ist still set

https://github.com/helhum/upload_example/issues/5

https://forum.typo3.org/index.php?t=msg&th=196895&goto=685918&#msg_685918

Frenck Lutke wrote:

- Re: Issues with "@cascade remove" and forms with nested objects
Frenck Lutke
Tue, 21 May 2013 10:28

Hi Franz,

I'm well familiar with this issue, as I had to debug it a long time ago
as well.

This happens because the objectStorage property has changed. The tricky
part is: all extbase knows is that the objectStorage has changed. It
doesn't know which child-objects are detached, because child-objects
aren't set to be removed when detached, as you could still attach them
somewhere else before persistence applies. Detaching a child-object
doesn't "say" anything about the child-object, it only says something
about the its relation to the parentobject, and that's not stored in the
child-object.

Extbase's way to deal with this, is to simply set the entire ORIGINAL
objectStorage content as removed as you've noticed, and then and
reattach the child-objects that were in the changed objectStorage, while
in turn removing re-attached child-objects from the removedObjects
storage. This way, only child-objects that weren't re-attached can be
considered "lost children" and remain in the removedObjects storage.

While that method is an acceptable solution in itself, the problem that
occurs is that there is a cascade remove check in persistObjectStorage()
BEFORE the re-attachment, that doesn't differentiate between removing
always or only if the parent object was removed. It is this that I would
classify as the actual bug, as "cascade" implies a status passed down
from the parent object in programming.

Cheers,
Frenck

- Re: Issues with "@cascade remove" and forms with nested objects
Frenck Lutke
Tue, 21 May 2013 10:51

A factual inconsistency in my post:

On 21-5-2013 10:28, Frenck Lutke wrote:

re-attached

Sorry, this seemed weird to me when reading my documentation on this
issue, so I've looked again and they're not literally re-attached. The
objects in the changed objectStorage are simply removed from the
removedObjects.