The team’s designs for a navigation block are still in the rough sketches stage, but it’s interesting to see different approaches as the project develops.
“If the Nav block could live in a container block (columns perhaps), then the settings for it could be tweaked in the sidebar,” XWP designer Joshua Wold said. “A further problem comes up when you try to figure out how much of the design of the nav should be controlled by the theme vs the Gutenberg editor.”
This is an important question that will need to be answered in the near future – not only for navigation but also more broadly for the future of the role of themes in WordPress. We will be exploring this in more depth in future posts.
Designer Mel Choyce and Riad Benguella (one of the leads for Gutenberg phase 2), are currently soliciting ideas from the wider WordPress community about how the project should tackle the upcoming customization focus.
One of the chief complaints about the first phase of the Gutenberg project was the lack of public discussion about the goals and the process of creating the editor. The Gutenberg team’s willingness to collate ideas across multiple mediums demonstrates a strong effort to seek out more diverse perspectives for phase 2. Ideas have already started rolling in.
“Rather than starting with the back-end UI, we can start with the front-end result and build a UI to make the building of that front-end possible without messing up the accessibility and resilience of the root HTML document,” Morten Rand-Hendricksen said. “At the root of this would be CSS Grid as the main layout module to allow drag-and-drop style block layouts without making changes to the HTML source order.”
WordPress 5.0.2, the of first of two rapid releases following 5.0, is now available. Sites with automatic background updates enabled should already be on the latest version.
This release addresses performance issues, one of the chief complaints for users who have adopted the block editor. It brings 45 improvements to the editor, with 14 of those related to performance and 31 bug fixes. According to Gary Pendergast, “the cumulated performance gains make it 330% faster for a post with 200 blocks.”
This maintenance release also fixes 17 editor-related bugs in the default WordPress themes as well as internationalization issues related to script loading.
Overall, 5.0.2 updates have gone smoothly, with the exception of a few conflicts with a handful of plugins. Most notably, WooCommerce store administrators found that the Orders tab had disappeared after their sites updated. WooCommerce has fixed the issue in a quick patch release (version 3.5.3) that was pushed out this morning.
NextGEN Gallery creator Erick Danzer also reported a minor issue with the Classic block that prevents users from editing galleries via the placeholder the plugin had added. A fix for that issue should be forthcoming in an update to the plugin.
XWP’s Gutenberg-inspired Jenga sets were arguably the most innovative swag at WordCamp US this year, but there weren’t enough to go around. Gutenblox, fondly dubbed “the Other Block Building Interface,” is now available on its own website where anyone can buy a set.
Blocks treat Paragraphs, Headings, Media, etc. all as components that strung together make up the tower. Replacing the traditional concept of board games, Gutenblox is designed with progressive enhancement, meaning as new blocks are added to the top of the tower, they are backward compatible with all legacy content (although the legacy structure may become unstable as new blocks are added on).
We hope to offer rich value to players who will start with the foundation of a stable, accessible, and secure architecture, and then use a simple drag-and-drop method for modification.
If you’re looking for a last-minute holiday gift or birthday gift for a friend who loves WordPress, Gutenblox is fun option. It also helps support a good cause. XWP is donating all profits from the sales of the game to the WordPress Foundation.
At WordCamp US 2018 I had the chance to sit down with Jason Bahl and Ryan Kanner, both engineers at Digital First Media in Denver, Colorado, and contributors to the WPGraphQL project. WPGraphQL is an open source plugin that provides an extendable GraphQL schema and API for any WordPress site.
Bahl, who created and maintains the project, also gave a lightning talk at WCUS on using GraphQL with Gutenberg to improve the performance of custom blocks, as well as the developer experience of building them.
In our interview, Bahl and Kanner offer a general overview of the differences between GraphQL and REST. They explained how Digital First Media improved performance for the company’s publications by switching from REST to GraphQL. We also discussed how Gutenberg is a great use case for GraphQL and whether the project is something that could someday be included in WordPress core.
For years, WordPress has been ever-so-slightly behind the times on PHP version support…to put it kindly.
However, WordPress’ legendary support for PHP versions back to 5.2 — versions long unsupported by the PHP project itself — wasn’t born out of a “we hate developers” strategy (although you’d be forgiven for thinking so given the reaction that policy often gets from developers). Instead, it was a genuinely noble and pragmatic effort to make WordPress, and thus publishing on the web, as widely available as possible.
But the winds of progress are blowing, and in 2019 WordPress is planning to make a change. Assuming everything goes according to plan, PHP 5.6 will become the minimum supported version in the first half of the year, and the minimum version will be bumped again to PHP 7 in the second half of 2019.
There are obvious benefits here from a security perspective. The oldest versions of PHP supported by WordPress today stopped receiving official security updates ages ago (PHP 5.2 hit EOL, or “end-of-life,” nearly 8 years ago). The speed improvements will be tremendous as well, particularly in PHP 7. Speaking from my own experience, I have several sites that once needed aggressive caching to prevent server overload. Since PHP 7, they run faster than ever, without caching of any kind.
Speed and security are the two most-cited reasons (and the most measurable reasons) for bumping the minimum version, but there are also other less tangible benefits that will filter well beyond WordPress core development.
While plugin developers have never been obligated to support all the versions of PHP that WordPress core does, many still chose to do so. That’s understandable: it could be tough to explain to a user why they can install WordPress in a certain development environment but couldn’t install a certain plugin.
For plugins that tried to match core’s backward compatibility support, that means testing and supporting up to nine versions of PHP: 5.2 through 5.6, and 7.0 through 7.3. (There was no PHP 6. I won’t bother explaining the boring reasons why.)
By pushing to 5.6, and eventually some version of PHP 7+, that cuts the number of versions that developers will feel compelled to support in half. In some way, Core will likely continue to support these old versions (through security backports to old versions of WordPress, for instance) but plugin developers can be assured that they don’t need to — and don’t need to feel any semblance of guilt about it either.
Bumping the minimum version won’t change that apathy or exodus overnight, but it will give developers something to feel excited about. Modern PHP versions (especially PHP 7) offer genuinely cool new language features that make it easy to write performant, well-designed, and interesting code. I would even argue that it makes it fun. Modern PHP contains plenty of syntactic sugar, and while you shouldn’t base your diet on sugar it certainly makes for a nice treat.
Again, it is unlikely that core will start adopting these new language features on day one. The real benefit is that developers will feel empowered and secure in their decisions to start using these new capabilities, and will start to build plugins and themes that can borrow ideas from best practices in the broader PHP community.
Celebrating the intangible
While the measurable justifications for changing the minimum PHP version are certainly compelling, I think it’s also important to acknowledge these intangibles and indeed celebrate them. Bumping these versions will create a ripple effect across the ecosystem that will make developers more comfortable with writing modern code. It will reduce support and QA loads for companies that no longer need to support 9 different versions of PHP. It will make WordPress core a more attractive place to contribute.
Gutenberg, and all the modern tooling and architecture it brought, has already reinvigorated developers across the ecosystem and brought a huge number of new core contributors (myself among them). Embracing modern PHP is another step forward, and with other changes on the horizon (such as a move from SVN to Git, coding standards changes, and projects like Tide which embrace new languages and architectures) I hope that 2019 will be the year WordPress delivers not only a best-in-class user experience, but a best-in-class developer experience too.
For a long time I could not compose posts with the Gutenberg editor. I tested each release of the plugin throughout its journey into WordPress 5.0, but found it too distracting for my basic needs. It seemed better suited for building a brochure website, not for someone who uses WordPress primarily for writing.
This is the first thing you see on a vanilla install of WordPress when you go to the “Add New” post page:
Although it may not be immediately evident, the new editor actually has some built-in controls for improving the writing experience. They are tucked away behind the vertical ellipsis menu at the top of the screen. Here’s how to configure Gutenberg for writing:
Step 1: Hide the Settings Sidebar
The first step towards a more distraction-free writing experience is to hide the settings. Click the X at the top right of the screen. If you’re trying to stay in the flow of writing, it’s not necessary to keep the block and document settings in view at all times. You can always toggle them on later when you’re finished getting your thoughts onto the screen.
Step 2: Turn on “Fullscreen Mode”
Many new and experienced WordPress users are not aware of Gutenberg’s “Fullscreen mode” that places the writing area in the center of the page and hides WordPress’ admin menu sidebar. This setting is a must for keeping distractions at bay. You can find it at the top right corner in the vertical ellipsis menu:
Once Fullscreen Mode is enabled, the writing area is greatly improved, with distractions removed from both sides of the content area.
Step 3: Fix the Toolbar to the Top (optional)
The block toolbar popping in and out of view was the bane of my Gutenberg experience until they developed the “Top Toolbar” setting. By default, the block-level toolbar obscures part of the content above it (as seen in the image below) and an obtrusive blue outline follows your mouse as you move over the paragraphs you have already written.
The psychological affect of all these boxes popping in and out of view may be more taxing for some writers, so this step is optional. The “Top Toolbar” setting to hide the block-level toolbar, as well as the blue block outlines, is also inside the vertical ellipsis menu at the top. The best way to see the difference in the experience is to experiment with turning it on and off.
Spotlight mode takes it one step further and greys out all the content except the current block, allowing writers to focus on one block at a time. When it is enabled, the blocks that are not being edited will partially fade away and no block outlines will be visible.
Gutenberg still has a way to go before it can provide a truly distraction-free editing experience. None of the modes highlighted above will hide the metaboxes at the bottom or the menu bar at the top. They do, however, allow you to compose in an area without the block-level toolbar and sidebars getting in the way.
My thoughts don’t always come out in full sentences and paragraphs. Sometimes they are scattered throughout a document in half sentences, single words, quotes, and fragments of quotes that I’m not certain I will use. How do I reconcile this with Gutenberg? Sometimes the Classic Block is a good option for a first draft that looks more like a pile of messy notes than a document of well-formed thoughts. Here’s what that looks like if you have never used it:
Even with these settings available, some writers may still prefer to use a dedicated writing app instead of the WordPress editor. Fortunately, Gutenberg has very good support for copying and pasting from other applications.
Top Toolbar, Spotlight, and Fullscreen modes are not the easiest features to discover but they can make a significant impact on your experience writing in the new editor. WordPress core may never provide a truly distraction-free writing experience, but that’s where the beauty of the plugin system comes into play. It gives developers the opportunity to create new and interesting approaches towards a better default writing experience. I hope to see some of those popping up in the directory as more users adopt Gutenberg.
WordPress 5.0.2 will be the first planned followup release to 5.0 and is now scheduled to be released December 19, 2018. Gary Pendergast posted a summary of this week’s dev chat that includes the schedule and scope for the upcoming release. It will include Gutenberg 4.7, Twenty Nineteen bug fixes, and a few PHP 7.3 compatibility fixes.
Slow performance as compared to the classic editor has been a commonly-reported issue with Gutenberg. The project has a label for it on GitHub with 26 open issues. 140 performance-related issues have already been closed so the team is making progress on speeding it up. 5.0.2 will bring major performance improvements to the editor, particularly for content that includes hundreds of blocks.
“The cumulated performance gains are around 330% faster for a post with 200 blocks,” Matias Ventura said in an update on the editor. “This might be even bigger for certain setups and plugin configurations — seeing the same test post be 540% faster with Yoast, for example.”
These changes are already in version 4.7 of the Gutenberg plugin, which users can run alongside WordPress 5.0.1 to test the latest.
RC 1 for 5.0.2 is planned for today and RC 2 (if necessary) is targeted for December 17. The official release is scheduled for December 19.
Gary Pendergast also outlined the scope and schedule for WordPress 5.1, which will be led by Matt Mullenweg. Pendergast proposed a relatively short release cycle with an official release February 21, since there are already more than 200 tickets fixed for 5.1. Focuses for the release include the REST API (particularly authentication solutions), core JS, and core themes. Beta 1 is planned for January 10, with RC 1 following February 7.
Dates for WordCamp US 2019 were announced today, less than a week after wrapping up a successful camp in Nashville. Unlike all previous years held in December, next year’s event will take place November 1-3 in St. Louis, Missouri.
For the most part, community reactions to the new dates were positive. Early November dates place the event well ahead of the end of the year holidays that attendees had previously bemoaned.
“I love this date set better than the previous one. It’s so much easier to attend/speak pre-Thanksgiving,” WordPress developer Mitch Cantor said.
There is always a conflict for some demographic of attendees. This year the hardest hit are parents of small children who will likely miss taking their kids trick-or-treating due to traveling on or before Halloween in order to make it to the event. WordCamp US is a family-friendly event but bringing children to a WordCamp can be extraordinarily challenging, even when the event includes childcare. (This particular event doesn’t.) For a few attendees, missing Halloween with their children is a deal-breaker.
Exactly what I was thinking. I'd have to fly in on Halloween, no way I'm missing Halloween with my 2 year old.
One possible solution for the parents who feel they have to miss WordCamp US because of their kids, might be for the organizers to schedule the contributor day as the first day of the camp. That might enable people to fly in on an early morning flight and still get to experience part of the contributor day and all of the main event.
In a community this large, with many other holidays and WordCamps already on the calendar, it’s difficult to find a date for WordCamp US that doesn’t have conflicts. This is a good problem for the community to have. Matt Mullenweg shared during the State of the Word that the community has experienced 50% year over year growth with more than 350K members in 687 meetup groups and more than 5,000 meetup events. With this rate of growth, the community can expect more regional and local camps to spring up in the coming years, which means more conflicts but also more options for getting together in the future.
While at WordCamp US, I had the opportunity to catch up with WPCampus director Rachel Cherry, who is coordinating an audit on Gutenberg for the organization she leads. WPCampus launched its crowdfunding campaign at the end of November and more than $10K has come in towards the $30K goal.
The day before WordPress 5.0 was released, WPCampus announced that Automattic has pledged to ensure WPCampus’ accessibility audit of Gutenberg is fully funded.
“I think that they [Automattic] see that it is important,” Cherry said. “Even when they said they weren’t going to do it, I don’t think it was ever ‘We’re never going to;’ it was just ‘Not right now.’ For us, we couldn’t necessarily wait for ‘maybe we’ll do it later,’ so that’s why we jumped on it and got the ball rolling. I think they saw an opportunity where they could step in and have the means to move this along even further. They see the value and I think that’s why they wanted to jump in. They also saw all the community effort going on.”
In the interview below, Cherry discusses how leaders in the WPCampus community rallied to get the audit in motion. The organization has received seven responses from vendors and is currently in the selection process. She also shared a little bit about her conversation with Matt Mullenweg during his community office hours and their discussion about how WordPress is used in higher education.
Cherry’s strategy in advocating for accessibility is to focus on slicing through the confusion surrounding accessibility problems with an emphasis on education and communication. Although WordPress has set accessibility standards, the project has fallen short on enforcing them. In addition to putting automated accessibility testing in place for core, Cherry said she would also like to get more support for helping theme and plugin authors meet accessibility standards. This would help ensure that the code WordPress.org puts on the web is more accessible for those who are creating customized sites.
WordCamp US kicked off in Nashville over the weekend, following the release of WordPress 5.0. In the first 48 hours, 5.0 had been downloaded more than 2.8 million times. It passed 3 million Saturday night.
“There’s been a lot that’s been going on, so I’d like to allow WordPress the chance to re-introduce itself,” Matt Mullenweg said during the preamble of his State of the Word address. He invoked the four freedoms as the project’s constitution and called the community back to its roots.
“It’s the reason we’re here,” Mullenweg said. “WordPress isn’t a physical thing; it’s not a set of code. It’s kind of an idea. WordPress is backed by the full faith and credit of every person and company that depends on it.”
He reiterated the project’s mission to democratize publishing and recast his vision for advancing the open web.
“Like I said a few years ago, we’re building a web operating system, an operating system for the open, independent web and a platform that others can truly build on,” Mullenweg said.
WordPress’ 32.5% market share and its commercial ecosystem, which Mullenweg estimates at $10 billion/year, give the project the resources to make a powerful impact on the future of the web.
Mullenweg Builds a Compelling Case for the Block Editor
Mullenweg drove home the necessity of Gutenberg by showing a selection of videos where new users struggled to accomplish simple tasks in the old editor. Their experiences were accompanied by painful commentary:
“This feels like writing a blog back in 2005.”
“This was very finnicky; this does not work.”
“How would I add a caption? I have no clue.”
Mullenweg described how he used to effortlessly switch back and forth between the visual and HTML editors prior to WordPress 5.0 but realized that not all users are able to do this.
”This has been our editor experience for over a decade now and many of us have learned to deal with it,” he said.
He followed up with a video demonstrating how much easier these tasks are in the new block editor and identified blocks as the way forward for WordPress.
Some attendees commented after the fact on how the user testing videos, paired up against an expert using Gutenberg, seemed unbalanced and they would have liked to see videos of new users attempting the same tasks in the new editor. The goal of that segment, however, seemed to be more aimed at communicating the need for Gutenberg and the possibilities it opens up once users have had the chance to grow into it.
Mullenweg Urges Attendees to “Learn Blocks Deeply”
Millions of early adopters have already embraced the block editor during phase 1 of the Gutenberg project, which closed out with 1.2 million active installs and 1.2 million posts written. There have already been 277 WordCamp talks on Gutenberg, 555 meetup events focused on the new editor, and more than 1,000 blog posts discussing it.
Blocks are taking over the world of WordPress. Version 5.0 shipped with 70 native blocks and there are already more than 100 third-party blocks in existence and 1,000 configurations related to that.
“Blocks are predictable, tactile, and can be simple like a text block, or as rich as an e-commerce interface,” Mullenweg said. He described them as the new DNA of WordPress, from which users can create anything they can imagine.
Mullenweg showcased two sites built using the block editor, the Indigo Mill and Lumina Solar. These beautiful sites open the imagination to what Gutenberg is capable of bringing to websites.
Mullenweg highlighted tools like the create-guten-block toolkit, Block Lab, and Lazy Blocks that are making it easy for developers to create their own blocks. Block collections and libraries are also emerging. He said one of the priorities for 2019 is to build a WordPress.org directory for discovering blocks and a way to seamlessly install them.
Gutenberg Phase 2: Navigation Menu Block, Widget blocks, Theme Content Areas
Mullenweg announced the next phases for the Gutenberg project. Phase 2 has already begun and focuses on site customization, expanding the block interface to other aspects of content management. This includes creating a navigation menu block. Reimagining menus is will be challenging, and Mullenweg said they may even get renamed during the process.
Phase 2 goals also include porting all widgets over to blocks and registering theme content areas in Gutenberg. An early version of phase 2 will be in the Gutenberg plugin so anyone wanting to be part of testing can reactivate it.
During the Q&A time, one attendee asked a question about how this phase seems to include very little about making layout capabilities more robust. He asked if Mullenweg plans to let those the marketplace handle those layout decision or if core will define a layout language. Mullenweg responded that it may be more prudent to see what others in the ecosystem are doing and cherry pick and adopt the best solutions. He also remarked that it would be exciting if users could switch between different page builders in the future and not lose their content.
Gutenberg Phases 3 and 4: Collaboration and Core Support for Multilingual Sites
Mullenweg announced that Gutenberg phase 3, targeted for 2020, will focus on collaboration, multi-user editing, and workflows. Phase 4 (2020+) is aimed at developing an official way for WordPress to support multilingual sites. When asked what that will look like from a technical standpoint, given the many existing solutions already available, Mullenweg said he didn’t want to prescribe anything yet, as it’s still in the experimental stage.
Other major announcements included a highly anticipated bump in the minimum PHP version required for using WordPress. By April 2019, PHP 5.6 will be the minimum PHP version for WordPress, and by December 2019, the requirement will be updated to PHP 7.
WordPress releases are going to come faster in the future, as Gutenberg development has set a new pace for iteration. Mullenweg said he would like WordPress to get to the point where users are not thinking about what version they are on but instead choose a channel where they can easily run betas or the stable version.
Mullenweg Acknowledges Mistakes Made and Lessons Learned in the 5.0 Release Process
WordPress 5.0 was one of the longest and most controversial release cycles in the project’s history. Those outside the inner circle of decision-making endured a great deal of uncertainty, as dates were announced and then missed, with secondary dates thrown out in favor of pushing 5.0 out with just three days’ notice.
“We were scared to announce a new release date after missing our previous one,” Mullenweg said, acknowledging the controversial release date. He said this seemed to create a lot of fear and uncertainty until they announced a new date. The dates seemed to come out of the blue and were stressful for the community.
Mullenweg highlighted the lessons they learned in the process of releasing 5.0:
Need the various teams across WordPress working together better
Importance of triage and code freezes
Always announce release dates
Mullenweg noted that WordPress 5.0’s beta releases were tested 100 times more than other releases, which he said contributed to Gutenberg becoming more robust before landing in 5.0. However, these positives seemed to be overshadowed by several critical breakdowns in communication that many feel betrayed the community’s trust.
He noted that people used the plugin review system as a way to vote on Gutenberg and that perhaps the community needs a different medium for expressing those kinds of things. Users did this because they felt it was one of the only feedback mechanisms where they had a voice. Negative reviews piled on in the early days of the plugin’s development but they continued steadily throughout the feature plugin’s journey into core. After 5.0 was released, negative reviews on the Gutenberg plugin have continued to pour in, and its rating has fallen to 2.2/5 stars.
Growing Pains and a Call for Transparency
Mullenweg said that Gutenberg development happened entirely in the public eye, surfacing many challenges associated with developing open source software in public. The code was public, but the most important decisions were made behind closed doors. This was compounded by the developer community voicing frustrations during core dev chats and on social media.
During the Q&A segment, several audience members called for more transparency in the release process, noting that most of the posts and announcements regarding 5.0 came from Automattic employees. Morten Rand-Hendriksen, who has become somewhat of a community firebrand at WordCamp Q&A’s, received applause for his question regarding the use of the word “we” in connection to posts on the make blogs. He pressed Mullenweg for more insight into where these decisions are made.
Mullenweg said the “we” he meant in regards to 5.0 release dates referred to a private channel where the release leads discussed it. He said with so many people showing up to the dev chats, the discussions became difficult.
“I don’t just go in a cave and come up with these things,” Mullenweg said. “A lot of people were showing up [to dev chats] who had never contributed to WordPress before and were crowding out the discussion of the core team.” He also said the private conversations were “every bit as feisty as the public one,” except there weren’t any drive-by opinions.
To those on the outside, these meetings appeared to be secret, as they were never referenced or summarized on the make blogs. This left the developmer community wondering where these decisions were coming from and whether or not they had a voice.
Gutenberg was developed in public, but too many decisions were made in silos and not clearly communicated. This can be improved for 5.1 and beyond #WCUS
During the Q&A, Mulllenweg said he listened to vigorous discussion and diverse viewpoints from release leads coming from different companies, while gathering as much information as possible from reading reviews, blog posts, and comments from the community. He described this process as part of the art of trying to make sense of all the different things people are saying and balance that.
Supporting a BDFL-led project requires a certain amount of trust that the leadership is listening. Over the past several weeks Mullenweg has made a strong effort to keep the channels of communication open.
The painful user testing videos Mullenweg shared demonstrated how desperately WordPress needed to grow out of its old editor. It isn’t often that core makes changes that affect nearly every corner of the WordPress ecosystem at the same time. This experience came with its fair share of growing pains. Despite communication missteps during the 5.0 release process, Mullenweg has successfully navigated the project through this rocky transition. Although WordCamp US attendees seemed road weary after 5.0, they were united by a shared desire to move forward and continue working together with the leadership that has kept WordPress on the course of growth and improvement for the past 15 years.