Managing Styles for Custom Blocks

Learn strategies for using Tailwind in theme-specific custom blocks

If you’re creating custom blocks for your project and you want a single Tailwind build process capturing both your WordPress theme’s utility classes and the utility classes for your custom blocks, you have a number of options:

• In your custom block repository, use dynamic blocks and add a filter to the dynamic block’s HTML markup. Then use that filter to put the block’s markup in your theme repository with add_filter.
• Put your block plugin or plugins inside your theme repository.
• Use a relative path in the tailwind.config.js content key, pointing outside your theme repository.
• Manually safelist the utility classes required by your block.

My preference would be to move the block’s markup to your theme via a filter. If that isn’t possible, there are some potential downsides to the other approaches:

Putting your block plugin inside your theme repository

Imagining that you add a plugin folder alongside the theme folder in your theme repository, you would need to create a symbolic link to add the plugin to WordPress during local development, and you would need to create a separate build process for the plugin.

Using a relative path in your configuration

This requires all developers on the project to maintain the same directory structure, which may mean placing your theme inside a larger repository containing the theme, plugin and anything else associated with your project.

Manually safelisting the required utility classes

This means any changes to the block’s utility classes need to be made in two places as you maintain both the safelist and the class attributes within the block’s markup.

All Documentation