Matt Mullenweg took the stage once again for his annual “State of the Word” talk at WordCamp US in a packed room of over 1,500 attendees.
Matt started by “reintroducing WordPress” and the four freedoms, stressing that “WordPress isn’t a physical thing or code, it’s an idea.” Additionally, a “robust commercial ecosystem” supports WordPress, and Matt noted that current estimates indicate WordPress generates about $10 Billion (USD) annually.
After two years of development and just after WordPress 5.0 officially launched, it’s not surprising the focus of Matt’s talk was on Gutenberg. “We’ve gotten a lot of questions about why we are doing certain things… why we are working on Gutenberg. And it’s good to return to users to find that,” Matt acknowledged.
Enhancing editor usability
A video of new WordPress users testing the classic editor (WordPress 4.9) was shown projected on the big screens over the stage. These clips primarily showed people having difficulties with relatively simple tasks in the editor.
Matt’s point was that we’ve become accustomed to the custom editor’s quirks, but blocks offer a better experience — from copying and pasting from Microsoft Word and Google Docs into WordPress to quickly creating a responsive website.
Community Gutenberg adoption
Matt continued with a summary of how Gutenberg has performed in Phase 1 of its release. Before the WordPress 5.0 release, 1.2 million active installs and 1.2 million posts were published, with about 39,000 posts written daily. Phase 1 had 8,684 commits and over 340 contributors. The ‘Gutenberg’ tag is already available for plugins in the WordPress repo, and it will be “coming soon” for themes.
Notably, over 100 Gutenberg themes are already present in the WordPress repo — including the new Twenty Nineteen theme. Matt highlighted two websites — The Indigo Mill and Lumina Solar — as examples where Gutenberg blocks have been used well to create effective layouts. Matt riffed on the “Learn JavaScript Deeply” mantra by repeating “Learn Blocks Deeply.” Blocks are the DNA of the new editor. Currently, 70 native blocks and over 100 third-party blocks exist for Gutenberg.
Community Gutenberg development
He highlighted some of the third party blocks in the wild:
- Yoast SEO
- 360 Image
- Google AMP w/ Gutenberg Integration
- Drop It
- Ecwid Ecommerce Shopping Cart
- WooCommerce Products Block
- BigCommerce
- Recipe Card Blocks
- Tarot
- Sketch Block
- Jetpack Form Block
- Guidepost
- Ghost Writing
- Spoiler Alert
- Caxton Shape Divider Block
Matt mentioned several block libraries and frameworks that have appeared:
Mobile Apps
Matt gave the audience an update regarding the WordPress native mobile apps: In the past month, app users published 1.3M posts and uploaded 3.1M photos and videos. Gutenberg will be going into the mobile apps, with a beta release expected in February 2019; I heard February 22nd is the current target date for a beta release.
The Next Phases of Gutenberg
Matt highlighted the next phases of Gutenberg’s evolution, which included new information about Phases Three and Four:
Phase One
Fundamental blocks for writing and editing in the backend editor. These are complete now, although Matt later said that work on the editor would continue.
Phase Two
Customizing outside of the page/post content will be the next point of emphasis. It may include widgets, menus, and miscellaneous content. Matt notes that menus “will need a bit more experimentation”. “2019”.
Phase Three
Collaboration, multi-user editing in Gutenberg, and workflows. The target for this to phase to be complete is “2020+.”
Phase Four
“An official way” for WordPress to support multilingual sites. Also slated for “2020+.”
Other Announcements
There were several non-Gutenberg tidbits of note:
Auto updates on major versions of WordPress
On a list of items to work on in 2019, Matt said he wanted to make it a goal to add optional auto-updates for plugins, themes, and major versions of WordPress.
Updated minimum PHP versions
A proposal written by Gary Pendergast makes a case for WordPress to start updating its minimum PHP versions. The proposed plan is to move to PHP 5.6 by April 2019 and to PHP 7.0 by “as early as” December 2019. Notably, security support for PHP 5.6 expires in a few days, and the “end of life” for PHP 7.0 just passed.
After Matt mentioned this proposal, it received an enormous amount of applause — far more applause than most of the Gutenberg news that came earlier, and Matt noticed. It is definitely welcome news!
WordPress release adoption
During the life of the WordPress 4.9 branch, there were over 173 million downloads with 68.4% of all known WordPress installs running 4.9.
Matt notes that the early adoption numbers for WordPress 5.0 were very similar to WordPress 4.7, which was also a December release back in 2016.
Lessons learned in 2018
Matt took time to summarize the lessons he learned in 2018, starting with the need for teams to improve how they work together: “There should be no reason for accessibility, testing, and other teams not to be working together since these features should be a feature of everything we develop from the very beginning.” No doubt this came as a response to the concerns about accessibility in Gutenberg that surfaced before WordPress 5.0 was released.
Community Update
Matt offered some community-related data as well:
- WordCamps: In 2018 there were 145 WordCamps in 48 countries, with over 45,000 tickets sold. A total of 1,300 organizers (a 33% increase!), 2,651 speakers, and 1,175 sponsors made it all possible.
- Meetups: This year saw 50% member growth in meetup attendance, with over 687 meetup groups and 5,400 meetup events.
And with that, he began Q&A.
You can view the State of the Word on YouTube in full, and it should become available on WordPress TV very soon.
Photos by Brian Richards, for Post Status.
Featured WordPress Job Openings
Remote Position 
Matt is correct that accessibility needs to be baked into every team. But in order for that to happen, the accessibility team cannot be expected to keep bailing the other teams out. Those teams need to learn accessibility deeply, before JS, before blocks, and they need to learn HTML and CSS deeply before JS and blocks as well. Learning these two foundational languages, as well as the basics of accessibility, (WCAG and how to look things up and what questions to ask), are absolutely crucial to baking accessibility in everywhere. What’s also crucial is that Matt put his full weight behind advocating for accessibility as a priority within the project, and yes, admitting mistakes. What would have gone a long way, for me at least, would have been Matt admitting during the state of the word that he did not realize the extent of the challenge of making a complex app like Gutenberg useable by everyone, and that as a result of this, resourcing an intensive task like that among his staff was something he did not know how to address, followed by at least a rough outline of an action plan to mitigate the issues. I’ll go ahead and note that admitting you didn’t realize the extent of the challenge is perfectly OK and there is no shame in that, because making an app as complex as Gutenberg useable by everyone, without compromising useability for anyone whenever possible, is indeed a challenge, and it calls for more than just trite statements like “don’t use custom UI elements”, “Accessibility is easy”, or any of the other talking points that get thrown around and are applicable to basic websites. Given Gutenberg’s development cycle, it also calls for not resourcing with volunteers. What also would have been very helpful would have been phase two being allocated to fix the accessibility problems already present, because fixing those and establishing an accessible framework upon which to build, combined with appropriate training among at least Matt’s allocated staff, is critical before Gutenberg can move forward as an accessible product. It’s one thing to patch ten year old PHP code to fix accessibility. JS is an entirely different ball of wax, React is yet another ball of wax, and Matt cannot expect that he’s going to find enough volunteers with the required expertise to fix what’s broken. JS experts who are also accessibility experts are already in very short supply across the industry, and it takes years to get to that point, not just “hey I picked up a React course and spent six months on it and now I’m an expert”. Expecting any of the maybe ten, definitely five, React experts who are also accessibility experts to give away what it took them years to attain for free is laughable, however much it aligns with the unwritten open source principle of free work that everyone gets to benefit from. Finally, it would be super helpful if Matt would quit trolling accessibility experts as well as accessibility team members, because believe it or not, we’re all trying to help him and save him a lot of pain. Granted, now that he’s in a situation where accessibility must be remediated, (since it wasn’t considered from the start of this process), there’s going to be a lot more pain involved. Yeah, there’s a reason we tell you to build in accessibility at the process level and culture level and design level from the ground up, before you even touch a line of code. Matt needs to be honest about all of this instead of continuing to wrap it in political talking points. He needs to be honest about where he and WordPress actually are, instead of claiming to be somewhere else, only for that claim to be provably false. I can’t speak for anyone else, but if I start seeing some honesty and straight talk with regard to all this, I will be the first person to go to bat for him, and I’ve gotten into more than my fair share of scraps with accessibility experts over WordPress. But there has to be honesty and transparency and the trolling has to stop.