Project

General

Profile

Actions

Bug #72930

closed

GraphicalFunctions/GifBuilder vs. Files without Extension

Added by Carsten Bleicker about 8 years ago. Updated about 4 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
File Abstraction Layer (FAL)
Target version:
-
Start date:
2016-01-25
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

A Storage allows creating files without extension:

f.e. ->createFile('foo', ...)

instead of:
->createFile('foo.jpf', ...)

Creating files without extensions is totaly okay for me and also useful if you f.e. running an upload frontend api.

Example Request
POST /api/myProduct/mainImage/foo
Content-Type: image/jpg
Content: The Payload

Putting this into a Storage works well:
>createFile('foo', ...)>setContent($payload);

But there is a problem.
You can add the new fal record to another record as relation.

Example:
§myProduct->setMainImage($theResourceOfPreviousAPIUpload);

Now edit a simple property (f.e. the name of the product) of the Produkt in the Typo3 Backend and save it. T3 checks here, if there are any unknown file extensions exists on $mainImage and removes the relation. After saving the mainImage is gone. It's bad, that T3 removes already existing relations. Better leave it as it is and only check for new files but never remove existing relations.

1.
If T3 behaviour is based on file-extensions instead of the mimetype the storage-api should not accept files without an extension.

2.
Filetypes should be detected by mimetype everywhere.

3.
Storage-API should support passing an optional identifier for this file which is different to its name. If this param is set, T3 should use this identifier instead of building its identifier by the $filename property. Identifier should not contain any kind of path info. Its just used to fetch it by identifier. Identifier and Filename ist different to me.

4.
Several cases in t3 using different kind of GraphicalFunctions.
IRRE using GraphicalFunction. Frontend using GifBuilder extends GraphicalFunction.
You have to patch both if you want to patch them to work proper with extensionless files.

$GLOBALS['TYPO3_CONF_VARS']['SYS']['Objects'][\TYPO3\CMS\Core\Imaging\GraphicalFunctions::class]['className'] = \Foo\Bar\Imaging\GraphicalFunctions::class;
$GLOBALS['TYPO3_CONF_VARS']['SYS']['Objects'][\TYPO3\CMS\Frontend\Imaging\GifBuilder::class]['className'] = \Foo\Bar\Imaging\GifBuilder::class;

These Object changes seems not to be enough.
- Irre showing extensionless preview images.
- Frontend showing extensionless preview images.
- Fileadmin does NOT showing extensionless images
- Fileadmin/EditFile shows extensionless images

Seems that different places using several different kind of image processes. Should be "centralized", i think.
F.e. GifBuilder should act as a decorator instead of extending the GraphicalFunctions.
Gifbuilder should inherit changes by $GLOBALS['TYPO3_CONF_VARS']['SYS']['Objects'][\TYPO3\CMS\Core\Imaging\GraphicalFunctions::class]['className'].

[pre]
class GifBuilder{

/**
  • @var GraphicalFunctions
    */
    $graphicalFunctions;
... Then needed decorating functions
}

instead of:

class GifBuilder extends GraphicalFunctions {
...
}
[/pre]

Actions #1

Updated by Riccardo De Contardi about 8 years ago

  • Category set to File Abstraction Layer (FAL)
Actions #2

Updated by Susanne Moog about 5 years ago

  • Status changed from New to Needs Feedback

Hey,

basically TYPO3 uses a combination of MIME Type and file extensions to handle files. As you noticed, getting rid of the file extension would be a tremendous amount of work (in my eyes for little gain). As for the potential refactoring of GIFBUILDER - yes, especially in the GraphicalFunctions area there's a lot of code left that's been mainly unchanged since a long, long time because it's not a priority. If you are interested to work on the area you'd be very welcome. See our contribution guide at https://docs.typo3.org/typo3cms/ContributionWorkflowGuide/ for a start. If not, I'd rather close this issue and if necessary new issues can be created for the single steps making it easier to handle.

Actions #3

Updated by Benni Mack about 4 years ago

  • Status changed from Needs Feedback to Closed

I'M closing this one for the time being.

Actions

Also available in: Atom PDF