Bug #92455
closed
createFile with file image extension causes ImageMagick identify errors
Added by RVVN no-lastname-given over 3 years ago.
Updated over 3 years ago.
Description
Hi,
since 9.5.22, creating file with an image extension ("jpeg", "jpg", "png") with Storage->createFile() causes the following errors from ImageMagick "identify" function :
identify: insufficient image data in file `/xxxxxxxx/xxxxxx/375536226116427_1338295523173821.jpeg' @ error/jpeg.c/ReadJPEGImage/1039.
identify: improper image header `/xxxxxxxx/xxxxxx/1675979572678151_2805251863084244.png' @ error/png.c/ReadPNGImage/3954.
This is because Indexing is invoked during the file creation, and Indexer extract width and height but these metadata (via ImageMagick "identify") don't exist yet.
As a side question, why indexing at file creation ?
RVVN no-lastname-given wrote:
since 9.5.22, creating file with an image extension ("jpeg", "jpg", "png") with Storage->createFile() causes the following errors from ImageMagick "identify" function :
Can you elaborate what exactly the error is you are seeing? How do these error from Imagemagick affect your goals? Are you seeing any exceptions?
As a side question, why indexing at file creation ?
That is how FAL works. Any file that is added will get an index entry.
We have a scheduler cron job that fetches remote images then stores them in fileadmin.
Images are well created at the end, but we receive emails with the mentioned errors.
TYPO3 logs warnings too :
component="TYPO3.CMS.Core.Type.File.ImageInfo": I could not retrieve the image size for file /xxxxxxxx/xxxxxx//381438182400366_776716469539200.jpeg
We use the following sequence :
- storage->createFile(filename.jpeg) => that causes identify errors because of extracting metadata on an image file that doesn't exist yet
- storage->setFileContents(fileObject, [image data retrieved by cUrl])
Maybe that's not the right way ?
- Status changed from New to Under Review
RVVN no-lastname-given wrote:
We have a scheduler cron job that fetches remote images then stores them in fileadmin.
Images are well created at the end, but we receive emails with the mentioned errors.
I'm still puzzled why you get these warning emails.
TYPO3 logs warnings too :
Yes, that is indeed wrong and unfortunate.
We use the following sequence :
- storage->createFile(filename.jpeg) => that causes identify errors because of extracting metadata on an image file that doesn't exist yet
- storage->setFileContents(fileObject, [image data retrieved by cUrl])
Maybe that's not the right way ?
You could create a local file from CURL data and the use the addFile API instead. I will created a fix though, so that your way will not log warnings any more.
Helmut Hummel wrote:
You could create a local file from CURL data and the use the addFile API instead. I will created a fix though, so that your way will not log warnings any more.
Thanks ;)
I've already tested the patch and it seems to work.
No warning in log from File.ImageInfo so I guess identify is not called.
We'll have a look at addFile method ;)
- Status changed from Under Review to Resolved
- % Done changed from 0 to 100
- Status changed from Resolved to Closed
Also available in: Atom
PDF