The good thing about looking back at early work, and cringing, is seeing how much you’ve learned.
I built the first website for the law firm of Despres, Schwartz, and Geoghegan, Ltd. around 2015. They needed a responsive website (migrating from a classic table layout) and WordPress seemed the right solution. I used my premium theme builder and created a simple website with a few pages and a blog.
After nearly ten years, the site desperately needed a rethink; both to become more usable for editors and, selfishly, to be less cringe for me. Rebuilding in the site editor this year was an opportunity for me to explore (and learn) what might be possible in a block theme on a “real”1 website.
1 Some anti- block-theme sentiment spirals around block themes being fine for displaying simple content but not functional for the complexities of an actual website.
Using the Create Block Theme Plugin
The Create Block Theme plugin is not required but it sure does make things easier. For example, creating a child theme (unclear if this is still as essential with block themes as with classic themes), including fonts in theme.json, or even just setting up a new “empty” theme with the basic structure and files you need to get started. When you generate your theme, it will create the theme folder in the site’s theme directory. You can also choose to export your theme.
Using this plugin I first created a child of the theme Beaumont by Anders Norén (because his designs are so great). At some point, I decided it wasn’t quite right – I didn’t really want any styling to exist, just the basic structure. I opted for something more stripped down, Blockbase. In this attempt, I didn’t create a child at first. I chose to create a style variation for the current theme thinking, “Let’s keep this simple – I’m just customizing styles and blocks, right?”
As many of us know, simple soon becomes complex. I experimented in changing my selected style variation to see what would happen if an editor did that. All of my customizations were lost, probably due to me not saving my changes.
Lesson #1: Always save your work
We can make a whole lot of changes in the site editor very quickly and saving changes isn’t an obvious part of the flow (as it is when you are working directly in a file editor). A nice feature in Create Block Theme, which I discovered through doing things wrong, is that in addition to saving your theme at any point through the Create Block Theme dash, you can also write your user changes (to styles and templates) to the database while working in the site editor. The wrench icon opens to display your save options:
- Save Changes saves everything to the theme.
- Export zip exports your theme but you also want to be sure to “save changes” to your theme first or they won’t be included (learned this the hard way!)
Notifications are a little too discreet here. I’d like to see an alert or something that repeats the description of what to expect, like: “You may want to save your user changes to the theme first or they won’t be included in your exported theme.” A message when you change your variation would be nice too. If the site editor can note that changes have been made, but not saved, remind me. Especially for a new user or non-developer, contextual messaging about what happens next could help them from feeling frustrated that things appear broken “for no reason”.
Revision history in the site editor
We can view a list of changes and revert to a previous version using the revision history panel in Styles.
3rd (or 4th) time, the charm
I began again with a copy of Blockbase and got pretty far with my new theme until I read somewhere that it should be a child. Or, maybe I began second-guessing myself and thinking, “this should be a child,” in case the parent theme is updated. Once more, I returned to the beginning and created a child of Blockbase.
Some minor issues that happened at various points in development:
- At one point, the social links block was missing the setting to change the link color on icons. I could change the block background and text color but not individual link icons.
- The height unit for spacers stopped working. The values are displayed in the spacer block settings (em, rem, px, vh) but only the pixel value would change the height.
I’m not sure if those bugs are related to some glitch that may have happened during a save/write to theme files.
Major Mental Model Shift
The most challenging aspect of working to create a block theme, for me, was not relying on editing files directly. It felt a bit like I was working with blinders on, unable to see the actual code. I could work on theme.json initially in my code editor but after a certain point what happens in the code editor and what happens in the site editor starts to break down (as one might expect in a mirror universe). This is because what’s happening in the site editor is being written to the database, which is not the case when editing files outside of WordPress (I think).
Why can’t I just write CSS?
I don’t like the tiny little panel we get for custom CSS stuff. “Additional CSS” isn’t even exposed by default. It’s like, don’t you want me to write CSS anymore, WordPress? Where block themes are currently, and what theme.json can control, is pretty awesome. But, there ends up being a fair amount of CSS we designers and developers will want/need to add in a custom theme. Even a block theme. The few examples that occurred in this very basic site involved:
- Custom bullet styles for unordered lists
- Overwriting a form plugin gap and required field color in order to meet color contrast requirements
- Creating a negative margin style so that an image could “overlap” a section
- Adding a transition to buttons to ease the background color shift
- Many styles to adjust the navigation block
Which brings me to the navigation block.
Navigation Block: Bane or Boon?
The great thing about the navigation block is that it has accessibility baked in. A parent item with children is a button element. Keyboard interaction is as expected. Yay! But … there’s a few things that are hard here:
- I want the .current-menu-item li to have some style that shows what is current and active in the menu, like a bottom border.
- If a page is a pseudo parent, for example, a static team page contains the custom post type team, I still want to highlight the parent page when viewing a single team member (post).
- I also had this issue with the /blog/ page menu item when a single post was viewed. Even with a .current-menu-item style, I had to add another custom style for this to work on the archive view.
- The mobile menu: there’s minimal and then there’s, um, the mobile menu for the navigation block. Compared to what we are used to, it’s too limited. I want to be able to show the word “Menu” and “Close” as well as the icons. I also want to be able to change alignment and styles here.
Your selected, primary navigation menu is synced: a good default but not obvious.
When adding the navigation block to the footer template part, I customized it not realizing that the navigation block was by default my “primary” navigation and synced with the header navigation.
Under the navigation settings, the title is simply “menu” and then menu items are listed. It wasn’t obvious that this is a specific default menu that would also be synced. If I click on the options menu, I can see that I am able to import classic menus or create new menus. If the selected menu name was also shown in the settings panel, not just the “Menu” label, we might infer multiple menus could be created and managed and that changes to a current menu would affect all instances of that menu.
Search Icon, wherefore art thou?
A search icon that opens up a search panel is ubiquitous in website designs. The search field is probably better UX but it’s not always going to work in those minimal header designs with a logo to the left and navigation to the right. My work around on this website was to use a modal block and, basically, fake it.
Working with Page Templates
As I neared the end of the rebuild I started to use Polypane for a look at responsive and accessibility issues. One thing immediately noted was that the Page Title was not in a landmark. That’s not good! I checked my page template and realized that the Page Title, which has a full-width cover image background, was indeed outside of the <main> content group.
The main group has a margin that doesn’t allow for full-width inside the template. On a page, you can include full-width blocks but not inside the template (I’m not sure why, to be honest). I referred to my usual _S (Underscores) theme structure within the body:
<header class=”entry-header”>Page Title</header>
<div> The Content </div>
Since we can define the HTML element under the “advanced” settings of the group block, I added two more container groups to create the missing article and article header sections and grouped everything in a new <main> section. I then demoted the <main> content group to a general purpose div.
This is something that will vary by theme since the theme author decides the structure when they build their templates. It’s not something everyone would investigate. More explicit instructions could be useful, for both DIY folks and developers. Landmarks may not be top of mind for everyone when building out a template and even developers aren’t always aware of their importance to accessibility.
- This setting is hidden under an advanced label. The name “advanced” would probably deter many content creators from even looking here.
- Could there be a warning / “are you sure” message if a landmark is missing from a template?
- The descriptions are a little vague, for example: “The <section> element should represent a standalone portion of the document that can’t be better represented by another element.”
- Some examples or a link to learn more about each type of element could be useful, as we have for the HTML anchor option.
File under “Miscellaneous”
One thing that is necessary for larger sites is handling custom field data. I use Advanced Custom Fields (ACF) on many of my sites. I likely want my custom field content to appear dynamically in certain places and not just the page or post it is created on. Here’s where I start to encounter a knowledge chasm going from classic theme to block theme developer.
really hard not possible to keep up on everything and do it well. I am excited about the potential of the site editor and block themes. I’m a little sad to lose the control and autonomy I had with my _S based theme process.
There is a middle path (for now)
Hybrid themes afford someone like me a viable option for sites of any complexity. I kind of understand PHP now and I am able to manipulate it. With the inclusion of theme.json, some editor styles, and custom blocks I can leverage the more modern aspects of WordPress core. But, if I see an opportunity to go full-on block theme I definitely will.
Re: Block theme and site editor resistance
When I was first introduced to WordPress, I had been building websites using BBedit and Dreamweaver. I started by creating child themes but, not knowing any PHP, there were many things that I couldn’t do. Using a builder framework offered me much more design control and a speedier process (in theory). Gradually, I tried to improve my processes to follow what I considered to be “best practices” – relying on defaults, using semantic HTML, prioritizing accessibility in design. Using a builder began to feel confining because I didn’t want to just do it faster and increase my volume to make more “web product”. I wanted to craft the web experience more holistically and have a meaningful personal and professional investment in my work. Or, maybe I just like doing things the hard way.
Despite the recent advances of the site editor, builder frameworks are still a prevalent solution and the default editing capabilities of WordPress are often compared negatively. Most commonly, the developer complaint is that the block editor is great in theory but it’s still too new and not capable of the robust solutions (ie. control) we developers have in our established themes and plugins of choice. That always makes me think of the agency job I had 5 or 6 years ago where my manager vetoed the use of CSS Grid for the same reason. It’s been almost seven years, that’s super old in internet years? But, okay, I get it.
The future is now
When web creators push back and say something is too new to use, often that means, “I’m not comfortable with this change and I’m worried about all the additional labor needed to understand this.” Once that knee-jerk “no” is out of our system, I think we can acknowledge that adapting to change is one of the strengths inherent in our practice. And, if that doesn’t inspire you, the block editor is here to stay. It’s on us to learn and understand more fully what is possible – and to work together to make it better.
View the new site at DSGChicago.com.