Josepha Haden, Executive Director of WordPress, published an update of WordPress’ goals in 2019. The focus for WordPress over the past year has been on nine primary projects. Of the nine projects, WordPress only managed to ship two in 2019. This means that the focus in 2020 will be much the same as the community continues building on the progress it has made toward the existing projects.
Currently, there are three planned major releases for WordPress in 2020:
- Version 5.4 – March 2020
- Version 5.5 – August 2020
- Version 5.6 – December 2020
Each of those dates are subject to change. We should also get more specific dates as each release draws near. The various projects for 2020 should land in each release.
Matt Mullenweg, co-founder of WordPress, initially laid out the 2019 plans in his 2018 State of the Word address and listed the projects on the Make Core blog. The big takeaway is that 2019 was supposed to be the year that we got closer to full-site customization (Phase 2 of the Gutenberg project). While developers have made huge strides in making that a reality, much of the project is still in its infancy.
Projects That Shipped in 2019
All existing core WordPress widgets now exist as blocks. Rather than being limited to placing widgets where the theme decides, users can now put widgets in posts, pages, or any other content area via the block editor. As the project continues to move toward full-site editing, users will eventually have the ability to place these widgets and other blocks nearly anywhere.
The site health project was merged into core. It features a screen that provides information about the site’s health to site owners. It also has a fatal-error detection script that emails site owners when plugin and theme issues are found.
Projects to Expect in 2020
Most of the remaining projects that did not quite make the cut for release in 2019 have still made progress during the year. The following is a breakdown of what projects to expect in the coming year.
Navigation Menu Block
Currently, the navigation block’s target is to ship with WordPress 5.4. This is a likely reality because it is now out of the experimental stage and is available for beta testing in Gutenberg 7.0. The development team worked on this block for several releases and now have something stable enough for user testing.
This block is a major piece of the site-customization puzzle. In the long term, users will need an easy-to-use block for handling navigation menus across their site.
Custom Block-Aware Content Areas for Themes
Phase 1 of the Gutenberg project brought the block editor to post content. A large part of Phase 2 is breaking outside of post content and allowing users to add blocks in more areas. It is unclear exactly what that will look like in the long run. Themes should be able to register additional block-aware areas.
The target release for this feature is set to WordPress 5.5, but it is too early to guess whether that is a realistic target. It is a tough issue to solve because it will need to coincide with decisions on theme block templates, saving multiple entities, and full-site customization in general. It is not a feature that can be rushed because it will have far-reaching consequences to how WordPress works for years into the future.
Widget Areas to Support Blocks
The current plan is to allow widget areas (sidebars) to support blocks alongside widgets. The Gutenberg plugin has an experimental widget areas option for enabling an early version of this feature, which has a target release of WordPress 5.5.
There are two aspects to making this feature a reality. The first is making it work on the widgets admin screen. The second is making it work in the customizer, an area where users can also manage widgets.
At the moment, it feels like the sidebar concept should be deprecated. The experimental feature works by allowing users to add blocks to a sidebar, which are converted into one big “block area” widget on output. If WordPress is “all in” on the block paradigm, energy would be better spent focusing on allowing themes to build custom block areas and letting the official Sidebar API die a slow death. Mixing an old concept with a new one feels clunky at best. It’s time to move on and soft-deprecate sidebars and widgets until most themes no longer support them.
Block Directory Search and Install
Eventually, all WordPress users will be able to search for a block via the block inserter. If the block exists, they can insert it into the block area. If not, the inserter will allow users to discover new blocks from the block directory. The installation, activation, and insertion of the new block should be seamless.
The target release for this feature is set for WordPress 5.5, which should be possible (if not earlier) based on how well the feature currently works in the Gutenberg plugin. It is not perfect yet and has broken more than a few of my posts when working with installed blocks. There are still several open issues that need to be addressed.
Plugin authors who are looking to get ahead of the game can submit block plugins by following the block plugin guidelines.
Automatic Plugin, Theme, and Major Core Updates
After years of extensive testing and using automatic updates for minor WordPress releases, it feels like we should already have auto-updates on everything at this point. Having to keep up with plugin and theme updates can be a pain for some site owners. With enough plugins, it is not out of the realm of possibility to have one or more plugins to update daily.
Some hosting solutions and Jetpack have mitigated this issue for many users by offering automatic plugin updates, but this is a long overdue core feature that should be a high priority. No target release was given for auto-updates on themes/plugins or major core releases. Let’s hope the feature does not get put on the back burner for another year.
Tackling Over 6,500 Trac Issues
With the Gutenberg plugin getting much of the attention these days, it is easy to forget that there are thousands of tickets awaiting patches, reviews, and decisions on Trac. I have long been a champion of using one major release of WordPress to simply fix existing bugs while adding no new features.
Jonathan Desrosiers has written an extensive post that covers much of the work the Triage Team has done earlier this year.
Triaging is not something that ever truly reaches a conclusion. It is an ongoing process that must continue throughout the life of a project. People who are interested in being involved with the Triage Team can find more information on the Triage Team announcement post.
What about a major release which says:
People used WordPress to have a working website and mind their own business otherwise.
Currently people have to hire devs for each and every update, because it breaks things, changes things, does not work.