The Mission: Democratise Publishing

Blank open book on plain wooden table

It’s exciting to see the Drupal Gutenberg project getting under way, it makes me proud of the work we’ve done ensuring the flexibility of the underlying Gutenberg architecture. One of the primary philosophies of Gutenberg’s technical architecture is platform agnosticism, and we can see the practical effects of this practice coming to fruition across a variety of projects.

Yoast are creating new features for the block editor, as well as porting existing features, which they’re able to reuse in the classic editor.

Outside of WordPress Core, the Automattic teams who work on Calypso have been busy adding Gutenberg support, in order to make the block editor interface available on WordPress.com. Gutenberg and Calypso are large JavaScript applications, built with strong opinions on design direction and technical architecture, and having significant component overlap. That these two projects can function together at all is something of an obscure engineering feat that’s both difficult and overwhelming to appreciate.

If we reached the limit of Gutenberg’s platform agnosticism here, it would still be a successful project.

But that’s not where the ultimate goals of the Gutenberg project stand. From early experiments in running the block editor as a standalone application, to being able to compile it into a native mobile component, and now seeing it running on Drupal, Gutenberg’s technical goals have always included a radical level of platform agnosticism.

Better Together

Inside the WordPress world, significant effort and focus has been on ensuring backwards compatibility with existing WordPress sites, plugins, and practices. Given that WordPress is such a hugely popular platform, it’s exceedingly important to ensure this is done right. With Gutenberg expanding outside of the WordPress world, however, we’re seeing different focuses and priorities arise.

The Gutenberg Cloud service is a fascinating extension being built as part of the Drupal Gutenberg project, for example. It provides a method for new blocks to be shared and discovered, the sample hero block sets a clear tone of providing practical components that can be rapidly put together into a full site. While we’ve certainly seen similar services appear for the various site builder plugins, this is the first one (that I’m aware of, at least) build specifically for Gutenberg.

By making the Gutenberg experience available for everyone, regardless of their technical proficiency, experience, or even preferred platform, we pave the way for a better future for all.

Democratising Publishing

You might be able to guess where this is going. 😉

WordPress’ mission is to “democratise publishing”. It isn’t to “be the most popular CMS”, or to “run on old versions of PHP”, though it’s easy to think that might be the case on the surface. That these statements are true is simply a side effect of the broader principle: All people, regardless of who they are or where they come from, should be able to publish their content as part of a free and open web.

The WordPress mission is not to “democratise publishing with WordPress”.

WordPress has many advantages that make it so popular, but hoarding those to ourselves doesn’t help the open web, it just creates more silos. The open web is the only platform on which publishing can be democratised, so it makes sense for Gutenberg to work anywhere on the open web, not just inside WordPress. Drupal isn’t a competitor here, we’re all working towards the same goal, the different paths we’ve taken have made the open web stronger as a whole.

Much as the block editor has been the first practical implementation of the Gutenberg architecture, WordPress is simply the first practical integration of the block editor into a CMS. The Gutenberg project will expand into site customisation and theming next, and while there’s no requirement that Drupal make use of these, I’d be very interested to see what they came up with if they did. Bringing together our many years of experience in tackling these complex problems can only make the end result better.

I know I’m looking forward to all of us working together for the betterment of the open web.

Forking is a Feature

There’s a new WordPress fork called ClassicPress that’s been making some waves recently, with various members of the Twitterati swinging between decrying it as an attempt to fracture the WordPress community, to it being an unnecessary over-reaction, to it being a death knell for WordPress.

Personally, I don’t think it’s any of the above.

Some years ago, Anil Dash wrote an article on this topic (which I totally ripped forked the name from), you should read it for some context.

With that context, I genuinely applaud ClassicPress for exercising their fundamental rights under the GPL. The WordPress Bill of Rights makes it quite clear that forking is not just allowed, it’s encouraged. You can and should fork WordPress if you choose to. This isn’t a flaw in the system, this is how it’s supposed to work.

Forks should aways be encouraged.

Forks are a fundamentally healthy aspect of Open Source software. A relatively recent example is the io.js fork of Node.js, which resulted in significant changes to how the Node.js project is governed and developed. WordPress has seen forks in the past, too: Lyceum was a fork that added multi-site support, before it existed in WordPress. WordPress MU was something of a sibling fork which also added multi-site support, and was ultimately merged back into WordPress.

There are examples of forks that went on to become independent projects: WordPress itself is a fork of cafelog/b2. X.org is a fork of XFree86. LibreOffice is a fork of OpenOffice. Blink is a fork of WebKit, which in turn is a fork of KHTML. MariaDB is a fork of MySQL. XBMC has been forked dozens of times. Joomla is a fork of Mambo. (Fun historical coincidence: I very nearly accepted a job offer from Miro, the company behind Mambo, just a couple of months before Joomla came into being!)

Maintaining a fork is hard, thankless work.

All of these independent forks have a common thread: they started with a group of people who were highly experienced in building the software they were forking (often comprising of core developers of the original software). That’s not to say that non-core developers can’t drive a fork, but it does seem to require fairly fundamental knowledge of the strengths and weaknesses of the software, in order to successfully fork it into an independent product.

From a practical perspective, I can tell you that maintaining a fork of WordPress would require an extraordinary amount of work. For example, WordPress.com effectively maintains a fork (which happens to almost exactly match the Core codebase) of WordPress. The task of maintaining this fork falls to a talented team of devops folks, who review and merge each patch.

Now, WordPress.com is really only an internal fork. To maintain a product fork of WordPress would require so much more effort. You’d need to maintain the web infrastructure to push out updates. As the fork diverges from WordPress Core, you would need to figure out how to maintain plugin and theme compatibility. You’d likely need to do your own bug and security fixes, on top of what’s merged from WordPress.

I’m not saying this to dissuade anyone from forking WordPress, rather, it’s important to go into this aware of the challenges that lay ahead. For anyone who uses a fork (whether it be a fork of WordPress, or any other software product), I’m sure the maintainer would appreciate a word of thanks for the work they’ve done to make it possible. 🙂

What’s next for ClassicPress?

Well, that’s ultimately up to the folks building it, and the people who use it. As a member of the WordPress core team, I certainly hold no ill-feelings towards them, and I hope they’ll be open to working with us in the future. I hope we’ll be able to learn from their work, to improve WordPress for everyone.

It’s humbling and inspiring to build something that’s used by so many millions of sites, but at times it involves accepting that we can’t build the tool that will work for 100% of people, 100% of the time. Regardless of WordPress’ future popularity, there’ll always be a place for alternatives, whether that be forks like ClassicPress, different CMSes like Drupal or Joomla, or even different publishing concepts, like MediaWiki or Mastodon.

Ultimately, we all share the same goal: creating a free and open web, for everyone to enjoy. While ClassicPress has styled itself as a protest against Gutenberg for now, I hope they’ll find their voice for something, instead of just against something. 💖

Trying Mastodon

It’s no secret that Twitter is red hot garbage fire, so I’ve signed up for a Mastodon account to give them a try. Because I’m super vain, I decided to create my own Mastodon instance, with a custom domain.

Mastodon is kind of weird to sign up for: think of it as being kind of like email. You can sign up for a big provider like Gmail or Outlook, you can run your own server, or you can pay someone to run a server for you. In my case, I’m paying for a personal account on Masto.host, they’ve been super helpful in getting it all configured. If you’re just looking to try it out for free, here’s a tool to help you choose an instance.

Some Initial Impressions

It’s pretty quiet, of course. I’m currently following 13 people on Mastodon, and 500 on Twitter, there’s going to be a difference in volume.

Mastodon Bridge is a useful tool for you to be able to find your Twitter friends when you start out. I highly recommend using it.

None of the apps have the polish that I’m used to with Twitter apps like Twitterific and Fenix, but they’re evolving quickly. I do miss Tweet Marker support. I’ve settled on using Whalebird for my MacOS app, none of the various Android apps have appealed enough for me to start using them.

Search is pretty bad. There’s a confusing limitation (for a reasonable, but not really satisfactory technical reason): You can only search through the Toots that people on the same instance as you have subscribed to. So, because I’m on only person on pento.net, I can only search through the Toots of people I’m immediately subscribed to. If you sign up for a big host, you’ll see many more results, but you still won’t see everything.

I’m going to have to share this post manually, because Jetpack doesn’t know how to share to Mastodon yet. 😉

Will I Keep Using It?

Yep, for now. There’s a lot of potential, I’m interested to see where it goes.

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.

General Ann Dunwoody is Joining Automattic! 🤩

"Don’t surround yourself with only people that think or act or look like you." - General Ann Dunwoody

I’m excited that General Dunwoody is joining the Automattic board: not just for the new perspective to help bring different ideas, but also for how important diversity is to her.

Personally, I’ve found that my work is only improved when I’m working with a diverse group of people, who don’t think, or act, or look like… well, me! The tech industry as a whole suffers from a myopic lack of diversity: if Automattic can help improve that, then I’m proud to play my part.

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. 🎉

Introducing: Click Sync

Photo of a link visited status syncing between two computers

Chrome’s syncing is pretty magical: you can see your browsing history from your phone, tablet, and computers, all in one place. When you install Chrome on a new computer, it automatically downloads your extensions. You can see your bookmarks everywhere, it even lets you open a tab from another device.

There’s one thing that’s always bugged me, however. When you click a link, it turns purple, as all visited links should. But it doesn’t turn purple on your other devices. Google have had this bug on their radar for ages, but it hasn’t made much progress. There’s already an extension that kind of fixes this, but it works by hashing every URL you visit and sending them to a server run by the extension author: not something I’m particularly comfortable with.

And so, I wrote Click Sync!

When you click a link, it’ll use Chrome’s inbuilt sync service to tell all your other computers to mark it as visited. If you like watching videos of links turn purple without being clicked, I have just the thing for you:

While you’re thinking about how Chrome syncs between all your devices, it’s good to setup a Chrome Passphrase, if you haven’t already. This encrypts your personal data before it passes through Google’s servers.

Unfortunately, Chrome mobile doesn’t support extensions, so this is only good for syncing between computers. If you run into any bugs, head on over the Click Sync repository, and let me know!

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.

Curing a Critical Security Bug

A WordCamp US this year, I spoke about the Trojan Emoji security bug, which we fixed in WordPress 4.1.2.

In particular, I went through how we came to wrap our head around the bug, and then write a solution that worked for every WordPress site.

Replacing Rdio

I guess we’ve all heard of the impending demise of Rdio.

As one of the 500k subscribers with good taste in their streaming apps, it’s now time to consider a replacement. Here are my criteria – some of them may vary for you, but it’ll hopefully give you an idea for how you can choose, too.

Must Have

  • Offline sync to mobile (I listen to music when I’m flying a lot)
  • Ability to play from my Mac (I listen when I’m working)
  • Ability to play on Sonos (the rest of my house)
  • Family accounts

Should Have

  • Desktop App (I kill my browser pretty regularly, I don’t want that to interfere with my music)

Nice To Have

  • Android Auto support (I don’t have an Android Auto device, but I’m likely to buy one in the near future)
  • Account sharing instead of family accounts (it’s cheaper, and my wife and I mostly don’t use the account in different locations at the same time)

Given that the death of Rdio was most likely due to its lack of market share, I decided to only go with major players – this quickly narrowed it down to Google Play Music, Apple Music, and Spotify.

Google Play Music

Out of the box, Google Play Music does okay – it has an excellent selection of music, the mobile app isn’t terrible, and it works on Sonos. YouTube Red is supposed to be pretty nice, too, but it’s currently not available in Australia.

It falls down heavily when using it on my desktop, though. There’s a Chrome extension to hook into my keyboard media buttons, or there are third party apps available, none of which are very good.

Finally, it becomes completely unusable to share with my wife – I obviously can’t sign into my Google account on her phone, and Google still don’t have family accounts (though they have been announce as “coming soon”).

Apple Music

I’ve never had a good relationship with iTunes – it’s always been a clunky beast, and my recent experiments seem to indicate that not much has changed, except for a re-skin of some of the UI. It feels really hacked together. It is a native app, though, so it wins points by not being associated with my browser.

The family account was super janky to setup, I found the UI kept dying on me. Eventually I got through, however, and I hopefully will never need to touch that again (famous last words…).

On the bright side, the Apple Music app for Android is really nice, despite being a recent beta release. There’s no word on if it supports Android Auto, but that’s not an immediate requirement for me, so I’m happy to let it go.

Spotify

Spotify’s biggest benefit is that it’s not attached to a personal account. Unlike with Google or Apple, my wife and I could share the same account, without needing to share our personal logins. It’s cheating the system slightly, but it’d save us $6/month, so I’m not too concerned about it.

Spotify’s apps have been severely ugly in the past, but the good news is that the Android app is much more useable now. Unfortunately, I was unable to try out the OSX app, because the downloader was broken. The web app requires Adobe Flash, which is a total non-starter.

Conclusion

In the end, I chose Apple Music, for two reasons. One, it was the only one with a desktop app that actually worked. And two, it’s the only service that I can play Taylor Swift’s 1989 on. If the other services can’t get their act together enough to negotiate for a popular album to be on their service, then I’m concerned about their future ability to do so.

I may end up needing to re-evaluate this decision, particularly if the Sonos support doesn’t happen before Rdio finally closes it’s doors (I’m maintaining my Rdio account just for that). But for now, this will do.