I've changed the behaviour of the RemoteObjectUpdater::onLocalMetadataRecordUpdatedOrCreated method to prevent errors if a file cannot be retreived because of the changed signals / PSR-14 events in TYPO3 v10. Because of these changes, the $data array that's returned doesn't always contain the complete object so the $data['file'] doen't always exist. Then the function reaches the catch statement which results in $file being null. By wrapping the code that is using $file with isset($file), we prevent $file->getStorage() throwing the exception Call to a member function getStorage() on null.
This can be tested by uploading a file using the filemodule. Uploading should fail and an error should be written to the sys_log table containing the error message as mentioned above.
Apart from fixing the issue above, I've managed to resolve most of the deprecation warnings. One of the warnings was using the ResourceFactory::getInstance(). Instead I'm now using GeneralUtility::makeInstance(ResourceFactory::class) because the getInstance() method was just a wrapper for the GeneralUtility::makeInstance() function.
At the getFileInfoByIdentifier method I've also added the extension and atime to the return values. The TYPO3 forms extension seems to use this data to filter it's view to show the forms. After adding the file extension to the return type and adding it to the database, the TYPO3 forms module was showing the forms again.
Because I wanted to maintain support for older TYPO3 versions, I chose to not migrate the SignalSlot Dispatchers at ext_localconf.php.
I also managed to update the PHPDoc blocks, slightly changed the use statements, applied PSR-2 code style and replaced traditional array syntax with short notation.
For automated testing I've updatet the nimut/testing-framework to include a version that works with the latest TYPO3 v10 LTS and added some travis tests for TYPO3 v9 and v10 for the supported PHP 7 versions.
I've changed the behaviour of the
RemoteObjectUpdater::onLocalMetadataRecordUpdatedOrCreatedmethod to prevent errors if a file cannot be retreived because of the changed signals / PSR-14 events in TYPO3 v10. Because of these changes, the$dataarray that's returned doesn't always contain the complete object so the$data['file']doen't always exist. Then the function reaches the catch statement which results in$filebeingnull. By wrapping the code that is using$filewithisset($file), we prevent$file->getStorage()throwing the exceptionCall to a member function getStorage() on null.This can be tested by uploading a file using the filemodule. Uploading should fail and an error should be written to the
sys_logtable containing the error message as mentioned above.Apart from fixing the issue above, I've managed to resolve most of the deprecation warnings. One of the warnings was using the
ResourceFactory::getInstance(). Instead I'm now usingGeneralUtility::makeInstance(ResourceFactory::class)because thegetInstance()method was just a wrapper for theGeneralUtility::makeInstance()function.At the
getFileInfoByIdentifiermethod I've also added the extension and atime to the return values. The TYPO3 forms extension seems to use this data to filter it's view to show the forms. After adding the file extension to the return type and adding it to the database, the TYPO3 forms module was showing the forms again.Because I wanted to maintain support for older TYPO3 versions, I chose to not migrate the SignalSlot Dispatchers at
ext_localconf.php.I also managed to update the PHPDoc blocks, slightly changed the use statements, applied PSR-2 code style and replaced traditional array syntax with short notation.
For automated testing I've updatet the
nimut/testing-frameworkto include a version that works with the latest TYPO3 v10 LTS and added some travis tests for TYPO3 v9 and v10 for the supported PHP 7 versions.