Add WP-CLI command to reprocess inbox items #2500
Conversation
Adds 'wp activitypub reprocess_inbox' command for local development that: - Accepts an ap_inbox post ID - Deletes any existing comments or ap_post items created from the activity - Reprocesses the activity through the inbox handler This is useful for: - Testing inbox processing logic - Debugging activity handling - Re-importing activities after code changes Also enables activitypub_create_posts option in local development to allow testing of post creation from ActivityPub Create activities. Usage: wp activitypub reprocess_inbox <post_id> Example: wp activitypub reprocess_inbox 123
obenland
added
the
Skip Changelog
There was a problem hiding this comment.
Pull Request Overview
This PR adds a WP-CLI command for reprocessing ActivityPub inbox items during local development, enabling developers to test activity handling without re-receiving activities from remote servers.
- Adds
reprocess_inboxWP-CLI command to delete existing content and reprocess an inbox activity - Enables
activitypub_create_postsoption by default in local development - Implements deletion of existing comments and posts before reprocessing to ensure clean state
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| local/load.php | Enables automatic post creation from ActivityPub activities in local development |
| local/class-cli.php | Implements new WP-CLI command to reprocess inbox items with cleanup of existing content |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Use object_comment instead of reusing comment variable for the second lookup to improve code clarity and prevent potential confusion.
pfefferle
left a comment
pfefferle
left a comment
There was a problem hiding this comment.
I would assume that a method called reprocess would reprocess any kind of Inbox Item, not only Creates (aside from that, the current implementation would handle any kind of Item as a Create). The Inbox stores every incoming Activity (except Deletes), so a reprocess has to take care of properly reprocessing Announces, Likes, Undos and all other types, the plugin supports.
To have a proper reprocess we should simply call the same do_action that is triggered by the inbox, to run through the same detection and handler process, a normal Activity would run through.
Instead of directly calling process_create_item(), the reprocess_inbox command now makes an internal REST API call to the shared inbox endpoint. This ensures the activity goes through the full processing pipeline including validation, moderation, recipient determination, and all registered action hooks for any activity type.
Changed reprocess_inbox to conditionally delete existing artifacts based on activity type. Only Create, Like, and Announce activities now trigger deletion. This preserves existing posts/comments for Update, Delete, and Undo activities, which need to find and operate on those artifacts.
The reprocess_inbox command now:
- Deletes existing artifacts before reprocessing (handlers check for
duplicates and skip creation if they exist)
- Calls both activitypub_inbox_{type} AND activitypub_handled_inbox_{type}
hooks since handlers are registered on different hook sets
- Preserves original recipients from inbox post meta
- Works for all activity types (Create, Update, Delete, Like, Announce, Undo)
This ensures activities go through the same detection and handler process
as new activities, addressing feedback about proper reprocessing.
|
@pfefferle Thanks for your feedback, I think this is in a better shape than it was last night. This is about as much time I'd want to invest in this PR. If there are any additional points of feedback, I think we're quickly approaching a negative return for time invested, and I'd want to find a different approach. |
What is the purpose of the PR? |
|
To allow reprocessing of inbox items in local development to test changes in ap_post parsing. Test if changes like in #2499 are working. |
I’m not so sure about that then. I think the time investment is still worthwhile! If the reprocessing isn’t working correctly, then an |
|
@obenland can you provide me some examples to test why the reprocess only work with the deletion? |
|
The way I tested it was to change an ap_post item, remove some content for example, then reprocess its inbox item and see if the content was restored. |
|
@obenland found the issue! will work on a fix! |
Replaces do_action hooks with direct calls to Update::handle_update and Create::handle_create for improved clarity and flow in activity handling. Removes artifact deletion logic from CLI reprocessing, streamlining the process.
|
@obenland should be fixed now! |
|
@pfefferle Yes, looks good. Has some unit tests failing now. You'll have to accept the PR when you're happy with it ;) |
Replaces references to the deprecated 'activitypub_inbox_create' action with 'activitypub_handled_create' in the test. Also updates the test activity object and adjusts the action handler parameters for compatibility.
|
Now that I’ve seen the effects of the restructuring, I’m not sure “happy with it” is the right way to put it. :( |
Proposed changes:
wp activitypub reprocess_inboxcommand for local developmentactivitypub_create_postsoption in local development for testingOther information:
Testing instructions:
wp activitypub reprocess_inbox <post_id>where<post_id>is an ap_inbox post IDExample usage:
# Reprocess inbox item with ID 123 wp activitypub reprocess_inbox 123Expected output:
Changelog entry