Justin Tadlock
Going through my routine this week, I skimmed the latest WordPress theme releases and found a new project that supported the block editor. It even shipped a few custom patterns. While the design was nothing extraordinary, it was a solid theme overall. However, after spending the better part of today writing about it, I did not think I could move forward with the story. Something was bugging me.
It was the same thing I have felt with several others as of late. There were too many missed opportunities. The theme had the foundation, the underlying potential, to be more than it was.
The theme had a commercial “pro” version that users could purchase. However, nearly every pro feature relied on old-school tactics of upselling extra theme options. The one exception was a block-related feature that will be free as part of the Global Styles component likely to ship with WordPress later this year.
Where were the custom block styles? Where could a user snag some unique patterns? Extra nav menus, sidebars, color settings, and typography options are becoming less and less of a value-add for end-users. It is probably safe money right now, and I can understand the comfort of not taking too many chances.
Theme authors need to start shifting gears. Upsells need to come in the form of features that will not be available from stock WordPress. Right now, that means building unique block patterns and styles.
In the last month, I have been tinkering with custom patterns. While I was in the design and development business for over a decade, what I was able to accomplish with the block editor alone — using no custom code — and a well-rounded block-ready theme is merely scratching the surface. We have far better talent in the WordPress community, and I want to see their artistry unleashed.
It all started with the WP Tavern Jukebox podcast — you should check out episodes #1 and #2 if you have not heard them already. Nathan Wrigley, the new host, pushed me enough to put my design-and-dev cap back on to implement some features that he needed. Over the years, I have not worked much with podcasting or any type of audio. This was new territory for me. Ultimately, the podcast inspired me to think about audio patterns.
What is possible with WordPress’s editor today?
I scoured the web for various layouts, looking for modern audio presentations. Numerous concepts were impossible for an end-user to implement from the editor alone. They would need extensive custom block styles from the themes themselves. And, there were several designs that I simply did not think could be done at all, but these typically had plugin-territory elements.
However, I did find ideas that I could run with and make my own. I started with a simple audio file from The Martian soundtrack — I had re-watched the movie the night before and was on a David Bowie kick.
It was simple. Just add Group, Columns, Image, Paragraph, Heading, Audio, and Social Icons blocks. I was happy with the result, and some of my Twitter followers responded positively.
Inspired by the support, I created an alternative layout. It was even simpler by adding Cover, Paragraph, Heading, Audio, and Social Icons blocks.
Based on the original pattern, I built one that used a SoundCloud embed instead of the Audio block. I also created another with some alterations that catered more toward podcasters.
As I dived deeper into this project, the more capable I became at creating layouts. I began to understand what some of the limitations were and piecing everything together around them.
One of the most problematic areas with the editor is that it does not hand over enough spacing control. Therefore, I had to make liberal use of the Spacer block, something I prefer not to use because it relies on pixel units and puts an extra <div> into the markup. To build some patterns, I had to become a little less of a purist and just use the available tools.
That change in mindset opened some more possibilities. I built a couple more audio-related block patterns. They were, again, simple layouts, but I wanted to make them stand out visually with imagery that end-users could add. The goal is to give users one-click access to pre-designed sections, starting points where people can showcase their own creativity.
The next step was to start thinking beyond audio patterns. There is so much more others can do in that space. I wanted to venture out a bit more.
I have since built several other patterns like the following news-type article header that I would love to use on the Tavern in the future:
I could share more concepts, but this seems like an ideal place to stop. The goal is not to showcase my portfolio of patterns. It is to inspire our theme design community in hopes that they build something far better. I also wanted to show how easy it was to pop out a few patterns. Instead of hours of development time, many ideas were cut down to mere minutes. That is the power the block system provides today.
When I wrote about the block system creating commercial opportunities for theme authors in January, it was a theoretical post. This is a follow-up that puts it into a little more practice (without the actual selling, of course).
Imagine, as a theme company, you are building a freemium theme for musicians. You might want to include a few base patterns for users to choose from. However, there is an endless number of alternatives you could offer as part of a pro package.
I am sure there is already a theme author/company out there right now with a multi-purpose theme concept in mind that will eventually have hundreds of patterns. I can only hope that they have a solid categorization system or offer separate packages or imports.
The block pattern directory is slated to land alongside WordPress 5.8. At first, it will primarily be core patterns. However, others will be encouraged to contribute over time. This is a welcome feature for the platform, but it will never match every theme design perfectly. Each theme has its own design nuances. Each has different methods of solving problems.
The best patterns will come from theme authors themselves, especially when combined with custom block styles, packaged and marketed as part of their theme’s experience. Developers can wait until the entire market catches up or jump ahead of the game.
“To build some patterns, I had to become a little less of a purist and just use the available tools. That change in mindset opened some more possibilities.”
For developers focused on performance and clean code, this is a difficult hurdle.
It’s difficult to accept that you don’t have much control over the HTML markup of the elements that you’re trying to make unique.
And another problem with patterns is that the user has to do everything manually. It is somehow counter-intuitive to think of a pattern for “Latest episode”, when the user will have to manually update the block after every published post.
But it is true. The more I play with blocks and patterns, the more my mindset shifts towards them.
If the perfectly clean code is a blocker — and I can certainly understand that — there is still a world of possibilities. Using the Spacer block is more of a limitation when doing this without code from a user’s point of view. From a theme developer angle, the block styles system would make this far cleaner. It is one reason that I think theme-specific patterns will thrive over the block directory. But, I’m definitely on the we-need-better-spacing-controls-and-we-need-them-now train.
It’s rough on me not being able to control the HTML output too. I’m someone who has built entire packages just to fix the horrid HTML with classic theming. The trade-off here is that there is a standard (kind of ignoring that the markup sometimes changes for some blocks). I have a lot of thoughts about what this means for theming and hope to share in more detail in the future.
As for the manual entry of the “latest episode,” I’m imagining integrating with something like a podcasting plugin that had such a block built in. That seems like a more sensible route in a real-world scenario.
The block editor still remains difficult for developers who need to create carefully created custom experiences for end-user clients. Patterns are useful but not that useful for actual real world use cases when we don’t have full control over coding what’s allowed or not allowed (what things can be added, how many, what blocks must be in what position, etc.). For actual real world clients, this just means they can easily create a neat experience, but then by accident can mess it up and not know how to fix it, or have guidance on what is supposed to look like.
Gutenberg also still exposes too little control over core blocks (leading to awful, fragile hacks to hide unsupported or inappropriate features) and many of the basic needs, like validation, that have been well solved and long fulfilled by other solutions (like the trusty ACF) are barely fleshed out or left as an exercise to the reader (potentially to break or rely on deprecated features down the road).
I’m excited for the big features on the way, but it’s the little stuff that’s missing/hardcoded that are really restraining what’s possible to ship.
The block editor still remains difficult for developers who need to create carefully created custom experiences for end-user clients. Patterns are useful but not that useful for actual real world use cases when we don’t have full control over coding what’s allowed or not allowed (what things can be added, how many, what blocks must be in what position, etc.)
From time to time, I keep reading here that right now there are many possibilities to custom-tailor the block editor for clients via templates. But, checking the official docs, I only see a small reference to a property named “templateLock” with just three settings, which is almost useless for real-world site builders and developers.
Gutenberg and Full Site Editing needs better docs. Without that support will take a while.
I love block patterns. Love creating them. Love finding inspirational patterns whether they are actual WP patterns or not, and tweaking them.
This issue for me – and this is purely anecdotal, no hard evidence to back this up – is that your average user does not want to insert a pattern, only to then have to swap out all the content to make it their own. Building a full site this way is much more of a slog than say importing a demo site. Sure, with a full-site demo the content still needs manually changing, but the user has clicked once to import rather than clicking once multiple times to insert multiple patterns, and with a really well thought out demo there is a congruous design.
There is also the issue of – for want of a better word “flow”. The stop-start nature of opening up the block pattern sidebar, searching for a pattern, inserting said pattern only to find it’s not really what the user was looking for, or they don’t then know exactly what to do with it.
All that being said, I’m really looking forward to how patterns will evolve, especially with block-based templates where the pattern content can be more dynamic.
There is definitely a large WordPress user segment that wants a one-click, full-import solution. I’m glad you brought this up because it is one of the few comments that touches on a real business opportunity.
To me, or a savvy theme business owner, that looks more like an opportunity than a barrier. Instead of patterns being the whole solution, they become part of it.
If I’m a business owner, I’m directing my dev team to start building one-click imports for a full site. Within these imports are the patterns themselves. The user doesn’t need to know they are patterns from the start. They just click a button and watch the magic happen. They get their home, about, portfolio, etc. pages easily.
Then, User X comes along a month later and wants to “recreate that portfolio demo page” on another page. That’s when you introduce them to the pattern concept. Walk them through the process of clicking on the Portfolio pattern that you’d already built and wrapped into the demo importer. It’s sort of the best of both worlds.
It’s not like theme authors haven’t already been doing demo imports. Many of them already have the scripts/libraries for doing this. Patterns just add another arrow in their quiver, so to speak.
And, I’d love to see different user-experience takes (“flow”) on handling this too.
My main concern is still “how do I deactivate the block pattern directory in a client site which doesn’t need public patterns”.
Lets say I’m specifying a site for a client and they’ve requested they want a mostly locked down page template with a few editable or switchable elements. They wish to (Create New) Article and see a WYSIWYG layout with key elements fixed in position, editable but not removable, then to select from 3 potential sub-page page layouts (EG: Magazine / Academic Paper / Podcast ) where they can edit safely. In that area they want their editors to have access to a few blocks relevant to the context.
So… to accomplish this first I need to lock down the page template in general and unlock the sub-page using template_lock nested templates. There is only this documentation for this feature:https://developer.wordpress.org/block-editor/how-to-guides/block-tutorial/nested-blocks-inner-blocks/ then lock the outer blocks and unlock the inner blocks with https://developer.wordpress.org/block-editor/reference-guides/block-api/block-templates/#locking
Next I must hide all patterns which are not provided by me (deregister using remove_theme_support( ‘core-block-patterns’ );)
Now lastly I’ll want to completely prevent public blocks from being used, and hide the upcoming UI for the public block pattern directory to prevent Jimmy The Intern from inserting a non-approved external pattern into the approved layout.
There is no documentation for the pattern directory feature. The UI is not specified yet. The GitHub has no docs, information is scant. I’m very busy and I need a central documentation reference for this massive new feature.
The Directory will launch In July 2021 and might appear in the client site at any point afterwards, perhaps part-way through development! So I’ll be needing to deal with it, to turn it off at the very least!
But how? Who knows!
Currently the best option we have seems to be “email Justin”. Now that’s very kind but is it really the best option?
This is why people like me avoid the Block Patterns. I’m actively looking for a solution for sub-page user-selectable templating .. and yet this Block Pattern/ Directory solution looks a lot like a problem for me. It’s another asteroid heading for my planet.
Good points. As I understand these can be controlled by Global Settings (theme.json)
https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-json/
Thanks for this.
I have to admit after trying to implement certain ideas with the block editor and either the design not being possible or, being too much of a purist. I have given up numerous times, this article is definitely pushing back to the editor again.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.
WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…
© All Rights Reserved. Powered by WordPress, hosted by Pressable
