Real-Time Collaboration in the Block Editor  🔗 **Source:** [Real-Time Collaboration in the Block Editor](https://make.wordpress.org/core/2026/03/10/real-time-collaboration-in-the-block-editor/) > [!note]+ Document Notes > tags: #real-time-collaboration #gutenberg #wordpress-core #yjs #developer-tools > author: Gopal Krishnan > source: Make WordPress Core > reference: https://make.wordpress.org/core/2026/03/10/real-time-collaboration-in-the-block-editor/ > date created: 2024-12-19 20:30 > > # 🏷️ Title: Real-Time Collaboration in the Block Editor > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Migrate meta boxes to show_in_rest post meta — enables collaboration #wordpress-core - [H2] Replace useState with useSelect for shared data — prevents sync conflicts #gutenberg - [H3] Implement WebSocket provider for lower-latency collaboration — custom transport #real-time-collaboration ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [Meta Boxes Guide](https://developer.wordpress.org/block-editor/how-to-guides/metabox/) - [WordPress Data API](https://developer.wordpress.org/block-editor/reference-guides/data/) ## 📝 Summary - WordPress 7.0 introduces real-time collaboration using Yjs for simultaneous editing - Collaboration is automatically disabled when classic meta boxes are present to prevent data loss - Developers can customize sync transport via the sync.providers filter (HTTP polling to WebSockets) - Plugin compatibility requires using WordPress data stores and avoiding local React state for shared data - Feature is opt-in via Settings > Writing but may cause connection issues in some environments ## 📖 Main Content WordPress 7.0 introduces real-time collaboration in the block editor, allowing multiple users to edit content simultaneously using the Yjs library. This represents a significant shift in how WordPress handles concurrent editing, moving from post locking to true collaborative editing. The system automatically disables collaboration when classic meta boxes are detected, as these cannot be synced through the real-time system. This creates a compatibility challenge for plugins relying on traditional meta box implementations. The collaboration system uses a provider-based architecture with HTTP polling as the default transport mechanism. Developers can replace this with custom providers like WebSockets through the sync.providers filter for improved performance. Plugin developers must adapt their code patterns to work with collaborative editing, particularly around data synchronization and state management. The key requirement is using WordPress data stores rather than local component state for any shared data. ## 🗒️ Notes #### WordPress Core Architecture Changes - Key idea: Real-time collaboration uses Yjs library for operational transforms - Evidence: "Real-time collaboration (RTC) in the block editor allows multiple users to edit content simultaneously by utilizing Yjs" #### Meta Box Compatibility Limitation - Key idea: Classic meta boxes automatically disable collaboration to prevent data loss - Evidence: "Classic WordPress meta boxes are not synced by the real-time collaboration system. To avoid data loss, collaboration is disabled when meta boxes are detected" #### Migration Path for Meta Boxes - Key idea: Developers should migrate to show_in_rest post meta with sidebar plugins - Evidence: "consider migrating meta box functionality to registered post meta with show_in_rest set to true, and use sidebar plugins or block-based alternatives" #### Extensible Transport Layer - Key idea: sync.providers filter allows custom transport mechanisms beyond HTTP polling - Evidence: "The sync.providers filter allows plugins to replace or extend the transport layer. For example, a plugin could switch from HTTP polling to WebSockets" #### Data Store Synchronization Requirements - Key idea: Plugin UIs must consume from WordPress data stores, not local state - Evidence: "custom meta field UI must be consumed from the WordPress data store and passed to controlled input components" #### React State Management Anti-Pattern - Key idea: Local useState disconnects components from collaborative state updates - Evidence: "avoid copying that data into local React state with useState. This applies to any shared data, such as post meta or block attributes" #### Block Side Effects Consideration - Key idea: Block insertion side effects trigger for all connected collaborators - Evidence: "Custom blocks that trigger side effects on insertion will trigger that side effect for all connected collaborators, since block content syncs immediately" #### WebSocket Provider Implementation - Key idea: Custom providers need destroy and on methods for connection management - Evidence: "returns a ProviderCreatorResult with destroy and on methods. The destroy method is called when the provider is no longer needed" ## 📚 References - [Make WordPress Core](https://make.wordpress.org/core/2026/03/10/real-time-collaboration-in-the-block-editor/) - [Block Editor Handbook](https://developer.wordpress.org/block-editor/) - [Yjs Library](https://github.com/yjs/yjs) ## 🗣️ Paraphrase - WordPress 7.0 adds Google Docs-style collaborative editing to the block editor using advanced conflict resolution technology - Old-style meta boxes break the collaboration feature, so developers need to modernize their plugin interfaces - The system is flexible enough that developers can swap out the networking layer for faster connections like WebSockets ## 📰 Newsletter WordPress 7.0 brings real-time collaboration to the block editor! Multiple users can now edit posts simultaneously, just like Google Docs. However, this requires some plugin updates. If your plugins use classic meta boxes, collaboration will be automatically disabled. The solution is migrating to modern post meta with `show_in_rest => true` and using sidebar plugins instead. For advanced developers, the new `sync.providers` filter lets you replace HTTP polling with WebSockets for faster collaboration. Remember to use WordPress data stores instead of local React state to keep everything in sync. This is a major step forward for WordPress as a collaborative platform, especially for teams and multi-author sites. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### WordPress - Core: Update meta box detection to provide migration guidance warnings - Core: Document provider architecture patterns and WebSocket server requirements - Core: Add collaboration status indicators and connection recovery UX - Documentation: Create migration guides from meta boxes to show_in_rest patterns - Documentation: Provide WebSocket provider implementation examples and best practices - Training: Develop collaborative editing workshops for plugin developers - Community: Host collaboration-focused contributor days and plugin compatibility sprints #### DevRel - Developer advocacy: Present collaboration patterns at WordCamps and developer meetups - Education: Create video tutorials on migrating plugins for collaboration compatibility - Developer experience: Improve error messages when collaboration is disabled by meta boxes - Developer marketing: Highlight collaboration as competitive advantage for WordPress - Community management: Moderate collaboration feature feedback and compatibility reports ## 🧪 Hypotheses - Plugins using show_in_rest post meta will have seamless collaboration support without additional code changes - WebSocket providers will show measurably lower latency and better user experience than HTTP polling in multi-user scenarios - Sites with collaboration enabled will see increased user engagement and content creation velocity - Meta box detection will drive accelerated adoption of modern WordPress data patterns ### 📊 Methodology - A/B testing collaboration vs traditional editing for content team productivity metrics - Performance benchmarking HTTP polling vs WebSocket providers across network conditions - Plugin compatibility audits measuring collaboration support adoption rates ### ❓ Questions - How will collaboration handle plugins that modify post content through server-side filters during save? - What happens to collaboration state when users have different plugin versions or capabilities? - Can the provider architecture support hybrid approaches mixing local and cloud synchronization? ### 🔮 Future Research - Integration patterns with headless WordPress and external editing interfaces - Collaborative editing for custom post types and non-post content like theme customization - Conflict resolution strategies for plugins that programmatically modify content ### 💡 Implications - Practice: Plugin developers must audit meta box usage and plan migration timelines - Policy: Sites need collaboration guidelines and user permission structures - Security: Real-time sync introduces new attack vectors requiring transport encryption and access validation - Education: Developer training must cover data store patterns and collaborative state management - Funding: Plugin compatibility work may require dedicated development resources and testing infrastructure ### 🧠 Learning Styles Assessment Reading level estimate: 12th grade (technical documentation) #### 👀 Visual learners - Present: Code examples with syntax highlighting, provider architecture diagrams - Improve: Collaboration flow diagrams, before/after migration screenshots #### 🔊 Aural learners - Present: No audio content currently available - Improve: Narrated code walkthroughs, collaborative editing demo videos #### 🗣️ Verbal learners - Present: Clear technical definitions, step-by-step migration instructions - Improve: Analogies comparing collaboration to familiar tools like Google Docs #### 🧩 Kinesthetic learners - Present: Code examples for immediate implementation and testing - Improve: Interactive demos, plugin migration checklists, testing environments #### 🧠 Logical learners - Present: Clear cause-and-effect relationships between meta boxes and collaboration - Improve: Decision trees for migration approaches, compatibility matrices #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion in comments section - Improve: Collaboration working groups, peer code review processes #### 🧘‍♀️ Solitary learners - Present: Self-contained documentation with complete examples - Improve: Migration assessment worksheets, solo testing procedures #### 🌿 Naturalistic learners - Present: Limited environmental connections - Improve: Collaboration as ecosystem thinking, sustainability of development patterns ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Proper heading hierarchy, code blocks with language labels - Improve: More descriptive link text beyond "here" references #### Keyboard navigation - Present: Standard WordPress.org navigation structure - Improve: Skip links for long code examples, improved focus management #### Contrast and readability - Present: Meets basic contrast requirements for body text - Improve: Ensure code syntax highlighting maintains sufficient contrast ratios #### Text resizing and reflow - Present: Responsive design supports text scaling - Improve: Prevent horizontal scrolling in code blocks at high zoom levels #### Media and captions - Present: No media content requiring captions - Improve: Add video demonstrations with full transcripts #### Forms and interactions - Present: Basic comment form with labels - Improve: Inline validation for developer feedback submissions ### 🌍 DEIB Assessment #### Cultural breadth - Present: Technical content accessible to global developer community - Improve: Multi-language code comments, international collaboration examples #### Inclusive language - Present: Gender-neutral technical writing, defined technical jargon - Improve: Avoid developer assumptions about team structures and workflows #### Neurodiversity support - Present: Logical content structure with clear headings - Improve: Summary bullets for each major section, consistent code formatting #### Representation - Present: Neutral technical focus without exclusionary examples - Improve: Diverse contributor acknowledgments, varied use case scenarios #### Psychological safety - Present: Constructive technical guidance without blame for legacy patterns - Improve: Emphasize migration support rather than deprecation pressure ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Clear connection between meta box limitations and collaboration disabling - Inductive strength: Well-supported examples of migration patterns from specific cases - Causal reasoning: Strong explanation of how local state breaks collaborative synchronization - Analogical strength: Effective comparison to familiar collaborative tools #### Fallacies - Appeal to novelty: Implicit assumption that newer patterns are always better without cost-benefit analysis - False dichotomy: Presents migration as only solution without exploring meta box compatibility layers #### Tone of voice - Overall tone: Authoritative technical guidance with supportive migration assistance ### 🛡️ DARVO Analysis - Deny: No denial patterns detected - Attack: No attacks on critics or alternative approaches - Reverse victim/offender: No victim/offender dynamics present - Emotional cues and rhetoric: Constructive technical communication without manipulation ## 🎯 Conclusion Real-time collaboration in WordPress 7.0 represents a major architectural advancement, bringing Google Docs-style editing to WordPress. However, successful adoption requires plugin developers to modernize from meta boxes to REST API patterns and embrace WordPress data stores for state management. The extensible provider system offers opportunities for performance optimization through custom transport layers. This feature will likely accelerate the broader modernization of the WordPress plugin ecosystem while enabling new collaborative workflows for content teams. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad Purpose: Stage CEE units that become Literature notes. Split level: H3 ### [H1] Meta boxes disable real-time collaboration automatically > [!quote] [Real-Time Collaboration in the Block Editor](https://make.wordpress.org/core/2026/03/10/real-time-collaboration-in-the-block-editor/) by [[Gopal Krishnan]] via [[Make WordPress Core]]. Published 2026-03-10. Accessed 2024-12-19. > "To avoid data loss, collaboration is disabled when meta boxes are detected on a post." Critical compatibility constraint requiring plugin architecture changes for collaboration support. [view highlight](https://make.wordpress.org/core/2026/03/10/real-time-collaboration-in-the-block-editor/#H1) #xref #articleseed ID:rw_wp_collab_meta ### [H2] WordPress data stores required for collaborative state > [!quote] [Real-Time Collaboration in the Block Editor](https://make.wordpress.org/core/2026/03/10/real-time-collaboration-in-the-block-editor/) > "Always derive the input value directly from the WordPress data store via useSelect." Essential pattern for maintaining synchronized state across collaborative sessions. [view highlight](https://make.wordpress.org/core/2026/03/10/real-time-collaboration-in-the-block-editor/#H2) #xref ID:rw_wp_data_sync --- ### 🔖 Atomic Split Pad (Zettel Candidates) Purpose: Promote reusable claims into Atomic notes. Split level: H4 #### [Z1] Yjs enables operational transform collaboration - Applies to real-time document editing systems - Reference: WordPress 7.0 implementation - Links: [[Operational-Transforms]] [[CRDT-Algorithms]] #### [Z2] Local React state breaks collaborative synchronization - Applies to any shared editing interface - Reference: WordPress data store requirements - Links: [[React-State-Management]] [[Collaborative-Patterns]] --- ### ✏️ Fleeting Queue Purpose: Capture quick actions for Fleeting notes. - [F1] Test WebSocket provider performance vs HTTP polling — collaboration latency comparison #fleeting #inbox - [F2] Audit existing plugins for meta box usage — collaboration readiness assessment #fleeting #inbox - [F3] Document provider architecture for custom transport — developer implementation guide #fleeting #inbox <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Articles/Real-Time Collaboration in the Block Editor|Real-Time Collaboration in the Block Editor, make.wordpress.org]] ## Highlights - The `@wordpress/sync` package uses a [provider-based architecture](https://docs.yjs.dev/ecosystem/connection-provider) for syncing collaborative editing data. By default, WordPress ships with an HTTP polling provider. The `sync.providers` filter allows plugins to replace or extend the transport layer. For example, a plugin could switch from HTTP polling to WebSockets for lower-latency collaboration. ([View Highlight](https://read.readwise.io/read/01kkvghwpb9j2ev9cbgwma80h2)) - Tags: 👻 ai highlighted