Let's now create an event called DeleteNotice and also make sure we
handle the onNoticeDeleteRelated properly in ActivityModeration to
avoid possible endless loops etc.
Because we don't want to auto-fetch items from a remote server. Such
items should be delivered as attachment metadata and portrayed in the
way the local instance chooses.
Choices for portrayal are either simply nullifying this and embedding
the data, linking the file remotely requiring a manual click or maybe
use remote oEmbed data etc. to download files locally so no remote
requests have to be made.
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.
It's too farfetched to assume any text.com in a notice is an HTTP URL.
For example stuff like pasting from log entries, with domain.com:1234
where 1234 is a _PID_ or something, not a port number for http://...
This goes for both users and groups, since they share nickname namespace.
If you want to enable nickname changes, just add this to your config:
$config['profile']['changenick'] = true;
This commit should cover all changes in our usual web forms as well as through
the API.
Default is now to take still thumbnails of animated GIFs and then
show them as originals in an AttachmentListItem. The still frames
are mostly used with front-ends like qvitter.
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.
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.
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.
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)!
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.
At the same time we remove the "filecommand" setting, since we will
likely not have use of it thanks to PECL fileinfo.
Also the "supported" list for attachment mime types has changed
format, so we can keep track of at least some known file extensions.
My reasoning: Minifying makes third party review harder. A visitor on
a GNU social site should have no problem reading, understanding and
modifying javascripts for their own liking. A minified script is much
more difficult to use, reuse, modify and share.
Free software is not minified.
