Distributor is a WordPress plugin that makes it easy to distribute and re-use content across your websites — whether in a single multisite or across the web.
You can learn more about Distributor's features at DistributorPlugin.com.
Note: The latest stable version of the plugin is the stable branch. Download the stable branch if you are intending to use the plugin in production.
Distributor supports safe, SEO-friendly content reuse and sharing via "pushing" and "pulling".
While logged in and editing or viewing any single post (or custom post type) that can be distributed, a Distributor admin bar item will appear, that will facilitate sharing ("pushing") that content to any connection.
In the admin dashboard, a top level Distributor menu item links to the "pull" screen. Here, editors can share ("pull") content from any connection into the current site.
Content this is distributed (via Push or Pull) is connected to the original. Reposted content receives updates from the original, canonical source automatically.
There are two connection types: internal and external.
- Internal connections are other sites inside of the same multisite network. Any user logged into the network can distribute any content in the network to any other sites in the network where that user has permission to publish posts (assuming the site supports the same post type).
- External connections are external websites, connected by the JSON REST API. External connections can be added in the WordPress admin dashboard under
Distributor>External Connections. Administrators can decide which user roles are allowed to distribute content to and from that connection (Editors and Administrators by default). All users with those roles will inherit the permissions of the user account used to establish the remote connection.
Distributor is built with the same extensible approach as WordPress itself, with fully documented hooks and filters to customize its default behavior and create custom distribution workflows. You can even create connections to other platforms.
- PHP 5.6+
- WordPress 4.7+
- External connections require HTTP Basic Authentication or WordPress.com OAuth2 (must be on VIP) be set up on the remote website. For Basic Auth, we recommend the Application Passwords plugin.
- For external connections, Distributor needs to be installed on BOTH sides of the connection.
For production use, we recommend registering and downloading the plugin from DistributorPlugin.com – it's 100% free. You will be emailed a direct link to download the latest, production-ready build. Alternatively, you can download the latest release from GitHub.
You can upload and install the archived (zip) plugin via the WordPress dashboard (Plugins > Add New -> Upload Plugin) or manually inside of the wp-content/plugins directory, and activate on the Plugins dashboard.
To help inform our roadmap, keep adopters apprised of major updates and changes that could impact their websites, and solicit opportunities for beta testing and feedback, we’re asking for a little bit of information in exchange for a free key that unlocks update notifications and 1-click upgrades inside the WordPress dashboard. Your information is kept confidential. You can register here and input your key in Distributor settings in the dashboard (network dashboard for multisite users). Note that you need to input the email address you used to register Distributor (included in the email with your registration key) as that is linked to the registration key.
- Ensure Distributor is installed on BOTH sites being connected. We'll refer to these as mainsite.com and remotesite.com.
- On mainsite.com, navigate to
Distributor>External Connectionsand clickAdd New. - Enter a label for the connection (e.g.,
remotesite.com), selectUsername / Passwordfor theAuthentication Method, and a username from remotesite.com. - On remotesite.com, ensure that Application Passwords is installed. (Note: Using this plugin instead of a normal WordPress users password helps limit the use of your primary password and will allow you to revoke access to Distributor in the future if needed.) Then navigate to the user profile that will be used to create the External Connection on mainsite.com and then to the
Application Passwordssection of the user profile (not theAccount Managementsection). Add a label for the New Application Password Name (e.g.,mainsite.com) and clickAdd New. Now copy the password provided into mainsite.com's External ConnectionsPasswordfield. - On mainsite.com, add the
External Connection URL(e.g., http://remotesite.com/wp-json). You should see a green circle and "Connection established.". - Ensure the roles selected in
Roles Allowed to Pushare the ones you want to support, then press theCreate Connectionbutton. You should now be able to push from mainsite.com to remotesite.com. If you want to pull from remotesite.com to mainsite.com, simply repeat these instructions swapping mainsite.com and remotesite.com.
Active: 10up is actively working on this, and we expect to continue work for the foreseeable future including keeping tested up to the most recent version of WordPress. Bug reports, feature requests, questions, and pull requests are welcome.
Gutenberg Fullscreen Mode - Gutenberg 3.8 originally introduced Fullscreen mode for the editor and WordPress 5.4 and Gutenberg 7.7 made that the default setting. Fullscreen mode creates a problem as the admin bar is no longer visible which means the Distributor push menu is no longer visible. We are working on researching a resolution to this issue, but in the meantime we recommend clicking on the three vertical dots in the upper right corner of Gutenberg and disabling fullscreen mode to ensure the admin bar and Distributor push menu is in view.
Remote Request Timeouts - With external connections, HTTP requests are sent back and forth - creating posts, transfering images, syncing post updates, etc. In certain situations, mostly commonly when distributing posts with a large number of images (or very large file sizes), using poorly configured or saturated servers / hosts, or using plugins that add significant weight to post creation, Distributor requests can fail. Although we do some error handling, there are certain cases in which post distribution can fail silently. If distribution requests are taking a long time to load and/or failing, consider adjusting the timeout; you can filter the timeout for pushing external posts using the dt_push_post_timeout filter. More advanced handling of large content requests, and improved error handling is on the road map for a future update.
Post Meta Associations - A distributed post includes all of the post meta from the original version. Sometimes arbitrary post meta references an ID for another piece of content on the original site. Distributor does not "bring along" the referenced content or update references for arbitrary post meta (it will take care of updating references in the case of core WordPress features, such as the featured image ID). This issue is very common when using field management plugins like Advanced Custom Fields (ACF). This can be addressed on a case by case basis by extending the plugin; for external connections, you can manually handle post meta associations using the dt_push_post hook. For internal connections, use the dt_push_post hook. Note that while named the same, these hooks accept different parameters.
Deleting Distributed Posts - When a post that has been distributed is deleted, the distributed copies will become unlinked ("forked") from the original and thus become editable. Similarly, when a distributed post is unpublished, distributed copies will not be unpublished. More sophisticated "removal" workflow is on the road map for a future update.
Gutenberg Block Mismatch - When distributing a Gutenberg post to another site that supports Gutenberg, if a block in the post does not exist on the receiving site, the block will be converted to a "Classic" HTML block.
Parent Posts - Distributor does not "bring along" parent (or child posts). If your post (or custom post type) has a parent or a child, it will distribute it as if it's an orphan.
Custom Post Type Support - Internal Connections (multisite) support multiple post types. In order for distribution to work with External Connections that have custom post type content, that post type needs to be registered with the argument show_in_rest => true on the external site.
Unable to Push to New Custom Post Types - If new Custom Post Types are created after establishing an External Connection, you will only be able to Pull those from an External Connection. To ensure you are able to Push new Custom Post Types to an External Connection, you will need to update the External Connection by editing it and then clicking the Update connection button.
Backwards Compatibility - While we strive to be mindful of backwards compatibility much the same way WordPress itself is, we do not currently guarantee continued interoperability between different versions of Distributor. We assume the current userbase for this plugin has a high degree of control over any site that has been set up as an external connection and urge you to keep Distributor up to date.
Distributing Post content - By default, post content is rendered before being copied. This means that shortcodes are expanded before being distributed and remote posts will not have the shortcode, but rather the expanded HTML content.
Distributing Authors - By default, distributed stories reference the original site as the "author" with a link to it. This can be altered by extending Distributor with custom code to make it sync authors.
Distributing Post Date - By default, the "post date" on distributed stories is the date its published on the remote site, not the date published on the origin site. This can be overridden by extending Distributor with custom code to make it preserve the post date.
Distributing Canonical URL - By default, canonical URL of distributed post will point to original content, which corresponds to SEO best practices. This can be overridden by extending Distributor with custom code and removing Distributor's default front end canonical URL filtering (look for 'get_canonical_url' and 'wpseo_canonical').
Drafts as preferred Status - By default, drafts are the preferred status and can't be changed at the source site.
If you are compiling Distributor locally, note that there is a minimum requirement of Node.js 8.10. If you're using an older version of Node, then it will not compile correctly.
The plugin contains a standard test suite compatible with PHPUnit. If you want to test across multiple PHP versions, a Dockunit file is included.
You can define a constant DISTRIBUTOR_DEBUG to true to increase the ease of debugging in Distributor. This will make all remote requests blocking and expose the subscription post type.
Enabling this will also provide more debugging information in your error log for image side loading issues. The specific logging method may change in the future.
A complete listing of all notable changes to Distributor are documented in CHANGELOG.md.
Please read CODE_OF_CONDUCT.md for details on our code of conduct and CONTRIBUTING.md for details on the process for submitting pull requests to us.
