Default supported files need to use consistent names. Bumped version to 1.20.0
ImageFile has been changed to extend MediaFile and rely on it to partially
validate files. This validation has been extended to not rely solely on
Fileinfo, as it is disabled on some places. Now it'll try to use the shell
command `file`, if Fileinfo isn't available.
ImageFile now converts every new upload to PNG, except JPEG and GIF, which
are kept, but still resized (to the same size), to remove possible scripts
embedded therein.
MediaFile::fromUpload will return an ImageFile if the uploaded file is an image
or a MediaFile otherwise.
MediaFile can be constructed with an id with value -1 to denote a temporary
object, which is not added to the DB. This is useful to create a temporary
object for representing images, so it can be used to rescale them.
The supported attachment array needs to be populated with the result of calling
`image_type_to_extension` for the appropriate image type, in the case of images.
This is important so all parts of the code see the same extension for each image
type (jpg vs jpeg).
Added documentation to classes/File.php and to lib/MediaFile and lib/ImageFile
We're now capable of doing image rotation for thumbnails based on
EXIF orientation data. Also, thumbnails are tracked by filenames and
thus we can delete them from storage when we feel like it.
The File object now stores width and height of files that can
supply this kind of information. Formats which we can not read
natively in PHP do not currently benefit from this. However an
event hook will be introduced later.
The CreateFileImageThumbnail event is renamed to:
CreateFileImageThumbnailSource to clarify that the hooks should not
generate their own thumbnails but only the source image. Also it now
accepts File objects, not MediaFile objects.
The thumbnail generation is documented in the source code. For
developers, call 'getThumbnail' on a File object and hope for the best.
Default thumbnail sizes have increased to be more appealing.
The exception thrown from MediaFile will be caught and simply result in
no thumbnail at all right now. In the future we might use a catch-all
and have a "cannot generate preview"-icon or something.
VideoThumbnails requires php5-ffmpeg and php5-gd.
We're also now using $config['image']['jpegquality'] to determine the
quality setting for resized images.
To set Avatar max size, adjust $config['avatar']['maxsize']
The getAvatar call now throws exceptions too. Related changes applied.
Now let's move Profile->avatarUrl to the Avatar class!
Part of the reported issue was previuosly fixed by dc497ed0 (smaller size images being blanked).
This commit fixes the remaining bug with original-size avatars being left as BMP (which could include the 96px size for instance, which could cause problems in browsers not supporting BMP natively)
Added ImageFile::copyTo() as a convenient alias for resizeTo() when not resizing; this performs the BMP/XPM/XBM->PNG conversion if needed, or copies the original file.
Copying instead of using move_uploaded_file() is fine here since:
a) the files are cleaned up on script completion anyway (vs moving to remove it)
b) we're already performing getimagesize() and possibly load/resize on the file before this point (vs needing to move the file into a usable area to work with open_basedir restrictions that prevent working directly with uploaded files in the temp dir; since this would fail anyway, we lose nothing)
ImageFile::preferredType() now works on $this->type instead of asking for one, to make it handier to use from outside. (This is still needed in order for calling code to generate a target filename.)
Recommended for future:
* additional consolidation between the various ways of uploading avatars (touched avatarsettings, grouplogo, and apiaccountupdateprofileimage with similar minor changes)
* consolidate type checks and file naming into Avatar class
