Progress on WordPress’ 2019 Projects Sets 2020 Roadmap

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

Screenshot of using the navigation block in the block editor.
Navigation block in the block editor.

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

Screenshot of the experimental widget areas feature in the Gutenberg plugin.
Experimental widget areas feature in Gutenberg.

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

Screenshot of the block directory search feature in the Gutenberg plugin.
Experimental block directory search in Gutenberg plugin.

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.


16 responses to “Progress on WordPress’ 2019 Projects Sets 2020 Roadmap”

  1. What about a major release which says:

    Version 5.whatever – Soon – Fix all those bugs

    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.

  2. All I want is to use WordPress as my platform, like a complete headless system and use my own tools for my front-end, be it Vue, React, Angular, even Express if I wanted to!

    As it is, I’m forced to depend on a theme…yeah I know I could simply use a nearly empty index.php with a style.css, but the whole thing is, I want flexibility.

    Can’t we have something like Composer packages, but for WordPress core components?

    There are so many things I don’t need and I’m forced to load them with every single click…ugh my nerves!

  3. As a full-time WordPress developer I have to say that Gutenberg et al is one of WP’s biggest blunders to date. The idea behind it is great of course, there is no doubt about that. I just think its release was very premature; WordPress being as popular as it is I would’ve thought that at least some form of intense beta testing would’ve gone into such a major feature change prior to it being even remotely ready for public release.

    What irks me the most is that user ratings seem to be ignored completely by WordPress where Gutenberg is concerned; the same can be said for folks who, somehow, expect you to be familiar with something which is fundamentally broken at this point in time. The fact that The WordPress feature release roadmap went down the toilet this year is testament to that, yet they keep pushing for its adoption instead of removing it from the repository and fixing the bugs which have been breaking sites since its release.

    Gutenberg is a novel idea, but it should be a completely optional feature instead of being forced down the throats of users and developers alike. There are plenty of other customisation plugins out there which do a waaaaay better job than Gutenberg will likely ever be able to do, with a development track record of years and years and great APIs for developers to interact with as they wish.

    My point is, instead of trying to reinvent the wheel WordPress should focus on improving that which is already there. A more advanced and feature rich Classic Editor would’ve sufficed; instead they waste time and energy on something which has been achieved years and years ago by other teams.

    In that sense Gutenberg has been a complete waste of time in my professional opinion, taking value away from WordPress as a website building platform instead of adding anything of value. Their biggest blunder was taking away people’s choice of which editor to use, and doing so right from the get go. Big mistake.

    I for one will keep avoiding Gutenberg until such a time that it actually becomes a viable tool/asset in my toolbox.

    Just my two cents. Cheers.

    • instead of removing it from the repository

      I’m afraid you’re no longer in touch with how WordPress works nowadays. Gone are the days where the users had any say in the direction WP developed. Now all decisions are taken behind closed doors, groups created to handle governance are facades, reviews are completely ignored, and handicapped people are being told to go back into the closet (indirectly, via accessibility being completely broken and unfixable in GB).

      GB will never be removed, because Matt and his investors don’t want it removed. They want a piece of the Wix / Squarespace cake – which would be fine, if they would just be honest enough to admit it. Instead Matt talks about things one would expect from a PR-agency.

      It’s sad it has gotten this way, but in the end it’s the fault of the users for accepting such behavior.

      My clients are entirely unimpressed by GB, since they’re used to the normal formatting buttons of a word processor, so I’ll continue disabling GB for as long as I can. Or, in some cases, just use a normal page builder that has a normal text editor.

      • GB is getting better and better, and the concept behind is great.
        so why i am still using the Classic Editor and scouting for alternatives (Ghost i am looking at you)?

        I think coz it’s clear I cannot trust Wp “management” anymore. it remind me the Mambo/Joomla querelle…

  4. My personal feeling is 2019 is too much for Gutenberg. I hope other issues were resolved before. Looking at from 6500 tickets from the Matt’s post and now the number is still 6500, I don’t see a big progress here. How many years does it take to get Gutenberg ready as planned? We’re getting old and web development is running too fast.

  5. Hi Justin, Thanks a lot for sharing this information. Looks like 2020 is going to be a great year for WordPress ecosystem. I am sure that the all focus and thought that has been put into Gutenberg in 2019 will show definite results in 2020. Justin thanks writing the progress and future plan of WordPress in a single post in here. Keep up the good work.

  6. Thanks for this Justin (good to see you writing for WP Tavern, if I haven’t mentioned before).

    Way back in WordPress 2.x there used to be a note on the Page admin screen, pointing out how awkward it was to reorder Pages, but that a fix would be coming. The note got removed but the awkwardness remains, unless you use a third-party drag-and-drop solution.

    It’s the “WordPress Way”. Full steam ahead, let enthusiasts and plugin developers fix the problems created along the way (see also ‘special characters’). I’d like to see a few of the 6,500 outstanding Trac items fixed as well, that’s a ridiculously high number, but I won’t be holding my breath for a major effort for version 6 (rhymes with ‘fix’).


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: