WordPress 5.9 Proposed Scope: Major Push Towards Full-Site Editing, Plus a New Default Theme
WordPress 5.9 is starting to take shape as Josepha Haden Chomphosy published a planning roundup at the end of last week with a tentative schedule and scope. This will be the last major release of the year, which Haden Chomphosy said will require “a slightly larger release squad,” considering the proposed scope.
The squad leads have not yet been named with the exception of Matt Mullenweg as release lead, Haden Chomphosy as marketing lead, and Jonathan Bossenger who was invited to be a technical writer as part of a small experiment in the 5.9 release cycle. Bossenger said this new role was created “to get the technical details of new releases translated into accessible and actionable information for other contributor teams.” The rest of the team will be named as features are confirmed to land in the release.
“The main goal for 2021 is getting full site editing to all WordPress users,” Haden Chomphosy said as a preface to the scope of work outlined for 5.9. These include the following block and site editing features that Matias Ventura previously identified as already underway in Gutenberg:
- Blocks + intrinsic web design
- Navigation menus
- Interface for theme.json
- Refining editing flows for block themes
- New default theme
- Additional design tools
A few other items are being considered for the roadmap but may not be ready in time. These include:
- Pattern insertion + creation
- Unzip/Rollback Failsafes
- PHPUnit Tests
- Improved compatibility with PHP 8.0 and 8.1
The proposed timeline puts the go/no go date for features at October 12, with Beta 1 arriving November 16, and the general release on December 14.
While this timeline seems ambitious for the proposed features, work on many of these efforts has already been happening for months via the Gutenberg plugin. The continual work happening alongside core in the plugin has many advantages but also introduces some complexity into the release process.
One common complaint logged on the 5.8 retrospective was that backporting PHP changes from the Gutenberg plugin to WordPress core was a significant pain point for contributors.
“The current structure of the Gutenberg plugin makes it really hard to locate the changes necessary to bring to WordPress core together with related JavaScript logic,” Greg Ziółkowski said. “Before anything else, we should make it more transparent in the plugin what’s already in WordPress core, what’s ready to be backported, and what’s still an experiment.” Ziółkowski has opened a ticket to discuss how contributors can make backporting a more semi-automated process.
Meanwhile 5.8.1 RC 1 is on deck with 41 bug fixes for core and 20 bug fixes for the block editor. The minor release is expected to land this week.
10 Comments
·
For all rich features of block design WordPress begins to lose the beauty of simplicity.
Report
·
Rather than build out the CMS functionality of the application, we keep going down this gutenberg path. While its a beautiful system, and I applaud all the work on gutenberg, it should have always been a plugin.
The very first thing we do is turn off gutenberg every time, opting instead for robust custom post type/taxonomies/fields in an effort to build a content management flow that does the opposite of what the gutenberg editor does – allow content managers to do their work without having to make a single design decision.
We use WordPress for robust enterprise sites, we could never, ever deliver a gutenberg powered site. All our hard work would be trashed within weeks.
Less is always more, guys.
Report
·
Be careful about saying “never” when it comes to software development. We also build enterprise sites, and we decided to give Gutenberg a try a couple years ago.
I completely get the idea that you don’t want content authors screwing around with all the various design options that Gutenberg blocks provide. That’s why we disable all the blocks we don’t want authors using. We even built a plugin that allows us to toggle blocks on and off. Sometimes, we create our own, more limited blocks, or in some cases, the default blocks provide a few options we don’t like, such as the paragraph block allowing you to set text and background color. However, those options can be easily disabled. It may seem like a lot of work setting up Gutenberg in this way, but once you’ve done it once, you have a framework on which to build all your future sites.
So, you may be wondering, “if I’m just going to disable most of Gutenberg (and maybe rely on just the classic editor block), why should I waste time configuring it?” And the answer is that Gutenberg provides a lot of useful features beyond just giving a ton of design control to authors.
We still make use of custom post types, taxonomies, and meta boxes where appropriate, but we also create blocks when they are a better fit for the content. For example, without Gutenberg blocks, a simple image carousel usually requires a separate plugin, and it has its own UI and pages for managing it. Then, the authors have to remember shortcodes to inject the carousels into the editor. It’s a much better user experience to add a carousel block to the page, edit it in place, and see live feedback on the changes.
Block patterns are also incredible! Instead of creating multiple templates and post types and forcing authors to choose them before building the page, you can create common patterns for your authors to change on the fly. Columns with cards, a gallery of logo images, whatever design layouts you create, you can make them into patterns for authors to quickly drop onto a page. And, as I said before, how much design control you give is entirely up to you.
I’m starting to sound like a Gutenberg shill, so I’ll stop here. I just wanted to say that we were in a similar position when it came to adopting Gutenberg and worrying over the amount of design control we would lose. Having a couple years experience with Gutenberg now, I can honestly say we’d be doing our customers a disservice forcing them to use the classic editor.
Report
·
Have you looked at ClassicPress? That might be a solid alternative for your enterprise clients. They’re upgrading TinyMCE to version 5, which is something WordPress isn’t planning on doing. There’s talk about building out custom fields API (something WP abandoned) to make it a more robust CMS.
Report
·
You’re not building your clients Custom Blocks based on thoses tidy taxonomies? Ouch, poor them. Coolest thing since sliced bread for creating content that hasn’t been shaped with a ‘cookie-cutter’.
Report
·
I always wonder if there will ever be a release that focuses on performance and/or modernization.
Report
·
All I want is a very fast site. I wish they put this as number one priority.
Report
·
Site speed depends so much on the content, hosting, weight of images, scripts, theme, plugins, etc. I think if you test the base theme out of the box, it is fast.
Report
·
As far as speed, it has been proven that pages built with blocks are inherently faster than most, if not all current page builders. I also believe that with each iteration, there are benchmarks that are tested against in order to try and improve performance.
Report
·
I have always wondered why WordPress lacks a file management system. Admittedly there is a good inexpensive plug-in for this, but this seems so fundamental
Report