Follow Kjell Reigstad’s process as he explores designing a block-driven theme with Sketch, for the Gutenberg era.
There’s been an exciting discussion happening around the changes that Gutenberg will bring to themes. At Automattic, we’ve begun to prepare for Gutenberg by reevaluating our theme design and development processes.
As part of that work, I did some thinking about how I might start designing a block-driven theme today and what sorts of resources I’d want to have. The most important thing that came to mind was a way to access and customize all of the core Gutenberg blocks with a few clicks. This would allow me to quickly test and iterate on block design without having to dig into code. I do a good deal of my design work in Sketch, so I began to search for a way to make this possible there.
Luckily, there are already a few Gutenberg-related Sketch files in the wild. The Gutenberg Contributors page on GitHub and the Design Principles & Vision page on WordPress.org are great places to start. These are mostly aimed at the Gutenberg editing interface, however, and didn’t quite accomplish what I was looking for, so I ended up building a new file instead:
This new Sketch file contains symbols for all of the default Gutenberg blocks (with the exception of all the embeds, since those aren’t very customizable). With this set of symbols, it’s possible to quickly build a layout composed entirely of Gutenberg blocks using Sketch:
It’s actually pretty fun to use! In a way, it’s Gutenberg — but for Sketch. 😄 From here, it’s easy to start customizing styles:
I took this method for a spin and tried to mock up a theme for an imagined restaurant. To get started, I built out the page structure using default Gutenberg blocks:
From there, I started doing some light customizing. I cut myself off after a while, but the end result looked fairly decent:
I find this pretty cool. It’s an example of what a block-driven theme might look like with just a little bit of CSS customization.
From here, I could easily keep going and put together a complete, modular design system for this theme by customizing the rest of the Gutenberg blocks. I could view the blocks all at once on the Symbols page, and quickly build out a wide variety of layout options to make sure my styles held up to intense layout customization.
I almost ended there, but I decided to confront a lingering concern I’ve had about Gutenberg: I’ve feared that if we lean too much on Gutenberg for theme layout, we’ll end up with lots of very similar, “blocky” themes. The restaurant site I designed above looks fine, but it’s also clearly made of blocks. I wondered if it’d be possible to create something more experimental using this same Sketch file as a base.
So I took another stab at a pretend site design (this time for a band named Superserious), and forced myself to break out of the blocks a little more. Again, I began with a pure-Gutenberg layout:
But this time, I was much more aggressive in my customization and aimed for a more tailored mobile experience with bold typography:
This was a fun exercise, and it helped allay my fears a bit. That first Cover Image has all the usual pieces, but they’re styled in a very opinionated way. The rest of the blocks are fairly standard, but they still stand out because they exist within a heavily stylized, off-balance frame. The overall effect is drastically different from the theme in the previous exercise.
This process was very useful for me, and I’d love to see if it’s useful for the rest of the community as well. You can download and contribute to the Sketch files here:
The repository includes a basic Sketch file with just the symbols, plus all the text hierarchy styles (H1, H2, etc). I also created a library file in case that’s preferable for anyone. We hope to update these files periodically, and would love to hear feedback from others who use them.
In the meantime, we’ll keep experimenting with ways to design themes in this new Gutenberg-based future.
The Gutenberg editor uses blocks to create all types of content, replacing a half-dozen inconsistent ways of customizing WordPress, bringing it in line with modern coding standards, and aligning with open web initiatives. These content blocks transform how users, developers, and hosts interact with WordPress to make building rich web content easier and more intuitive, democratizing publishing — and work — for everyone, regardless of technical ability.
The three themes we developed during the meetup are called Fashion Blog, Handicraft, and Ohana. We decided to try to make these themes CSS-only to help keep the focus on Gutenberg itself and let us build on the recent work the team’s been doing with Style Packs. This turned out to be an ambitious restriction — a little more on that later — but it made for an interesting design challenge.
Fashion Blog, Handicraft and Ohana are currently available on GitHub; you can learn more about each theme there and check out exactly how they were set up. The themes are still works in progress and have some rough edges. The end goal is to get them ready for WordPress.com.
Over the course of a few days, we researched and decided on an audience for each theme, designed and built them, and added Gutenberg support.
We opted to use a one-column design for all three themes, to best accommodate the “full” and “wide” block alignment options in Gutenberg.
Adding Gutenberg Support
You don’t actually have to do anything to use Gutenberg with a theme, but by declaring theme support you can add two optional features: the “wide” alignments (full width and wide width), and custom colors for the block-color palettes.
The following example, when included in the setup function in functions.php, will add both:
* Add support for Gutenberg.
* @link https://wordpress.org/gutenberg/handbook/reference/theme-support/
add_theme_support( 'gutenberg', array(
// Theme supports wide images, galleries and videos.
'wide-images' => true,
// Make specific theme colors available in the editor.
'colors' => array(
Whether or not you include custom colors in your theme, Gutenberg will always include a color picker with the palette, for further customization.
Styling the Themes
In general, the default blocks don’t need styling — Gutenberg already includes styles that match each block’s functionality. For example, the Gallery block already has the styles needed to split your galleries into different columns, and the Cover Image block will place the text and image added on top of each other, without the theme’s help.
If any of the styles don’t fully suit your theme’s design, you can adjust them as needed. One thing we noticed while we were developing these themes was Gutenberg’s distinct pill-shaped button style, which might not work with every theme.
On the flip side, themes are fully responsible for figuring out how the “wide” and “full” alignment styles should be handled, if they support them. This makes sense, since support is optional, and exactly how they should look can vary depending on a theme’s individual style.
In our three themes, we approached it a bit differently, setting a max-width for the page content, and instead using CSS to stretch those wider elements outside of it. We used vw and stretched the wider elements based on the screen size:
This approach works, but because vw includes the width of the vertical scrollbar as part of the whole screen width, you can get a little horizontal scrolling. One fix is adding overflow: hidden to one of the page-width elements further up the HTML tree.
In our themes, we also kept any block-specific styles separate in their own stylesheet.
Adding Editor Styles
To make the editing experience more what-you-see-is-what-you-get, you can add Gutenberg editor styles using enqueue_block_editor_assets. It’s similar to how editor styles can be enqueued for the current TinyMCE editor. This makes sure what a user sees when building their pages best matches how the content will actually look with your theme when published.
Here’s an example of enqueuing an editor-specific stylesheet:
Unlike the TinyMCE editor, Gutenberg’s editor styles include the post title:
The editor styles need to be pretty specific to make sure they’re not applied to other elements of the page outside of the editor — Rich Tabor has a good post here about his experience with this behavior. Gutenberg includes specific classes around different elements in the editor, so you can prefix selectors more generally with the class .editor-post-visual-editor, or use more specific classes to target individual blocks — for example, styles for .editor-block-list__block[data-type="core/heading"] h1 would only be applied to h1s inside of a Heading block.
What We Learned
Overall, this project was a great way to ramp up quickly on some Gutenberg-theming basics, and get our feet wet. Some specific things we learned from this process include:
The Gutenberg default block styles are numerous and can be a bit opinionated. This is good, in that you can rely on Gutenberg to do a lot of the heavy lifting, but there are some styles that would need to be updated to match individual theme styles.
It can be tricky to set up the wide and full-width styles; as more themes add styles for Gutenberg, it’ll be interesting to see all the different ways themes handle this.
Setting up the block styles for the back-end editing experience was more involved than any of us had anticipated. It’s very much like adding editor styles to the current TinyMCE editor, but some Gutenberg blocks have very specific classes that needed to be overridden.
We also learned a couple non-Gutenberg related things:
From a project-planning perspective, we could have spent more time narrowing down the kinds of themes we wanted to build — and the actual designs — prior to the meetup. This would have left more time to focus on the Gutenberg part of each theme.
In the end, it wasn’t possible to complete the project without making edits to these themes in addition to CSS. On top of the PHP changes needed to support Gutenberg’s optional features, we needed to make edits for common WordPress.com-functionality — like adding social menus, and more Content Options support — and for the designs themselves, like enqueuing Google fonts.
Our goal is to get these themes launched on WordPress.com. To get there, they still need some WordPress.com-specific functionality, like the annotations for WordPress.com’s custom fonts and colors, WooCommerce support, and styles for WordPress.com widgets.
We hope that sharing this process is helpful for your own Gutenberg journey as themers. We’d love to hear about your adventures.
Gutenberg promises the vision you have takes shape in the editor, instead of something you can’t see. Why’s that so powerful?
It happened again.
I sat with a potential WordPress themer, who wanted to know how to get started the right way with theme development. He’s a user experience professional by day, looking to up his coding skills.
He pointed to the WordPress editor, and said something like, “I understand HTML and CSS, but I’m not sure how to make something beyond putting it in there.”
We’ve all been there. Having that vision of what you want your site to look like, and not knowing how to get there. Gutenberg promises the vision you have takes shape in the editor, instead of some PHP file or a special plugin that isn’t truly native to WordPress. That’s powerful! It shifts much of the customization control from the themer to the person using the theme.
Today, if you’re trying to get into WordPress development, you might start by tweaking an existing theme. Then making a child theme. Then diving into a custom theme. My user-experience professional friend did just that. He’s already customized a theme and made a child theme. But the whole world of specialized WordPress theme knowledge can intimidate even professional web workers. Imagine how it feels to new users of WordPress who have never built a website before?
But with Gutenberg, people – professionals and beginners alike – can begin building what they want. Now, Gutenberg will no doubt need its own specialized knowledge. But at its heart, it will transform what a theme means to WordPress. They can become more about pure design, powered by the simplicity of CSS.
You might be saying, “But you can already use CSS now to change a theme’s design.” That’s true, but much of a theme’s structure gets determined by and locked away in template files. Hard to change unless you start learning how to “theme.” But with much of that structure and markup becoming blocks that can be added to a theme, it becomes easier for people who aren’t themers to see different possibilities.
Say goodbye to lots of custom widgets and theme options. Oh, and to limiting page templates. The future of WordPress themes can become more about empowering users to work on their vision instead of always having to learn how to “theme.” It starts in the editor and not with the theme.
The title may strike you as a bit ominous, but fear not. Underscores, our popular starter theme for WordPress theme development, isn’t going anywhere. As we continue to push for consistency in themes and imagine what they might become with Gutenberg, we’re bringing our attention back to Underscores. 🚀
For the last year and a half, we’ve experimented with a new starter-theme generator called Components. It was a way to make a few different theme “types” comprised of different components. The starter themes born from it brought with them more code and styles, and gave theme authors a bigger head start in their work. The generator we built to piece the different components together got complex quickly, though. We created a plugin to test builds locally and struggled with a seamless way to make many starter themes from one code base.
We learned a lot, though. We worked on Components at two team meetups, made almost 900 commits to the project and launched dozens of themes with it. However, we hit a point where we realized we had over-engineered parts of the project. The original idea is still solid: make starter themes do more by crafting them out of building blocks. But we didn’t hit the mark, so we’re retiring Components, and looking to bring some of what we learned there to Underscores.
In the last year, we’ve gotten a lot of questions from the community about Underscores and whether we had abandoned it. No way! It’s a stable project, and we enjoyed working on something new, away from it. It gave us better perspective and more ideas for the future of Underscores.
We also know that involvement from the community is vital. It’s been a while since we added our first contributor external to Automattic. To that end, we’ve given long-time Underscores contributor Ulrich Pogson commit access. He’s also a contributor to WordPress, most frequently as a member of the Theme Review Team. We’re excited to have his expertise and passion for world-class themes as part of the project. Please join me in welcoming Ulrich! 🎉
It’s always hard to let go of a project, in this case, Components. But it shouldn’t be, when you walk away with more knowledge than before. It has us excited and reinvigorated about Underscores and its role in the future of theming. And we’re glad Ulrich will help us along the way!
Content Options are now available to self-hosted WordPress sites with the latest version of Jetpack (4.5). Theme developers can add support for Content Options by following the Jetpack guide.
Let’s look at the main features of Content Options in more detail.
Users can choose between displaying the full content of each post or an excerpt on the blog and category, tag, and date archive pages, as well as search results.
Default Blog Display
If a theme displays either an excerpt or the full post depending on the post’s post format, theme developers can add a “Default” blog display option to let the theme keep its default blog display settings. For example, by default a theme might always displays posts with the Quote post format as the full post, so a quote is never truncated, while other post formats like Standard might be always displayed as an excerpt.
On the single post view, users can opt to display the name and bio of the post’s author. This information comes directly from the author’s profile at Users → Your Profile, and their Gravatar image.
The post details section allows users to show or hide the post date, categories, tags, or the post author’s name.
Users can choose whether to display featured images on single posts and pages. They can also opt whether to display featured images on blog and archive pages, which include category, tag, and date archives as well as search-results pages.
WordPress.com users have loved the flexibility Content Options gives them. We’re very pleased that self-hosted sites can now benefit as well!
This year, we’ve focused heavily on improving people’s experience using themes on WordPress.com. We’ve dug into defining the most common and tricky issues for people using themes through research, user testing, and iteration.
We still have a long way to go toward substantially improving people’s WordPress theme experience. To that end, we’re introducing a new set of requirements for all themes on WordPress.com to follow, geared toward making themes easier for people to set up and use. We call it the TUX List.
It features best practices like this:
Keep widget names descriptive of their location, ie. Sidebar, Footer, etc. Reason: Users can more easily find them and know what area they refer to.
Widget IDs should take the format of sidebar-1, sidebar-2, etc.
Reason: Consistency across themes means that a user can switch themes and not have to reassign their widgets to the theme’s widget locations. It also allows for easier readability in code.
We wanted to share it with the community, since incorporating these best practices into your themes on WordPress.org and elsewhere means anyone using them will have an easier time getting to what they really want to do: publish their site. Nothing on the list should restrict your creativity when it comes to designs.
Give it a read and let us know if you have any questions or ideas on how to make it better. Making themes easier is a job for everyone. Happy theming!