More improvements from Varia, a new Tailwind Typography selector, and a lot of housekeeping!
This update has been a long time coming. Originally planned for July, I was forced to delay these changes to recover from my first COVID infection, and then to get caught up on the client work I was forced to postpone while recovering from COVID.
This round of changes will almost certainly be the largest I ever make to _tw, and completing them allows me to move on to long-planned updates to documentation and for work to begin on new screencasts. These are also primarily WordPress-focused improvements, with minimal changes to the Tailwind side of the project.
Improvements from Varia
This round of improvements completes my months-long project to incorporate changes from Varia into _tw. I first described my reasoning in May’s release notes:
In search of a new theme to use as a basis for _tw, I found Varia via this comment on GitHub. Varia seems to be as close to an Underscores successor as exists at Automattic and receives ongoing maintenance.
Going through every file in Varia and choosing the parts I thought would work for _tw strengthened my belief that this was the right path forward for _tw, as I kept seeing fixes for things that had long bothered me about Underscores. Subtle changes like the removal of the line break before the document type declaration in header.php
begin to add up over time, and wrapping post navigation in a theme-specific function to be used theme-wide (and using the_posts_pagination
instead of the_posts_navigation
inside that function) has already saved me time in my client work.
I’ll likely make minor refinements to the updated templates as I use them in more projects and as I hear from other people using _tw, but I’m very happy with them so far.
A new Tailwind Typography selector
My original strategy for the Tailwind Typography selector was to add the appropriate prose
modifier classes to the entry-content
class. This felt like the right approach because the_content
was always inside a container with an entry-content
class, and post content was meant to be the primary or only target for Tailwind Typography’s styles.
However, I began to realize that there may be use cases where entry-content
needs classes to control its width and position, and it may not make sense to apply those classes everywhere that uses Tailwind Typography’s styles.
My solution was to create a theme-specific version of the prose
class using the function prefix. So if your function prefix is abc
, your Tailwind Typography class would be abc-prose
, allowing you to maintain all of your Tailwind Typography modifier classes on one line in the tailwind/custom/components/components.css
file.
Comments and text strings
Something I’ve noticed forking other projects over the years is the extent to which comments can drift away from describing the code below them. I wanted to make sure that wasn’t happening here, so I reviewed every comment in _tw and refined them where necessary.
I also reviewed every translator comment to ensure the generated translation files were working as expected.
Finally, I’ve long felt that some of the text strings in Underscores (and Varia) were a bit more opinionated than I would like. I’ve updated them to be more neutral. This only amounted to eight strings being changed—things like the heading, “Oops! That page can’t be found” (with a period) changing to, “Page Not Found” (without a period).
Lock files and other housekeeping
A post-3.1 Tailwind update caused brief issues with stylesheet compilation in _tw that needed to be resolved with changes to the theme. In order to ensure this type of issue doesn’t reoccur, I’ve added lock files for npm and Composer, and I’ll update to new versions as I’ve tested them as compatible.
I’m now convinced I should have included these files all along, but I was influenced by Underscores including them in the theme’s .gitignore
file, and I convinced myself that that made sense because they were generated files (like minimized JavaScript or CSS, as an example).
I also made some very minor changes to the scripts included in the package.json
file. I think the new structure does a better job keeping the build commands for Tailwind and eslint separate (and making them easier to trigger independently).
Coming soon
I had hoped to sneak official WooCommerce support into the generator during the summer, but I’m going to prioritize rewriting _tw’s documentation and recording a few screencasts over those changes. I’m working on a WooCommerce project right now, so the wait shouldn’t be much longer.