One of the goals for Gutenberg Phase 2 is a new navigation menu block. There’s already been a lot of thought and discussion on this, which I wanted to gather into one location so it’s easier to review and compare all the options.
Early concepts
There are a number of early explorations on the GitHub thread:
WordCamp US contributor day
At the WordCamp US contributor day, a group got together and started thinking through a navigation block:
As y’all might remember, I’m currently co-leading the release of WordPress 4.9. Since we’re winding down toward release, I wanted to take the opportunity to walk through some of the key features of the release.
Drafting and scheduling changes in the Customizer
This slideshow requires JavaScript.
In WordPress 4.9, you’ll be able to draft your customizations before publishing them, or schedule them to go live in the future.
Imagine you’ve just started a new site — you have an introduction post up, but otherwise you’re still working on finishing up the design of your site. Now you can draft your changes and come back to them later, so when you are ready to go live, your site looks perfect.
Another scenario: let’s say your store is having a holiday sale. Rather than staying up until midnight to add a banner about the sale to your homepage, now you can add that new section to your homepage and schedule it to go live later. Once the sale is live, you can hop back in and schedule it’s removal after the holidays. Much less of a hassle!
Additionally, these new features includes a quick way to share a link to preview your changes on the front-end that anyone can view, not just your site users. Now you can easily share your design updates with clients and teammates before publishing them.
We’ve also made it safer to make changes in the Customizer. We’ve introduced “locking” (like post locking), so two people can’t work on the same changes at once. This prevents people from overwriting each other’s updates. Hurrah!
Finally, if you leave the Customizer with unsaved changes, when you come back you’re presented with the option of restoring those changes, which autosaved. Harder to lose your work. ?
A unified theme browsing experience
This slideshow requires JavaScript.
Since the WordPress 4.2 release, you’ve been able to browse and preview your installed themes from within the Customizer, so you can try a bunch of themes before committing to one. 4.9 iterates and expands on this work. Now, you can also search, filter, and browse themes from the WordPress.org theme directory directly from the Customizer. This means once you start setting up your site, you won’t have to leave the Customizer when trying to find the perfect theme. It’s just one step closer to a completely comprehensive, Customizer-driven site building experience.
Once you find a new theme you like, switching to that theme has become even easier. Previously, when switching themes, your menus and widgets had a bad habit of coming unassigned, so you’d have to go back and re-add them to your site. We’ve added some improvements to menus and widgets so you can feel even more comfortable with trying out a new look.
Widget Improvements
Following up on the Image, Video, and Audio widgets we created in WordPress 4.8, we’re introducing a Gallery widget in 4.9. Secondly, you can now add media directly to your Text widgets for mixed-media content.
Both of these improvements bring us closer to converging with Gutenbergfeatures — it’ll be much easier to migrate widgets to blocks in the future.
Menu improvements
In usability testing, we’ve consistently found that people struggle with creating menus and adding new pages to their menus in the Customizer. I’ve watched easily a dozen tests in which someone went to “Add new menu,” hoping it would let them add a new page to their menu (rather than creating an entirely new menu to put on their site). It wasn’t intuitive.
Coming in 4.9 is a new flow for creating menus in the Customizer, focusing on splitting up tasks into more manageable chunks and clear, friendly instructions. I worked with our local Happiness Engineers and Editorial team to simplify and clear up confusion around the specific interactions. Team work made the dream work, y’all.
For example, syntax highlighting and error checking have been added to:
The native WordPress plugin and theme editors
The “Additional CSS” panel in the Customizer
The Custom HTML widget, introduced in 4.8.1
Of these, my favorite is definitely the improvements to Additional CSS. Most of the sites I build nowadays use existing themes, so I don’t need to do a bunch of custom coding, but I always want to tweak the design a bit. We’ve had syntax highlighting for a while on WordPress.com, but now I’ll finally be able to use this on my self-hosted sites, too. We’ve also added autocompletion, which makes writing CSS even faster!
We’ve also made it MUCH safer to make edits in the theme/plugin code editors. We also warn folk before entering the theme/plugin code editors now that you can mess up your site, and make folks click an “I Understand” button before proceeding. And now, if you leave out a semicolon or call an undefined function, instead of white-screening your site, we catch the error and stop you from saving until you fix it.
Keep an eye out for WordPress 4.9, launching November 14th! And remember, always keep your WordPress sites up-to-date. ?
I’m lucky that Automattic sponsors my time to work on the core WordPress software full-time. This allows me the time and focus to take on more leadership responsibilities in the community, including my current role as Customization Design Lead and the co-lead for the upcoming WordPress 4.9 release. ✌️
One of our major goals during the 4.9 development cycle is to improve the various code editing portions of WordPress: the code editor for plugins and themes, the CSS editor in the Customizer, and the new HTML widget.
The current editors in WordPress
This is a controversial decision. Many people believe that WordPress should remove code editing, for many good reasons! At the very least, the theme and plugin code editors make it very easy to break your site. If you don’t backup your site regularly, this can be anything from a couple minute inconvenience to a catastrophe. ?
I’m of two minds: that yes, we either need to remove the editors entirely, or… we need to make them better, and safer for people to use.
After reflecting, my co-lead and I decided that making them better and safer can have more of a positive impact. WordPress has been a gateway for many new web designers, developers, and builders on the web. I’ve personally met dozens of people who became web professionals because they worked on a WordPress website, and poked around on it for a while. Seeing your site’s source code is, in my opinion, an integral part of this process.
There’s many ways we can improve the editors:
Add syntax highlighting, so it becomes easier to read and write code in the editors.
Introduce warnings that inform people that editing the code can break their site.
Encourage folks to learn about version control, backups, and safe editing of their site’s code.
Redirect people who just want to update CSS to the Additional CSS section of the Customizer.
By improving the editors and introducing better warnings, and even code linting, we’re creating a teachable moment for new web users. By providing some protection against saving broken code, we’re helping folks safely edit their sites — versus now, where you can just save anything and totally whitescreen your site (which I’ve done before ?).
One of my biggest breakthrough moments in WordPress was learning how to create a child theme, which allowed me to safely edit themes to my client’s specifications. Suddenly, I had much more control over the site I was building. It felt magical! The code editors seem like the perfect place to introduce this concept, and maybe even create a simple way to make a child theme from WordPress itself.
Coming in 4.9: syntax highlighting in the code editors in WordPress
I see these various improvements as a way to encourage WordPress users to grow into developers. Creating an ecosystem that supports teaching new developers is an important part of WordPress’ influence on the web, and only through providing a way to safely play can we hope to grow. ?
Interested in helping out? You can get involved on GitHub.
Recently, I’ve been starting to look at converting widgets in WordPress to Gutenberg blocks. Widgets are the bits of content you can currently drop into your sidebar or footer in WordPress — like the recently updated image widget, some text, or a search bar.
Current Widget Panel in the WordPress Customizer
Updating some of these widgets to use Gutenberg’s block patterns has been quite easy — they are simple blocks of content without a lot of settings. However, some widgets are quite complex. Turning them into blocks has been a challenge.
Take, for example, the Categories widget. It creates a list of all your post categories, and links to the archive pages for those categories. It’s very useful for the large number of bloggers who organize the blog posts on their site using categories. The Categories widget comes with a couple options:
Display categories in a dropdown, instead of a list.
Display the number of posts in each category.
Display category hierarchy, if you have parent and child categories on your blog.
The widget settings work well in the “Inspector” on the right, while the block itself is previewed inside of your post or page editor (and eventually your whole site).
Not all widgets are this easy to turn into blocks. Let’s take a look at Recent Posts widget, which shows a list of your most recently published posts. At first, it seems just as simple as the Category widget, right? Well, what if we took this opportunity to improve the widget while we turn it into a block?
Currently, you can control the numbers of posts listed in the Recent Posts widget, and you can choose to display post dates. That seems like a good start for a sidebar, but what if you wanted to show a list of posts on your homepage? You’ll probably want to show more details about the post.
Looking at popular blogging websites and themes, many include the post’s featured image, and either an excerpt, or the content of the whole post. Let’s add that to our list.
Many sites and themes also show posts as a grid, not a list. What if we gave folks the option of choosing between a list or a grid layout? If we support grids, we’ll likely also want to let people choose how the maximum number of columns in which to display their posts on larger screens.
Now, our feature list looks like this:
List view or grid view
Number of posts to show
Columns (only if grid view)
Display date
Display featured image
Featured image size (taken from your site settings)
However, the block is still mostly controlled through a list of options in the Inspector. What about a block that you need to build, like the Custom Menu widget?
At its most basic, this could be a simple block. The widget is pretty simple: just choose an existing menu from a dropdown, and it displays that menu in your widget. This isn’t great, though, since you need to know to make the menu first. It’s a pain and it breaks your flow.
In a future where all of the navigation menus on your site are blocks, it seems more important to let you actually build that menu where you’re adding a block. We don’t have any established patterns for a task like menu-building yet, so we need to establish some.
Core contributor Joshua Wold kicked off the brainstorming with a great sketch:
Within the block, you can choose an existing menu, or create a new menu. If you choose to create a new menu, you can drag pages over from the Inspector (or click on them) into the block to build your menu. This is similar to how menus currently work in the Customizer.
Another direction we can take is cutting out the confusion of duplicate menus, and building the block to make one-off menus instead. That could look something like this:
This block is still being explored. If you have ideas, you can post them on the GitHub issue! We’d love to see more folks involved in shaping the future of WordPress.
I hope, by tackling the hard widgets (and shortcodes!) now, we’ll establish all the key patterns and lead the way for other plugins and themes to convert their custom widgets into blocks. I’d like to help create an ecosystem where page builder builders and premium themes can continue to flourish, while remaining consistent and compatible with core WordPress design patterns. Hopefully we’re off to a good start! ?
Thanks to Joen and Tammie for their ongoing support and feedback as I explore these new block designs!
