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.
I used this hacky sed-command (run it from your GNU Social root, or change the first grep's path to where it actually lies) to do a rough fix on all ::staticGet calls and rename them to ::getKV
sed -i -s -e '/DataObject::staticGet/I!s/::staticGet/::getKV/Ig' $(grep -R ::staticGet `pwd`/* | grep -v -e '^extlib' | grep -v DataObject:: |grep -v "function staticGet"|cut -d: -f1 |sort |uniq)
If you're applying this, remember to change the Managed_DataObject and Memcached_DataObject function definitions of staticGet to getKV!
This might of course take some getting used to, or modification fo StatusNet plugins, but the result is that all the static calls (to staticGet) are now properly made without breaking PHP Strict Standards. Standards are there to be followed (and they caused some very bad confusion when used with get_called_class)
Reasonably any plugin or code that tests for the definition of 'GNUSOCIAL' or similar will take this change into consideration.
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.
Newly supported:
- TwitPic: added a local function using TwitPic's API, since the oohembed implementation for TwitPic produced invalid output which Services_oEmbed rejects. (bug filed upstream)
Tweaked...
- Flickr: works, now using whitelist to use their endpoint directly instead of going through oohembed
- Youtube: worked around a bug in Services_oEmbed which broke the direct use of API discovery info, so we don't have to use oohembed.
Not currently working...
- YFrog: whitelisting their endpoint directly as the oohembed output is broken, but this doesn't appear to work currently as I think things are confused by YFrog's servers giving a '204 No Content' response on our HEAD checks on the original link.
Some minor database changes for file tables. Namely:
* Added a timestamp to all tables
* Added a filename column for local files
* Change some tables that had unnecessary auto-increment primary
keys when they had another unique column that should act as
the primary key
* Change engine from MyISAM to InnoDB for a couple of files.
Also, rebuilt the DB_DataObject files for all these tables.
