Core Committers Convene at WordCamp Europe 2026: Key Discussions and Future Directions

Core Committers Meet at WordCamp Europe 2026: A Deep Dive Into WordPress Development Challenges

On June 5, 2026, WordPress Core committers gathered informally during WordCamp Europe in Kraków, Poland, to engage in candid discussions about ongoing challenges and future directions for WordPress Core development.

What Happened

During their informal meeting under Chatham House Rule, WordPress Core committers discussed several key topics:

• Reducing Friction Between Code Bases: The recent changes in build scripts for wordpress-develop and the Gutenberg plugin aimed to streamline syncing changes from GitHub to SVN. While initial disruptions have been addressed, issues like svn:ignore properties being out of sync with .gitignore remain unresolved (#64971). The syncing process is still manual, requiring human review. The new build script concepts involving pages and routes are novel and still revealing edge cases.
• Improving Communication: Committers agreed on the need for maintainers to communicate more consistently and proactively about ongoing explorations and planned changes. Early announcements can prevent workflow disruptions, clarify expectations, and improve feedback quality. The communication channels discussed include RFCs, Trac updates, and weekly Dev Chats.
• Canary-style Development Proposal: A suggestion to adopt a Canary-style approach similar to Chrome was debated. Such a shift would require rethinking commit processes, issue tracking, and communication strategies. Questions remain about the relationship between Core, Gutenberg, and Canary builds, feature locations, and backward compatibility.
• More Testing More Often: The group acknowledged that insufficient beta testing and feedback delay feature stabilization. The Beta Tester plugin has limited adoption (~3,000 active installs), and the usage of Gutenberg experiments is unclear. The idea of integrating the Beta Tester plugin into Core was broadly supported to increase exposure and engagement.
• Rollback Challenges: Concerns were raised about the inability to revert database migrations, complicating beta testing and experimental feature rollbacks.

Why This Matters

These discussions underscore persistent structural and operational challenges in WordPress Core development that directly affect the ecosystem’s velocity and stability.

Synchronizing Multiple Code Bases is inherently complex because wordpress-develop and Gutenberg serve different roles: the former is the canonical stable Core repository, while the latter is a plugin testing ground for new features. The manual syncing process introduces risks of inconsistencies that can cascade into release delays or regressions. Automation here is not just convenience but a necessity for scaling development without increasing overhead.

Communication Gaps have operational costs. In production WordPress environments, unexpected Core or plugin changes can break client sites or disrupt agency workflows. Early and clear communication helps contributors plan and test effectively, preventing costly surprises. The proposed cultural shift toward over-communication aligns with practices seen in high-velocity open source projects.

The Canary-style Development Proposal represents a significant paradigm shift. Chrome’s Canary channel allows rapid iteration and user feedback but requires a robust infrastructure for feature flagging, crash telemetry, and user segmentation. For WordPress, the challenge lies in balancing stability for millions of sites with the desire for faster innovation. This approach could accelerate feature delivery but risks fragmenting the ecosystem if not managed carefully.

Testing and Feedback remain the Achilles’ heel of WordPress Core releases. Low adoption of beta testing tools limits exposure to real-world conditions and edge cases. Integrating beta testing capabilities into Core could lower the barrier for participation, but this entails careful UX design to avoid confusing users or causing accidental site instability. Additionally, without reliable rollback mechanisms, users may hesitate to enable experimental features.

Database Migration Rollbacks are a technical limitation that affects the feasibility of safe beta testing and feature experimentation. Since database schema changes are often irreversible, any failed feature can leave a site in a broken state. Addressing this requires architectural innovations or new tooling to sandbox migrations or allow safer rollbacks.

What This Means for WordPress Users

For agencies and developers managing multiple client sites, these discussions highlight the importance of monitoring Core and Gutenberg updates closely and participating in testing cycles when possible. The current manual syncing and limited beta testing uptake mean that regressions can still slip through. Proactively testing pre-release versions on staging environments remains best practice.

Hosting providers and managed WordPress hosts should consider how beta and experimental feature adoption impacts their update strategies. WordPress.com’s use of the Gutenberg plugin as a staging ground for features is unique and may not align with typical managed hosting environments. Hosts may want to explore Canary-style approaches cautiously, balancing innovation with reliability.

Site operators should be aware that while new features can improve site capabilities, enabling experimental options carries risks without robust rollback options. Waiting for stable releases remains prudent unless you have dedicated staging and backup processes.

Plugin and theme developers must stay informed about the evolving build and deployment workflows. Differences in how dependencies are handled, such as the discontinuation of pinning npm packages, affect build reproducibility and compatibility. Active engagement in communication channels can help anticipate breaking changes.