WordPress’ Gutenberg: The Long View

WordPress has been around for 15 years. 31.5% of sites use it, and that figure continues to climb. We’re here for the long term, so we need to plan for the long term.

Gutenberg is being built as the base for the next 15 years of WordPress. The first phase, replacing the post editing screen with the new block editor, is getting close to completion. That’s not to say the block editor will stop iterating and improving with WordPress 5.0, rather, this is where we feel confident that we’ve created a foundation that we can build everything else upon.

Let’s chat about the long-term vision and benefit of the Gutenberg project. ūüôā

As the WordPress community, we have an extraordinary opportunity to shape the future of web development. By drawing on the past experiences of WordPress, the boundless variety and creativity found in the WordPress ecosystem, and modern practices that we can adopt from many different places in the wider software world, we can create a future defined by its simplicity, its user friendliness, and its diversity.

If we’re looking to create this future, what are the key ingredients?

Interface unity. Today, the two primary methods of embedding structured data into a WordPress post are through shortcodes, and meta boxes. Both of these have advantages, and drawbacks. With shortcodes, authors can see exactly where the shortcode will be rendered, in relation to the rest of the content. With meta boxes, the site creator can ensure the author enters data correctly, and doesn’t get it out of order. Additionally, meta boxes allow storing data outside of post_content, making it easily queryable. With blocks, we can combine these strengths: blocks render where they’ll be in the finally content, they can be configured to only allow certain data to be entered, and to save that data wherever you want it. With block templates, you can lock the post to only allow certain blocks, or to even layout the blocks exactly as they need to be, ensuring the post is saved and rendered exactly as intended.

Platform agnosticism. There’s never been a nice way for plugins to provide custom UI for the WordPress mobile apps (or any other apps that talk to WordPress, for that matter) to render. Thanks to the magic of React Native, this is a very real possibility in the near future. The mobile team are working hard on compiling Gutenberg into the mobile apps¬†and getting the core blocks working, which will guide the way for any sort of custom block to just‚Ķ work. ūü§Į

Concept simplification. Even vanilla WordPress has masses of similar-but-subtly-different concepts to learn. Within the post, there are shortcodes, meta boxes, and embeds. Outside of that, we have menus and widgets (and widget areas, of course). The first phase of Gutenberg is focussed on the post, but ultimately, we can imagine a world where the entire site creation process is just blocks. Blocks that can fit together, that can be easily rearranged, and can each take care of important individual things, like their own responsive behaviour.

A common base. Gutenberg isn’t going to replace page builders, or custom field plugins like ACF. Instead, it give them a common framework to build themselves upon. Instead of every page builder having to spend a huge amount of time maintaining their own framework, they can use the one that Gutenberg provides, and focus on providing the advanced functionality that their customers rely on.

A design language. I don’t know about y’all, but as a developer, I find it challenging to create quality interfaces in the WordPress of today. I’d really love if there was a simple library for me to refer to whenever I wanted to create something. Desktop and mobile¬†environments have had this for decades, but the web is only just starting to catch on. The WordPress design team have some really interesting ideas on this that’ll help both core and plugin developers to put together high quality interfaces, quickly.

There are side benefits that come along for the ride, too. Encouraging client-side rendering gives a smoother UX. Using modern JS practices encourages a new generation of folks to start contributing to WordPress, helping ensure WordPress’ long term viability. Because it’s Open Source, anyone can use and adapt it. This benefits the Open Source world, and it also benefits you: you should never feel locked into using WordPress.


What’s next?

Naturally, there’s going to be a transition period. WordPress 5.0 is just the start, it’s going to take some time for everyone to adjust to this brave new world, there will be bugs to fix, kinks to iron out, flows to smooth. The tools that plugin and theme developers need are starting to appear, but there’s still a lot of work to be done. There’s a long tail of plugins that may never be updated to support Gutenberg, the folks using them need an upgrade route.

If you feel that your site or business isn’t quite ready to start this transition, please install the Classic Editor plugin now. Gutenberg is very much a long term project, I’m certainly not expecting everyone to jump on board overnight. Much like it took years for the customiser to get to the level of adoption it has now; every site, plugin, and agency will need to consider how they’re going to make the transition, and what kind of timeline they’re comfortable with.

Ultimately, the WordPress experience, community, and ecosystem will grow stronger through this evolution.

I’ve been been working on WordPress for years, and I plan on doing it for many years to come. I want to help everyone make it through this transition smoothly, so we can keep building our free and open internet, together.

Podcasting: Tavern Style

Scattered lego blocks

Earlier today, I joined JJJ and Jeff on episode 319 of the WP Tavern’s WordPress Weekly podcast!

We chatted about GitHub being acquired by Microsoft (and what that might mean for the future of WordPress using Trac), the state of Gutenberg, WordCamp Europe, as well as getting into a bit of the philosophy that drives WordPress’ auto-update system.

Finally, Jeff was kind enough to name me a Friend of the Show, despite my previous appearance¬†technically not being a WordPress Weekly episode. ūüéČ

WPWeekly Episode 319 ‚Äď The Gutenberg Plugin Turns 30

Introducing: Linkify for Chrome

In¬†WordPress 4.2, a fun little feature¬†was quietly snuck into Core, I’m always delighted to see people’s reactions when they discover it.

But there’s still a problem – WordPress is only ~26% of the internet, how can you get the same feature on the other 74%? Well, that problem has now been rectified. Introducing, Linkify for Chrome:

Thank you to Davide for creating Linkify’s excellent icon!

Linkify is a Chrome extension to automatically turn a pasted URL into a link, just like you’re used to in WordPress. It also supports Trac and Markdown-style links, so you can paste links on your favourite bug trackers, too.

Speaking of bug trackers, if there are any other link formats you’d like to see, post a ticket over on the Linkify GitHub repo!

Oh, and speaking of Chrome extensions, you might be like me, and find the word “emojis” to be extraordinarily awkward. If so, I have another little extension, just for you.

How I Would Solve Plugin Dependencies

lol, I wouldn’t1.


1. If I absolutely had to, I wouldn’t do it the same as Ryan.

WordPress isn’t (and will never be) Linux

ZYpp is the dependency solver used by OpenSUSE (and its PHP port in Composer), it was born of the need to solve complex dependency trees. The good news is, WordPress doesn’t have the same problem, and we shouldn’t create that problem for ourselves.

One of the most common-yet-complex issues is determining how to handle different version requirements by different packages. If My Amazing Plugin requires WP-API 1.9, but Your Wonderful Plugin requires WP-API 2.0, we have a problem. There are two ways to solve it – Windows solves it by installing multiple versions of the dependency, and loading the correct version for each package. This isn’t a particularly viable option in PHP, because trying to load two different versions of the same code in the same process is not my idea of a fun time.

The second option, which ZYpp solves, is to try and find a mutually compatible version of the dependency that each plugin can use. The biggest problem with this method is that it can’t always find a solution. If there’s no compatible way of installing the libraries, it has to throw back to the user to make the decision. This isn’t a viable option, as 99.999*% worth of users wouldn’t be able to tell the difference between WP-API versions 1.9 and 2.0, and nor should they.

But there’s a third option.

Technical Debt as a Service

Code libraries are, by their nature, developer facing. A user never really needs to know that they exist, in the same way that they don’t need to know about WP_Query. In WordPress Core, we strive for (and often achieve) 100% backwards compatibility between major versions. If we were going to implement plugin dependencies, I would make it a requirement that the code libraries shoulder the same burden: don’t make a user choose between upgrades, just always keep the code backwards compatible. If you need to make architectural changes, include a backwards compatible shim to keep things working nicely.

This intentionally moves the burden of upgrading to the developer, rather than the end user.

What Version?

If we’re going to require library developers to maintain backwards compatibility, we can do away with version requirements (and thus, removing the need for a dependency solver). If a plugin needs a library, it can just specify the library slug.

Better Living Through Auto Updates

If we were to implement plugin dependencies, I think it’d be a great place to introduce auto updates being enable by default. There’s no existing architecture for us to take into account, so we can have this use the current WordPress best practices. On top of that, it’s a step towards enabling auto updates for all Core releases, and it encourages developers to create backwards compatible libraries, because their library will almost certainly be updated before a plugin using it is.

Let’s Wrap This Up

I’m still not convinced plugin dependencies is a good thing to put in Core – it introduces significant complexities to plugin updates, as well as adding another dependency on WordPress.org to Core. But it’s definitely a conversation worth having.

JSON Encoding in WordPress 4.1

Earlier in the year, we noticed a problem with JSON in WordPress. The JSON spec very explicitly notes that it¬†only supports UTF-8, whereas WordPress can use any character set that MySQL supports. So, for sites that didn’t use MySQL’s utf8 or utf8mb4 character sets, this generally presented itself as json_encode() returning false;¬†which resulted in either invalid JSON being returned from an Ajax request, or a JavaScript error in some embedded code.

To fix this, WordPress 4.1 now includes a shiny new function that we recommend for all plugins and themes:

wp_json_encode()

Usage for wp_json_encode() is identical to json_encode(). It works by trying a json_encode(), then checking if that encoded properly. If it failed, wp_json_encode() will go through whatever lump of data you passed to it, convert it to UTF-8, then return it as JSON.

Have fun with WordPress 4.1, and see you next year for new and exciting functionality coming to a WordPress install near you!

The Next Adventure

Over my past few years at Automattic, I’ve worked on a bunch of different teams and projects – VideoPress, the WordPress iOS app, various Social projects, and most recently, o2. I even took a few months to work on WordPress core, helping build the auto-update functionality that we now see rolling out security updates within hours of their release.

The few months I spent working on WordPress core made me realise something – there’s a lot more I have to contribute. So, with the WordPress 4.0 RC¬†out the door, I’m super excited to be moving to my next project – working on WordPress core full time!

Automattic naturally puts a lot of people-hours into WordPress, with over 30 of us contributing to WordPress 3.9. I’m looking forward to being a bigger part of that, and giving more back to WordPress community!

WordPress and UTF-8

Update: WordPress 4.2 has full UTF-8 support! There’s no need to upgrade manually any more. ?

For many years, MySQL had only supported a small part of UTF-8, a section commonly referred to as plane 0, the “Basic Multilingual Plane”, or the BMP. The UTF-8 spec is divided into “planes“, and plane 0 contains the most commonly used characters. For a long time, this was reasonably sufficient for MySQL’s purposes, and WordPress made do with this limitation.

It has always been possible to store all UTF-8 characters in the¬†latin1¬†character set, though¬†latin1¬†has shortcomings. While it recognises the connection between upper and lower case characters in Latin alphabets (such as English, French and German), it doesn’t recognise the same connection for other alphabets. For example, it doesn’t know that ‘ő©’ and ‘ŌČ’ are the upper and lower-case versions of the Greek letter omega. This creates problems for searching text, when you generally want to match characters regardless of their case.

5557649

With the release of MySQL 5.5, however, the utf8mb4 character set was added, and a whole new world opened up. Plane 1 contains many practical characters from historic scripts, music notation and mathematical symbols. It also contains fun characters, such an Emoji and various game symbols. Plane 2 is dedicated to CJK Ideographs, an attempt to create a common library of Chinese, Japanese and Korean characters.

For many websites, being able to use Emoji without installing an extra plugin is an excellent reason to switch your WordPress database to¬†utf8mb4,¬†but unfortunately it’s not quite that simple. MySQL still has a few more limitations that cause problems with ¬†utf8mb4.

Without further ado, here’s how to configure MySQL, so that WordPress can use utf8mb4. If you don’t have the ability to configure your MySQL server directly, you should speak to your host. If they don’t want to, it’s probably time to look for a new host.

Upgrade MySQL

You need to be running MySQL 5.5.14, or higher. If you’re not already running at least MySQL 5.5 (ideally 5.6), you should be doing that anyway, as they provides significant performance and stability improvements over previous versions. For help with upgrading MySQL, check out the MySQL manual.

Configure MySQL

Before we convert your tables, we need to configure MySQL correctly.

In your my.cnf file, add the following settings to the [mysqld] section. Remember to double check that you’re not duplicating settings in your my.cnf file – if any of these options are already set to something different, you’ll need to change that setting, rather than add a new setting.

You’ll need to restart your MySQL server after adding these settings.

Use InnoDB

Next, convert your WordPress tables to InnoDB and utf8mb4:

You’ll need to run these two queries for each WordPress table, I used¬†wp_posts¬†as an example. This is a bit tedious, but the good news is that you’ll only ever need to run them once. A word of warning, you should be prepared for some downtime if you have particularly large tables.

Configure WordPress

Finally, you can tell WordPress to use utf8mb4 by changing your DB_CHARSET setting in your wp-config.php file.

And there you have it. I know, it’s not pretty. I’d really like to add this to WordPress core so you don’t need to go through the hassle, but currently only a very small percentage of WordPress sites are using MySQL 5.5+ and InnoDB – in order to justify it, we need to see lots of sites upgrading! You can head on over to the core ticket¬†for further reading, too – login and click the star at the top to show your support, there’s no need to post “+1” comments. ūüôā

Oh, and a final note on Emoji – Chrome support is pretty broken. There’s an extension to add Emoji to Chrome, but it interferes with WordPress’ post editor. If you really want to use Emoji in your posts, Safari or Firefox would be better options.

Don’t Let Your Plugin Be Activated on Incompatible Sites

When you write a WordPress plugin, you can specify a minimum WordPress version that your code is compatible with, using the “Requires” option in your plugin header, but it isn’t enforced. Along with that, there’s no way to specify a minimum version of PHP or MySQL.

This can cause your users to have bad experiences with your plugin, and you’ll get bad ratings.

So, here’s how I make sure my plugins are only activated when I want them to be.

 

It’s only a little extra code when added to a plugin, provides complete protection, and won’t cause any weirdness on the front end of your site, it’ll just deactivate itself either on activation, or when someone visits wp-admin.