Bug #66600
closed
Extbase / Filereference / public method of api class changed in patch release, causing fatal errors.
0%
Description
This change broke some of my websites.
(https://forge.typo3.org/issues/48965)
Before this change it was possible to set a File as OriginalResource, because the Method AbstractFileFolder::setOriginalResource expects \TYPO3\CMS\Core\Resource\ResourceInterface, now the the model has its own setter which expects \TYPO3\CMS\Core\Resource\FileReference.
I make use of import processes a lot and synch external contents to internals.
I suggest not changing public functions in @api classes unless a new major release is made.
Updated by Frans Saris over 9 years ago
- Status changed from New to Needs Feedback
Hi Philipp,
I'm not sure why you would to provide a different object then a FileReference here. And further there is this line in the code @api experimental! This class is experimental and subject to change!
We could change the code for 6.2 to something like the snippet below, but not sure if that makes sense.
/**
* @param \TYPO3\CMS\Core\Resource\FileReference $originalResource
*/
public function setOriginalResource(\TYPO3\CMS\Core\Resource\FileReference $originalResource) {
$this->originalResource = $originalResource;
if ($originalResource InstanceOf \TYPO3\CMS\Core\Resource\FileReference) {
$this->uidLocal = (int)$originalResource->getOriginalFile()->getUid();
}
}
Did you already change your custom code or is this still a issue you want to see resolved.
gr. Frans
Updated by Philipp Wrann over 9 years ago
I solved this myself by simply setting the uidLocal of my FileReference Model. As long as no one faces problems you are good i think.
I'm not sure why you would to provide a different object then a FileReference here
The param was declared as ResourceInterface before, so i thought i could pass a File object too - why not? To me this sounds just logic. The original Resource of a FileReference sounds for me to be a File object - and so i passed the File Object (it implements the ResourceInterface).
@api experimental sounds a bit funny. Either something is api or not. If something is marked api it should not change until a subversion release (6.3/7 in case of 6.2) but thats not mine to say - simply my opinnion. In public methods you should allways stick to the simply pricinple that a methods must not get more strict in its requirments (what it takes) and must not get more lazy in its output-types (what it gives). That way an api can never break.
So changing a parameter from Interface to Class = BAD. But changing a parameter from Class to Interface (if the Class implemented it before) = GOOD.
Updated by Riccardo De Contardi over 9 years ago
- Status changed from Needs Feedback to Closed