So far we only trust i.ytimg.com for YouTube thumbnails, but you can
configure the Oembed plugin in config.php by setting the plugin's class vars:
addPlugin('Oembed', array('param'=>'value', ...));
Some might think this is a security risk or privacy invasive, but as the Oembed
script is already calling remote sites to get information _about_ linked media,
the way to stop it is to disable the Oembed plugin. However it is not certain
it has been migrated out into a plugin properly yet. But try it if you want to.
The portion after StartAtomPubNewActivity would never be reached since
Favorite handles that activity through ActivityHandlerPlugin nowadays.
So I cleaned it up and followed a couple of paths, making stuff prettier.
will verify unknown aliases against old ones if the new identifies as a
previously recognized URI.
Steps:
1. Check the newly received URI. Who does it say it is?
2. Compare these alleged identities to our local database.
3. If we found any locally stored identities, ask it about its aliases.
4. Do any of the aliases from our known identity match the recently introduced one?
Currently we do _not_ update the ostatus_profile table with the new URI.
Use profile URL (not URI), like elsewhere.
Profile::getUri() doesn't actually do anything useful, here--
it does nothing unless a plugin (like OStatus) is already
able to resolve the Profile into a backend object (e.g.: an Ostatus_profile).
If we might not already have an Ostatus_profile for a given Profile,
then we need to use $profile->getUrl() and fetch the data from that URL.
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!
So that we can actually find commandline.inc.
This should have been updated when the files in the EmailSummary tree
where moved down a level into subdirectories.
At the same time we change this to call ActivityUtils::checkAuthorship
instead to let the retrieval/verification go through event handling.
rozzin (Joshua Judson Rosen) found this error. Thanks.
We need to look up a feed profile for HandleFeedEntryWithProfile events,
regardless of whether they're an OStatus user, group, or something else;
this is the least hairy way of doing that--the alternative being
to keep spreading the same logic all over the calling code.
Theoretically, this change might allow OStatusGroups to be recorded
as the authors of activities if they pass through any authorless
activities; but that's why we have checkAuthorship().
Similarly to what ActivityUtils::checkAuthorship does; try to ensure
that activities from ambiguous OStatus feeds (groups and peopletags)
that require explicit authorship don't get in without explicit authors.
InboxNoticeStream::getNotices() no longer returns an ArrayWrapper;
just fetch notices normally via $notice->fetch(), so that
we can actually get the top notice-ID and update email_summary_status
accordingly--and not mail about the same notices repeatedly.
The last commit found a bug that a previous move of the FavCommand
into a plugin called $this in FavoritePlugin instead of the instance
of a CommandInterpreter class. Now that call is statically defined in
CommandInterpreter and appropriately called in FavoritePlugin.
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>
There is required to be an answer-action element for the threaded view
so we can fetch that action value to an AJAX call which fetches the form.
That is: Currently the "Your answer..." placeholder will fetch a blank URL.
Got this mainly from my patches to FreeSocial. The idea is to migrate
also the Note activity to a plugin and have everything be handled as
events, only filling out the basic "context" stuff in the Notice class.
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.
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.
It's less of a problem that one queue-item does not get handled, attention wise,
than that the queue keeps filling up. The typical error raised here is 'already exists'
so it's not even the case that the item won't get handled (it already has been).
The real problem is that the queue_item table accepts duplicates (content-wise) which it
should not.
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
This also fixes a problem with "initial salmon slap", which was a
problem for newly registered accounts which would have their first
salmon slap fail to distribute since there was a problem with Magicsig
keys. Apparently we have to re-read them with importKeys so the
Crypt_RSA objects publicKey and privateKey match later instances of them.
I think it may have been that generate() doesn't specify a signatureMode,
but I leave experimentation of that to the future.
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.
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.
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.
Make the logic match the intent described in the comments.
The intent is clearly "accept notices whenever (A or B or C)", but
the logic implemented was more like "not ((not A) or (not B) or (not C))",
which is a basical boolean algebra fail (each of those ORs need to
become ANDs for double-negation to work).
The practical implication was that, for example, writing a reply
to someone else's notice and including an @-reference to _another_
user on another site to bring them into the discussion would
fail to deliver the notice to the new user because their server
would basically say `oh no, you can't message this user
from someone else's thread' because an earlier check for
the `A' or `C' parts of `(A or B or C)' prevents `B' from
being checked.
cf.: <http://status.hackerposse.com/notice/55846>, which was
refused by the nhcrossing.com server because it didn't know
about <http://sn.jonkman.ca/notice/93724>, even though it would
have passed the later `notice contains a reference to a local user'
check if not for an exception being prematurely thrown.
The whole idea of reporting `which specific check FAILED'
in an `if ANY SUCCEEDS' analysis is just bogus, so nix all of
the distinct ClientExceptions--a single `ALL FAILED' exception
is the only one that makes sense.
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.
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.
Added the following FIXME:
How should a Twitter user get their Inbox filled with foreign tweets?
Every imported Twitter user has a profile in the Profile table, so we
could setup a Subscription entry for each of those, meaning they get
collected in the InboxNoticeStream... But this would mean a lot of
unnecessary entries and listings that generally just point to the
locked down Twitter service.
Let's figure out a good relation so we can connect any profile to any
imported foreign notice, so it shows up in the "all" feed.
Also cleaned up and made typing stricter for the stream, so only
profiles can be submitted. This reasonably also means we can create
"inbox" or "all" streams for foreign profiles as well using the same
stream handler (but of course only for messages we already know about).
To avoid looking up posts for a long time in a large notice database,
the lookback period for the inbox is no longer than the profile creation
date. (this matches the behaviour of Inbox)
Inbox class can probably be removed now.
There was a problem with (specifically at least) PuSHpress for
Wordpress. A previous attempt to perform a DB transaction backfired
because the remote side could connect to the callback before our
commit had gone through.
I take full responsibility for introducing the bug in the first place :)
This will work without much extra effort because there will always be
more notices (higher value) than conversations (so no collisions).
But please run upgrade.php to avoid having an autoincrement id on
conversation table.
Installations using code after 2014-03-01 will have identical
conversation IDs to the initial (conversation root) notice IDs. This
will not affect older installations, which will have very different
values.
require_once lines were required since _plugins_ don't __autoload
Also, Realtime would load the wrong URL for css/js since $this->name()
returns get_class($this) instead of the calling class' __CLASS__.
Many of the microapps are pretty javascript dependant, but at least
we should allow users to get to the new notice field without allowing
javascript to run in the browser. :)
Minutely will NOT necessarily run by the minute, because it depends on
site visitors. Busy sites will be able to do this, but sites where the
visitors (or search engine stuff or api calls) are more than a minute
apart, the interval will be much larger.
Among other things (such as permanent subscriptions), Pubsubhubbub 0.4
removed the "sync" verification method. This means that any incoming
PuSH subscription requests that follow the 0.4 spec won't really
_require_that we handle it as a background process, but if we were to
try direct verification of the subscription - and fail - there's no way
we could pick up the ball again. So _essentially_ we require background
processing with retries.
This means we must implement something like the "poorman cron" or
similar, so background processing can be handled
on-demand/on-site-visit. This is how Friendica, Drupal etc. handles it
and is necessary for environments where we can't run separate queue
daemons.
When the poorman-cron-ish thing is implemented, auto-renewal will work
for all users.
PuSH 0.4 spec:
https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
More on PuSH 0.4 release (incl. breaking changes):
https://groups.google.com/forum/#!msg/pubsubhubbub/7RPlYMds4RI/2mIHQTdV3aoJ
This is more of a proof of concept and will likely not stay in exactly
this form. We should reasonably deliver the entire notice upon webfinger
querying.
If you're using XMPP by setting $config['xmpp'][*] then you should do:
addPlugin('Xmpp', $config['xmpp']);
because setting it directly in $config[''] won't do anything.
Also, default resource for XMPP is now 'gnusocial'. If you want something
more random, set it in your addPlugin config array.
Also removed the entirely unused saveGroups function.
Now avoiding multiGet and using listFind in Profile->getGroups()
so we don't have to deal with ArrayWrapper.
"[...] posts _local_ users (like you) make won't get data about "repeated by"
from federated users"
This was because the ActivityObject would processShare where the shared object
has a _local_ 'actor' URI. Ostatus_profile would complain this meant that a
"Local user cannot be referenced as remote.".
So we see if the shared activity object's id (URI) is in our Notice table, so
we don't have to processActivity - and can skip ensureActivityObjectProfile.
Added the relevant section in INSTALL about queues and daemons to get
the plugin runnig.
Made resource required, as otherwise XMPPHP will send invalid from JIDs
in it's stanzas. For example when my configuration didn't had the
resource part, outbound stanzas looked like this:
<message
from="gnusocial@example.de/"
to="flow@example.de"
type='chat'>
<body>
User "flow" on GNU Social has said that your
XMPP/Jabber/GTalk screenname belongs to them.
…
</body>
</message>
Note the '/' at the end of the from attribute, without an actual
XMPP resource. But according to RFC6122 2.1 "every allowable portion of
a JID MUST NOT be zero bytes in length". Causing a jid-malformed
response from the server.
Also, it's nice to know that debug=true will print out all sent and
received stanzas, which helped me to debug the problem.
Furthermore I add a note that if the XMPP services uses DNS SRV records,
'host' has to be configured (in cases where service host != xmpp domain).
This is the beginning of getting notice URI info via WebFinger
*XrdActionLinks is renamed *WebFingerProfileLinks, check EVENTS.txt
in WebFinger plugin for new events.
Nickname verifications on registration and updates for profiles (not yet
groups) have been improved.
Minor bugs in RegisterAction were also fixed, where multiple forms would
be outputed because the function did not return after showForm(). This
will be solved more permanently with throwing exceptions in the future.
I implemented changes from quitter.se's new API that their front-end qvitter
uses, https://github.com/hannesmannerheim/qvitter/blob/master/api-changes-1.1.1/CHANGES
However I left out the URL shortening commens, since I believe whatever behaviour
they experienced that caused them to implement this was a bug (or many) and should
be fixed in their proper areas and that shortening should not be entirely left
out in API calls.
We're also now using $config['image']['jpegquality'] to determine the
quality setting for resized images.
To set Avatar max size, adjust $config['avatar']['maxsize']
The getAvatar call now throws exceptions too. Related changes applied.
Now let's move Profile->avatarUrl to the Avatar class!
XML_XRD::getAll requires arguments (at least relation). If one really
want all links, just get the 'links' array. It's public!
Also, not all XML_XRD_Element_Link were migrated from the previous
array style.
* getOriginal added to Avatar class
This is a static function that retrieves the original avatar in a leaner
way than Profile->getOriginalAvatar() did (see below).
This will throw an Exception if there was none to be found.
* getProfileAvatars added to Avatar class
This gets all Avatars from a profile and returns them in an array.
* newSize added to Avatar class
This will scale an original avatar or throw an Exception (originally from
Avatar::getOriginal) if one wasn't found.
* deleteFromProfile added to Avatar class
Deletes all avatars for a Profile. This makes the code much smarter when
removing all avatars from a user.
Previously only specific, hardcoded (through constants) sizes would be
deleted. If you ever changed lib/framework.php then many oddsized avatars
would remain with the old method.
* Migrated Profile class to new Avatar::getOriginal support
Profile class now uses Avatar::getOriginal through its own
$this->getOriginalAvatar and thus remains backwards compatible.
* Updating stock GNU Social to use Avatar::getOriginal
All places where core StatusNet code used the
$profile->getOriginalAvatar, it will now useAvatar::getOriginal with
proper error handling.
* Updated Profile class to use Avatar::newSize
When doing setOriginal, the scaling will be done with the new method
introduced in this merge.
This also edits the _fillAvatar function to avoid adding NULL values to
the array (which causes errors when attempting to access array entries as
objects). See issue #3478 at http://status.net/open-source/issues/3478
New plugins:
* LRDD
LRDD implements client-side RFC6415 and RFC7033 resource descriptor
discovery procedures. I.e. LRDD, host-meta and WebFinger stuff.
OStatus and OpenID now depend on the LRDD plugin (XML_XRD).
* WebFinger
This plugin implements the server-side of RFC6415 and RFC7033. Note:
WebFinger technically doesn't handle XRD, but we serve both that and
JRD (JSON Resource Descriptor), depending on Accept header and one
ugly hack to check for old StatusNet installations.
WebFinger depends on LRDD.
We might make this even prettier by using Net_WebFinger, but it is not
currently RFC7033 compliant (no /.well-known/webfinger resource GETs).
Disabling the WebFinger plugin would effectively render your site non-
federated (which might be desired on a private site).
Disabling the LRDD plugin would make your site unable to do modern web
URI lookups (making life just a little bit harder).
Allow the OStatus queue-handler to handle all posts,
and give it the smarts required to make correct decisions
about whether it should or shouldn't relay notices
over OStatus.
cf. http://status.net/open-source/issues/3540
Conflicts (staticGet => getKV):
plugins/OStatus/lib/ostatusqueuehandler.php
No need to restrict the autocomplete suggestion system to logged in users.
It only botched the registration process, because the 'autocomplete' action
had not been connected in the routing system.
Orbited plugin may not work at all anymore, I had no means to try it.
But there's a check whether 'LACONICA' is defined there, which is a
very unlikely thing in the future. So far only tests and scripts have
been migrated consistently, though.
I had a problem with PHP5.5 that caused ajax responses to be empty. This
fixes it, as the problem was related to pretty inconsistent calling to
headers, XMLWriter::startDocument etc. etc.
Includes some minor changes to other things as well, such as the session
token input element now having the same 'name' attribute as everyone else.
(it still retains a 'token-'+noticeid 'id' attribute for clientside JS)
In 6de3fc0217 bookmark.js was patched to
jquery 2.x (removed '.die' call) but unfortunately the 'submit' event
was attached to an input element instead of a form element (which got
a 'click' event).
No longer bundled with the library (as jquery-ui is bundled with the
main software, including the autocomplete part).
Rewrites had to be made to migrate, as several API things had changed
when jquery-ui took over the library.
Currently (like before, right?) this only autocompletes in the end of
the current textarea. So you can't jump back in the middle of a text
and autocomplete a user or group. This is a serious deficiency, though
not a regression.
getUser calls are much more strict, and one place where this was found was
in the (un)subscribe start/end event handlers, which resulted in making the
Subscription class a bit stricter, regarding ::start and ::cancel at least.
Several minor fixes in many files were made due to this.
This does NOT touch the Foreign_link function, which should also have a more
strict getUser call. That is a future project.
lib/plugin.php now has a parent onAutoload function that finds most common
files that are used in plugins (actions, dataobjects, forms, libs etc.) if
they are put in the standardised directories ('actions', 'classes', 'forms',
'lib' and perhaps some others in the future).
In commit e95f77d34c HubSub lost the
'staticGet' function in a consolidation into the Managed_DataObject class.
This was done carelessly by me as HubSub::staticGet was actually taking
two arguments, none of which was a key and merging them in HubSub::hashkey()
(staticGet was renamed getKV 2a4dc77a63).
NOTE: This complements commit 7e4718a4eb which
fixed a similar issue for the Magicsig class.
