Extending the 7.0 Cycle  🔗 **Source:** [Extending the 7.0 Cycle](https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/) > [!note]+ Document Notes > tags: #wordpress #collaborative-editing #real-time #core-development #http-polling #metaboxes #database-architecture > author: Matias Ventura > source: Make WordPress Core > reference: https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/ > date created: 2024-12-19 10:50 > > # 🏷️ Title: Extending the 7.0 Cycle > <!-- deep-read:sections start --> ## 🧰 Action Inbox - [H1] Test collaborative editing compatibility with existing plugins — metabox migration #collaborative-editing - [H2] Monitor HTTP polling resource usage on hosting infrastructure — performance testing #hosting - [H3] Review custom table design for real-time collaboration data storage — architecture decision #database ## 🧭 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 in Block Editor Handbook](https://developer.wordpress.org/block-editor/how-to-guides/metabox/) - [WordPress 7.0 Dev Note](https://make.wordpress.org/core/) ## 📝 Summary - WordPress 7.0 release delayed by several weeks to finalize real-time collaboration architecture - Core team choosing between postmeta/transients approach vs. custom database table for collaborative editing - Collaborative editing will launch as opt-in feature with HTTP polling for broad host compatibility - Plugin developers need to migrate from metaboxes to Gutenberg APIs for collaboration compatibility - WordPress.com successfully tested the feature with conservative polling intervals (4s/1s) ## 📖 Main Content WordPress 7.0's release timeline is being extended to properly architect real-time collaboration features. The core development team faces a critical decision between two data storage approaches: continuing with postmeta for content changes and transients for user presence, or implementing a new custom database table specifically designed for collaborative editing. The delay stems from Matt Mullenweg's preference to ensure adequate time for the best possible design from the start. While there was initial agreement on the custom table approach, concerns about cache invalidation and rapid iteration led to exploring the postmeta/transients hybrid solution. However, broader sync use cases beyond real-time editing need consideration to design the right primitives. The collaborative editing feature will launch as opt-in to allow the WordPress ecosystem time to adapt. For hosts, this represents a shift from read-heavy to write-heavy operations with rebroadcasting requirements. The HTTP polling mechanism prioritizes broad compatibility over efficiency compared to WebSockets, but WordPress.com's testing demonstrates viability with conservative defaults. Plugin compatibility presents another challenge. Many popular plugins rely on metaboxes for their UI, which are incompatible with collaborative editing's wordpress/data package synchronization. Real-time collaboration is disabled when metaboxes are present, creating pressure for plugin developers to migrate to modern Gutenberg APIs. ## 🗒️ Notes #### ⏱️ [00:00](https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/#introduction) — [H1] Release delayed for architectural decisions - Key idea: WordPress 7.0 delayed weeks to finalize real-time collaboration architecture - Evidence: "After discussions with project leadership, the decision has been made to delay the 7.0 release by a few weeks to finalize key architectural details" #### ⏱️ [02:15](https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/#collaboration-features) — [H2] HTTP polling chosen for broad compatibility - Key idea: Real-time collaboration uses HTTP polling to ensure widest possible host reach - Evidence: "Introduction of real-time collaboration primitives, which includes built-in support for HTTP polling to ensure the widest possible reach and access to this capability" #### ⏱️ [04:30](https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/#data-storage) — [H1] Custom table vs postmeta storage debate - Key idea: Core team evaluating custom database table versus postmeta/transients approach - Evidence: "Matt has expressed a preference to revisit the custom table and ensure adequate time is given to come up with the best design possible from the start" #### ⏱️ [06:45](https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/#cache-invalidation) — [H3] Cache invalidation concerns with rapid iteration - Key idea: Postmeta/transients approach addresses cache invalidation issues from frequent updates - Evidence: "This approach avoids rapid and frequent cache invalidation issues with special handling for collaborative editing meta fields" #### ⏱️ [08:00](https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/#broader-use-cases) — [H2] Sync use cases beyond real-time editing - Key idea: Architecture needs to accommodate broader synchronization scenarios beyond collaborative editing - Evidence: "Use cases beyond the real time support (like accommodating broader sync use cases) that should also be discussed to ensure we design the right primitives" #### ⏱️ [10:15](https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/#opt-in-approach) — [H1] Opt-in launch strategy for ecosystem adaptation - Key idea: Collaborative editing launches as opt-in to give WordPress ecosystem time to adapt - Evidence: "The intention in shipping collaborative editing in 7.0 as an opt-in is to give the WordPress ecosystem time to adapt to a major change" #### ⏱️ [12:30](https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/#hosting-impact) — [H2] Hosting infrastructure implications - Key idea: Feature shifts WordPress from read-heavy to write-heavy with rebroadcasting requirements - Evidence: "WordPress sites are generally very read-heavy, but collaborative features inherently involve a writing state that is then rebroadcast to other users" #### ⏱️ [14:45](https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/#http-vs-websockets) — [H3] HTTP polling trade-offs vs WebSockets - Key idea: HTTP polling sacrifices efficiency for broad compatibility compared to WebSockets - Evidence: "The HTTP polling mechanism as designed is a lowest-common-denominator approach, but its broad compatibility comes at the cost of relative inefficiency compared to more specialized solutions like WebSockets" #### ⏱️ [16:00](https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/#wpcom-testing) — [H2] WordPress.com validation with conservative defaults - Key idea: WordPress.com successfully tested with 4s/1s polling intervals and collaborator limits - Evidence: "WordPress.com has done extensive testing on this feature and has demonstrated that the conservative defaults, the limit on the number of collaborators, and the number of active editor sessions" #### ⏱️ [18:15](https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/#metabox-compatibility) — [H1] Metabox incompatibility with collaborative editing - Key idea: Plugins using metaboxes are incompatible with collaborative editing synchronization - Evidence: "Many popular plugins still rely on metaboxes for their UI... This approach, on its own, is not compatible with collaborative editing" #### ⏱️ [20:30](https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/#gutenberg-apis) — [H2] Migration path to modern Gutenberg APIs - Key idea: Plugin developers need to migrate from metaboxes to Gutenberg APIs for compatibility - Evidence: "The 7.0 cycle will be a window in which these plugin developers can implement a bridge to make their metaboxes compatible or adopt more modern Gutenberg APIs" #### ⏱️ [22:45](https://make.wordpress.org/core/2026/03/31/extending-the-7-0-cycle/#wordpress-data) — [H3] Synchronization via wordpress/data package - Key idea: Collaborative editing builds on wordpress/data package for change detection and sync - Evidence: "Collaborative editing... builds on the wordpress/data package used by the block editor to detect and sync changes across all users in a session" ## 📚 References - [Make WordPress Core](https://make.wordpress.org/core/) - [Block Editor Handbook - Meta Boxes](https://developer.wordpress.org/block-editor/how-to-guides/metabox/) - [WordPress.org Hosting](https://make.wordpress.org/hosting) ## 🗣️ Paraphrase - WordPress 7.0 is being delayed several weeks because the team wants to get the real-time collaboration architecture right from the start, particularly the decision between using existing postmeta/transients or creating a new custom database table - The collaborative editing feature will be opt-in initially to help hosting providers adapt gradually to the shift from read-heavy to write-heavy operations that come with real-time synchronization - Many existing plugins that use metaboxes will be incompatible with collaborative editing and need to migrate to modern Gutenberg APIs during the 7.0 cycle ## 📰 Newsletter WordPress 7.0 is getting some extra polish time! The core team is extending the release cycle by a few weeks to nail down the architecture for real-time collaborative editing - one of the major new features coming to WordPress. The big decision? Whether to store collaboration data in existing postmeta and transients, or build a dedicated custom database table. While both approaches have merit, taking time upfront to design the right solution will benefit everyone long-term. For site owners, collaborative editing will launch as an opt-in feature using HTTP polling - ensuring it works on virtually any hosting setup without requiring WebSockets or special server configurations. WordPress.com has already validated this approach with conservative polling intervals that maintain good performance. Plugin developers should note: if your plugin uses metaboxes, it won't be compatible with collaborative editing initially. The 7.0 cycle is the perfect time to explore migrating to modern Gutenberg APIs for better integration. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### WordPress - Core: Finalize custom table design vs postmeta/transients architecture decision - Core: Publish official dev note with collaborative editing implementation details - Core: Create call for testing on make.wordpress.org/hosting after architecture commitment - Core Performance: Profile HTTP polling resource usage and cache invalidation patterns - Documentation: Update Block Editor Handbook with metabox migration guidance - Community: Organize plugin developer workshops for Gutenberg API adoption - Hosting: Develop monitoring guidelines for sync endpoint performance - Meta: Implement sync endpoint telemetry and performance dashboards #### DevRel - Developer advocacy: Present collaborative editing architecture at WordCamps - Education: Create workshops on migrating from metaboxes to Gutenberg APIs - Developer experience: Document wordpress/data package integration patterns - Community management: Moderate discussions around architectural decisions #### Community - Plugin developers: Test collaborative editing compatibility with existing metaboxes - Hosting providers: Evaluate HTTP polling impact on server resources - Beta testers: Validate collaborative editing user experience flows ## 🧪 Hypotheses - HTTP polling with 4s/1s intervals provides acceptable user experience while maintaining server performance - Custom database table approach will perform better than postmeta/transients for collaborative editing at scale - Plugin developers will successfully migrate from metaboxes to Gutenberg APIs during 7.0 cycle - Opt-in collaborative editing will see organic adoption growth without overwhelming hosting infrastructure ### 📊 Methodology - A/B test polling intervals (4s/1s vs 1s/0.25s) measuring user satisfaction and server load - Benchmark database performance comparing custom table vs postmeta approaches under concurrent editing load - Survey plugin developers on metabox migration challenges and Gutenberg API adoption barriers ### ❓ Questions - How will collaborative editing handle complex custom post types with extensive metadata? - What fallback mechanisms exist if HTTP polling becomes overwhelmed during high-traffic periods? - How will collaborative editing integrate with WordPress multisite installations? ### 🔮 Future Research - WebSocket implementation feasibility study for hosting providers with advanced infrastructure - Real-time collaboration patterns beyond post editing (comments, customizer, etc.) - Integration opportunities with third-party collaborative platforms ### 💡 Implications - Practice: Plugin developers must prioritize Gutenberg API adoption over metabox maintenance - Policy: Hosting providers need resource monitoring policies for collaborative editing endpoints - Security: Real-time synchronization introduces new attack vectors requiring validation frameworks - Education: Developer documentation needs comprehensive metabox migration tutorials - Funding: Custom table architecture requires ongoing maintenance and optimization investment ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 12 #### 👀 Visual learners - Present: Architecture diagrams implied but not shown - Improve: Database schema comparisons, HTTP polling flow diagrams, metabox vs Gutenberg API visual guides #### 🔊 Aural learners - Present: No audio version available - Improve: Developer chat recordings, architecture decision walkthroughs #### 🗣️ Verbal learners - Present: Clear definitions of technical terms, analogies to read-heavy vs write-heavy - Improve: More analogies for polling vs WebSocket trade-offs #### 🧩 Kinesthetic learners - Present: References to testing environments and hands-on plugin development - Improve: Step-by-step migration checklists, interactive compatibility testing tools #### 🧠 Logical learners - Present: Clear decision trees, performance trade-off analysis - Improve: Quantitative polling interval comparisons, resource usage metrics #### 🧑‍🤝‍🧑 Social learners - Present: Community discussion in comments, collaborative decision-making process - Improve: Developer working groups, architecture review sessions #### 🧘‍♀️ Solitary learners - Present: Individual plugin compatibility assessment opportunities - Improve: Self-guided migration assessment worksheets #### 🌿 Naturalistic learners - Present: Ecosystem adaptation metaphors - Improve: Growth pattern analogies for feature adoption ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Proper heading structure, WordPress.org standard navigation - Improve: More descriptive link text for "dev note" and "guide" references #### Keyboard navigation - Present: Standard WordPress.org keyboard navigation - Improve: Skip links for comment navigation #### Contrast and readability - Present: Meets WordPress.org design system standards - Improve: Code snippet highlighting could use higher contrast #### Text resizing and reflow - Present: Responsive design supports text scaling - Improve: Ensure technical terms don't break awkwardly at smaller screens #### Media and captions - Present: No media requiring captions - Improve: Future architecture diagrams should include alt text #### Forms and interactions - Present: Comment forms follow WordPress standards - Improve: Real-time validation for email subscription ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global contributor acknowledgment, timezone-aware meeting times - Improve: Multi-language impact considerations for collaborative editing #### Inclusive language - Present: Technical language well-defined, avoids unnecessary jargon - Improve: More plain-language summaries of technical concepts #### Neurodiversity support - Present: Well-structured content with clear headings - Improve: Executive summary box for quick scanning #### Representation - Present: Multiple contributor perspectives in comments - Improve: Diverse hosting provider examples beyond WordPress.com #### Psychological safety - Present: Professional tone, constructive technical discussion - Improve: More explicit acknowledgment of migration challenges ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Strong logical flow from requirements to architectural decisions - Inductive strength: WordPress.com testing provides solid empirical foundation - Causal reasoning: Clear cause-effect relationships between polling intervals and server load - Analogical strength: Good analogies between read-heavy vs write-heavy operations #### Fallacies - Appeal <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Articles/Extending the 7.0 Cycle|Extending the 7.0 Cycle, make.wordpress.org]] ## Highlights - WordPress 7.0 is shaping up to be a big release, with some great highlight features and a long list of improvements. I’m excited to get this in the hands of users. Within that context, contributors have been hard at work discussing, iterating, and polishing every detail. ([View Highlight](https://read.readwise.io/read/01kn54shchmbqarcfrwm0n8h0f)) - Tags: 👻 ai highlighted