Real-time collaboration is coming to WordPress 7.0, enabling users to edit content together within the block editor. But what happens when the default HTTP polling provider doesn’t meet your needs? For hosting providers or high-performance sites, creating a custom sync provider might be the answer. Here’s what you need to know about building one and why it matters.
Key Takeaways
- WordPress 7.0 introduces real-time collaboration in the block editor with HTTP polling as the default sync transport.
- The new sync.providers filter lets developers replace the default transport with custom solutions, such as WebSockets.
- Custom providers can reduce latency, lower server load, and align better with existing infrastructure.
- Existing Yjs providers like y-websocket can streamline development, but authorization is critical for security.
- Building a custom provider requires substantial coding and server setup expertise.
Why Build a Custom Sync Provider?
The default HTTP polling provider in WordPress works reliably on any installation, batching updates into periodic HTTP requests. However, it isn’t always the optimal choice for high-performance or collaborative editing environments. Here’s why you might want to replace it:
- Lower latency: Polling waits for intervals to send updates, while transports like WebSockets deliver changes instantly.
- Reduced server load: Polling continues to generate HTTP requests even when no updates occur, whereas a push-based transport sends data only when necessary.
- Infrastructure alignment: If your organization already uses WebSocket servers or other real-time transports, leveraging them can simplify operations.
These advantages come with trade-offs. Developing a custom provider means writing code, deploying servers, and maintaining infrastructure—all tasks requiring significant expertise.
How Sync Providers Work
WordPress real-time collaboration is powered by Gutenberg and Yjs, a robust library for Conflict-free Replicated Data Types (CRDTs). Yjs represents WordPress editor content as documents, which are synchronized by exchanging updates through a transport layer—the sync provider.
A sync provider must handle three core responsibilities:
- Send local document updates to remote peers.
- Receive remote updates and apply them locally.
- Report connection status to the editor UI (e.g., connected, disconnected, or error).
Gutenberg’s sync manager orchestrates this process by creating a sync provider for each document. To replace the default provider, developers supply a custom provider creator function, an asynchronous function that integrates with Yjs and the sync manager.
Using Existing Yjs Providers
You don’t have to start from scratch when building a sync provider. Yjs offers several prebuilt providers, such as y-websocket and y-webrtc. The most commonly used, y-websocket, includes both a client library and a Node.js server component, simplifying deployment.
For example, integrating y-websocket into WordPress might look like this:
import { addFilter } from '@wordpress/hooks';
import { WebsocketProvider } from 'y-websocket';
addFilter('sync.providers', 'my-plugin/websocket', () => {
return [async ({ objectType, objectId, ydoc, awareness }) => {
const roomName = `${objectType}-${objectId ?? 'collection'}`;
const provider = new WebsocketProvider('wss://my-sync-server.example.com', roomName, ydoc, { awareness });
return {
destroy: () => provider.destroy(),
on: (event, callback) => provider.on(event, callback),
};
}];
});While this example demonstrates basic functionality, it omits security measures like user authorization, a critical requirement for production use.
Authorization and Security
Custom sync providers connect WordPress to external infrastructure, such as WebSocket servers. Because these servers live outside WordPress, authorization is your responsibility. Without it, your server may accept unauthorized connections or expose sensitive data.
Recommended security practices include:
- Using token-based authentication to verify users.
- Encrypting WebSocket connections with TLS.
- Implementing server-side session management to prevent hijacking.
Warning: A poorly secured sync provider can lead to data breaches or service abuse. Always implement robust authentication and encryption.
What This Means for WordPress Users
The introduction of real-time collaboration in WordPress is a milestone, but the default sync provider may not suit every use case. Hosting providers and developers managing high-traffic or collaborative sites should consider whether custom transports like WebSockets offer meaningful performance gains.
For most WordPress sites, the default HTTP polling will suffice. However, if your infrastructure already supports real-time transports or you need ultra-low-latency collaboration, the sync.providers filter makes customization achievable. Be prepared for the technical demands of coding a provider and deploying supporting servers.
This feature also signals WordPress’s growing emphasis on modern editing workflows. Real-time collaboration aligns with trends in cloud-based productivity tools, positioning WordPress as competitive in collaborative environments.
Frequently Asked Questions
What is a sync provider in WordPress?
A sync provider is the transport layer responsible for exchanging Yjs document updates between collaborators in real-time. It ensures content changes are synchronized across peers.
Why use a custom sync provider?
A custom sync provider can reduce latency, minimize server load, and better align with your existing infrastructure, especially if you use WebSockets or similar technologies.
What are the risks of building a custom provider?
Custom providers require significant coding and server setup expertise. Security risks such as unauthorized access or data breaches must be addressed with robust authorization and encryption.
What is y-websocket?
y-websocket is a Yjs provider that facilitates real-time syncing via WebSockets. It includes a client library and a Node.js server for deployment.
