dev diary update

After three years I’m resurrecting this idea. More determined than ever after having built at least two block themes privately. My experience applying for jobs has made me have to confront something a bit depressing, too; I don’t have a lot to show for all the work I’ve done. As much as I understand what I’m doing and the “best practices” of this profession, my GitHub profile doesn’t really reflect that.

block themes: a fish out of water

Most of my experience is developing “classic” themes, and it’s been a struggle wrapping my head around theming for the block editor. At least two important things I’ve learned so far are that 1) the tools need to catch up to make working with the style engine less of a hassle, and 2) fluid spacing and typography is a must. I’ve always been a fan of fluid typography and spacing but trying to develop a responsive block theme without writing much (if any) CSS makes it a requirement.

What I’m also lacking is a system for theming for the block editor. That, I think, is forgivable. I’m still determined to change that, even if it means developing a few of my own tools. For example, I started work on a PostCSS plugin to extract styles targeting Gutenberg blocks and then merge them as valid JSON strings into theme.json.

go, grind, hustle

But more than that I don’t have scripts on hand for simple tasks like zipping up theme assets for distribution. If I want to be a productive plugin and theme developer (and who doesn’t?) I can’t keep building up my tooling from scratch for every new project. This was a motivating force in publishing my composer-managed development setup.

Part of my motivation for reviving this goal of mine to get a theme into the dot org repository is to also setup a base block theme and set of tools for theming specifically. What working on two block themes has done for me so far is give me a sense of the template parts and theme settings/styles that will need to be included in most projects. I want to take that to make a flexible base for any theming project.

unspoken wisdom

What I’m finding the more that I develop block themes and patterns is just how much of the process is going unspoken. Everyone talks about how you can copy or export your theme templates from the editor, but not how to de-reference media items or elements like navigation menus. Creating re-usable/distributable patterns requires patience, looking over the shoulder of author theme authors, and sometimes trial and error.

This has been an issue with the Gutenberg project from the beginning though. Everything moves at a blistering pace and the only people who seem to understand issues like this, or how to work with editor’s state store, or any miriad number of other details relevant for developers seem to be the people working on the editor itself. My man crush Rob Neu said as much circa 2021 and the situation has not improved.

But expect updates on this little project to demystify some of that. I don’t believe in hoarding information, and like I said when I “started” this years ago, if I don’t write things like this down during the course of development I’m just going to forget, anyway 🥴