TYPO3 Core

I guess this was a copy&paste error. Indeed, the class does not exist. Sorry for that.

Shall we generalize the ticket to refer to the usage of BasicFileUtility in general?

I started to patch TYPO3\CMS\Core\DataHandling\DataHandler and stumpled across folowing problem.

The uploads/ folder, this folder isn't maintained default within a FAL storage.

So the question is, do we want to add "uploads/" as a default FAL storage?

I wouldn't be happy with that, as this will get editors to the point uploading images every time they are used.

Suggestions please. :)

@Alexander, AFAIK the default storage with the id "0" exists and embraces the complete TYPO3_site, so if you want to refer to files in "uploads/" just use this storage.

@Markus, Having an issue for each class involved would help keeping track of the process. To me it seems to be:

• DataHandler
• backend / FileController
• impext / ImportExport
• ElementBrowser (#47648)
• frontend / GifBuilder
• lowlevel / DoubleFilesCommand (will probably have to be completely rewritten for FAL anyway - or is obsolete...)
• lowlevel / RteImagesCommand
• rtehtmlarea / BrowserLinks and SelectImage

Maybe more. Search for BasicFileUtility and ExtendedFileUtility (which extends the basic one...).

If I got it right ExtendedFileUtility is not deprecated, but ExtendedFileUtility and BasicFileUtility are coupled. In most places ExtendedFileUtility is used, the deprecated init method of BasicFileUtility is called.
So ExtendedFileUtility needs also to be decoupled from BasicFileUtility.

Either we manage to remove all Core internal calls to BasicFileUtility, or we remove the deprecation log message.

I think the best chance to improve the current behaviour is to remove the deprecation of the init method and to explicit deprecate the functions in BasicFileUtility, that should not be used from the outside anymore, check and change the internal calls to them.