Fixed Non JPG/GIF/PNG Images are being Stored as MP4

CvP

CvP

Member
@Chris D

I'm having the same issue during an import (~200 files out of 1.5M).

All XFMG options are default; nothing changed. v 1.1.10

The source file is just a standard image attachment. For whatever reason, XFMG is pushing it as mp4.

Example:
upload_2017-4-11_8-34-11.webp

Another issue is, when clicking "Rebuild Caches", this is causing a fatal error as you are trying to generate thumb using imagecreatefromjpeg based on .jpg (mime from getimagesize() ) instead of using exif_imagetype of the file first.

So we have
- a BMP file,
- with .JPG extension (vbulletin style, you know...),
- stored as MP4 (why?)
- and XF is trying to generate thumb on it without checking exif_imagetype first
- which is causing fatal error
- and if .BMP is passed, XFMG is trying to use some bmp related functions that are only available in PHP 7.2.0+ :/
 
Last edited:
Moved your post to its own thread as a big report as this sounds like a new issue.

Which gallery and version are you importing from?

Which caches being run specifically cause the fatal error?
 
The import is from a custom platform (which retains some of the vbulletin things) and using a custom importer written by myself.
I'm using standard importXYZ functions (like importMedia).

The rebuild cache in question: Rebuild XenForo Media Gallery Thumbnails

It is trying to generate thumbs from
- bmp files with jpg extension using imagecreatefromjpeg causing fatal error (vbulletin stores bmp files as .jpg without converting them)
- bmp files with bmp extension using imagecreatefrombmp causing undefined function error (nobody is using php 7.2.0 yet). Making a custom imagecreatefrombmp results in another issue: it is trying to use imagebmp which again, is php 7.2 stuff.
- tiff files with tiff extension using imagecreatefromjpeg (as you have set jpeg as default type) causing fatal error

Right now what I have done is edit library/XenGallery/Helper/image.php and add custom code
- to detect file type (exif_imagetype) and use appropriate functions
- provided a custom imagecreatefrombmp function
- it still using imagejpeg to save the thumb but that's fine

I think XFMG should use GD methods as fallbacks and use imagick as primary which is far better than GD for most things.


As to why it is pusing BMP files as MP4, no idea yet.
 
Code: 
library/XenForo/Upload.php

line 189 to 212.
Surprised to see "only consider gif, jpeg, png to be images in this system" type of code.


Code: 
library/XenGallery/Model/Importers.php

line 189
if ($upload->isImage()) {
}
else {
 //video
}
this code really needs to be sorted out. isImage() being false does not mean the content is video.
 
Well, if you're using a custom importer then there's likely something wrong with that process.

The default importers don't import BMP/TIFF files, they also don't import valid images as if they were MP4 files.

Going to tag this as not a bug then.
 
It is fine if you mark it as not a bug but there is nothing wrong with my code.

It is XF's default uploader which considers only gif/jpg/png as image and XFMG's code which relies on that to determine what is video.

As a test, I just uploaded a BMP file using front-end (after allowing BMP as a file type from XFMG's options). XFMG stored it as mp4 file :)

Sketch.webp

upload_2017-4-11_18-13-1.webp
 
Last edited:
It wasn't clear that's how it was manifesting itself. We'll give it another look for the next release.
 
Back
Top Bottom