wordpress-webmention
wordpress-webmention copied to clipboard
pfefferle
Async Processing
http://indiewebcamp.com/webmention-spec
The webmention specification states that the webmention should be queued and processed asynchronously to avoid DoS attacks.
There is a more ambitious proposal I put through for Core if this ever happens. But within the scope of this plugin, would like to see about using wp-cron to delay remote retrieval.
@dshanske do you have an idea how we can start with that? Perhaps we save all mentions in a custom post cue and either process them directly or running a cron.
@petermolnar how do you handle this problem in your plugin?
ah, @petermolnar is cueing a single cron with the URL as param... this is a nice and simple idea, but it makes it hard to provide a status API... hmmm...
Oh no, this is only for the archive.org call... the Webmentions are cued in an extra webmention table... But I will avoid creating a new table... hmmm...
wp_insert_comment allows a comment to be stored in the database without going through the usual filters/actions. We can then trigger those filters after source verification.
https://github.com/A5hleyRich/wp-background-processing - This looks promising.
I read a little bit in the docs, but in the end it also uses a wp_schedule_event, so I am not sure if we need the overhead of this classes...
@pfefferle Revisiting this in light of #474, and thinking of conducting the tests of how an unsupported status might work. Technically, the comment table doesn't have a custom status, it has comment_approved, which acts as an unofficial status.
WP_Comment_Query has the argument - Comment statuses to limit results by. Accepts an array or space/comma-separated list of 'hold' (comment_status=0), 'approve' (comment_status=1), 'all', or a custom comment status. Default 'all'.
However, ready the actual code, the documentation is off. https://github.com/WordPress/wordpress-develop/blob/6.5/src/wp-includes/class-wp-comment-query.php#L559 . All is actually 0 or 1, and there is an 'any' status that would show hidden types.
So, it looks like a custom comment status wouldn't be picked up anywhere by default, but should be easy enough to test just to make sure.
If so, we could store incoming webmentions with a 'queued' status and a type of webmention, then schedule a query in the background process to run through them.