Thoughts on Gutenberg and WordPress 5.0

So, Gutenberg recently took over my Twitter feed. Hundreds of fellow devs are discussing it and writing their feedback. I would like to take a bit different approach though.

First, I confess that I haven’t tried it yet, but already love it. The beta (although I think it’s too early to call it beta) is still missing a lot of features, has bugs, accessibility issues etc — check any of the recent blog posts about Gutenberg for more info. It raises tons of questions, but it looks very promising. Let’s be honest — it looks awesome!

But the most important conclusion I’ve made so far is that Gutenberg is a breaking change. It will retire a lot of plugins, both free and commercial. It will introduce new internal APIs. It will require devs to learn them. It will force devs to rewrite a lot of their code. Especially for custom client websites.

And I think it’s great. I see this as an opportunity. If WordPress introduces a major, breaking change, why limit ourselves to only this one change?

No one said that after version 4.8 comes 4.9 and after 4.9 the next version must be 5.0. The next major release without breaking changes could be 4.10 (followed by 4.11, 4.12 and so on). But the 5.0 release, once it’s ready, could be a major breaking release. It could introduce multiple breaking changes that are being discussed (and many patches are available) for years.

Some of those changes could be (from top of my mind, in no special order):

  • Composer support, dependency management and autoloading
  • Better routing to replace Rewrite API
  • Templating engine (Blade, Twig?)
  • Native gettext support (if available)
  • Native support for content in multiple languages
  • Abstracting away from default blog-centric architecture
  • Better support for “custom fields” (instead of wp_*meta tables)
  • Remove admin-ajax.php, force REST API
  • Store widgets as post types, don’t use wp_options table anymore
  • Don’t pollute wp_options table with transients, use dedicated table
  • Do not use hardcoded URLs in content
  • Better assets loading (async, defer etc)
  • Native UI for granular permissions control (roles and caps)

And, of course, deprecate a lot of old, legacy stuff.

This list is not complete, of course. And I don’t say everything must be stuffed into the new release. But the 5.0 could set the foundation for “making WordPress great again” — modern, flexible, better CMS for all types of content, in (m)any languages.

Latest 4.X branch can become some sort of LTS, providing critical bug fixes and security patches for several years. But the 5.X branch will become a new, modern version of WordPress — with better CMS architecture, better database schema, better codebase. And with Gutenberg.