Open franck-grenier opened 6 years ago
Hello.
I tested this, and indeed can reproduce your problem.
I think that this is an error that comes from the ezpublish kernel, specifically in method eZ\Publish\Core\FieldType\BinaryBase\BinaryBaseStorage::storeFieldData() : for version kernel 5.4 around line 114, the mimeType that is sent from the user gets overwritten with the one that is calculated by the IOService. (ref: https://github.com/ezsystems/ezpublish-kernel/blob/v2014.11.8/eZ/Publish/Core/FieldType/BinaryBase/BinaryBaseStorage.php#L114 )
The only fix that I can think of is to replace the BinaryBaseStorage class with a patched one, by setting a different value for parameter %ezpublish.fieldType.ezbinaryfile.externalStorage.class%
ps: it seems that the same problem still applies to the current ezplatform code, even though the code has been refactored:
Created ticket: https://jira.ez.no/browse/EZP-28380
Note that at least the current BinaryBaseStorage does create a coherent value on disk and in the db, as it sets the new mimetype to the field Value. Version v2014.11.8 is even more buggy, as if a user passes in manually a mime-type which differs from what eZ find out on its own, the resulting created field value will be unusable (the file will be stored in the wrong place on disk)
Old one...
Thanks for the update. Most important is that current releases are fixed.
Feel free to close.
Hello Kaliop, we are uploading css files into ezbinaryfile attributes during a migration. Though we explicitly set the mime type with
mime_type: text/css
in the migration file, EZ (5.4.10) savestext/plain
mime type.We are doing that kind of migration :
Do you have any feedback on this bug ?
Thanks