Refine handling of local content visibility for posts

[pfefferle]

This PR aims to send an Update activity when a previously federated post is later set to local, reflecting changes to the audience (to, cc fields) and in_reply_to.

The benefit of this change (if it works as intended) over sending a Delete is that the post can be reactivated by simply changing its visibility.

Improves logic for 'activitypub_content_visibility' set to 'local', ensuring posts are only disabled if not already federated. Updates transformer logic to set correct recipients for local posts, prevents in-reply-to for local visibility, and adds/updates related unit tests to cover these scenarios.

For reference https://wordpress.org/support/topic/how-to-delete-federated-posts/

Proposed changes:

• Send Updates when a post was published before and set to local afterwards
• Clear in_reply_to (not sure if that is needed)
• Only set Post-Author to to and cc (not if that is needed or if empty arrays would also do the job)

Other information:

• Have you written new tests for your changes, if applicable?

Testing instructions:

• Publish a public post

• Change visibility to local

• Check Outbox if Update is properly created

• Write new post and set to local before publishing

• Check that no Update / Create Activities were created

Changelog entry

• Automatically create a changelog entry from the details below.

Changelog Entry Details

Significance

• Patch
• Minor
• Major

Type

• Added - for new features
• Changed - for changes in existing functionality
• Deprecated - for soon-to-be removed features
• Removed - for now removed features
• Fixed - for any bug fixes
• Security - in case of vulnerabilities

Message

Improved handling of posts switched to 'local' visibility so they update correctly and can be re-enabled by changing visibility again.

[Copilot]

Pull Request Overview

This PR improves the handling of posts switched to 'local' visibility by sending Update activities instead of Delete activities when a previously federated post becomes local. This allows posts to be reactivated by changing visibility again rather than requiring deletion and recreation.

• Modified logic to send Update activities for previously federated posts set to local visibility
• Updated transformer to set correct audience for local posts (author as both to and cc)
• Prevented in_reply_to field population for local visibility posts

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
includes/functions.php	Enhanced is_post_disabled() logic to handle local visibility posts based on federation status
includes/transformer/class-base.php	Added audience handling for local visibility posts
includes/transformer/class-post.php	Prevented in_reply_to population for local posts
tests/includes/transformer/class-test-post.php	Updated test to verify local posts have author in to and cc fields
tests/includes/collection/class-test-replies.php	Added status metadata cleanup in test
tests/includes/class-test-query.php	Enhanced test coverage for local visibility scenarios

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[pfefferle]

After some feedback from Mastodon contributors: This is actually not possible. We would have to send a Delete in this case.

The risk here: A Delete is irreversible and a re-publish is not possible then.

[pfefferle]

@obenland the question is if we want to send a delete!?

[obenland]

Maybe we could add a notice into the visibility selector in the editor, warning that it's a permanent change?

Other than that, it feels like a specific-enough action to me, to assume that it doesn't happen accidentally. I'd be fine with sending the delete even without a warning.

[Jiwoon-Kim]

In the case of Misskey, there is an option for delete-and-edit. For WordPress federation, this could be implemented by actually deleting the original post and publishing a duplicate as a new post with a new ID.

Of course, any existing comments or interactions would be lost.

[Jiwoon-Kim]

For WordPress federation, this could be implemented by actually deleting the original post and publishing a duplicate as a new post with a new ID.

By the way, couldn’t this approach also be applied to actors? I have a hunch that threads.net might be using a similar method to implement federation opt-out.