The code used to operate under the assumption that MariaDB doesn't support
quoting identifiers. Not only is that not exactly true, but MariaDB has
reserved keywords that cannot be used as table or column names unquoted.
Issue description as reported by aab:
About one day after enabling redis plugin:
PHP Fatal error: Uncaught Error: Call to a member function getPayload() on int in /var/www/html/plugins/RedisCache/RedisCachePlugin.php:96
Stack trace:
0 /var/www/html/lib/event.php(89): RedisCachePlugin->onStartCacheSet('gnusocial:gatea...', Object(Queue_item), NULL, 86400, false)
1 /var/www/html/lib/cache.php(202): Event::handle('StartCacheSet', Array)
2 /var/www/html/classes/Memcached_DataObject.php(496): Cache->set('gnusocial:gatea...', Object(Queue_item))
3 /var/www/html/classes/Memcached_DataObject.php(416): Memcached_DataObject->encache()
4 /var/www/html/classes/Managed_DataObject.php(620): Memcached_DataObject->update(Object(Queue_item))
5 /var/www/html/classes/Queue_item.php(74): Managed_DataObject->update(Object(Queue_item))
6 /var/www/html/lib/dbqueuemanager.php(75): Queue_item::top(Array, Array)
7 /var/www/html/lib/iomaster.php(287): DBQueueManager->poll()
8 /var/www/html/lib/iomaster.php(161): IoMaster->poll()
9 /var/www/html/scripts/queuedaemon.php(112): IoMaster->service()
10 /var/www/html/lib/spawni in /var/www/html/plugins/RedisCache/RedisCachePlugin.php on line 96
NoticeSearchAction:
- Add new event before finding query matches
ActivityPubPlugin:
- Subscribe new searchNotice event
- Bump minor version number
Activitypub_explorer:
- Update lookup to make remote-grabbing optional
ActivityPubPlugin:
- update grab_notice_from_url to make online grab optional
- subscribe events of user and profile deletion
- bump minor version number
Activitypub_inbox_handler:
- separate handle_delete for delete-note and delete-person
Activitypub_postman:
- add delete-person logic
Activitypub_delete:
- update validation method to check for the "Person" type
- update to_array method to target the activity
Both StartSubscribe and StartUnsubscribe had a wrong initial if-condition.
Furthermore, this events were calling Activitypub_profile::from_profile()
which is wrong because it creates the Activitypub_profile object when
the goal is only to check if it exists already.
OStatusPlugin:
- Stop adding the remote-follow button
- Subscribe to required RemoteFollow plugin events
- Drop main/ostatussub route and update urls to the main/RemoteFollowSub route
- Bump plugin minor version number
actions/ostatusgroup,
actions/ostatuspeopletag:
- Update urls to the main/RemoteFollowSub route
lib/util:
- Port required functions from OStatusSubAction and adapt to be used with the new events
lib/default.php
- Add RemoteFollow to the list of default plugins
RemoteFollowPlugin:
- Subscribe events to add the remote-follow button
RemoteFollowInitAction:
- Handles the remote-follow form and getting the redirection url for follow completion
RemoteFollowSubAction:
- Handles the remote profile pulling and actual following
ActivityPubPlugin:
- Subscribe DirectMessage events
Activitypub_inbox_handler:
- Update handle_create_note to create private messages
Activitypub_postman:
- Add create_direct_note for sending private messages
Activitypub_create:
- Update create_to_array to support the 'directMessage' attribute
- Add isPrivateNote to verify private activities
Activitypub_notice:
- Update create_note to support the 'directMessage' attribute
- Remove isPrivateNote
lib/models:
- Add Activitypub_message, the model in charge of private notes
Activitypub_profile:
- Fix subscription-counter getter functions, invalid profiles were being counted
apActorFollowingAction:
- Small rewrite of generate_following, didn't make sense to not use try-catch block
apActorFollowersAction:
- Small rewrite of generate_followers, didn't make sense to not use try-catch block
Note that this commit isn't intended to add support for sending such notes
in GS. Instead, we handle the reception, storage and direct reply to this
type of notices, in AP.
ActivityPubPlugin:
- Subscribe the event StartNoticeSave to hack answering non-public notes
Activitypub_create:
- Add 'directMessage' attribute to the Create activity, defaulting to false for now
- Update validation method: validate 'directMessage' and add debug
Activitypub_notice:
- Handle incoming unlisted/followers-only notes
- Add support for unlisted-replies
- Add method to verify private (direct) notices
inbox_handler:
- Add handler for CREATE Note
- Prepare logic for private-messaging
- Overall refactor: Class members were continuously being passed as function arguments without need
SharePlugin:
- Stop showing the announce button in non public posts
For reference (raised by rozzin in IRC):
* http://foldoc.org/module
* http://foldoc.org/library
* http://foldoc.org/plugin
As noted by XRevan86, modules are not necessarily non-essential.
As we will keep the modules directory in GS root [therefore, near to
plugins/], it is evidenced the difference between both.
This is a simple yet fundamental structural change. It doesn't change
functionality but makes clearer the way we understand GNU social's
internals.
This commit does the necessary rework to store private messages
as Notices and to support Federation. The plugin's README presents
some more detail about the changes and future work that is still
required to do.
ActivityPubPlugin:
- Change event-based notice distribution to queues logic
ActivityPub/lib:
- Add queue handler class activitypubqueuehandler.php
Misc:
- Add documentation for the (Start/End)InitializeQueueManager events
OStatusPlugin:
- Enqueue in the last position, as it should be. No need to worry about
the OMB comment, this protocol no longer have queue handlers that could
cause a conflict.
ActivityPubPlugin:
- Prevent sending a Delete for an Announce
Activitypub_announce:
- Update announce_to_array to add id, to and cc information to the retrieved object
Activitypub_follow:
- Add id to the arguments of follow_to_array, useful for Accept-Follow activities
Activitypub_notice:
- Fix notice validation, url isn't a MUST
Activitypub_inbox_handler:
- Make handle_follow use the received activity id for the later Accept-Follow
Activitypub_postman:
- Fix call to the updated announce_to_array
- Fix successive unnecessary calls to ActivityPubPlugin::actor_uri()
ActivityPubPlugin:
- Minor onDeleteOwnNotice rewrite
Activitypub_inbox_handler:
- Add deletion check to incoming notice
Activitypub_postman:
- Call the correct getUrl function
ActivityPubPlugin:
- Minor re-write of favor/disfavor event handlers
Activitypub_postman:
like/undo-like:
- fix proper getUrl() call
misc:
- make all activities accumulate errors (may be needed later) and log some information about it
ActivityPubPlugin:
- Fix of accepted activity verbs to include SHARES
- Add attention profiles to delivery when announcing
Activitypub_notice:
- New local function to retrieve original URL
- Removal of unnecessary 'Atom*' attributes
- Small fix to the ensuring of actor profile
Activitypub_profile:
- New local function to fetch AP profiles from a collection
Activitypub_postman:
- Fix url passed in the announce activity
Follow interaction:
- Fixed mini-bug where the subscriber profile was being used as the subscribed
- Updated cache subscription-related values in both instances
- Tested and working with local GS instances
Unfollow interaction:
- Updated cache subscription-related values in both instances
- Tested and working with local GS instances
Followers/Following collections:
- Now returning ActivityPub profiles only
- Stored collections in cache
Misc:
- Fix bug concerning the retrieval of public/private-key after in-function generation
This is not the same as the one in https://notabug.org/diogo/gnu-social-activitypub-plugin
Differences to the first "release"
-> Doesn't use guzzle nor has any composer dependencies
-> Supports HTTP Signatures
-> Has basic l10n/i18n
-> Some minor bug fixes
Seriously improved documentation
Now NodeInfo 2.0 is available at /api/nodeinfo/2.0.json
For active users we now also consider favourites and recently created accounts
Some further minor bug fixes and full review of the implementation
Advantages:
* Increases security by preventing direct access to file/
* We are careful and have a defined('GNUSOCIAL') || die() to prevent
direct access to GS files, but we may miss one or a vendor/extlib may
not be as careful
* Improves directory structure - It's more natural to physically
separate what is public from what are GNU social resources
DeletenoticeAction:
- Added tombstone check before deletion
NoticeListItem:
- Added tombstone check before showing delete-form
ActivityVerb:
- The plugin was overwriting the deletenotice route. Added stronger
regexp to the connected routes.
Router:
- Fix calls to connect, most of them were misusing the function's params
URLMapper:
- Minor fixes
- Documentation
- Add support for accept-header specification
Plugins/*:
- Fix calls to connect
This commit also fixes the translation in /plugins/OpenID/actions/finishopenidlogin.php#L203-L204 (s/Syncronize/Synchronize)
Sync is a bad technical jargon and we should use Synch instead.
Synch is already used in other parts of GNU social as seen in plugins/TwitterBridge/classes/Twitter_synch_status.php
UI:
- "Delete" area is now "Actions" area
- Updated themes to better reflect the changes
Routes:
- index.php?action=finishsyncopenid => finishsyncopenid
Translations:
- Updated OpenID translation files
- Updated OpenID POT file
Versioning:
- Bump OpenID minor version
- Bump GS patch version
Why would have labeling the Synchronize button of Sync been of bad taste? - answered by XRevan86:
In "synchronise" "ch" is a digraph meaning /k/ (actually /x/ turned into /k/ in English but whatever).
So… not separate letters.
It's like "ph" in "alphabet", or "sh" in "sheep", or "ch" in "chop" -- "ch" can mean a whole variety of sounds.
Original XMPPHP is no longer maintained
Therefore I've done some optimizations and imported some commits from birkner and zorn-v forks.
None of the forks really looked ready to be adopted...
Added two more options: delete image-only attachments; delete previews (like oembed thumbs)
Some further minor improvements.
Thanks to colegota for spotting this issue.
I noticed that each time a notice was accessed it'd do a remote lookup
with HEAD (and continue despite 404 etc.) and then another attempt to
download the resource. If this wasn't successful new attempts would be
made for each loading of the resource, which is extremely resource
intensive.
Whenever we can say "it's been n seconds since the last attempt" we
could probably enable this again - or just manually reload remote
thumbnails (as part of the StoreRemoteMedia plugin etc.)
WebSub is probably finalised before we make a release anyway. Here is
the official spec: https://www.w3.org/TR/websub/
Mostly just comments that have been changed. Some references to PuSH <0.4
are left because they actually refer to PuSH 0.3 and that's not WebSub...
The only actual code change that might affect anything is FeedSub->isPuSH()
but the only official plugin using that call was FeedPoller anyway...
This because some remote server might have used third party PuSH hubs
but switch and we don't know about it.
Possible risks here are of course MITM that could force us to rediscover
PuSH hubs from a feed they control, but that currently feels ... meh.
