A very interesting post from Gary Pendergast on his vision for the future of WordPress and Gutenberg.
WordPress has been around for 15 years. 31.5% of sites use it, and that figure continues to climb. We’re here for the long term, so we need to plan for the long term. Gutenberg is being built as the base for the next 15 years of WordPress. The first phase, replacing the post editing screen with the new block editor, is getting close to completion. That’s not to say the block editor will stop iterating and improving with WordPress 5.0, rather, this is where we feel confident that we’ve created a foundation that we can build everything else upon.
Let’s chat about the long-term vision and benefit of the Gutenberg project.
As the WordPress community, we have an extraordinary opportunity to shape the future of web development. By drawing on the past experiences of WordPress, the boundless variety and creativity found in the WordPress ecosystem, and modern practices that we can adopt from many different places in the wider software world, we can create a future defined by its simplicity, its user friendliness, and its diversity.
If we’re looking to create this future, what are the key ingredients?
Interface unity. Today, the two primary methods of embedding structured
Gary Pendergast, one of the 5.0 release leads, shares some thoughts on merge proposals. "Creating a framework for more fluid feedback over the entire lifecycle of a feature project is beneficial for everyone."
Developing new WordPress features as plugins has been a wonderfully valuable process for all sorts of features to come into being, from the MP6 Dashboard Redesign, to oEmbed endpoints, and including multiple Customiser enhancements over the years. Thanks to the flexibility that this model offers, folks have been able to iterate rapidly on a wide range of features, touching just about every part of WordPress. The “Features as Plugins” idea was first introduced during the WordPress 3.7 development cycle, during which the features were merged after a short discussion during a core chat: it was only in the WordPress 3.8 cycle that the idea of a merge proposal post (called “Present Your Feature” back then) came into being. It was envisioned as a way to consult with WordPress leaders, key contributors, and the wider WordPress community on the readiness of this feature to be released. Ultimately, WordPress leaders would make a decision on whether the feature was right for WordPress, and the release lead would decide if it was ready for that release.
Since then, most feature plugins have published some form of merge proposal post before they were ultimately merged into
Talks by Gary Pendergast in WordCamp US, 2015 about the Trojan Emoji security bug, and how the team struggled to fix it for every WordPress site.
A WordCamp US this year, I spoke about the Trojan Emoji security bug, which we fixed in WordPress 4.1.2. In particular, I went through how we came to wrap our head around the bug, and then write a solution that worked for every WordPress site.