Move: support same-server domain migrations #1530

mattwiebe · 2025-04-01T00:46:46Z

Very much a WIP, utterly untested, but the general shape of things is there. There's no listener on the home option yet, just working to have a Move::change_domain method that would ultimately connect to it, and the beginnings of serving the $from Actor distinctly from the $to Actor.

Fixes #1513

Proposed changes:

Other information:

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

Testing instructions:

Apply this PR to a WoA test blog.
Go to https://wordpress.com/domains/manage/SITE and update the primary domain.
Dump the saved old actor json and make sure the domains are correct (the old primary domain)

var_dump( get_option( 'activitypub_old_domain' ), json_decode( \get_option( 'activitypub_blog_user_old_domain_data' ) ), json_decode( \get_user_option( 'activitypub_old_domain_data', 12082294 ) ) );exit;

Make sure there's a Move activity in the outbox with the correct target property (new domain).

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

Support same-server domain migrations

includes/class-move.php

includes/model/class-cached-actor.php

includes/class-move.php

mattwiebe · 2025-04-01T19:01:46Z

Sorry I overwrote your changes @obenland - but I changed the approach radically enough that that function doesn't exist anymore :)

includes/class-move.php

includes/collection/class-actors.php

includes/model/class-user.php

mattwiebe · 2025-04-01T20:40:50Z

Some remaining tasks:

Handle the lifecycle of receiving follows on the new ID and unfollows on the old ID
Ensure that the old domain ID is used when POSTing the Move Activity to Follower inboxes
Add a home option listener, gated behind a constant for further testing

obenland · 2025-04-01T20:48:22Z

Ensure that the old domain ID is used when POSTing to Follower inboxes

Could you share more on that? I would have expected no changes since followers will send new Follow requests to the new account.

mattwiebe · 2025-04-01T20:57:15Z

Ensure that the old domain ID is used when POSTing to Follower inboxes

Could you share more on that? I would have expected no changes since followers will send new Follow requests to the new account.

When we send the Move activity from the outbox to our Followers, we need to make sure we're using that we're using the correct Actor ID here. The "main"/default Actor at this point will be the new domain, but these requests need to be sent/signed by the old domain.

obenland · 2025-04-01T21:04:46Z

Ah, in the context of Move activities, only. I thought in general. Thank you!

mattwiebe · 2025-04-01T21:05:10Z

Also note that some concerns we're raising here probably also apply to Move::internally.

I think we need to serve $from and $to differently in that case as well. So I think we ultimately need to follow a very similar caching behaviour there as well, but it's going to be harder to detect say https://wp.test/?author=1 vs https://wp.test/@username in that case.

includes/class-dispatcher.php

includes/collection/class-actors.php

Updates blog user option to retain naming convention.

obenland · 2025-04-04T21:51:10Z

Tested this on WoA a bit, with little success. Primary domain changes happen there through direct SQL updates, bypassing the pre_update_option_* hook we rely on.

Maybe we should keep track of the current domain ourselves and use that to populate our $from values. It would also allow us to switch back to the update_option_home action, that fires after it's actually been updated.

obenland · 2025-04-07T20:52:58Z

I think I made a fair bit of progress today:

Found a way to make change_domain() work on the update_option_home hook. It's not very elegant, it just replaces all instances of the new domain in the actor json with the old domain, before saving it. Maybe that's too naïve? Do we need. toworry about the signature we're storing?
Made a few updates to domain checks in order to allow actor identification with the old domain.
Updated the test to reflect the changes in hooks used.

@pfefferle I'd love for you to test this on a WoA sites or something more real world than localhost and see what you find!

Copilot

Copilot wasn't able to review any files in this pull request.

Files not reviewed (14)

.github/changelog/add-same-server-domain-move: Language not supported
activitypub.php: Language not supported
includes/class-activitypub.php: Language not supported
includes/class-dispatcher.php: Language not supported
includes/class-move.php: Language not supported
includes/class-query.php: Language not supported
includes/class-signature.php: Language not supported
includes/collection/class-actors.php: Language not supported
includes/functions.php: Language not supported
includes/model/class-blog.php: Language not supported
includes/model/class-user.php: Language not supported
tests/includes/class-test-move.php: Language not supported
tests/includes/model/class-test-blog.php: Language not supported
tests/includes/model/class-test-user.php: Language not supported

pfefferle · 2025-04-09T09:13:03Z

includes/class-move.php

+		 *
+		 * @param bool $domain_moves_enabled Whether domain moves are enabled.
+		 */
+		$domain_moves_enabled = apply_filters( 'activitypub_enable_primary_domain_moves', false );


@obenland I know that you are not a fan of constants, but this would be the third possibility to enable a feature, aside from advanced settings and constants.

I think we should have a certain level of consistency. I am not arguing for a constant her, maybe we should think about a Developer Preview or Beta Features section in the Advanced settings to enable beta features!?!

I'd be happy to deprecate feature constants in favor of filters or advanced settings

Even if `get_collection` is returning the correct result, it is very specific to the API endpoint and might change over time, so we should not rely on it here.

pfefferle · 2025-04-09T10:02:35Z

I think we should merge this PR! It is behind a feature flag, so it is not breaking something and with the functionality in the core plugin, it would allow us to more easily test it on WordPress.com or self hosted installations.

It is a solid state we can improve on.

* first pass from AI generation. Needs work * reign in the chaos * move logic into models * Move constructor to below properties * Update function name * Don't show `movedTo` on the same ID * DRY old domain handling * Add options to delete list on uninstall Updates blog user option to retain naming convention. * Register user option * Move actor saving inline * changelog * Remove all followers on `Move` to allow the new Actor to be re-followed * lint lol * Fix indent after merge * Combine conditional on host * Fix unit test * First pass at testing change_domain * Revert "lint lol" This reverts commit c50a441. * Revert "Remove all followers on `Move` to allow the new Actor to be re-followed" This reverts commit 1d8948f. * Encapsulate domain check * Remove unused defaults * Hook in with feature flag * Add filters and handle username in callback * Remove unused import * Add unit tests for old actors * Update reason for pre_update_option hook. * Instantiate old actors through filters * Remove unused import * use query instead of Http client * store check * simplify code * call action before sending an Activity to inboxes * check class attribute before generation an id * make old domain request setable * Account for old domain in two more places * Fix json creation on update_option_home * Fix tests * fix phpcs * use \WP_Error * Domain -> Host * global namespace * replace `get_collection` with `get_all` Even if `get_collection` is returning the correct result, it is very specific to the API endpoint and might change over time, so we should not rely on it here. --------- Co-authored-by: Konstantin Obenland <obenland@gmx.de> Co-authored-by: Matthias Pfefferle <pfefferle@users.noreply.github.com>

* tag '5.7.0': (29 commits) Release 5.7.0 (Automattic#1574) Fix: Show error if site uses "Almost Pretty Permalink" structure (Automattic#1570) Admin: Add padding to extra fields nav links (Automattic#1569) Signature: Add compat for more key encodings (Automattic#1557) Reply block: Improve fallback embed (Automattic#1560) Add label for "Health Check" and "REST API" (Automattic#1571) change changelog items (Automattic#1572) Transformers: Allow setting properties to false. (Automattic#1567) Upgrades: Delete orphaned extra fields (Automattic#1566) Fix: Missing Actor in Outbox-Activities (Automattic#1564) Outbox: Properly handle username requests (Automattic#1559) Import: Load on admin_init (Automattic#1561) Move: support same-server domain migrations (Automattic#1530) Follow Me: add a button-only mode (Automattic#1133) Tests: Convert timestamp to int for comparison (Automattic#1556) Reply: Make Mastodon embeds work (Automattic#1555) Add: `Vary` header settings (Automattic#1552) Actors: Don't convert non-numeric strings to Blog user id (Automattic#1554) Add: Shared Inbox setting (Automattic#1553) Add: New Health checks (Automattic#1524) ...

github-actions bot added [Feature] Collections [Status] In Progress labels Apr 1, 2025