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!
In some development code I noticed that when handling File objects without
filename values, there would be problems calling getPath and such.
The width and height value testing will be validated later anyway, and by
removing such a narrow test we can use events to generate thumbnails of
media formats supported by recently added plugins on demand.
This really should be a UUID or something else totally unexpected
but I figure that crc32 is good enough for now. The reason we keep
the main structure is because some third party scripts have begun
relying upon the tag URI format to parse out domain name, type etc.
This means we import the URI string from remote instances to track their
conversations and are able to stitch together replies in a single thread.
We might have to try to avoid collisions so noone remotely can predict
conversation URIs which we generate on our server, causing a DoS kind of
problem.
If we know the URI sent from the remote party, and we don't know the
notice it is replying to, we might still be able to put it in the same
conversation thread!
Getting rid of NoticeListItemAdapter, putting more into ActivityHandlerPlugin
and relying on plugins to handle rendering code of the content. This gives us
a lot more structure and consistency in notice structure and allows activity
plugins to stop rendering certain kinds of notices more easily.
There should also be a property for an ActivityHandlerPlugin class to avoid
rendering notices in the ordinary stream, so we don't have to overload stuff.
saveActivity will accept an Activity which gets parsed and saved through
plugins. So when an ActivityHandlerPlugin (such as Favorite will be soon)
gets a feed to save, this will be the function called instead of saveNew.
The code is now more event-driven when it comes to rendering notices
and their related HTML elements, since we can't have direct calls from
core to a plugin.
lib/activitymover.php has a function to move a Favorite activity which
will not happen now. The move must be pluginified and performed as an
event which plugins can catch on to.
Now we have to fix any code in the core which directly uses the Fave class
or any other favorite stuff, since it is pluginised and thus might not be
available on some installations.
No validation has been attempted yet. Lots of changes left. This
is visibly not (very) different from the previous CSS layout. But
some simplifications have been made.
Might cause issues with local changes to themes and CSS. Also maybe
javascript which depends on certain legacy microformats elements.
The move to microformats2 is motivated by the announcement that all
microformats should be migrated to version 2, as of 2014-06-20 at:
http://microformats.org/2014/06/20/microformats-org-turns-9-upgrade-to-microformats2
For a Notice object with multiple results, ->getProfile() would ALWAYS
return the first profile in the list. For example our "popular notices"
stream ended up believing all notices were made by the same profile.
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.
Conversation trees works pretty bad with the current layout, javascript
etc. So it's best if we separate it and work on it as a side-project. The
oldschool settings are currently being deprecated (or broken out like this).
I'll wait with removing User preferences for oldschool conversation tree,
since that might be reusable data. But I guess it will go in the near future.
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.
