Bug #66600


Extbase / Filereference / public method of api class changed in patch release, causing fatal errors.

Added by Philipp Wrann about 9 years ago. Updated about 9 years ago.

Must have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


This change broke some of my websites.

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.

Actions #1

Updated by Frans Saris about 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

Actions #2

Updated by Philipp Wrann about 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.

Actions #3

Updated by Riccardo De Contardi about 9 years ago

  • Status changed from Needs Feedback to Closed

Also available in: Atom PDF