Revised suggested roadmap for Gutenberg and Customization

Gutenberg is about to reach a milestone of having the technical and design vision in place. I know that we’re a little off from the existing roadmap, so I’d like to suggest an update to the milestones going forward.

The milestones below are based on information from the focus leads about who will be available and when. As with all things in open source, these are best guesses and I encourage everyone to join us in being flexible as we keep creating:

Aug 2017 (late): Testing plan begins: this will start with a public meeting.

Aug 2017 (late): Promotional page goes live for Gutenberg. This is in progress.

Sep 2017: Potential *.1 release with banner to encourage use of and feedback for Gutenberg

Nov 2017: 4.9 release

Dec 2017: Begin merge proposal for Gutenberg

Jan 2018: Gutenberg —> Customizer crossover (switching the focus)

It should be clear this is not set in stone. Gutenberg is not ready to merge and as a result giving it this time is important to iterate and respond to feedback. Beyond the merge proposal it’s also difficult to predict, so the roadmap to 5.0 isn’t being predicted here, that will depend on the proposal.

Share this:

Frankly I am dismayed that a project with as far reaching ramifications as Gutenberg is being rushed into release as soon as early 2018. Given WP’s past experience on projects, the projects that get rushed (like menus) don’t get time to mature before they establish a legacy of technical debt that is either very difficult or unable to be changed in future versions.

I fear the train has already left the station but my input is to say that Gutenberg should be a feature plugin for probably at least 2 years before it is merged into core. I just hope the built up inertia for Gutenberg is not so much that is overcomes a more measured approach that avoiding adding an albatross to WordPress.

Apologies if it wasn’t clear, it’s only saying a start of a merge proposal. Also, it’s not at all set in stone. What at potentially that stage is ‘Gutenberg’ will be down to all types of feedback and input from the entire community. No train has left, please join the train and help with the project.

Understood, but the implication from your post is merge would be for WordPress 5.0, which feels far too soon. 6.0 feel more like the right timeframe.

Also, I can’t really join the train because I do not have ReactJS experience. Part of the reason for my concern the lack of a very solid extensibility model that does not require significant developer expertise to do make even the simplest extensions.

I fear the extensibility model has been given the same level of thought as the extensibility model for the current media system, which is to say not much. And a model that requires a build system to allow for creating a simple enhancement is troubling.

You raise a good point worth clearing up Mike, you don’t have to know React to contribute to Gutenberg or even code at all. Like any area of WordPress, we need contributions from everyone and there is something for everyone to dive right in with. If you want help with that just let me know – that extends to anyone.

Show and tell about Gutenberg in a meetup, have a discussion in your local group.

These are just some ways but they do not require code. Another that sounds simple, is just to start using it and give us as a team feedback. You could write a post, if you do drop the link into Slack #core-editor and it will be noticed.

I cannot agree more with both Mike Schinkel and Lee Hodson.
This is being rushed, it is being pushed forward without any long term thinking or a proper look at all the potential issues it will create. I have used the plugin on our test bed and it is still, in my personal opinion, an Alpha release of a possible idea in the future of WordPress editing.
Out of interest we transferred a very simple clients site and turned on Gutenberg and then worked out the estimated time and cost to the client to fix all the broken pages and layouts.
We worked on the fixes between us over a ten day period keeping a standard client billing sheet for the project.
The estimated Cost for a Very Simple Physiotherapists site was 20 hours and £800.

It needs to remain a plugin permanently A CHOICE so that bloggers can install it if they wish but the massive community that use WP as a CMS can continue to work unhindered.

We use the Beaver framework for building client sites, we build them simple page and post templates that they load and edit in a visual builder, they love it and the WordPress text editor is not even used by the bulk of our clients.

Two things that I think would make sense to include in the roadmap are 1) an API freeze (essentially saying when we think the API is stable enough to start encouraging people to be building experiences/plugins upon Gutenberg) and 2) publishing of documentation/examples in order to assist developers with extending Gutenberg. I know that this has started, but it would also be good to have a target for when those are “vision complete”

I’m sure you meant very much before a merge proposal since I don’t think we should even entertain a proposal that changes one of the most important interactions in WordPress without there having been a decent amount of time for developers to test the API. That testing can’t take place without an API freeze and documentation.

Lee Hodson
7:30 am on August 13, 2017

Gutenberg is a nice idea but it gets in the way of content creation. It makes the process of writing a post both laborious and clumsy. Add text block, begin writing in the cramped text block, realize the text block lacks required formatting options, delete block, sift through tabs to find the right kind of block for the type of content to be added, add new block, add content, add another new block, add content and son and so on and so on….

With Visual Composer the text block gives me the full TinyMCE experience. No other page builder that I use takes away my options. The text block always gives me the full TinyMCE experience.

There is no way to say this politely and still express properly the concerns people have about Gutenberg.

I read the plugin’s reviews today and not many of the reviews show a preference for Gutenberg over TinyMCE. I try Gutenberg with every new release. It has evolved since it’s first public release. I’d like to see it evolve it something usable but I can’t see that happening in its current form.

I can’t be alone in wanting to be in control of the editor features I have access to when I write my posts. I don’t want the Gutenberg design team to restrict me to a limited set of text format options when I use a text block. Do what you want with your own sites but don’t presume I want the same as you or even that our needs are similar.

The text block widget is more like a tweet box in the cramped space provided for content.

Turn Gutenberg into a TinyMCE addon or into a feature that is compatible with TinyMCE similar to the way other page builders work.

Gutenberg smacks of a repeat of the jpeg compression quality fiasco which saw every single one of my customers complain about poor quality images, and I was not the only developer to receive complaints. I voiced concern before the change but the WP development team failed to listen.

Similar with Jetpack. A product that took time to mature into a useful set of feature plugins but then Automatic saw fit to make it the “let’s get people onto wordpress.com” product and hid the more useful settings to the debug screen.

I’m struggling to understand the state of Planet WordPress. It feels as though end users and developers are being ignored so that people can make a name for themselves by adding ‘did xyz as a member of the WordPress core development team’. Can someone please tell me I’m wrong.

If we are not careful, Gutenberg will be the upgrade that kills WordPress.

Thanks for taking the time to comment Lee, it’s a very thought out comment and that matters. All feedback matters, I can’t say that enough because it really does. The project isn’t complete yet, this means it’s important to listen, iterate and adjust. I want to assure you that all voices are being listened to, let me ease your worry on that point.

It’s worth noting it’s not just developers creating this to and I can honestly say even the developers their motivation isn’t to get a label of ‘xyz contribution’. The motivation is to try and create the best experience for an editor, for all users not just developers or those that know WordPress today. In saying that, it’s also not to exclude those developers or those who have stuck with WordPress. It’s about an inclusive experience.

Gutenberg will be in the end the result of the community contributions, feedback and iteration. It won’t even be what you can download today, things will change and that’s exactly the way it should be as it responds to feedback and those joining to work on it.

Lee Hodson
9:28 pm on August 14, 2017

Thank you for your reply, Tammie. I appreciate what you are saying.

My perception is that Gutenberg is an attempt to

a) tidy up the editor screen such that less is immediately visible,
b) make the editor more click’n’play visual such that authors can easily design the layout of their content, and
c) make the editor easier to hook into and add new content block types than is TinyMCE.

The Gutenberg editor screen is cleaner until we get to the actual content editor. I see where it is headed. The problem is that authors need ready access to the features of the editor screen like the metafields, metaboxes, metawidgets and text format options that Gutenberg presently strips away from view.

All the above can be addressed by,

A) Rolling Tabify Edit Screen into core, or features similar to it.
B) Adapting Shortcake so it works with Gutenberg, and
C) Restricting the Gutenberg editor metawidget component to be only a means of listing content blocks that are available for use within the editor area.

That would provide a useful visual editor that is not too cramped, that does not limit format options and that helps users visualize their content in the layouts they build. Done properly this would allow content to be edited on the frontend too.

This makes more sense to me than does the idea of making the editor a blocky experience. It needs to be a flowing experience.

Hide what is not needed but keep hidden components within easy reach, let authors write content without need to add content blocks but keep the option to insert interactive blocks within the content where needed.

There needs to be a default editor canvas into which everything else fits otherwise the editor becomes clumsy, clunky and Gutenberg fails to achieve its intended purpose.

Personally, I think blocks are the right approach, just to be clear about that upfront. Is it in a finished perfect state now? No, it’s not. I see a lot of the refinement being around the interface and how from testing this develops.

Here lies the issue “I think blocks are the right approach” WP users so far are disagreeing with you and there are MILLIONS of users.

Hundreds of thousands of developers have spent hundreds of thousands of hours and dollars turning WP into MUCH MORE than a blogging platform. Now you will undo all that work and passion for a blooming text editor. REALLY?

Solutions for those that do not like tiny already exist. ALL our clients use the beaver builder and love it. They do not even use the native WP text editor. From what I read you will remove their capability to choose.

I have trouble with this proposed roadmap. It doesn’t feel very much like a roadmap at all, but rather a timeline for merging Gutenberg into core.

I’d expect a roadmap for Gutenberg to include a list of known blockers to core inclusion and a plan (including timeline) to get those fixed. This post doesn’t include anything along the lines of developer tools for Gutenberg, or an API freeze (as @jorbin mentioned), or user testing / UX work, or accessibility review, or a translation review from the polyglots team, or a true “beta” period with feature freeze, or a plan to triage and target any of the 452 (and counting) open issues in GitHub (acknowledging the some will be “maybelater” or “wontfix”), or any of the other dozens of things we expect from high quality, incoming features.

Gutenberg definitely needs a roadmap as to progresses toward core inclusion, but this isn’t it.

I might be mistaken, but I think in this case @karmatosed‘s referring to the general timeline of Gutenberg in the first half of the year, and Customization in the second half of the year. We’ve passed those points already, so the Editor/Customization focus leads wanted to publicly post some updated dates we’re aiming for.

Thanks, @melchoyce. I think the use of “update to the existing roadmap” on a post related specifically to Gutenberg is what was confusing to me, especially since this post more seemed specifically about Gutenberg and not about the overall focus areas for 2017.

That’s confusing and not helping to clarify the objectives and ramifications of Gutenberg, which is in heavy debate. The transparency of the project is useful, no one should complain about that, but the lack of long-term goals and a clear process for establishing those goals is not helping to resolve the wide set of concerns over this short-term plan.

I still agree with Samuel Slider that this is not a roadmap, per se, and a full roadmap would be useful, and I see that Matt Mullenweg has posted “We Called it Gutenberg for a Reason” with a wide range of objectives for the project—such that the goal is not simply to update the editor and improve the writing experience, but to re-engineer WordPress so that eventually all key web components are implemented as blocks:

The first version will be a page and post builder, and then we will take the block concept to replace widgets, menus, and have themes that allow you to build entire sites.

Is there a long-range roadmap that shows a full set of objectives down the line?

I’m also with Mike Schinkel. It seems there is a rush to merge this into the core and get it implemented without adequate testing.

Am I wrong for believing that Gutenberg will be incompatible with a huge number or plugins and themes? And that the authors of these software products will need to incorporate changes? And that will take time? And that some developers will abandon their products due to the effort required? And that any WordPress core upgrades after Gutenberg is implemented to websites where plugin/theme compatibility issues have not been resolved, will result in major frustration and downtime?

If these concerns are unwarranted, please educate me.

If I’m even partially correct, then please, let’s slow down and do this in a way that avoids major disruption.

Just to be clear, there is no rush. Anything said here was a suggestion and a big part of that included testing. What happens from testing is well unknown, although a plan is ok to have as to what may. Testing with themes and plugins is crucial, that’s exactly the feedback and help we need.

webmaster4business
9:36 pm on August 14, 2017

In that Case Tammie Gutenberg should not even be considered anything other than a new possible plugin.
This is being rushed and pushed on to the community, the negative outcome of this will be very angry Clients with large repair bills. My company does not work for free and the worst part is it won’t be you or the Gutenberg team or even Matt that will get the majority of the anger, it will be those of us that deal directly with the end user who will get the majority of the incredibly angry clients with totally broken websites.
In fact I am so concerned about this being forced through that we are disabling Automatic Core Updates from all our clients websites.

There have been zero decisions regarding what, if any, backward compatibility breaks there will be if Gutenberg is merged into core. “…the negative outcome of this will be very angry Clients with large repair bills” is nothing more than spreading FUD. Disabling Automatic Updates is just putting your client’s sites at additional risk of attack.

webmaster4business
12:04 pm on August 17, 2017

Actually Aaron no it does not put our clients sites at risk. We acknowledge the update, run the update on our test bed, check everything is fine and nothing has broken, if everything is fine then proceed with clients updates. Exactly the same procedure we use for plugins.

Phil C
8:40 am on August 28, 2017

You should at least leave WP_AUTO_UPDATE_CORE set as ‘minor’. Which is default anyway, so maybe just don’t set it at all. Turning off all auto-updates in an attempt to avoid new features is a little misguided.

webmaster4business
9:03 pm on September 9, 2017

Slight miss type on my part Phil C. We have set it for minor only and I never said we were turning off ALL Auto-updates, all plugins update as they come in it is just Core WordPress Updates.
If you load a clients site on to a test bed with Gutenberg installed and running you can see what happens for your self and it is not pretty

leeshields
11:54 am on August 15, 2017

Is Gutenberg being pushed by developers that still see WP as a blogging platform? The vast majority of the sites I build are not, WP is a CMS to me, the clients aren’t designers and frankly we don’t want them having layout controls which could play havoc with carefully styled designs. Adding to the comments above Gutenberg should be an addon or an option, not a replacement for the current editor, which we have so much ability to control in templates, and if we need more, we already have visual composers. My clients would not be happy if I go back to them with huge costs to rebuild working sites! As said above I could envision a situation where we stop updates to sites to prevent damage, something none of us want to do, please don’t push WP back by forcing functionality many people aren’t searching for!

Agree completely. Creates a false impression of what my theme looks like! Do I have time to make each theme I create also have a set of Gutenberg-specific CSS rules to work within its editor? And what is up with making a new text box every time you hit return?