Add filter to disable local attachment storage

[obenland]

Follow-up to #2314

Addresses #2314 (comment)

Proposed changes:

• Adds a new activitypub_store_attachments_locally filter that allows users and plugins to disable local storage of attachments from incoming ActivityPub posts
• This addresses the feedback about providing an option for users with limited webspace who may prefer not to download and store remote images locally

Other information:

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

Testing instructions:

Default behavior (no change):

1. Ensure the plugin is active
2. Receive an ActivityPub post with attachments
3. Verify attachments are downloaded and stored locally in wp-content/uploads/activitypub/ap_posts/{post_id}/

Disabled storage:

1. Add this code to your theme's functions.php:

add_filter( 'activitypub_store_attachments_locally', '__return_false' );

2. Receive an ActivityPub post with attachments
3. Verify that attachments are NOT downloaded or stored locally

Changelog entry

[Copilot]

Pull Request Overview

This PR adds a new filter activitypub_store_attachments_locally that allows plugins or users to disable local storage of attachments from incoming ActivityPub posts, which can be useful for users with limited webspace.

• Introduces filter hook to control whether attachments should be stored locally
• Applies the filter in both the add() and update() methods of the Posts collection class
• Maintains backward compatibility by defaulting to true (store locally)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

When $store_locally is false, the existing attachments directory is not deleted, which could lead to orphaned files if a post previously had local attachments enabled and is now being updated with the filter returning false. Consider deleting the existing attachments directory before the conditional check, or add an else clause to handle cleanup when the filter is disabled.

Suggested change

	Attachments::import_post_files( $activity['object']['attachment'], $post_id );
	Attachments::import_post_files( $activity['object']['attachment'], $post_id );
	} else {
	Attachments::delete_ap_posts_directory( $post_id );

[pfefferle]

That is not exactly what I had in mind 🤔

I will try to provide an example later today.

[Jiwoon-Kim]

https://wordpress.org/plugins/regenerate-thumbnails/

Using a plugin like Regenerate Thumbnails can pose a significant risk when dealing with a large number of image files. In other words, in the case of Fediverse, performing bulk synchronization of images could be very dangerous.

My suggestion is also based on the assumption of using the mediaLib endpoint(+FMO). By specifying the file size in advance, each instance can predictively generate the image itself.

Additionally, retrieving and synchronizing the file URL of remote image objects also becomes easier.

---

Inspired by FileBird, I think that using an S2S Media Library endpoint could make it possible not only to query collections or individual image objects, but even to transfer them in bulk as a compressed archive.

[Jiwoon-Kim]

The most painful idea I'm dealing with right now is that,
to implement a Proxy Post system, I would need to insert an actor_id mapping layer between the wp_users table and the author field.

However, once author is decoupled from wp_users,
the entire core structure and countless plugin/function dependencies will inevitably break.

I'm trying to design a blog actor model that allows multiple intermediaries (proxies or agents) to exist between the author and the post,
but the architectural complexity is skyrocketing to an unbearable level...

#2322 (comment)

As you know, when enabling Multisite in WordPress, additional tables related to blog_id and site_id are created.

Neither Mastodon nor Misskey supported ActivityPub from the beginning — their architectures had to be restructured to accommodate federation.

So why do you think WordPress could achieve full federation without any core modification?

In my opinion, a more proper and sustainable approach would be to first handle core extensions and housekeeping through a canonical plugin, and only then build the ActivityPub layer on top of that foundation.

[obenland]

That is not exactly what I had in mind 🤔 I will try to provide an example later today.

@pfefferle Have you had a chance to give this another thought?