With WordPress 5.8 launching on July 20th, it seems like a great time to round up some resources to help theme authors prepare for the future. By now, you’ve probably heard about block themes and the upcoming future of full site editing. Perhaps you have even begun to explore creating a block theme or adapting your current theme to some of the new features, like template editing mode. Whether you’re just starting out or already deep in the block theme world, the following resources should help you be aware of what’s to come and how to get involved in shaping the future.If you’re looking for a quick snapshot, it’s recommended to review the following for 5.8:
Since block themes are currently evolving along with the features to support them, it’s helpful to start by figuring out what will help you stay up to date with the latest happenings, as that makes sense for you. Here are a few options:
Since this is an area that folks across the WordPress community are diving into, there are some fantastic ways to keep in touch with what others are experimenting with, how they are solving problems, how they are getting started, and more. Especially during a time where we can’t meet up and look over someone’s shoulder at a WordCamp, hopefully these resources help bridge that divide even a tiny bit.
Check out the Theme Experiments Repo to see what others are building/doing to get started. You can even quickly create a blank theme to get started using resources within that repo.
While these are the resources we found most useful, we’d love to hear from you too. What resources have been helpful for you to explore block themes and the various pathways leading up to full site editing? Share in the comments so we can all learn together.
Last week I spent a little time putting Blockbase to the test. I had some explorations into warping text and images using CSS and SVG filters gathering dust, and I thought it would be fun to explore pulling those into a highly-opinionated block theme.
In the past when I’ve done a theme experiment like this, I’ve generally started with something like the emptytheme generator in the WordPress theme-experiments repository. This provides you with just the required files for building a block theme, so it’s a good minimal way to get started.
This time around, I used Blockbase. While it doesn’t yet include a quick generator script like emptytheme does, there is one in the works. In lieu of that, I just created a child theme like I normally would: by adding style.css, functions.php, and index.php files. I also copied over the child-theme.json file from the in-progress Quadrat theme, since I knew that would get me started.
My work in child-theme.json was very brief — I just changed a few variables and used Blockbase’s compiler script once. Then I copied and pasted over the block style effects from the plugin mentioned above.
Once that was all in place, I jumped into custom templating. I created just two templates, plus a custom header that featured a video loop of me waving at the camera (but filtered into oblivion using the tools at photomosh.com). I used a “Warped and Stretched Photocopy” block style on the header’s text, and “Photocopy” style on the featured images. Combined together, this created a highly stylized look and feel, reminiscent of (for better or for worse) the old days of Flash animations:
This all worked pretty well in the editor too! Due to a combination of Gutenberg limitations and browser bugs, I ran into an issue getting my SVG filters loaded into the Site Editor’s iFrame, but aside from that, things looked just like the frontend:
The filters did work great in the post editor though, so I can show you how that’s supposed to work by loading the header there:
In the end, the filters bug is not really a fault of the theme, and something I’m sure I could resolve if I choose to devote some more time to this exploration.
The theme is obviously a little over-the-top, but that was really the point of the experiment! I’m amazed I was able to fold my earlier block styles work into such a distinctive, full-featured theme with minimal effort.
Overall, I found that the benefit to using Blockbase was peace of mind. Compared to starting fresh or using emptytheme, Blockbase ensured that I had a fully-functional block theme immediately. It already contained extra templates for pages like 404 and search, and it was full of little CSS fixes for things that full-site editing just doesn’t quite support yet.
This eliminated a lot of extra busywork, and allowed me to dive right in and focus on the theme-building aspect that’s most exciting for me: the theme’s design and creativity.
The code for the theme is over here in case anyone would like to poke around:
Kjell Reigstad details how to build a single-page block-based theme.
The other day, my colleague Ian Stewart and I were discussing homepage templates, and this Carrd layout came up in conversation:
Its two-column design is friendly and simple. It’s also drastically different than most WordPress themes we see these days — it doesn’t have a traditional header and footer, or even a menu for that matter. It really doesn’t look like a WordPress site (partly because it isn’t. 😄).
It does however look like a relatively simple pattern that could be built with Gutenberg blocks. With block-based themes on the horizon, Ian suggested I see how easy it would be to build a block-based theme featuring a similar homepage layout. I took him up on the challenge.
In about an hour, I had a fully functional version of the theme. Read on for details on how it all came together.
The Structure
The first thing I did was set up the basic theme files, and get them all hooked up to each other. Most of the theme files are more or less boilerplate — aside from a little CSS and some experimental-theme.json value changes, they aren’t going to change much from theme to theme. Here’s how that looked:
functions.php contains a standard function to enqueue the stylesheet. Aside from that, it just sets some theme options. Since this is an experimental block-based theme, I opted-in to just about all of the experimental options from the Block Editor handbook.
Stylesheets
style.css is enqueued only on the front-end. It includes a standard theme header docblock, plus barebones alignment styles, courtesy of Ari Stathopoulos. These styles just replicate the editor alignment rules from Gutenberg (standard, wide, and full) in the front-end. Hopefully Gutenberg can provide these styles one day, eliminating the need for this standalone CSS file.
style-shared.css houses the basic font and color rules, plus just a few theme-specific spacing overrides. This is loaded in both the editor and the front-end.
Building the Front Page Template
Once I had those files in place, I was ready to build the block template in block-templates/index.html.
First, I installed and activated my theme. With the empty HTML file created, I opened up the site editor, and was presented with a blank slate:
From here, I added a full-width columns block. On the left, I used a Cover block and uploaded my image. I used a columns block because I wanted to take advantage of two great Cover block features: its ability to take up the full height of the screen, and also its focal point picker which would ensure that the image is always centered on the model’s face.
After that, I added a few center-aligned blocks to the right column: Site Title and Site Tagline blocks, a Button block, and a Social Links block:
From there, I hit “Update Design” and used the Gutenberg plugin’s “Export” tool to download a zip file containing this template:
The resulting zip file included an index.html file containing the block markup I had just built. I replaced my empty block-templates/index.html file with this new one, and I had a fully functional single-page block-based theme! 🎉
Viewing the Final Result
The only thing left to do was check out the site in the front end. I was pleased with how similar everything looked to the editor, and how the whole layout was responsive by default.
This exercise made me truly excited about the future of theming. It took very little time to assemble the boilerplate necessary to get started, and I constructed most of the theme the editor itself. I imagine whole process will only get faster (and the boilerplate will be whittled down further) as full-site editing progresses.
A typography-led theme, built for the future of block-based theming.
This week the Automattic theme team launched a brand new theme called Seedlet. Seedlet is a simple, typography-driven foundation for folks to build their websites on. Its styles are opinionated, but generic enough that the theme can apply to a wide variety of different use cases.
This is a particularly exciting launch for us, because not only is Seedlet a lovely theme on the front end, but its backend was crafted with the future of theming in mind.
It ships with block patterns
As we’ve written before, block patterns are an incredible new tool for theme authors. We anticipate building these into every one of our themes going forward, giving users easy shortcuts to creating some of what they see in the theme demo.
Seedlet ships with a few patterns. Two of them leverage some creative use of gradient background presets, and the other makes your posts appear to snake down the page like a vine.
It’s built to be flexible
Behind the scenes, Seedlet has been built with a comprehensive system of CSS variables. If you’ve seen our Varia theme, you’ll be somewhat familiar with the system. Essentially, it’s a tiered system of variables inspired by modular CSS. In effect, everything from the site’s color palette to its spacing and structure is hooked into CSS variables.
Seedlet uses CSS variables as design tokens, instead of the SASS variables used in Varia. By relying on CSS variables for all of the core style attributes, we’re able to bridge the gap between the front end and the editor styles. If we change the value of Seedlet’s --global--color--background variable, the background of the site will update in both the front end and the editor immediately, with no compiling necessary.
CSS variables are also easily manipulated in the Customizer (as in Seedlet’s custom colors implementation), or in child themes. In the tests we’ve done, you can easily create a drastically different child theme by modifying only Seedlet’s CSS variables. Stay tuned for more to come on this, as we build out the first round of child themes based on Seedlet.
It’s ready for our block-based future
Seedlet’s extensive use of CSS variables also sets it up nicely to integrate with the block editor’s upcoming Global Styles functionality. CSS variables are what make Global Styles work, and Seedlet is full of them.
To demonstrate this transition, we put together a child theme that maps a number of Seedlet’s CSS variables to Global Styles values defined in experimental-theme.json. That, plus a few block templates, results in a fully functional, block-based version of Seedlet. You can explore this today by visiting Seedlet’s GitHub repository:
We plan to iterate on (and eventually launch!) this block-based version alongside the standard version of Seedlet.
We’re excited to see how Seedlet evolves as we continue moving towards block-based themes. In the meantime, give Seedlet a try, and feel free to contribute on GitHub if you’re so inclined.
Block patterns are unique, predefined combinations of blocks you can use and tweak to create stunningly designed sections of your website.
From global styles, to entirely block-based themes, the WordPress block editor is aiming high. Amongst the newest experimental features are block patterns. Block patterns are unique, predefined combinations of blocks you can use and tweak to create stunningly designed sections of your website.
The possibilities for block patterns are extremely exciting, especially for those of us providing tools to help people create their own websites. Patterns start to tackle the user question of, “How do I make my website look like this theme demo?”
By providing our users with predefined portions of layout, they can build and customize their own unique pages with a click — no coding or advanced block building knowledge required.
The Patterns API
Gutenberg 7.8 introduced a new, experimental API we can now use to register custom block patterns:
The API really only contains two things: a name for your pattern, and the raw HTML output that you can copy and paste from the Code editor view. This means you can design your patterns straight in the editor, no coding knowledge required.
When you add a new pattern to your theme, it shows up in a new sidebar in the editor, along with any other pattern you might have installed:
Note: The new Block Pattern sidebar is a temporary proof-of-concept and is subject to change.
Using this API, we can start to introduce block patterns into our themes.
Adding Block Patterns to Twenty Twenty
Let’s take a look at adding a block pattern to the Twenty Twenty theme.
The Twenty Twenty demo site showcases content that highlights the strengths of the theme. We can grab some of that content, and make it into a pattern that can be included with the theme. Now, rather than trying to replicate the site demo by hand, people using Twenty Twenty can insert the pattern directly into their own sites.
On the homepage, one of the sections that catches my eye is the exhibitions list, which is a mix of images and text displayed in a grid. Not only does it look great, the combination of content is generic enough to be used for many different purposes, making it an ideal pattern to abstract out for reuse.
Let’s break this content down into its basic blocks:
The Columns block here acts as a wrapper for the exhibitions content, and provides a structure for it to collapse down into one column on smaller screens.
The single Columns block is the smallest atomic unit we can include to make this a complete pattern. Even if the demo shows multiple rows of exhibitions, we’ll stick to just this single row of two items. If someone wanted to add a bunch of exhibitions on their own website, they could reuse this pattern multiple times.
In order to convert this into a block pattern, we’ll need to grab the HTML output from the block in the Code view of the editor:
We need to copy this HTML, escape it, and add it to a register_pattern function inside of Twenty Twenty’s functions.php file.
(I’ve used onlinestringtools.com to escape the raw html output, but there are also code editor tools that can do this.)
You can add any number of patterns to your theme, and even unregister core patterns if you only want your patterns to be available to people using your theme. Create some great patterns that show off just what your theme is capable of! The only limitation is your imagination.
Have you added patterns to your theme already? Tell us about it 👇
Note: The code samples here are out of date. Please be sure to check out the block editor documentation for the latest on how to implement Global Styles.
Global Styles is an aspect of full site editing that will have a major impact on theme development. To further my understanding of this feature, I explored adding support for it to the block-based version of Twenty Twenty that Jeff Ong recently shared.
Some background: Global Styles aims to bring site-wide controls for things like colors, typography, and spacing into Gutenberg. The originating GitHub thread for the effort is a great primer on its goals and scope. From a technical perspective, Global Styles currently works by using CSS variables to define styles. A set of controls are being developed to allow users to edit those variables within the Gutenberg UI.
A lot of Global Styles work is still in flux, but early pieces are available for themes to experiment with. For example, while using the latest version of the Gutenberg Plugin, themes can define a base set of Global Style variables in an experimental-theme.json file. Here’s a simple example of what one might look like, courtesy of Andrés Manerio’s global styles demo theme:
Theme authors can pull those in like any other CSS variable. For example:
p {
color: var(--wp--color--text);
font-size: var(--wp--typography--font-size);
line-height: var(--wp--typography--line-height);
}
To help wrap my head around this, I took Jeff Ong’s work on the Twenty Twenty Blocks theme, and adapted it to use CSS variables as defined in a brand new experimental-theme.json file. You can browse this here:
This exercise was relatively straightforward. The concept really shines when thinking a little farther out though. Once I had those new variables in place, I tried them alongside an in-progress Gutenberg PR to add a Global Styles sidebar to the beta site editor. This provides a vision of how style editing might feel in the future:
This is still very early and very buggy, but the ability to modify these values globally in a single place is still very exciting. This is something my colleagues and I are looking forward to implementing into our themes when it’s ready.
In case anyone wants to dig in to the exploration, the full code and some instructions are available over in the WordPress/theme-experiments repository. Give it a test, and try adding an experimental-theme.json file to your block-based theme experiments as well.
Finally, if you’ve already given Global Styles a try, I’d love to hear about it! Please share your work in the theme-experiments repository, or drop a link into the comments.
There’s been a lot of conversation around how theme development changes as Full Site Editing using Gutenberg becomes a reality. Block templates are an experimental feature of Gutenberg (as of 7.2.0), and using them to create block-based themes is in exploratory stages of development.
A block-based theme is a WordPress theme with templates entirely composed of blocks so that in addition to the post content of the different post types (pages, posts, …), the block editor can also be used to edit all areas of the site: headers, footers, sidebars, etc.
Before diving in, I’ll reiterate that much of how this works is subject to change. This spec is in a very early stage. I hope by writing this, your interest is piqued to learn more and contribute your own experiment to the WordPress theme experiments repository.
Step 1: Create the theme project
In its simplest state, a block based-theme’s structure should look something like this:
This is refreshingly simpler than most WordPress theme boilerplates. Here’s a quick overview what each file and directory does:
block-templates/: page templates that are composed of blocks. These follow the same template hierarchy as traditional themes.
index.html: the primary / fallback template to generate a post or page. (Analogous to index.php in traditional theme templates.)
block-template-parts/: the common collections of blocks to be used in block templates.
header.html: The global header, expressed in Gutenberg-generated HTML.
footer.html: The global footer, expressed in Gutenberg-generated HTML.
functions.php: This contains the usual theme setup and any other reusable functions.
index.php: This is actually just an empty file. You can technically remove it, but it’s a good habit to include an index file in every directory.
style.css: Contains your theme’s styles as usual.
Recreating Twenty Twenty as a block-based theme required adding a few extra stylesheets. Overall, I chose to add no extra page templates to keep the demo as understandable as possible.
Step 2: Create the block templates + block template parts
There were just two that needed to be totally rebuilt as blocks: the header and footer. The process for turning these areas into block templates was something along the lines of:
Attempt to create the template parts in the block editor
This can be done in a draft post or page. If you’ve enabled the Full Site Editing experiment in the Gutenberg plugin, you’ll see a new admin panel area Appearance/Template Parts — an area where in the future I could create, store, and edit the block template parts in my theme.
Style them as closely as possible using the editor
Add block style variations + additional theme CSS to address any gaps that the core editor
Most of these styles were already present somewhere in the Twenty Twenty theme CSS, so I just needed to make minor modifications to assign them to the new blocks.
Step 3: Save those block templates + template parts as distinct files
When Full Site Editing is enabled via the Gutenberg > Experiments panel, Gutenberg will expect that your theme provides block templates, overriding the normal templating behavior:
Once I had my template parts designed and displaying properly, I would switch over to the Code Editor view, copy the markup generated, and paste the code into its respective file within my theme directory’s block-template-parts folder.
Edit: there’s an easier way to do this without switching to the code editor. You can select all blocks (Meta+A), copy (Meta+C), and paste into your text editor.
Step 4: Add theme starter content
In order for the theme to be populated with pages and content, I borrowed the official TwentyTwenty theme starter content. This step wasn’t 100% necessary, but a nice addition to have some content when someone activates the theme on a fresh WordPress site.
Converting the header and footer to blocks helped me identify some functionality that would be nice to add to core blocks. Some of these are already in the works.
Navigation block
Control over how the menu is laid out and collapses in different viewports (#16829)
Columns Block
The ability control the padding and margins (#10730, #16660)
Adjusting the size of one column, the remaining columns don’t resize equally (#19515)
How is this better than what we have now?
The structural block-based theme changes are generally not obvious on the front end. The process of switching between the Code editor, a template file, and previewing the site to achieve the intended design was tedious. However, this is just an interim step before we’re hopefully able to create and edit our theme (and your entire site) via Gutenberg.
The end benefit will become most apparent when the user can edit every piece of the page individually using Gutenberg. Being able to compose, manage, and reuse parts of your theme all within one visual interface is an exciting idea and one that’s close to reality.
The other exciting aspect of this process was that it required very little PHP — just a few block style variation declarations and standard theme support registration. Everything else is CSS and HTML generated by the editor. To me this feels like a step in the right direction, lowering the barriers to entry for folks that are new to theme development and WordPress.
I invite you to try it out; your comments and feedback are more than welcome. The source code for this theme is available on GitHub:
In that repository, you’ll find a handful of other block-based theme experiments: converted versions of Twenty Nineteen, the Gutenberg Starter Theme, and a theme called Parisienne. Each contains instructions for installation and activation.
By the way, the theme-experiments repository is open for PRs! I’d love to see more people creating and testing themes that use this method: that’s the only way it’ll grow and improve.
Feel free to ask questions in the comments or in the repository, and thanks for reading!
Kjell Reigstad walks through his experience designing a block-powered theme.
Last week, Allan Cole and I shared a new Gutenberg-powered theme called Music. In this follow up post, I’m going to take you through the design process for the theme. At its core, this felt a lot like a typical theme design process, but I did learn a lot about block-based design along the way.
Blocks
When Allan and I decided to make this theme, we already had a homepage comp featuring a handful of blocks. That comp did a great job of setting the tone for the design aesthetic. To get things going, I decided to apply that aesthetic to the other default Gutenberg blocks. I worked through the Gutenberg Blocks Sketch document from my last post, updating styles as I went.
Working this way was great for a couple reasons. First, it helped me focus — I’d never designed a block-optimized theme before, and this kept my design explorations squarely on the blocks themselves. I thought, “Gutenberg is all about blocks, right? I’ll design some blocks.”
Second, the Sketch file allowed me to see every single block style in one place. In effect, I was creating a sort of pattern library as I went. I thought this was pretty cool, and figured it’d come in handy later on when we began development.
As I got further through these block designs, I realized the need to see all of these individual blocks in context; I’d design a wide-width cover image block, but I had no idea how it’d look in use. So I began dragging blocks around and stacking them up to get a sense of how they’d feel together.
This helped a little bit, but still wasn’t enough. At this point, I realized something that should’ve been obvious: blocks are not a theme. They’re just part of a theme. By designing blocks first, I’d been avoiding the big picture. Users will never see blocks all by themselves — they’ll exist within full pages. I needed to design more pages.
Pages
My initial homepage design comp introduced a rough idea of a header and an off-centered text column. I began by duplicating that initial page and clearing out all the blocks on it, then pulled together some sample content. Looking at the project through the lens of my imagined client (the band Superserious), I was able to think through examples of blocks and block combinations that might exist on a real site: the columns block to display album information, the table block to display tour dates. This felt much more effective than randomly placing blocks on a page.
Around this time, I hit my stride, design-wise. I’d lay out a page using my existing blocks and the sample content. Then I’d iterate and experiment with everything on that page. Once things looked right, I’d migrate any new block tweaks back to the global symbols and start fresh on the next page. After a little while, I ended up with a solid set of sample pages.
Backing up and thinking about page design helped me shift focus to other, more traditional components that needed to be designed too: archive pages, page footers, post headers, etc. Designing these wasn’t all that different than it would’ve been without Gutenberg. In a way, we’ve all been designing with blocks all along — we just hadn’t called them blocks. Take a look at this entry summary:
If I’d designed this theme pre-Gutenberg, I still would’ve designed each one of those pieces — they’re all fairly standard parts of a theme. But thanks to Gutenberg, each piece is part of a clear pattern library, to be reused throughout the design by me and by the user. That’s pretty cool.
I’d gone into this project thinking I’d spend most of my time styling individual blocks, but I ended up splitting my time pretty evenly between designing block variations and overall page elements. In that sense, this wasn’t as drastically different from a traditional theme design as I’d anticipated.
Prototypes
I’d been getting ongoing feedback from Allan throughout the process above, but once we were happy with the page designs above, we gathered with the rest of the Theme team to get broader design feedback. To help with that process, I pulled all my comps together into a prototype. This took just a few minutes to do, and really helped others get a sense of how the theme will work in practice.
I created two separate prototypes with Invision: one for desktop and one for mobile. If my transition from block design to full-page design was about looking at the bigger picture, these prototypes stepped back still further: they showed us the context around that big picture. We were all able to see the designs on-device and test some basic interactions.
The team’s feedback was (as usual) very helpful — we made some subtle revisions to text contrast, adjusted a number of margins, and kicked off a lot of iteration on the mobile menu treatment.
Development
Allan had been focused on the build from the beginning, and had the majority of the framework in place at this point. After our design feedback session, I jumped into the code too.
From the development angle, we’d already determined a few things in the design that we couldn’t do, or that would take too much effort. For instance, in my initial design comp I’d had a series of backgrounds run down the page. Gutenberg doesn’t have a method for doing something like that today; despite my wishful design thinking, there’s no method for layering a background behind a group of blocks. We could’ve accomplished it through customizer settings, but we shelved the idea in favor of keeping things simple. We also abandoned a bunch of the play buttons I’d originally included, since those’ll require some custom blocks (more on that later).
Once I jumped into the code, my main revelation was that there were way more block options than I’d originally anticipated. A number of blocks had options I’d never noticed before. I hadn’t realized that paragraph blocks could be set to full width, or that cover image blocks could be floated left or right.
In addition, I realized some design decisions I’d made were actually supposed to be user-editable: I’d overlooked the fact that users can edit the text alignment and image opacity for the cover image block. This required more design exploration, but it guided us towards a much more customizable theme — definitely a win in the end.
Beyond those updates, the majority of the design-oriented development work involved minor fixes and adjustments — polishing up the CSS to make sure it aligned with the intent of the original design.
Next steps
Now that we’ve had our initial release, Allan and I plan to build a separate plugin with complementary music-centric blocks, like a tour dates block and a mashup of a cover image and an audio player. We’ll hope to showcase those at some point in the future.
In the meantime, keep an eye out for the next post in the series: Allan’s experience from a development perspective.
Announcing the Music theme: an exploration of how Gutenberg can transform theme design and development.
A couple months ago, I createda Sketch document to assist with the design of block-driven themes. I posted about thathere on Themeshaper, and provided a couple short examples of how it could be used in a theme design workflow.
Since then, Allan Cole and I have been working to make one of those examples — a site for an imagined band named Superserious — into a working example of a Gutenberg-powered WordPress theme. We named the theme “Music.”
Allan and I set out to experiment, learn, and create a resource for the community. We’ve documented our experience designing and building this theme, and will be publishing our notes in a series of posts here on Themeshaper.
To kick things off, we’re releasing Music on GitHub today. We’d love for you to give it a spin, tinker with it, and explore how it works with Gutenberg. Here are a few things to look out for:
Design
Our design goal for the theme has been to show that it’s possible (and encouraged!) to make a Gutenberg theme that doesn’t necessarily look like Gutenberg. We wanted to create something bold and a little experimental; a theme with somewhat aggressive, non-standard styles.
Gutenberg gives users unprecedented control over their site design, opening the door for variety and experimentation. Our favorite example of this is our cover image blocks. They look great out of the gate, but users can adjust the image, alignment, and color to achieve a wide range of looks:
Development
You’ll be happy to hear that the overall theme development process wasn’t all that different with Gutenberg. Common patterns like headers, footers, and loops work just as you’d expect in a Gutenberg-powered theme.
In many areas, Gutenberg makes things easier for both users and developers. For instance, full-width header images used to require a custom-built customizer or theme option solution, but now they’re essentially built in. This was important to keep in mind while building the theme, and was a very positive change for development.
Creating stylesheets for blocks was pretty straightforward. Expanding on the built-in stylesheets in _s, we added a blocks.scss file to the SASS directory and placed all of our block-specific styles and overrides there. This kept everything nice and organized and is likely to appear in _s in the future.
Since Gutenberg is output by the_content(), we learned to take special care with any wrapper divs that might clip or obstruct the expected behavior of Gutenberg blocks. We’ll talk more about that in a follow up post.
Block Styles
We’re truly excited about the custom editor styles that ship with Music. These styles are a breakthrough: they give users a much clearer sense of what their visitors will see on the front end.
Best of all (for theme developers at least), the editor styles were a breeze to integrate! We built all of these in over the course of just a few hours.
Like most of the work we do, the Music theme is open source. You can find it on GitHub:
In many ways, designing and building this theme was similar to the way we’ve made themes in the past — but we did carve out a few new practices along the way. Allan and I will be sharing them with you in upcoming posts. In the meantime, we encourage you to download, install, and experiment with Music yourself!
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.
What we learned by developing three themes with Gutenberg in mind.
At the Automattic Theme Team meetup in December, we focused on several Gutenberg-related projects. The first one we’re sharing is a set of Gutenberg-friendly themes based on Underscores.
The project’s goal was to help us think about our themes differently, dig into adding theme support for Gutenberg, and as a byproduct, do some testing of Gutenberg itself.
Six team members participated in this project, and it resulted in three themes which are still in progress, and currently available on GitHub.
What is Gutenberg?
Gutenberg is the new block-based content editor currently being developed in GitHub for WordPress 5.0. Until it’s merged into core, it’s available as a plugin.
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 Themes
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
Ohana
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.
The Process
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.
Though it can vary from theme to theme, this is how Handicraft styles Gutenberg’s wide alignment (on the left) and Fashion Blog styles the full alignment (on the right).
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(
'#ffffff',
'#000000',
'#cccccc',
),
) );
Whether or not you include custom colors in your theme, Gutenberg will always include a color picker with the palette, for further customization.
Gutenberg’s default color palette, shown while editing the Button block.
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:
An example of Ohana’s editor styles.
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.
Next Steps
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.
ThemeShaper 