TYPO3 Core

It seems that this only occours if you safe an image and reload then the frame.

If you reload the frame without touching an existing image nothing occours.

If you reload the frame after saving a new image when an image was already present the last one is also rereferenced.

Cheers

As Philipp wrote, the issue seams that you resubmit your last action by reloading the frame.

So my question, why do you reload the frame and don't use the save button or one of the other action buttons?

The question is not, why do I do that but why does this happen or how to prevent it.

Google Chrome gives no warning in this case. In other cases eg. in FE where a resubmitting is invoked it does give a warning.

Imagine a user writes in the RTE an wants to negate it. Once he reloaded the frame the images get doubled without any notice. It´s just a usability detail which is not war-depending but would make sense to prevent such behaviour.

cheers

david

I dont see that this should be a bug in the core. The same happens if you create a new content element and after saving the first time reload the frame. In the end you have as many content elements as you reload plus one for the first save. That is in no means a core problem.

This still occurs in 8.7-dev (latest master). Steps to reproduce:

1) Create a new content element Text with Image, save
2) add an image, save
3) add another image, right click, reload frame

Result: the image added at 2) is duplicated.

still present in 9.0.0-dev (latest master)

If we just put aside the fact that this happens in the UI and are aware that this happens as well when invoking DataHandler directly, the following happens:

• parent.children = 10,20,NEWabc
• child.title = New record

1st invocation - result in child table¶

• 99 is parent.uid
• 21 is child.uid that just has been created

uid|parent
10 |99
20 |99
21 |99

2nd invocation - result in child table¶

• 99 is parent.uid
• 22 is child.uid that just has been created

uid|parent
10 |99
20 |99
21 |99
22 |99

Conclusion¶

After the second run, the target relations are not cleared up for child.uid 21.

• for IRRE at least the parent pointer field (foreign_field) should be reset to 0 (leading to some orphaned record)
• for MM the relation on the intermediate table should be removed (leading to some orphaned record)

However, for the UI view and handling forms it would be much better to send an HTTP redirect header once the form has been persisted to avoid sending these "NEWabc" instructions again - thus, mitigating side effects when reloading the frame.

Just tested again with the test on my comment 12

Results:

TYPO3 9.5.28: still reproducible

TYPO3 10.4.21: still reproducible

TYPO3 11.5.1-dev (latest master): not reproducible

[UPDATE]¶

I can confirm that on a fresh 11.5.0 TYPO3 installation the issue is not reproducible