The ActivityPub plugin turns a WordPress site into a Fediverse profile

What the plugin actually connects

The plugin description states the model plainly. The ActivityPub plugin connects your WordPress site to the Fediverse. Your site becomes a profile people can follow from Mastodon, and every post you publish is automatically delivered to your followers' feeds, where their likes, boosts and replies come back as comments on your site.

That is the whole value proposition, and it is a good one for a particular kind of publisher. If you already write on WordPress and you have an audience, adding the plugin means your existing posts reach a second network without you maintaining a second account, a second posting workflow, or a second set of credentials.

The federation direction matters as much as the outbound one. The description says replies come back as comments, which is the part that surprises people. A reply from a Mastodon user appears in your WordPress comment queue rather than in a separate inbox, so moderation, spam filtering and notification all stay in the tools you already have.

The audience is a WordPress site owner who publishes writing and wants it federated, plus the developer who wants to understand how a real WordPress implementation of the protocol handles the messy parts. The topic list covers the expected ground, with activitypub, activitystreams, decentralized, federated, fediverse, mastodon, ostatus, wordpress-plugin and hacktoberfest.

The plugin lives in the WordPress.org directory, and the default branch is trunk, which is the WordPress convention rather than a GitHub one.

FEDERATION.md is the file to read before anything else

The documentation section is short, and one of the links carries most of the weight. ActivityPub is a protocol for federated social networks enabling communication between different platforms, and for details on what the plugin supports, the documentation refers to the FEDERATION.md file in the repository root.

That is a good sign. A federated protocol has a large surface of optional and partly optional behaviour, and the difference between a plugin that implements the actor model properly and one that implements a subset is the difference between federating with Mastodon and federating with a corner of ActivityPub that some servers ignore. Rather than describing coverage in the readme, the project points at a single file that holds it.

The file is at the repository root next to SECURITY.md, LICENSE, CHANGELOG.md and the contributing guides, so it is treated as a first-class artefact rather than a wiki page.

For an adopter, this is the file to read first, and to read against your own scenario rather than skim. The specific questions are whether the server-side actor is your site or a per-user profile, how media attachments are handled, how moderation and follow-request approval are exposed in the WordPress admin, and what happens to a post that is edited or deleted after it has been delivered. The documentation does not answer those here, and it points you to FEDERATION.md rather than pretending otherwise, which is the behaviour you want from a protocol implementation.

WordPress Playground, so you can try it before you install it

There is a demo path, and it is a good one for a plugin that changes how your site talks to the rest of the internet.

The documentation says you can test out the plugin, specifically the settings, with WordPress Playground, and the note explains what that platform is: it lets you run WordPress instantly on any device without a host, and it is the place to build, experiment, test and grow.

That removes the main objection to trying a federated plugin, which is that turning it on changes your site's public identity and starts sending content to third-party servers. In a Playground instance you get a throwaway WordPress, you can configure the plugin, and you can see the shape of the settings without publishing anything from your real domain.

The repository also lists sites already running the plugin, so you can see behaviour before installing. The list includes the Social Web Foundation, the ActivityPub Blog, Evan Prodromou's site, IFTAS and Kaffeeringe, each with its Fediverse handle shown. The plugin invites people who run it on their own site to add themselves to a Show and Tell discussion category.

That combination, a sandbox to configure in and a list of live examples to observe, is a reasonable way to evaluate whether the plugin's model of identity matches what you want. Whether your WordPress site becomes a single followable profile or something more granular is exactly the kind of question the FEDERATION.md file and these examples are there to answer.

A plugin built on the standard WordPress toolchain

The package manifest shows this is a conventional WordPress plugin rather than a one-off script, and the tooling is worth understanding if you plan to contribute.

The build and test scripts run on wp-scripts. The dev script starts the development server, the build script removes the build directory, formats and builds with the experimental modules flag, and there are separate lint targets for CSS and JavaScript. Unit tests run under Jest, with a watch mode and a debug mode that pauses on a breakpoint, and end-to-end tests run under Playwright against a configuration in tests/e2e.

The environment scripts use wp-env, and the start and stop targets are plain npm aliases for it:

		"env-start": "wp-env start",
		"env-stop": "wp-env stop",

There is also an env-test target that runs PHPUnit inside the plugin directory, and a prepare script that points git at the hooks directory in .githooks.

There is a .wp-env.json at the repository root, which is where that environment is described, and the release script is node bin/release.js.

On the PHP side the repository carries phpcs.xml, phpstan.neon.dist and a phpstan-baseline.neon, plus phpunit.xml.dist, so there is coding standards checking, static analysis with a recorded baseline of known issues, and unit tests. The top-level structure also shows the split between includes/, src/, integration/, patterns/ and templates/, which suggests a plugin that keeps its PHP core, its JavaScript, its block patterns and its server-rendered templates in separate trees, with a src/ directory for the front-end code that webpack.config.js and tsconfig.json build.

There is an .agents/ directory and a .claude/ directory alongside AGENTS.md and CLAUDE.md, which is the current convention for giving automated contributors the project's rules.

MIT licensed, with Automattic's security process behind it

The plugin is licensed under the MIT license, with the LICENSE file at the repository root and the same field in the package manifest. For a WordPress plugin that is the expected choice, and it means a site can fork and modify it without a copyleft obligation on their own code.

The security story is more interesting than the licence. To report a vulnerability, the documentation sends you to https://automattic.com/security/ or directly to the security bug bounty site at https://hackerone.com/automattic. There is also a SECURITY.md file in the repository with more information on reporting security vulnerabilities.

The bug bounty route is a meaningful signal for a plugin like this one. A WordPress plugin holding federation credentials and making outbound requests to arbitrary fediverse servers is a component that touches the public internet in a way most plugins do not, and having a funded bounty programme behind the reporting route is a reasonable way to handle that surface.

Upkeep is steady. The last push was on 2026-10-22, the repository is not archived, and the tagged releases are 9.3.1 and 9.3.0 both on 2026-09-02, with 9.2.2 on 2026-08-11. The documentation also links a release process guide, so the tagging is a documented process rather than an ad hoc step.

Translations, snippets, and a defined scope

Two extension points in the documentation are worth knowing about, because they tell you what the maintainers expect people to do with the plugin.

The first is translations. There is a documentation page on translations and a link to translate.wordpress.org/projects/wp-plugins/activitypub/, so the plugin is localised through the standard WordPress translation infrastructure rather than a bespoke system. For a plugin whose whole purpose is to reach a broader audience, having the interface translated is a reasonable expectation.

The second is snippets. The documentation lists a snippets/ directory described as community-contributed snippets to extend or customize the plugin, and the repository root confirms the directory exists. That is the mechanism for the changes that do not belong in core.

The contribution guidelines are unusually explicit about scope. Keep issues clear and focused, using the bug report form for bugs and Discussions for feature ideas so they can be considered together. Stay relevant to the plugin's scope, with issues and comments expected to relate directly to improving the plugin, and tangential ideas or unrelated feature requests closed. Be concise, and follow the Contributor Covenant Code of Conduct.

The scope statement is the interesting one for an adopter. A federated protocol plugin has an obvious temptation to grow into a general-purpose social layer, and a maintainer who closes tangential requests is protecting the boundary that keeps the plugin maintainable. The trade-off for you is that if you want behaviour the plugin does not have, you will be doing it in a snippet or a fork, and the federation rules in FEDERATION.md are where you find out whether that is even possible.

Editorial conclusion

The ActivityPub plugin suits a WordPress publisher that wants a presence on the Fediverse without running a separate Mastodon server, and that is comfortable with the federation being partial rather than complete. It is the wrong choice if you need full ActivityPub actor semantics on the server side, because the plugin's own FEDERATION.md is the authority on what it supports and you should read it against your own use case first. Before enabling it on a live site, test the settings in WordPress Playground, which the project points to for exactly this, and confirm that your hosting can make outbound HTTPS requests to the fediverse servers your followers use.

Frequently asked questions

Official sources

1. Automattic/wordpress-activitypub on GitHub
2. License: MIT
3. Project website
4. README
5. Releases