Advertisement
  1. Code
  2. WordPress
  3. Theme Development

Looking Ahead to 2019: WordPress in the Year to Come

Scroll to top

What a year! At the end of 2017, I remember thinking that the previous year had been one of the biggest when it came to change in WordPress. But I didn't know what was in store for 2018!

2018 has seen some of the most fundamental and farthest-reaching changes in WordPress since its inception, embodied by the Gutenberg plugin (and the row over it).

But in my view, it's not Gutenberg that will dominate 2019—it's the changes it heralds.

So let's take a look at what 2019 might have in store for WordPress and its community of users and developers.

The WordPress Codebase

Gutenberg represents the beginning of a fundamental shift in the WordPress codebase.

Remember Matt Mullenweg's State of the Word 2015 (yes, it was that long ago), when he told everyone to "learn JavaScript, deeply"?

slide from State of the Word 2015 - learn JavaScript deeplyslide from State of the Word 2015 - learn JavaScript deeplyslide from State of the Word 2015 - learn JavaScript deeply

Well, now is the time when those people who listened to him will be glad they did. And it's also the time when the WordPress community is augmented by people who already have JavaScript and other front-end language skills, and can now use those with WordPress.

Gutenberg is based on blocks. And those blocks are written in JavaScript. If you've ever written a plugin that adds a meta box to the post editing screen, you'll now be better off adding a block instead. And to do that, you'll need to learn not PHP, but JavaScript.

The same goes for theme developers—you might not need to learn JavaScript just yet, but you'll probably have to update your themes so that they style the blocks output by Gutenberg instead of what the old editor output.

And blocks aren't going to be confined to the post and page editing screen. Oh no.

Phase 2 of Gutenberg will take blocks outside the post editor and implement them elsewhere in the WordPress admin. Widgets, menus and the customizer: you name it, it's going to use blocks. The ambition is to turn WordPress into a WYSIWYG page builder-type CMS, but without the code bloat of most page builders.

Here's what the WordPress customizer could look like:

The proposed WordPress WYSISYG interfaceThe proposed WordPress WYSISYG interfaceThe proposed WordPress WYSISYG interface

It's an ambitious goal, and one that will revolutionize WordPress both for users and developers. For users, it will mean a new, streamlined interface that feels more twenty-first century. For developers, it will mean learning JavaScript. Yes, deeply.

So what will all this mean for the WordPress community?

The WordPress Community

The WordPress community isn't really one entity. What most of those of us who go to WordCamps see as the community is really the community of developers. But there's a vast, and far less homogenous, community of WordPress users out there, with very different needs.

WordPress users don't tend to align themselves with the WordPress community, but instead with their own tribe, which will include a lot of WordPress users working in the same space. I'm part of one of these communities: the writer community. In that community, reactions to Gutenberg have been mixed. People often react badly to major changes, and right now the focus is on bugs and sites that have broken.

But over time, I think WordPress users will be well served by the changes. Maybe not by Gutenberg itself, as it's too close to the old editing experience to feel like anything more than a bolt-on, but by the planned WYSIWYG and Customizer changes.

The new user interface, as it develops and matures, will attract users who've previously used site builders like Wix and like to see what they're doing on their site while they're doing it.

As long as the accessibility issues are ironed out (more of which shortly), this could herald the beginning of a period of rapid growth for WordPress. Although I expect some users who preferred the old system will drop off along the way.

But what about developers?

It seems that the developer community is feeling sore right now. With the row over Gutenberg (especially accessibility and the short notice release), there's a feeling that the community isn't being listened to. That WordPress is serving the needs of WordPress.com rather than its community of users and developers.

This is a concern that Automattic shouldn't shrug off. Open source isn't just about the codebase and the license: it's about the ethos of a project too. True open-source projects aren't top-down. They're democratic, consultative projects that take into account a wide variety of groups and aren't driven by the needs of a commercial entity like Automattic.

Automattic, and Matt Mullenweg, have faced criticisms before. They've responded to them and built bridges. And I believe they can do so again. The future of WordPress and its community is too important for us all to fall out.

On a more positive note, the switch towards JavaScript offers plenty of opportunities. It's already bringing new people and new skills into the community. It will mean that WordPress developers are keeping up with developments in one of the most dynamic and evolving languages in web development. And WordPress developers who learn JavaScript will have access to more and better-paid jobs.

Accessibility

The issue of accessibility deserves a mention of its own. Aside from the disagreements over release dates (which no one will ever be happy with), the biggest argument over Gutenberg has been about accessibility.

For years, accessibility wasn't fundamental to WordPress. There was no accessibility team, and most of us learned about the subject from developers who weren't part of the core WordPress team, but who worked in the accessibility sphere or who were passionate about it.

But in recent years that's changed. WordPress has an accessibility team, new releases are audited for accessibility before they ship, and accessibility is always a hot topic at WordCamps.

However, this progress has reversed with Gutenberg. Accessibility is a challenge common to many JavaScript-based, visual tools. They're designed for people who can see what's on the screen and interact with it using a mouse. There would be no S in WYSIWYG otherwise.

But systems designed for visual use aren't designed for accessibility. Many web users with disabilities turn off JavaScript in their browser because it makes pages difficult to interact with. And the blocks system wasn't designed with accessibility in mind.

The issue became so dire that the WordPress accessibility lead, Rian Rietveld, resigned, citing "so many accessibility issues that most testers refused to look at Gutenberg again".

The feedback the accessibility team were given was that they should have explained why accessibility tickets were important when they raised them. This saddens me, as my expectation is that WordPress developers understand why accessibility fixes are important without having to be repeatedly told. It seems that another issue is that the accessibility team didn't have a skilled React developer who could interact with the Gutenberg code. If accessibility is important to WordPress's future, as it must be, then providing React developers to the accessibility team should be just as important as providing them to the core team.

This argument continues to rage on. Some say that Matt Mullenweg's response is inadequate, but Automattic has now agreed to fund an accessibility audit of Gutenberg. What remains to be seen is how this will affect the code for Gutenberg Phase 2. Hopefully, the core team will learn from this and ensure that accessibility is baked into the codebase from the outset, rather than tacked on at the end.

WordPress has millions of users around the world, and a significant proportion of them will have accessibility needs. If WordPress is going to continue to meet their needs (and demonstrate that it values all web users), then I hope this will mean an improvement in WordPress accessibility. If the lessons aren't learned, it could be a disaster.

Summary: My Predictions

To sum up, what do I think will be the key events, developments, and challenges for WordPress in 2019?

Here are my predictions:

  • The Gutenberg row will blow over as patches are released and it becomes more stable. Users will become accustomed to the new system and start to appreciate its merits.
  • Blocks will become more important, extending beyond the page editing screen.
  • People more accustomed to page builders will come over to WordPress, increasing its user base.
  • The accessibility lessons of 2018 will either be learned, meaning future releases will have accessibility baked into them... or they won't, in which case WordPress will gradually become the least accessible open-source CMS out there. Let's hope they will.
  • PHP skills will become less important, and the ability to code in JavaScript and all its incarnations will become an essential part of a WordPress developer's toolkit.

In a year from now, I hope to revisit this post and see what I got right. In the meantime, I wish you a very happy 2019!

Advertisement
Did you find this post useful?
Want a weekly email summary?
Subscribe below and we’ll send you a weekly email summary of all new Code tutorials. Never miss out on learning about the next big thing.
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.