* no avatars
* no details of user accounts or their auth info
* no group memberships or subscriptions
* no attachments
* will probably esplode if >20 messages in your network *whistle innocently*
Workaround for #2485: in profile output on feeds, fall back to the Twitter 73x73 avatar instead of going straight to the 96x96 default image on twitter-import profiles.
Fix for #2419: There is no function maxDescription in Oauth_application class (broke the 'description too long' error message when editing oauth app registrations)
Bump up HTTP timeout for OStatus remote-tests.php to 60 seconds; when running without queues and with only bcmath, salmon key generation is absurdly slow.
Ticket #2327: fixing block to remove the blocking user's subscription to the blockee if present; also cleaning up inbox delivery to apply the block checks more consistently, instead of just to group posts.
Ticket #2750: fixes to HTTP caching behavior across login/logout boundaries
* now ignoring if-modified-since if we failed an etag if-none-match comparison, per spec
* now including a hash of user id/nickname in most etags, so we'll update the view properly after login/logout
For API methods, checking the API-auth'ed user. (Many change results to include things like 'you're subscribed to this user' or 'this is one of your favorites', so user info is again needed)
There'll still be some last-modified stamps that aren't including user info properly, probably.
Fix bug in db queue manager: when receiving an invalid or deleted notice, we were running it through the 'temporary fail, release it to try again' path instead of the 'done, discard item' path. Should fix some infinite-loop-of-doom-in-queue cases.
DirectionDetector plugin: cleanup on reference usage & code comments.
Changed getClearText() to return its value instead of changing the input to keep things clearer to maintainers.
Changes in 2d4e0693c88bb8cad47f917db3ac5ecfacf28619 changed Ostatus_profile::filterReplies() (which sorts out the local, remote, and group recipients on incoming remote messages) from checking for remote profiles with a safe call to Ostatus_profile::staticGet() to calls through Ostatus_profile::ensureProfileURL() and Ostatus_profile::ensureWebfinger(), which throw exceptions and thus abort processing.
Since this was done before checking for local groups, the filter would fail when the ensure* functions determined it was looking at a local group and rightfully refused to create a remote group profile for it.
Changing the calls to the ensure* functions was done so we can record remote reply recipients for future reply-to-reply processing (the staticGet() call was a cheaper way to do a lookup when we knew we only actually had to process groups that somebody signed up to); most important fix is simply to actually check for the exception! :)
Here I'm changing the order of processing so we do the local group lookup first -- where it's nice and safe -- and then when we do the remote checks, we'll go ahead and gracefully skip that entry if the full remote lookup fails, so we'll still process any following recipients.
Changes in 2d4e0693c88bb8cad47f917db3ac5ecfacf28619 changed Ostatus_profile::filterReplies() (which sorts out the local, remote, and group recipients on incoming remote messages) from checking for remote profiles with a safe call to Ostatus_profile::staticGet() to calls through Ostatus_profile::ensureProfileURL() and Ostatus_profile::ensureWebfinger(), which throw exceptions and thus abort processing.
Since this was done before checking for local groups, the filter would fail when the ensure* functions determined it was looking at a local group and rightfully refused to create a remote group profile for it.
Changing the calls to the ensure* functions was done so we can record remote reply recipients for future reply-to-reply processing (the staticGet() call was a cheaper way to do a lookup when we knew we only actually had to process groups that somebody signed up to); most important fix is simply to actually check for the exception! :)
Here I'm changing the order of processing so we do the local group lookup first -- where it's nice and safe -- and then when we do the remote checks, we'll go ahead and gracefully skip that entry if the full remote lookup fails, so we'll still process any following recipients.