Distributor: pushing and pulling WordPress content between sites

Two directions for moving a post between sites

Distributor solves a specific editorial problem: the same story needs to appear on more than one WordPress site, and copying the content by hand produces a copy that immediately goes stale. The plugin frames this as pushing and pulling. While logged in and editing or viewing any single post, or custom post type, that can be distributed, a Distributor item appears in the admin bar and lets you push that content to any of your connections. The other direction lives in the admin dashboard, where a top level Distributor menu item opens the pull screen and editors can share content from a connection into the current site.

The part that makes it more than a copy button is the link back to the source. The README states that content distributed by push or pull stays connected to the original, that reposted content receives updates from the original canonical source automatically, and that the plugin presents the origin and status of any reused content. So a site running republished stories does not accumulate orphaned duplicates with a stale date line; it accumulates syndicated copies that track the source.

The audience is publishing teams, particularly those running WordPress multisite networks or a group of separate properties that share an editorial desk. The plugin is also useful for agencies that maintain a network of client sites from one stack, and the hooks and filters are documented for teams that want a different workflow than the default one.

Internal connections are other sites in the same network

There are two connection types, and the difference is where the request never leaves your infrastructure. An internal connection is another site inside the same multisite network. Any user logged into the network can distribute any content in the network to any other site in the network where that user has permission to publish posts, assuming the site supports the same post type.

That last clause is a real constraint rather than a formality. Internal distribution is limited by post type support on the destination site, and by the publishing rights the user already holds there. The permission model inherits from WordPress itself rather than adding a parallel role system, which is the cleanest part of the design and also its sharpest edge: because the rule is about the person rather than the post, a logged in network member can push network content to any site where they can publish.

For a large network this is usually the desired behaviour and it removes the second install, the API handshake and the remote credentials entirely. If your sites are not in one multisite, internal connections do not apply and everything moves to the external path, with the credential handling that comes with it.

External connections run over the JSON REST API

An external connection reaches a separate website over the JSON REST API, and the README describes it as being connected by the Authorization Setup Wizard for External Connections, which uses Application Passwords. Connections are added in the WordPress admin dashboard under Distributor and then External Connections.

The setup has hard prerequisites. The remote site needs HTTP Basic Authentication or WordPress.com OAuth2 set up, and for Basic Auth the recommended route is the Application Passwords feature built into WordPress. The plugin has to be installed and active on both sides of the connection, and version 2.0.0 of Distributor requires version 2.0.0 on both sides of all connections, with a separate migration guide for the version 1 to version 2 changes.

The version pairing rule is the kind of detail that turns into downtime if you miss it. A mismatch across the two ends of a connection is not something the plugin can paper over, so upgrading one site and not its peers leaves a working pair broken until the second side moves too.

The plugin metadata confirms the shape of the package. The published artifact is named distributor, and the licence field reads GPL-2.0-or-later.

	"name": "distributor",
	"version": "2.3.2",
	"license": "GPL-2.0-or-later",

The declared build engine is node 20 or newer, which matters only to contributors running the JavaScript toolchain.

Every editor on a connection inherits the remote account's rights

Permissions on an external connection are handled by role, and the README is unusually direct about what that means. Administrators decide which user roles are allowed to distribute content to and from a connection, and Editors and Administrators are allowed by default. All users with those roles inherit the permissions of the user account used to establish the remote connection.

This is the sharpest limitation in the plugin, and it is a design consequence rather than a bug. The connection is a shared remote identity. An editor on site A who can push to site B does not push with their own rights on B, but with the rights of the account that set the connection up, which by definition has publishing rights somewhere on B. If the remote account is an administrator, then every permitted editor effectively has administrator reach on the destination.

There is no per-post or per-destination scoping in the connection model, so the mitigation sits in how you choose the account that establishes the connection, and in how narrowly you assign the distributing roles. A team that wants site B to receive from site A only from a restricted group has to do that work through the role configuration and the choice of remote account, not through the connection settings themselves.

Installing the plugin and picking the branch that matches production

There is no command line installer. The README says that for production use the recommended route is to register and download the plugin from DistributorPlugin.com, which is free and sends a direct link to the latest production ready build, and that the alternative is to download the latest release from GitHub. Either way you get a zip you can upload through the WordPress dashboard under Plugins and then Add New and Upload Plugin, or unpack it into the wp-content/plugins directory, and then activate it on the Plugins dashboard.

The branch choice matters more here than in most plugins. The README notes that the latest stable version of the plugin is the stable branch and points to a download of that branch for production, while the repository default branch is develop. Taking the wrong one gives you a build that was never intended for a live site, and the two are not interchangeable.

Registration is a separate, optional step and it is worth understanding before you fill in a form. The README describes asking adopters for a little information in exchange for a free key that unlocks update notifications and one click upgrades inside the WordPress dashboard, with the information kept confidential, and the key entered in the Distributor settings in the dashboard, or the network dashboard for multisite users. The key is tied to the email address used to register, so use the same one. Without a key the plugin still works, you simply lose the in-dashboard upgrade path.

Documented hooks, a hook index, and a plugin-sized test suite

Distributor is built the way WordPress itself is, with documented hooks and filters for changing default behaviour and creating custom distribution workflows, and the README goes further, saying you can create connections to other platforms. That is the extension point for teams whose publishing flow does not map onto push and pull.

The repository is organised to support that. There is a wp-hooks-doc.json and a wp-hooks-docs directory, and the build script for the documentation generates it with a hook documentor, with a step that copies the CHANGELOG into the documentation tree. Quality tooling is extensive rather than minimal: separate workflows for Cypress end to end tests, PHPUnit tests, linting, dependency review, and code scanning, plus a WordPress Playground blueprint that points at a raw file on the develop branch so a reviewer can click into a running instance. The JavaScript side is built with wp-scripts and the only runtime dependency listed in package.json is mustache.

The practical read for an adopter is that hooks are a supported surface, not an accident, but a custom workflow means maintaining a patch against a plugin that ships releases every few weeks, and any custom connection to another platform is code you own rather than something the maintainers test for you.

Recent releases, an active develop branch, and GPL-2.0-or-later

The last push was on 2026-10-19 and the repository is not archived. The release list shows 2.3.0 on 2026-08-18, 2.3.1 on 2026-08-26 and 2.3.2 on 2026-09-23, and the package.json version field matches the 2.3.2 release. The default branch is develop, with the stable branch as the one intended for production, and the CHANGELOG.md is at the top level for the detail behind each release.

The licence is GPL-2.0-or-later, and the LICENSE.md file in the repository is the authoritative text. A WordPress plugin under this licence inherits the same expectations as other GPL WordPress code, and the practical consequence for an agency is that a modified version distributed to clients carries obligations that a permissive library licence would not.

The upgrade cost for a team running a multisite is low in effort and non-trivial in coordination, because the plugin requires matching versions on both sides of every connection. A site in a network that lags two releases behind is not necessarily broken, but it is a site that cannot pair with a newer partner until it catches up.

Editorial conclusion

Distributor fits editorial teams that publish the same piece across a multisite network or a set of sites they control and want reposts to keep tracking the original, and it does not fit a setup where each destination needs its own trust boundary or where a shared remote account would grant too much. Before adopting it, install the plugin on both sides of one external connection, push a single test post, and check that the repost still shows its origin after the original is edited.

Frequently asked questions

Official sources

1. 10up/distributor on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases