Bug #50608
closed
FAL - doubles file reference if frame is reloaded
Added by d.ros no-lastname-given almost 11 years ago. Updated over 2 years ago.
0%
Description
If you reference a file in IMAGE or TEXTPIC in BE and you reload the containing Frame the relation occours twice.
Cheers
David
Updated by Philipp Gampe almost 11 years ago
- Status changed from New to Needs Feedback
Before or after saving?
Updated by d.ros no-lastname-given almost 11 years ago
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
Updated by Philipp Gampe almost 11 years ago
- Category changed from File Abstraction Layer (FAL) to FormEngine aka TCEforms
Most likely this happens because you resubmit the form. Your browser should give you are warning when doing so.
Anyway, this does not look like a bug to me.
Updated by Alexander Opitz over 10 years ago
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?
Updated by d.ros no-lastname-given over 10 years ago
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
Updated by Alexander Opitz over 10 years ago
- Status changed from Needs Feedback to New
The question is not, why do I do that but why does this happen or how to prevent it.
But it is a good question, if a developer do not know, why someone do something, he never can find better solutions for a problem.
Google Chrome gives no warning in this case.
Didn't know that, tried it yet and yes, no warning. That's not nice. :-/ (BTW: If you reload over the source viewer, then you get a warning.)
So we have 2 issues:
- Prevent double submitting of forms (not the submitting them self but the processing of it).
- A UI Change to reset changed form data (I think this would be easier then right-click search for "reload frame").
Yet implemented is formToken to secure the Post (so no other site can link into your TYPO3 backend) and "_serialNumber", its an md5 over microtime, it seams that this exists only to prevent proxies to respond with a cached page instead to send the post request to the server (but why hashing the microtime?).
Updated by Sebastian Fischer almost 10 years ago
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.
Updated by Ingo Schmitt over 9 years ago
- Target version changed from 6.2.0 to 7.4 (Backend)
- Is Regression set to No
Updated by Susanne Moog over 8 years ago
- Target version changed from 7.4 (Backend) to 7.5
Updated by Benni Mack over 8 years ago
- Target version changed from 7.5 to 7 LTS
Updated by Mathias Schreiber over 8 years ago
- Category changed from FormEngine aka TCEforms to DataHandler aka TCEmain
- Target version changed from 7 LTS to 8 LTS
Moving this away from FormEngine, because this is not FormEngine related.
DataHandler needs to keep track of things like these.
Since we will not be able to touch DataHandler in 7 I moved the target version to 8.
Updated by Riccardo De Contardi about 7 years ago
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.
Updated by Benni Mack about 7 years ago
- Target version changed from 8 LTS to next-patchlevel
Updated by Riccardo De Contardi over 6 years ago
still present in 9.0.0-dev (latest master)
Updated by Oliver Hader over 6 years ago
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¶
99is parent.uid21is child.uid that just has been created
uid|parent 10 |99 20 |99 21 |99
2nd invocation - result in child table¶
99is parent.uid22is 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 to0(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.
Updated by Benni Mack about 5 years ago
- Target version changed from next-patchlevel to Candidate for patchlevel
Updated by Riccardo De Contardi over 2 years ago
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
Updated by Benni Mack over 2 years ago
- Status changed from New to Needs Feedback
Yes. This was finally solved by using TYPO3 v11 and limitation on GET/POST parameters (introduced in TYPO3 v11.1).
Can you check if your problem is solved in v11 LTS?
Updated by Riccardo De Contardi over 2 years ago
Updated by Benni Mack over 2 years ago
- Status changed from Needs Feedback to Closed
This was possible in TYPO3 v11 as we restricted the query params to be POST only values (introducing PSR-7 Request objects everywhere). This won't be fixed in TYPO3 v10 or prior.