Multi-server syndication. No broken links. No crashed servers.
EditorialPack Network is built for media groups that run independent WordPress sites on separate servers. Your newsroom writes a story once in a central hub. Every targeted site receives it, re-hosts its media and repairs its internal links — without an editor waiting on a spinner, and without a single 404.
Production-validated. Proven on high-frequency, multi-site regional publisher networks in live production environments.
What is EditorialPack Network?
EditorialPack Network is an event-driven WordPress content syndication plugin for independent sites on separate servers. A central hub site records every publish, update and delete in an ordered, append-only event log. Each node site pulls those events from its own cursor, re-hosts the media in its own library, and translates internal links so they resolve on its own domain.
- What it is for Media groups and multi-title publishers that write a story once and distribute it to many WordPress sites.
- Where it runs Standalone WordPress installs on different servers and hosts. It does not require WordPress Multisite.
- How it moves content The hub pings, the node pulls. The hub never pushes content to a remote site.
- What makes it different Per-node internal link translation with a 3-step fallback, so syndicated posts never produce cross-domain 404s.
- How it handles outages A node that goes offline resumes from its cursor and replays every missed event in order.
- What it needs HTTPS, WordPress Application Passwords, and the
/wp-json/wp/v2/and/wp-json/editorialpack/REST namespaces.
Why traditional syndication breaks
Most cross-server post duplication tools work the same way. When an editor clicks Publish, the origin site opens a connection to every destination and pushes the full post, one site after another, inside that editor's request. That holds for two sites on a quiet day. Under newsroom load it fails in three predictable ways.
Bulk actions hit the execution limit
Re-categorise 200 stories across 5 sites and the origin must complete 1,000 remote writes inside one PHP request. max_execution_time expires partway through. Some sites have the change, some do not, and nothing records which.
One slow site blocks the network
Synchronous push makes your fastest server wait for your slowest. If a destination is mid-deploy, rate-limited or down, the push fails — and a failed push is simply gone. The site returns an hour later missing every story published while it was away.
Links leak traffic or die
Copy hub HTML verbatim to a sister site and every internal link either sends the reader to another domain or points at a URL that does not exist there. The first bleeds sessions and link equity. The second is a 404 in front of a reader and a crawler.
These are not bugs in any one plugin. They are consequences of the push model. Fixing them takes a different architecture.
Core architecture: the hub pings, the node pulls
EditorialPack Network inverts the flow. The hub never pushes content. It records what happened and tells nodes that something is waiting. Each node then collects the work itself.
The hub appends an event
Every publish, update, unpublish, delete, taxonomy edit and media change is written to an ordered, append-only event log on the hub. It is a local database write: milliseconds, and the same cost for 2 nodes or 50.
The hub sends a ping
Each targeted node receives a small signed notification: new events are available. The ping carries no content. If it is lost, nothing is lost with it.
The node pulls from its cursor
Each node keeps a cursor — the last event it applied. It asks the hub for everything after it, in batches sized to its own limits, then re-hosts media, resolves links and advances the cursor.
A fault-tolerant event queue, inside WordPress
If this sounds like Kafka, that is deliberate. The hub is a durable log. Nodes are consumers with independent offsets. That one decision produces the behaviour enterprise networks need.
- A node goes down. Its cursor stops moving. The hub keeps appending events and is unaffected.
- The node comes back. It replays everything it missed, in order. No manual re-sync, no lost stories.
- A node is slow. It falls behind and catches up. Every other node is unaffected.
- An event fails to apply. The cursor does not advance past it. The failure is retried and visible, never swallowed.
- Replays are safe. Events are idempotent. Applying one twice yields the same post, not a duplicate.
- Publish returns immediately. Media, links and database writes run on the node, in the background.
The enterprise superpowers
What the event model buys a multi-title publisher in production.
No remote writes in the editor's request
Publishing is a local event write and one small ping per node. The heavy work — media, links, database writes — runs on the nodes, in batches they size themselves.
Zero cross-domain 404s
Every internal link resolves per node: own local copy, then sister site, then safe plain text. How it works →
Links that repair themselves
When a link target arrives days later, the node upgrades the link — without touching post_modified, so feeds and sitemaps stay truthful.
Traffic stays on the local brand
A story on a node links to that node's copy of related coverage. Sessions and link equity stay with the title that earned them.
Media re-hosted, not hot-linked
Images land in each node's own media library and block references are rewritten to local IDs. Nodes serve from their own domain and CDN.
Local editorial control
A node can override headline, image or byline for its audience. Hub updates keep flowing; local overrides are preserved.
Signed, authenticated delivery
Pings and pulls are authenticated end to end over HTTPS. A node only applies content that verifiably came from its hub.
Full delivery observability
Cursor position per node, delivery history per story, and a health view of what synced, where, and what failed.
Frequently asked questions
How is this different from WordPress Multisite?
Multisite requires one installation, one database and one server stack. EditorialPack Network is a multisite alternative for independent servers: each title is a standalone WordPress install that can sit on a different host, in a different data centre, under a different ops team. Sites share content, not infrastructure — so one site's outage does not become every site's.
How is it different from REST API push plugins?
A push plugin sends the full post from the origin to each destination over the REST API when an editor acts, inside that editor's request. EditorialPack Network inverts the flow: the hub appends an event to its own log and sends a small ping, and each node pulls from its cursor in the background. That is what allows a node to catch up after an outage, and what lets each node translate internal links for its own domain instead of receiving them verbatim.
What is a good alternative to Distributor by 10up for standalone servers?
Distributor, by 10up, is a free, open-source plugin for sharing posts between sites in a Multisite network or between separate WordPress sites over the REST API; an editor pushes or pulls a post and the copy stays linked to its original. EditorialPack Network is an alternative built on a different architecture for publisher networks on independent servers: an ordered event log with per-node cursors, automatic catch-up after a node outage, media re-hosted into each node's library, and per-node internal link translation with a fallback to plain text. If your network needs unattended, always-on syndication with links that resolve locally on every title, evaluate EditorialPack Network; if editors hand-pick occasional posts to share, Distributor may be all you need.
What happens when a node is offline during a publish?
Nothing is lost. The event stays in the hub's log. When the node returns it pulls from its cursor and applies every missed event in order.
How does it handle bulk edits and large migrations?
The hub never writes to remote sites inside a request: it appends events to its own log and sends one ping per node, and the nodes do the remote work in background batches. It is optimized for routine daily publishing. A manual bulk operation still runs over a single PHP thread on the hub, so keep those under roughly 50–100 historical posts and run mass migrations as batched CLI scripts. See the scale note.
Do syndicated stories link back to the hub domain?
Not unless you want them to. Internal links are resolved per node: first to the node's own copy, then to a sister site that carries the target, and otherwise converted to plain text. See Features.
Can a node edit a syndicated story?
Yes. Nodes can localise the headline, image and byline. The story remains linked to its source and continues to receive hub updates.
Does the hub need to reach every node at all times?
No. The ping is an optimisation, not a dependency. Nodes also pull on their own schedule, so a missed ping delays delivery by one polling interval at most.
What are the server requirements?
HTTPS on every site, WordPress Application Passwords, and open REST namespaces at /wp-json/wp/v2/ and /wp-json/editorialpack/. Full details are in the system requirements.
How do we evaluate it?
Email hello@editorialpack.io. We will walk your architects through the event model and scope a pilot on a staging hub and node.
Planning a multi-title network?
Send us your topology — how many titles, which stories go where. We will map the event flow and the link matrix with your architects.