[StoreRemoteMedia] Upgrade plugin to use the new Media system
API Changes:
- Added getters to File to better formalize the ideas of the commit "[Media] Fix issues with database file storage"
UI Changes:
- Now presented thumbnails are actual thumbnails (bug fix)
- Attachment actions have a slightly more extended behaviour
Many other minor bug fixes...
Fixed file quota as well.
There can be more than one file for the same filehash IF the url are different.
Possible states:
- A file with no url and with filename is a local file.
- A file with an url but no filename is a remote file that wasn't fetched,
not even the thumbnail.
- A file with an url and filename is a fetched remote file (maybe just a
thumbnail of it).
- A file with no filename nor url is a redirect.
Routes:
Given these states, updated routes so that an attachment can only be
retrieved by id and a file by filehash.
Major API changes:
File::getByHash now returns a yield of files
Major UI changes:
- Now remote non stored files are presented.
- /view became preferred
- Redirects to remote originals are preferred.
Many other minor bug fixes...
Avoid the use of deprecated MariaDB "zero dates" globally. If they're present
as attribute defaults somewhere, they will be replaced with NULL implicitly.
The existing "zero dates" in MariaDB storage will be left intact and this
should not present any issues.
The "timestamp" type in table definitions now corresponds to DATETIME in
MariaDB with "DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP", which
should be close enough to the original behaviour for compatibility purposes.
It is now the recommended type for "modified" attributes, because of the
update trigger on MariaDB. But there is no such trigger implemented on
PostgreSQL as of this moment.
This will probably cause older oEmbed images not to show, since they
probably were updated to use empty url entries because they were thought
of as local ones. During a migration period maybe you want to change
the default value of notNullUrl to 'false' in File_thumbnail::byFile(...)
If a new file is uploaded, it will be matched with a previously uploaded
file so we don't have to store duplicates. SHA256 is random enough and
also unlikely enough to cause collisions.
The getUrl call would think that a File_thumbnail object was the child
of a local File if its filename was set. That has been true up to recent
development code where a File_thumbnail can have a 'filename' value,
but the original File does not. Only look at the File object to indicate
whether it's a local or remote file!
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 only reason it worked was because DB fetches calls to get$varname if
the dataobject has a variable with the specific name. However, it started
blurting out errors that the case must be correct (which would require
'geturl' to be the function name).
Since we probably want to replace DB sometime, we'll just override this
auto-fetching mechanism and use more explicitly defined functions.
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.
The parent class for our database objects, Managed_DataObject, has a
dynamically assigned class in staticGet which objects get put into,
leaving us with less code to do the same thing.
We will probably have to move away from the DB_DataObject 'staticGet'
call as it is nowadays deprecated.
