I think the migration from core to plugin is done now for DMs.
This is required since we support the Twitter-based API by default,
which is implemented in many of the mobile clients etc. But you can
disable the DirectMessage for your instance of you wish, of course.
In the future, use events for formatting microapp notices, more specifically
through the plugin's function "showNoticeContent" or similar, which is called
from MicroAppPlugin, which is extended from ActivityHandlerPlugin.
---------------------------------------------------------
WARNING: Some plugins attempt to get a property 'group' from (basicly) a Menu
class which does NOT have such property. This badly needs fixing.
---------------------------------------------------------
Signed-off-by: Roland Haeder <roland@mxchange.org>
Since we store 'favorite' verbs as notices now too, they caused a lot of
"null" notices that might not be interesting before we handle them better
in the UIs.
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.
Lost dependency of OStatus plugin for lib/microappplugin.php, whoo!
also noting which plugins should be upgraded to new saveActivity support.
Favorite plugin won't work with the new system just yet, it doesn't have
the necessary functions to extract activity objects, but that's coming
in the next (few) commits.
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
IE versions older than 8 (which these were for) should no longer
be used anyway, since they are filled with security holes and not
even Microsoft recommends or supports their use anymore.
This reverts commit 38f5038cf0.
Random problems with, I assume, Chromium users. Ranted:
"FUCK YOU CHROMIUM WITH VARYING FUNCTIONALITY AND CRAPPY
INTEROPERABILITY THE NEW FUCKING INTERNET EXPLORER"
This will be back in the future with a vengeance (patches).
Some changes should be implied as larger with an incrementing alpha
release number. Not all commits will increase this of course, but it
will give an indication on which major reworks, features or layout
changes have been made for the version being used on an instance.
Instead of setting some weird $config['plugins']['disable-Blah'] yourself.
The class name, StatusNet, will probably change in the future to GNU social.
No global function added, as it exists for addPlugin().
We don't run a service similar to update.status.net yet. Maybe we should,
but that's for the future to decide. Currently I view it as a callback
that we want to avoid.
noembed.com acts as a proxy for oEmbed requests, but that also means they
get all the links we post on our instances, given that they're used as a
default endpoint.
htmLawed cleans stuff out properly, but there's no very good way right
now to show text/html attachments, since everything gets jumbled up with
our own CSS etc. Best would be an iframe or just a new tab or so.
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.
This will simplify actions for future development and maintenance
since we can automate much more (such as auto-running show[Ajax|Page])
and handle errors of various kinds. Essentially the same kind of
improvements as Managed_DataObject gives us.
notice.id will give us even really old posts, which were
recently imported. For example if a remote instance had
problems and just managed to post here. Another solution
would be to have a 'notice.imported' field.
It seems it was only used to get a _single_ file attachment from
the posted notice, with no possibility to get multiple attachments.
If one fetches metadata about attachments for the notice, we have
enough data there to fulfill anyone's fetching dreams.
This makes it easier to disable, but remember that you must then
either enable and maintain queue daemons or disable queueing (and
handle whatever remaining queue items are stored in the database)!
We can't say we officially support PostgreSQL, unfortunately. There
are too many database calls with MySQL specific syntax. This would be
desirable for a 2.0 release, but too much work while maintaining 1.x.
The main difficulty is that we're using PEAR::DB which is aging. If
that's exchanged, maybe we could use PDO or something.
Read more at http://microformats.org/
Also, tooltip text on time representation for humans has been improved.
Unfortunately no standardised representation (like "RFC850") had 4-digit years.
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.
