Posted on

A Farewell from Justin Tadlock

Around three years ago, I was at a crossroads. I had spent nearly my entire adult life and most of my professional career within the WordPress space. However, the responsibilities of being a solo theme/plugin shop owner were like a boulder upon my shoulders that I could no longer hold up. After 11 years in the business, I was ready to throw in the towel.

My work was my life, and my life was my work. I was not sure if I even knew how to do anything else. I briefly considered returning to South Korea for another year-long stint teaching English as a second language. But, I had already spent years rebuilding my life and relationships back in my home state of Alabama. Plus, I was not prepared to say goodbye to my cats for that long.

The only other practical experience I had was gardening and farming work. I have spent many summers working watermelon fields and hauling hay under the heat of the Alabama sun, and I have piddled around in my own garden over the years. However, I was not in a financially stable position to start my own farm. It was too risky a proposition at that stage in my life.

I was also not quite ready to let go of WordPress. There was more that I wanted to accomplish, but I still faced the reality of needing to move on from the place I was at or find some way to get more joy out of the work I was doing.

It was not until a few months later that the writing position for WP Tavern opened. I was hesitant about it at first. I figured I had the credentials and experience to do the job, but daily writing, editing, and publishing would be unlike anything I had taken on before. Sarah Gooding, who has been the best colleague anyone could ask for, convinced me that I should pursue this job.

It turned out to be one of the best things to ever happen to me.

As I got into the swing of things and began to find my voice, I was once again genuinely happy to be involved with the WordPress project. Since I have been here, I have rekindled the flame I once had with our beloved platform.

I have made wonderful friends along the way. It has been a blessing to have the Tavern and its readers in my life.

Today, I am ready for a new challenge. I am stepping down from my role as a writer at WP Tavern.

No, I am not ready to start that farm just yet. Y’all cannot get rid of me that easily. I will stick around the WordPress community for a while, but today is not about my new role. It is a celebration of the Tavern.

I have published 647 stories and written 857 comments as of this post. I can only hope that, somewhere along the way, I have made an impact in some of your lives or work.

As I leave, I have one request: be kind to one another.

I believe we all want WordPress to be successful. We might have different opinions about how to make that happen. Sometimes, those ideas clash, but if we all treat one another with respect and have constructive discussions, things will work themselves out.

To our readers, thank you for going on this journey with me.

There are two remaining questions I want to answer before closing this chapter in my part of that journey. Feel free to continue reading. Otherwise, thank you for making it this far.

Writing About WordPress

Written text on a spiral-bound paper notebook with a pen lying on top of it.
Photo by David Chandra Purnama.

Someone messaged me a week or so into my employment at WP Tavern about writing for WordPress. They wanted to know how they could become a writer on WordPress-related topics and one day work in the field. At the time, I did not have a great answer to the question. Maybe I still do not, but I will take a crack at it.

We might as well start with the advice of one of the most prolific writers in modern history, Stephen King. At the end of The Stand, one of my favorites from him, he answered this same question, and it has always resonated with me.

When asked, “How do you write?” I invariably answer, “One word at a time,” and the answer is invariably dismissed. But that is all it is. It sounds too simple to be true, but consider the Great Wall of China, if you will: one stone at a time, man. That’s all. One stone at a time. But I’ve read you can see that mother— from space without a telescope.

I think he may be wrong about seeing the Great Wall from space (Where’s a fact-checker when you need one?), but it is still generally sound advice.

I have been writing about WordPress for 17 years. Sometimes on my personal blog. At other times, I have taken one-off jobs. And, of course, I have written 100s of posts here at the Tavern. What has always helped me is sticking to topics I am passionate about. There are days when the job can be a grind (especially during slow news weeks), so you must love what you are doing to sustain any sort of career in writing.

I have a B.A. in English with a secondary concentration in journalism. However, my education merely provided a solid foundation. It is not a prerequisite for doing the job.

No one can teach you how to build those habits necessary for a sustainable career. They are too personal, and you can only figure out what works by practicing.

No one can give you your voice. That is a discovery that only you can make, and writing is a discovery in and of itself.

My advice to would-be writers is to give National Novel Writing Month a shot this November. It is a challenge to write 50,000 words in 30 days. I have won twice and hope to do it again this year. I guarantee that you will figure out everything you need to know about yourself as a writer if you push yourself through the challenge. It is OK to fail. Just dust yourself off and try again if you have your heart set on it.

To the person who asked this question: I am sorry for not remembering your name. It has been over two years, and my memory is not what it once was. But, I hope you are reading now.

Spilling the Beans

Coffee Beans. Photo by Chuck Grimmett

There is a question I get asked. A lot. Some of you probably already know what it is and have, perhaps, asked it or some variation of it yourself.

Does Matt dictate or control the content that we cover?

Since it is my last day on the job, I might as well let readers peek behind the curtain. And the answer is no.

Sorry to let down our conspiracy-theory-loving readers, but the truth is just not that juicy.

I always joke that I have only talked with “the boss” a handful of times while working here. That is pretty close to the truth (I have not actually kept count).

From the day I arrived until today, I have had complete independence to thrive or fail by the result of my work. It felt like our small team had been left on an island to fend for ourselves at times. We must go through the same channels as other publications for information and have never been given special treatment.

This level of autonomy is vital for journalistic integrity.

The WordPress community will always need a publication where its writers have the independence to do their work without conflicts of interest. The Tavern has always been that place, and I do not expect it to change going forward.

I appreciate that our readers have trusted our team to perform this job. It is a responsibility that has not been taken lightly. I am proud to have contributed in at least in some small way.

Posted on

Gutenberg 13.2 Adds Persistent User Preferences and a Visualizer for Margin and Padding Controls

Gutenberg 13.2 was released earlier today. While much of the developer community is gearing up for the WordPress 6.0 release in two weeks, work continues steadily on the plugin, driving future updates. The latest release is not as hefty on enhancements as previous updates but includes around four dozen bug fixes.

Despite a heavy focus on squashing bugs, there are several welcome improvements in the plugin update. Persistent user preferences will make for fewer surprises when opening the editor. New visual updates for block spacing and the Post Comments Form block make it easier to design layouts.

Developers should look at the early work on a new settings hook. This represents one step toward creating the concept of “sections” that can house settings and styles for block instances and descendants. Patterns are a prime example of the necessity of sections. Matias Ventura covered the various uses in a separate open ticket.

The latest release also removes spotlight mode for template parts, and I say, good riddance. The editor already has such a mode for all blocks, and users who prefer it can enable it.

Persistent Editor Preferences

WordPress post editor with the 'welcome to the block editor' modal that pops up when first using it.
Welcome to the editor popup.

Have you ever visited the WordPress editor and noticed the “welcome” popup, despite dismissing it ages ago? Or, logged in with a new browser only to reconfigure settings, such as enabling top toolbar support and turning off fullscreen mode? Annoying, right?

This has been a long-standing issue caused by WordPress storing user preferences in the browser. In Gutenberg 13.2, these preferences are now saved as user metadata in the database and should no longer pose an issue.

Sarah Gooding took a deeper dive into this problem and solution in an earlier post on the Tavern.

Padding and Margin Visualizers

WordPress block editor with a Group block in the content canvas. Above and below it are boxes that visually represent margin being added to it.
Adding margin to the Group block.

Landing in the pretty-neat-and-nice-to-have category is a new “visualizer” feature for block margin and padding. Essentially, it displays a colored box, representing the space when one of the two options is adjusted. It quickly fades out and returns the canvas to its default look.

I am a fan of this change. It draws the eyes back to the canvas and allows users to visualize how the block spacing is applied.

Comments Form in the Editor

WordPress site editor. The canvas area displays a comments form as if viewed by a logged-in user. It has a title, message box, and submit button.
Comments Form Block in the site editor.

The Post Comments Form block was simply a placeholder in the editor in past releases. This did not allow end-users to see how it would look on the front end of their sites.

Gutenberg 13.2 updates this to show something closer to what it will look like on the front end, at least for logged-in users. This also lets the user see how color and typography customizations will be displayed.

This is a two-part change. The Comments Query Loop block now outputs the form within its default template. This way, users and creators will not need to build out each part of the overall comments area.

There is still much work to do for the Post Comments Form block in the long term. It needs a broader selection of design tools for starters. However, it could also use a revamp that provides fine-grain control over the various elements shown for logged-in and logged-out users. That may even mean splitting the form into multiple blocks. For now, the additional visualization will have to suffice.

Margin Support for Separators

WordPress post editor that has two paragraphs separated by a Separator block with large sections of whitespace in between.
Adding top and bottom margin to a Separator block.

The Separator block now supports top and bottom margins. Users can adjust it from the spacing tools in the sidebar.

It is a small change but a welcome one. Users could previously increase the space between a Separator and sibling block through other means, such as setting the margin on the sibling or using a Spacer. However, those were often unintuitive solutions. And decreasing the space sometimes seemed an impossible task.

Posted on

Catch FSE Is a Bold, Business-Friendly WordPress Block Theme

And another theme shop hops on the block bandwagon. Catch Themes’ first block-based theme, Catch FSE, landed on WordPress.org over the weekend.

The company is one of the most prolific authors in the official WordPress theme directory, touting a total of 109 themes. There are only a few others with such an impressive body of work, at least in sheer numbers. Averaging over 10 new releases each year for the last decade is no small feat, and that just accounts for the company’s free themes.

At a time when WordPress is still in a transitioning phase between classic, PHP-based themes and those built entirely from blocks, the community needs leaders in the space pushing the project forward.

With WordPress 6.0’s slew of features, I expect we will see more and more authors join the ride.

When reviewing new themes, I typically install them a few days ahead of time and test them off and on. Then, I decide if they are worth sharing with the Tavern audience. However, in this case, I am going in blind. Well, not entirely blind. I am familiar enough with some of Catch Themes’ past work to know the company has produced some well-designed projects. Plus, I had quickly peeked at the demo.

My immediate reaction after installing and activating Catch FSE was disappointment. The homepage did not look like the theme’s screenshot or what was shown in the demo. Instead of the business-friendly layout I expected, I gazed upon a standard blog post listing.

Dark WordPress theme design that shows a header and a blog post excerpt with a featured image of a bird.
Default homepage blog posts.

This should not be happening in the block themes era.

Theme authors are not entirely at fault for this problem. Those who have submitted their designs to WordPress.org have been conditioned over the years to do this. This was a necessity in the classic theme era because users did not have the same control as they do now over their homepages. The site editor gives them that freedom, and it also breaks the shackles that have been holding theme authors back for years.

Now is the time to be bold. Now is the time for theme authors to put their signature on their work, showcasing their design skills with those custom homepages they have always wanted to provide out of the box. Now is the time to break free of those draconian guidelines from an era that block-based themes are leaving behind.

Catch Themes, if you are reading this, I want to see a front-page.html template in version 2.0 that outputs the following:

WordPress demo site homepage that showcases a header, large hero section, and three boxes of featured content.
Homepage design from the Catch FSE demo.

Give users an immediate solution instead of forcing them to create a new page, select a template, and move into the template editor to customize it.

A blog post listing is a perfectly acceptable default for a theme, and Catch FSE’s works well enough—those gradient “read more” buttons are also sweet. However, if the screenshot and demo showcase a custom homepage, that is what I expect to see upon activation. And, based on my somewhat educated guess, it is also what the average user will expect.

After tinkering around with the theme for a while longer, I realized how well-designed it was. The typography made for an enjoyable reading experience. Each template was well laid out. The footer “widgets” even felt right. Catch FSE was suddenly making a beeline toward the top of my favorite themes list this year.

And, I must take another moment to appreciate the gradient used for buttons in the theme, as shown in this screenshot of the About Us pattern:

Media & Text block serving as a base to an "About Us" pattern. On the left is a artistic image of a laptop. On the right is demo text and a button.
“About Us” block pattern.

Those who have followed me long enough know that I often dislike dark designs. Automattic’s Livro made me rethink my position earlier this year. With Catch FSE, I am moving beyond merely tolerating such designs to enjoying them. Well, some of them. Let’s not get crazy.

What Catch FSE does as well as any theme is offer a well-designed set of block patterns. In total, it ships 15 that users can pick and choose from.

WordPress post editor with the patterns inserter open. A CTA pattern with a heading, paragraph, and button are in the content canvas.
Inserting a call-to-action pattern in the page editor.

From a development perspective, other theme authors should take notes. Following the DRY principle, Catch FSE routinely reuses its own patterns in its templates and parts.

The theme registers 10 block styles, but it is impossible to know what most of them do without trying them out first. The user-facing label simply reads “Theme Style” for eight of them. What does that even mean? If it is the theme style, should it not be the default?

Most are generally design variations for the various blocks they are attached to. They might alter the typography, colors, or other styles, as shown in the following screenshot of the Blockquote block with the “Theme Style” assigned to it:

WordPress post editor with a quote from Shakespeare in the content canvas.
Assigning a custom style to the Blockquote block.

That is actually a well-designed Blockquote style, but I would have never known it was something I would want to use if I had not been digging. Custom block styles suffer from a bit of a discoverability problem by default, and cryptic names for them are doing users no favors.

Most of the issues I had with the theme were around the comments list design. However, it is not yet using the new Comments Query Loop block shipping with WordPress 6.0. In a future release, I would like to see the author put more time into bringing it up to par with the rest of the theme’s design. At the moment, it feels like a feature that was tacked on as an afterthought.

Catch FSE is a freemium theme with a commercial add-on plugin that offers three custom blocks and 10 patterns. I like seeing the upsells focused purely on value-adds.

I have often said that the next generation of freemium themes cannot be like the last. Developers will need to focus on enticing users with solutions to their problems instead of nickel-and-diming customers, locking necessary features behind a paywall. The block system is changing the game, and when most users can flesh out their site designs via the built-in WordPress site editor, the old-school upsells will not cut it.

Turnkey, plug-n-play solutions are needed. I may be so far off-base that I am not even in the ballpark, but I foresee block patterns being a central part of that. Once commercial theme authors figure out how to market and build with these new tools, we will see an explosion of growth in the block-based themes space.

Catch Themes’ 10 commercial patterns represent a start, but I imagine the company will need to continue pushing limits to see a worthwhile return on its premium upsell. Now is the time for experimentation while the field is wide open.

My biggest nit-pick? The name.

Attention all developers: Can we stop naming themes “Something FSE” and “Guten Something”? It is confusing and makes it tough to remember which project is which. Take some time to come up with something that stands out in the crowd.

Catch FSE is a bold and beautiful business-ready theme, but it needed a name to match its personality. I only hope folks remember it.

Posted on

WordPress 6.0 To Ship New Block Locking Feature

WordPress 6.0 has several new features that should make any extender happy about building on top of the platform. However, one of the more advanced tools is the ability to lock blocks, which can be used to prevent specific blocks from being moved or removed.

The upcoming release includes a new “Lock” setting in the block toolbar’s options dropdown, as shown in the following screenshot:

WordPress site editor with a header section shown in the content canvas. A dropdown is shown with the "Lock" option highlighted.
Selecting the Lock option from the block toolbar.

Once clicking the lock option, a modal appears that allows the user to disable movement of the block or prevent its removal:

WordPress site editor with a header section shown in the content canvas. A modal overlays the screen with options for disabling movement or preventing removal of a block.
Block locking options.

Thus far, the best use case I have found for locking blocks via the UI is to stop accidental edits. Because users have access to the UI settings by default, they can disable the lock later if I need to move something around the layout or delete it.

On the surface, this may not seem like a particularly robust feature. However, the real power of block locking is on the development end. Theme authors can use the new lock key to prevent end-users from moving or removing specific blocks in their templates.

The following code is an example of a Group block that prevents both:

<!-- wp:group {"lock":{"move":true,"remove":true}} -->

<!-- /wp:group -->

This can be especially handy for more complex layouts, such as a header and navigation area. Theme authors can now exert more control over the user experience in places where the design might easily be broken.

Note that locking does not trickle down to nested blocks. Therefore, if an outer Group block is locked, users can still add, remove, or move anything inside it. Themers must also add a lock to any nested items they want to keep in place. There is an open ticket and some early design work around locking nested blocks, but it will not land in WordPress 6.0.

While this new feature offers more control for theme authors, it does not grant absolute power. Users can still unlock blocks by clicking the lock icon in the toolbar. However, as is the common saying in WordPress development circles, “There is a hook for that.”

George Mamadashvili covered using the block_editor_settings_all filter hook to customize access. He provided a few examples of enabling or disabling the UI based on capabilities, user email, and context, such as the post type. There is no limit on how developers can use this hook. In general, capability checks are typically the best option when dealing with permissions.

A developer could disable any user’s ability to move or remove blocks. In real-world cases, this should help agencies and freelancers create tightly-controlled experiences for their clients, especially when handing over access to the site editor.

For developers who are building themes for release on WordPress.org, the Themes Team currently disallows using this hook. It falls under the “plugin territory” guideline. Last month, the team announced that themes could lock blocks but not disable the user’s ability to unlock them.

Block locking is not limited to block-based templates. It is also possible to lock things down within posts or pages. With a custom permissions setup, developers could extend it to give administrators and editors free rein while preventing authors and contributors from overriding locks, for example.

By default, all blocks support locking. For plugin developers who want to opt-out of this feature, they can set the supports.lock key to false in their block.json file.

I am eager to see new WordPress plugins built on this system. There is plenty of room to explore from site customization and editing flow angles.

For further reading, check out Anne McCarthy’s post on creating curated experiences with locking APIs and theme.json.

Posted on

FSE Outreach #14: Building Recipe Posts With Lists and Quotes

Round #14 of the FSE Outreach program is now open to the public. Anne McCarthy, who oversees the program, calls for testers to build a recipe post using existing tools like the template editor and some new and experimental blocks.

Those who want to leave feedback can do so until May 18. The program always needs testers from across the spectrum of user experiences. This is an easy way to contribute back to the WordPress project.

The latest round calls on users to test some new blocks in the Gutenberg plugin. Some of these are related to comments. I opted out of this part of the test because I had already covered everything I had to say in an article in early April. That post, along with feedback from the community, helped drive some of the changes that should land in WordPress 6.0.

My focus was on the List and Quote block updates for this round. “Version 2” of these are available via Gutenberg 13.1 and must be enabled via the Gutenberg > Experiments admin screen.

The new List is no longer a single block. Instead, each item within it is a separate block of its own. Likewise, for each sub-list.

The overhaul of the Quote block allows end-users to nest other blocks within it. By default, this is a Paragraph, and there seems to be no limit to what can be placed inside.

I had fun with this testing round. Recipes are my jam, so I had to pick the perfect one to share. Ultimately, I built a custom “recipe template” and a faux recipe post, as shown in the following screenshot:

WordPress post on the front end of a recipe. It has a hero header with with spaghetti tacos image, followed by a description. Below that are two columns. A recipe card on the left and tips from readers on the right.

For this experiment, I relied on the ever-reliable Archeo theme by Automattic. It has been my go-to for several weeks now, and I will likely continue using it until I find something new that sparks my interest. It is definitely a solid solution for these types of tests.

Testing the New List and Quote Blocks

The call for testing asks volunteers to create a custom template for recipe posts. The only change I made to the theme’s default single template was to wrap the site header, post title, and post excerpt in a Cover block tied to the post’s featured image.

WordPress template editor that showcases a Cover block housing the site header, post title, and post excerpt.
Custom single recipe template.

I described how to do this in a post in April. Once that was in place, I moved forward with building out a recipe post.

Ultimately, I added a short intro for the recipe. Then, used the Columns block to section off the recipe card and some tips from readers. This is where I was able to dive into the experimental List and Quote blocks.

The List block proved to be the most problematic. It seemed impossible to add a new item to the top level after an inserted sub-list. Clicking the first item and hitting Enter deleted everything nested below it. No amount of clicking or keyboard input seemed to get me back to the top level to continue adding more items.

Eventually, I wised up and navigated to the top level via the breadcrumbs in the editor. Then, I clicked the “+” icon (this could also be done from the editor’s list view). As someone who primarily works from the keyboard, this felt unintuitive.

WordPress post editor with a nested list block in the content canvas.
Troubleshooting a List block.

It also seems impossible to escape the List and into a new Paragraph block. In the past, this could be accomplished by hitting the Enter key twice while on the final list item. That action now creates a nested list.

Markdown-based lists are also not transformed into a List block when pasted into the editor. The formatting is lost, and each item gets absorbed into a Paragraph block.

The new Quote block worked well. It is now possible to add nested blocks inside it, one of the features I have long needed as a writer here at the Tavern when quoting from third-party resources.

One enhancement I would like to see for Quote v2 is the <cite> element separated into a standalone block. This would allow end-users to customize its design separately from the wrapping <blockquote> on the block and global levels. Currently, only theme authors can modify its style, which must be handled via custom CSS.

Overall, I am eager to see the finalized versions of these blocks. They will bring back some of the missing functionality from the classic editor and give users the flexibility to do even more.

Posted on

WordPress Should Support Featured Images for Categories, Users, and More

One of the features that I have long wanted for WordPress has been on my mind lately. It is not a new idea, and it has been implemented in some form or fashion by plugin and theme authors in the past. However, it has never been standardized. WordPress needs featured images for more than just posts. It should support them for taxonomy terms (e.g., categories, tags) and users.

One month ago today, I participated in Round #13 of the FSE Outreach Program. It was the first time that the Gutenberg plugin allowed adding a new author template via the site editor (this is coming in WordPress 6.0). Author templates have always been supported if added via the theme, but users now have that power. The program called for volunteers to test this feature and some new author-related blocks.

As I always do when participating in the FSE Outreach testing calls, I tried to push the design limits of the editor. Much of the program focuses on the user experience, but I want to go beyond that and find those design-related pain points.

Ultimately, I settled on a design for my faux author template:

alt="Author archive as shown on the front end of a WordPress site. Features a large hero header with the author avatar, title, and bio."
Custom author template.

I added a Cover block as the backdrop for the author profile section at the top of the page. I liked the look of the mountains mixed in with the active theme design. The problem was that there was no way to personalize that for each user account. Sure, every user gets to select their own avatar and write their own bio, but there is no easy way to let them have their own featured image.

Technically, it is possible to do this by creating custom author-{$id}.html or author-{$username}.html templates and manually and uploading them to the theme’s /templates folder. For controlled environments, such as client builds with a set number of users/authors, it is a possibility. Even in those scenarios, it is a bit of a management headache. And it does not account for every other WordPress user who might want to do something similar.

In the classic era, the same issue existed. However, it was relatively simple to code for the front end in a PHP-based templating system. For block themes, most would need to create a custom block. The image upload form would be the same in both scenarios (handled on user profile and taxonomy term admin screens).

The trouble with custom blocks is they do not tap into the core blocks’ built-in features. For example, WordPress 6.0 will allow setting a Cover block’s background using the post featured image. In the long term, core will likely support this for other image-related blocks like Media & Text. Porting these same features over to third-party plugins does not make sense.

It also does not empower users who want to build such designs with WordPress. Nor does it provide theme authors with the tools to ship templates and patterns with unique layouts to the public.

While I have primarily focused on author templates, the same arguments stand for taxonomy term templates, such as categories and tags. For example, I built out a quick category template using a similar design as shown earlier:

Front end of a WordPress site for a category archive page. The category header section has a forest image in the background with the category title and description sitting on top of it.

The image works well for my example Nature category but not so much for others. We need a way to dynamically display per-category images.

There is at least a solid plugin for taxonomy terms: WP Term Images. Perhaps I can convince John James Jacoby, the plugin’s author, to extend it to the block system.

After stewing on this for a month, I still did not know whether I could make a convincing argument for the feature other than I think this would be cool. I am unsure if there is enough demand for it. However, it is OK to dream about new things from time to time and share those ideas with others. So, this is me, dreaming out loud, hoping that one of the items from my wish list will land in WordPress one day.

What are some of the things you want to see?

Posted on

Gutenberg Hub Launches an Online Page Builder App Using WordPress Patterns

I have been raving about the power of patterns for what feels like forever at this point. And, just when I start wondering what this feature will look like next, someone surprises me with a new idea. Often that person is Munir Kamal.

He mentioned that he would share a “little” page-generation app that ties into the WordPress patterns library earlier this week. Today, he publicly announced that it was live on Gutenberg Hub.

The app is still at a concept stage, but the current online version works well. Essentially, it is an interface that allows users to piece together patterns to build entire pages. Unlike the block editor itself, users cannot directly edit the content. Instead, they can mix and match patterns, copy the block code, and paste it into the editor on their WordPress install.

When first visiting the Builder sub-site on Gutenberg Hub, users will see an empty canvas with a list of core pattern categories in the left sidebar panel. Inserting a new pattern into the page is as simple as selecting a category, searching for a preferred design, and clicking on it:

Website with a content canvas and WordPress block pattern in it. On the side is a list of pattern categories with an inspector open, displaying multiple pattern options.
Inserting a pattern into the Builder app.

Users do not need to stop after inserting a single pattern. The idea behind this project is to build an entire webpage from multiple patterns. Then, grab the resulting block code via the “Copy Code” button and paste it into the editor in WordPress. It is a convenient way to play around and try out new ideas.

By default, the patterns are presented for a desktop view. However, users can check how the design responds to tablet and mobile devices.

The Builder pulls all of its current patterns directly from the WordPress Pattern Directory. The API is public and allows others to build applications on top of it.

While Kamal made no indication that he would showcase patterns from outside the official directory, it is probably not out of the question. The Builder UI has a section labeled “Core” in the sidebar. I am merely speculating, but I assume he plans to extend this in the future.

A menu button sits in the top right corner of the Builder interface. This opens the Navigator interface. It allows visitors to customize the page layout:

Builder app with a left sidebar showing a list of WordPress block pattern categories, the center a content canvas, and the right a navigator of inserted patterns.
Navigator panel on the right.

There are options for moving entire patterns up or down, trashing them, or duplicating them. Based on my experience thus far, this was an easier way to make adjustments than when attempting to select large groups of blocks in the WordPress editor.

The only feature I would request is a “back” button. It is easy enough to open the navigator and trash an inserted pattern, but it would be quicker to undo that action via a dedicated button in the toolbar area.

Gutenberg Hub’s Builder does not allow visitors to customize the content of the patterns. Its purpose leans more toward layout creation. The customization happens when users paste it all back into their own WordPress editor.

Perhaps my favorite feature of the app is that users can share their creations with others. The Builder creates a custom URL for each variation and makes it easy to share over social media:

Builder app with an overlay for sharing both a direct link and selecting among multiple social networks.
Popover after clicking share button.

The concept of sharing is almost built into WordPress’s block system. Because everything is built upon a well-rounded set of standards, the tools that others build on top of it make it easy to continue paying it forward.

While this project is still in the concept stage, I am eager to see where Kamal takes it in the future. He also shared a short YouTube clip of the plugin in action.

Posted on

A Look at Twenty Twenty-Two’s Upcoming Global Style Variations

It is no secret that I have been excited about global style variations. The upcoming feature will allow theme designers to bundle multiple design presets. In turn, end-users can cycle through them, selecting their preferred look without changing their active theme.

I have been writing about the feature since November 2021, holding out some hope that it was going to land with WordPress 5.9. It did not ship with that release, but I have eagerly followed every related ticket since, knowing it would eventually come.

In January, the feature was merged into the Gutenberg plugin. That almost feels like an eternity in “tech time.” With everything else happening in the current WordPress 6.0 release cycle, it is easy to forget that it will be a flagship feature in just a few short weeks.

If I am being honest, I feel like I have been waiting for this my entire career in the WordPress space. I think I have always known I have wanted it without always being able to verbalize it. I was an early adopter of child themes and began using them when they were a feature only available via a third-party plugin. WordPress always seemed to be missing something between an entire theme and a child that made sense for developers and users.

Many theme authors have tackled this in one way or another. Some would package skins that users could pick from. Others presented preset color and font combinations. However, these methods were never standardized.

Global style variations are the answer I have been searching for. The system provides theme authors an easy way to bundle multiple variants without shipping them as separate child themes. Themers merely need to drop custom *.json files in their theme’s /styles folder. These appear in the Global Styles panel in the site editor for users.

Twenty Twenty-Two will officially be the first default theme to ship these style variants. The plan was to bundle six styles but was recently pared down to four (including the default). The following are screenshots of the three new variations expected to land in the next version of the theme:

Blue, Pink, and Swiss variations for Twenty Twenty-Two

These could change as we get closer to the WordPress 6.0 release, but they are the latest iteration. For others who want to test them, they are available via a pull request on the WordPress Develop GitHub repository. They have not been merged into the core code yet.

If I had to pick a favorite, it would be the Pink variation. It is not something I would typically select, but the IBM Plex Mono font works well with it.

I am a fan of shipping fewer variations for the initial set. As Kjell Reigstad said on the associated Trac ticket, it should “help folks differentiate them even more strongly.”

While Twenty Twenty-Two will be the first default theme to implement global style variations, other theme authors have already been offering some choices for users. Alara ships seven additional styles, and Frost has a Dark Mode variant. Users can already test these alongside the WordPress 6.0 beta or with WordPress 5.9 and the Gutenberg plugin installed.

Variations are primarily being used as a quick way for end-users to choose a preset design. This is a one-off choice, but I envision a broader scope for the feature in the coming months and years.

Using Frost’s Dark Mode as an example, I could eventually see that being tied to the site visitor’s settings, showing the variation their preferred scheme. If someone is not already working on a plugin for this, they should be.

Another possibility is that some site owners may want to have seasonal or event-based design tweaks that are easy to switch between. It would be fun to see WordPress release a Christmas-based Twenty Twenty-Two variation later this year.

Theme authors who want to start bundling their own style variations should read Carolina Nymark’s tutorial. It is one of the most up-to-date guides and covers everything needed to get started.

Posted on

Munir Kamal Updates and Overhauls the Block Slider Plugin

A couple of weeks ago, Munir Kamal updated his Block Slider plugin for WordPress. While not as popular as some of the other projects he has spearheaded, such as Editor Plus, he wanted to breathe some fresh life into it.

The original plugin allowed users to insert a slider block and create the slides directly from the post or page editor. The new approach is similar. However, end-users can only edit it from a new “Block Slider” post type.

WordPress block editor with an interface for inserting slides into a slider.
Creating a slide in the block slider.

Existing users should note that the new version breaks compatibility with their old galleries. It would be wise to make a backup to revert to if necessary.

Kamal listed several benefits to the updated approach:

  • A clean and wider slide editing/creation interface. Comparatively, the ‘block’ had less room to work with.
  • The fact we have a separate interface/post type, I took the opportunity to modify it a bit to make the slide creation easier for users.
  • This approach lets users create and manage sliders easily from one place (post type) compared to in-page block.
  • Using the slider to multiple pages/posts is easier with this approach.
  • The best part and the most important reason is that the slider can be used outside Gutenberg editor or anywhere with any page builder using the shortcode (or I could provide more ways to use it in the future).

Depending on the user, some of those can be advantages. However, for others, they are not. For example, not all websites would benefit from a dedicated slider management admin screen. Sometimes, a one-off slider is all that is wanted for something like the front page. The new approach creates more work and adds an unnecessary admin menu for those use cases. For users who add multiple sliders to their sites, it should simplify management.

Kamal touts using the block shortcode anywhere, but this feels like a step back from the earlier version of the plugin. It is now impossible to see what a slider looks like mixed with page content without previewing it on the front end. When laying out a full-page design via the editor, having the live preview can be vital to putting it all together.

“I am working on a block that lets you insert a slider (and maybe do a bit more),” Kamal said when I questioned him on the implementation. “It should be out in the next update soon.”

Overall, the user experience of creating and customizing sliders feels smooth. It is easy to attach new slides via the “Add Slide” button fixed to the bottom of the screen and navigate to others.

WordPress block editor with a Block Slider block that has multiple slides and buttons for navigating it at the bottom of the screen.
Adding multiple image slides.

Other than a minor spacing issue where the right navigation arrow butted against the side of the screen, I had no trouble using it. It worked well in the editor and on the front end.

Block Slider has a commercial version that begins at $29 per year. It includes updates and support for one site. There are also five-site and unlimited tiers for $49 and $99, respectively.

However, most users will likely not need the upgrade. Other than a handful of options, including a carousel view and a few customizations, most features are in the free version. And the plugin does not lack out-of-the-box options.

If anything, the number of settings is almost dizzying. Users who want ultimate customizability should enjoy tinkering with the design tools. Those who prefer a scaled-back interface can always leave the defaults in place. Otherwise, diving into them can be overwhelming.

Kamal shared an intro video to the plugin that barely scratches the surface of what the plugin can do:

I like where Kamal seems to be going with the plugin. His target audience focuses on users who love plenty of options and an easy way to manage their sliders. For one-off use cases, it is best to look elsewhere. Some bits still feel a little rough, like using a shortcode when placing the slider on a page, but that can always be addressed later.

WordPress Slider Plugin – Block Slider
Posted on

Failure and Learning: My Experience Building 4 Block Plugins in a Week

I built four block plugins last week. It was not something I had set out to do. I did not wake up one day and declare, “I think I will build a suite of custom block types over the next few days.” It just happened.

The first plugin I built was to address an old ticket for Gutenberg that had not seen any traction. Perhaps others were not interested in the idea, or it never crossed their path in the sea of 1,000s of other tickets. Why not just build it myself? So, I did. It took a couple of hours, but much of that time was re-configuring the @wordpress/scripts build script to my liking and reading docs.

With that plugin out of the way, I started seeking new problems to solve. One that was already on my radar was the missing Comments Title block necessary to bring the upcoming Comments Query Loop block to feature parity before WordPress 6.0 lands. So, I built a rough plugin for it.

WordPress site editor with a Comments Query Loop inserted. At the top, a Comments Title block is highlighted.
Comments Title block in the site editor.

Fortunately, others took that initial idea and ran with it, building something far more flexible than my first attempt. Now, there is a new block in Gutenberg.

I had a couple of other itches I wanted to scratch, and there was little to do on a rain-filled Sunday. Namely, WordPress does not include equivalent blocks for the wp_list_users() and wp_list_authors() template tags. That seemed like an oversight, so I tackled early versions of those.

I will put these up for free on the official WordPress plugin directory soon for folks interested in them. I can only hope they will help someone else in the future.

This post is about sharing my experience, the journey, rather than what became of it all.

Recently, someone asked whether I could operate in this JavaScript-heavy world of blocks as a developer. It has been over two years since I took on a writing position here at WP Tavern and developed real-world solutions for users. I was only starting to use JavaScript with the block editor back then.

Since then, I have dabbled with block themes, even releasing one on WordPress.org. I have built a few PHP-based projects for fun in my spare time. I even created my first custom block plugin last summer and shared my experience with readers. Shortly after, I built a second.

That burning flame I had nearly a year ago quickly died down. That had more to do with the state of block theme development, which was still in its infancy, than anything. I was excited about its potential, but consistent breakage was more than I had time to deal with, considering all of it was a fun side project.

At heart, I am still a programmer, a problem solver. So, I began anew.

The first stop was the JavaScript Build Setup documentation for building blocks. I was going to learn the “WordPress way” this time around. For the most part, I followed through with that.

The only hiccup I had was the setup script snake-casing my namespace, x3p0, into x_3_p_0 in function names. That was a mess to clean up. However, I did not need to go through that process in other block plugins. I just wanted the beginner experience on the first go.

For building blocks, @wordpress/scripts is all that is necessary. I tinkered with it, added a couple of custom commands, and modified the input/output folders. However, it has everything needed to get up and running fast.

I skipped past the Hola, mundo! (Hello, world!) portion of the setup tutorial. Whenever I set out to build anything, I plan to dive headfirst into something a bit more complex. However, it never hurts to get the basics down to see how things work.

My style of programming is one built upon failure. I venture out with an idea, fail miserably, and continue learning from my mistakes. A short while later, I had a custom block type that showed a link back to a nested comment’s parent:

WordPress site editor showing a Comments Query Loop with two comments. A block reading "in reply to Comment Author" is highlighted.
Comment parent link block.

While that was a success, I have learned that some other built-in editor components might make it even better.

That first block gave me a taste of modern development on WordPress. It was a relatively simple plugin to build, but it was easy to see how one could expand it out to more complex features.

The components system has grown into a robust and flexible toolset for developers over these last few years. Plus, the component-level documentation is well-rounded at this point, especially when pairing it with usage in the core code.

As I continued building new blocks, I started taking on more complex concepts. One of the things I needed to learn was how to interact with the core data layer. As I stepped into my third and fourth block types, I needed to query users and list them:

WordPress post editor with a custom-built Authors block that lists users with posts.
Listing users via an Authors block.

While there is a “basics” tutorial on working with core data, the reference guide was spotty in places. Some pieces even seemed to be missing altogether. Where were the advanced guides? I could not find any, and “doing stuff” with data is the meat of plugin development when you get beyond a few simple form fields.

I spent some time with the tried and true console.log() to figure out things and perused the core code. Eventually, I pushed through and built a couple of working projects.

Did my experience improve this time around compared to a year ago? Without a doubt, it did.

More than anything, I want to thank all the contributors to the Gutenberg project. The build tools and range of pre-built components are welcome for this developer who has spent most of his time in the PHP world. I always enjoy being able to pick up a toolset and start building with it right away. I am sure I have only glimpsed some of what is possible at this point, but I look forward to trying new things. As I grow more comfortable, maybe I will write some of those advanced tutorials that I believe are missing.

Posted on

A Pared Back Web Fonts API May Land in WordPress 6.0 or Not at All

Anyone who has been watching or participating in the development of the web fonts API can attest that it has been an emotional rollercoaster. At one point, it seemed to be a shoo-in for WordPress 5.9. Then, it was punted to the next release. Sure that it was landing once again, we find ourselves looking down the track, wondering just where the next dip or twist will take us.

Over the weekend, I had a sense of dread. The WordPress 6.0 Beta 1 release last week felt premature. I am just as excited about the next major update as I have been about any before. There are tons of noteworthy features. It is OK for some of them to not be polished for a beta release, but the problem was the list of incomplete and missing pieces.

The decision to postpone the Post Author Name block left me scratching my head. It is an obvious pairing for the new Post Author Biography block and almost feels necessary for Author Template support.

The new Comments Query Loop block, a replacement for Post Comments, was missing vital features. Fortunately, most of those seemed squared away now.

Then, there was the web fonts API. I had not paid it much attention since its inclusion in Gutenberg 12.8 over a month ago. I was happy to see it merged and have used it ever since. However, there has been some trouble brewing that might spoil its inclusion in the 6.0 release. It was notably missing from the first beta, and there was no final decision on its status as Beta 2 rolled out yesterday. There are still several open, high-priority tickets for the API.

Each of the problematic features was tied to other highlights of the upcoming 6.0 release, and the web fonts API is intrinsically linked to what is, arguably, the crème de la crème of the bunch: global style variations.

First touted before the release of WordPress 5.9 and its accompanying default theme, global style variations would allow end-users to switch between pre-built “skins.” Twenty Twenty-Two would showcase the feature in all its wonder:

Potential variations on Twenty Twenty-Two.

However, the feature did not make the cut. That was OK because the web fonts API did not squeeze in either. These variations would allow theme authors to mix and match different colors, block styles, and fonts. Like a PB&J without the J, the global style variations feature is a fine meal in its own right, but fonts offer a variety of flavors that users deserve to taste. If we wait for some future release toward the end of the year, Twenty Twenty-Two might feel like old news by then.

After WordPress 6.0 Beta 2’s release, it has become crunch time for this long-awaited feature that standardizes how fonts are loaded in WordPress. One truth is almost set in stone: the complete API will be deferred to a future release. However, there is a sliver of hope for theme authors that a theme.json-only version will be available.

Tonya Mork has opened a ticket for paring down the feature to disallow programmatically registering and enqueueing fonts. Along with work by Ari Stathopoulos, the associated pull request on GitHub would still allow theme authors to define custom font-faces via theme.json and custom /styles/*.json files.

It is a compromise on a robust API that many have been waiting for, but it is necessary. Yet, there are still no guarantees, and the patch needs testing from theme authors sooner rather than later.

As much as I want the web fonts API to land in 6.0, I would be remiss to not point out that April 12, the release date of Beta 1, was the “effective feature freeze.” Essentially, this is the deadline for new features for the release cycle.

Having these deadlines in place is not arbitrary. They give time for users to test and report bugs. They allow theme and plugin developers to make sure their extensions are working. When new features start landing in Beta 3 and Release Candidates, it can sometimes be a mad scramble to catch up in an already fast-paced cycle.

At a certain point, WordPress must abide by its own rules. Otherwise, it feels like some pet features get a pass where others might not.

The web fonts API is one of those things I would not mind breaking the rules for. My only argument is that it is such an integral piece of global style variations that I cannot imagine having one and not the other. Derailing this now will set a lot of possible theme advancements back for months as developers wait for the 6.1 release.

Posted on

Phi Phan Launches a Separator Block With an Icon Option

Less than a week after launching Block Enhancements, Phi Phan has released another project: Icon Separator. It is a block plugin for creating custom dividers with an SVG icon.

“I’ve tried to support icons in the core/separator,” Phan said when we last spoke about adding icons to core blocks. “But it requires changing the markup. So I may create a new tiny block just for it.” Now, he has checked at least one of the many ideas he mentioned off the to-do list.

Plugins that do one thing and do it well are generally my favorite types of extensions, and Icon Separator is no different. It is also the beauty of the block system itself. It was designed around allowing users to stick small components anywhere.

When first inserting the Icon Separator block, it will appear much like any other run-of-the-mill separator. It outputs a simple horizontal line across the screen:

Two paragraphs in the WordPress post editor separated by a single horizontal line.
Default output of Icon Separator block.

Users are welcome to use it in its default state, but that would not be much fun. This block is all about the icon.

The plugin bundles over 3,500 icons from the WordPress, Bootstrap, and Ionicons libraries, giving users plenty to choose from. It looks to be a carryover from Phan’s Block Enhancements plugin—it would make sense to reuse the same code. The block also allows users to input SVG code for custom icons.

It did not take long to pick an icon and begin customizing the separator output in the editor:

Two paragraphs in the WordPress block editor separated by an orange horizontal line with a sun icon in the middle of it.
Customizing the Icon Separator block.

The plugin has a lot of options that allow users to make it their own. Besides selecting an icon, they can customize its fill and stroke colors, size, spacing, position, and alignment.

The block also has options for customizing the separator line itself, including solid, dashed, and dotted styles. Users can change its alignment, width, color, and more.

Four horizontal separators in the WordPress post editor. Each has a different color and flower icon. The lines are solid, dashed, and dotted.
Various icons and separator modifications.

This block is an ideal use case for the reusable block system in WordPress. Assuming users wanted to use the same separator design across their site, it would make sense to design it once and save a copy for use everywhere else it is needed.

I am slightly disappointed that the plugin does not use the <hr> HTML element. I had grown excited when last speaking to Phan. I wanted to see how someone would tackle the problem this plugin does, but I expected it to be solved with the semantic <hr>. Part of this was just curiosity as a fellow developer and designer, knowing the limitations it would present as a generic block for use with any theme design.

Phan took the less-headache-inducing route of using a wrapper <div> and placing the icon <svg> code into it. That opened far more possibilities, and the block is probably the better for it.

However, I wanted to note that this block is not ideal for those who need to use a proper horizontal rule in their content. The <hr> element is meant for marking thematic breaks. It is better to stick to the core Separator block in those cases.

In scenarios where the divider is a design element rather than a break in the content, go wild. The Icon Separator block has plenty of options.

Icon Separator
Posted on

Plugin Directory Limits Ownership and Committer Changes on Official Featured and Beta Plugins

Plugin review team representative Mika Epstein announced changes for officially-recognized featured and beta plugins last Friday. Under the new rule, plugin owners will no longer be able to directly change ownership to someone else or add/remove commit access. The purpose is to prevent bad actors from pushing malicious code or premium upsells.

Plugin owners can still manually add and remove support reps for their plugins in the directory. However, they must email the plugin review team to change ownership or commit access.

Epstein wrote in the announcement:

This change was made due to the high profile nature of those plugins, and the potential for abuse if a plugin is given to someone who turns out to be malicious. We hope that it will prevent issues like a featured plugin being turned into a premium-upsell plugin.

The behind-the-scenes details were left out of the post. Presumably, the plugin review team would double-check requested changes or block them if something seemed awry.

The featured category displays the first plugins that WordPress users see from the Plugins > Add New admin screen. The beta category appears first on development versions.

WordPress add-new plugin screen in the admin. The screenshot displays 6 of the 15 featured plugins.
Featured plugins via WordPress admin.

Active installs range from a few dozen to over 5 million for the two groups. However, the number does not matter, as pointed out by Epstein in the announcement. “If a 2-user plugin is made a Featured Plugin, then it will have this limitation.”

There are nine featured and 15 beta plugins. Many of the latter have low install counts, and some have not been updated for over half a decade. Some house cleaning is likely in order.

The limited number of featured plugins is not likely in any danger of changing hands. Most are owned by the WordPress project itself or Automattic.

The announcement almost feels like much has not changed. However, the assurance that bad actors have more hurdles to jump when acquiring featured and beta plugins is welcome.

The real danger with ownership changes lies with the other 59,000+ plugins in the directory. They have no such added protections.

Nearly a year ago, I started receiving reports that the Dark Mode plugin seemed to be doing something fishy. Once a proposed featured plugin, it went from being a simple tool for switching the WordPress admin color scheme to a copy of the premium Iceberg editor project.

This new rule change would not have gone into effect for Dark Mode had it existed a year ago. It never made it to the officially-sanctioned point of becoming a featured or beta plugin.

There is a 17-month-old ticket for notifying users of ownership changes, but there are limits to what is possible with such a system. For example, a company acquisition would not necessarily reflect changes on WordPress.org.

There have been clear and documented cases of developers and agencies acquiring a plugin and repurposing it. Dark Mode had only a few thousand users when new owners changed it. In the case of WP User Avatar, many of its 400,000 users had to deal with the aftermath of an overnight switch to a full-fledge membership solution. I have little doubt that the plugin review team catches cases of a more malicious nature.

It would be a management nightmare for the plugin review team to require manual approval every time a plugin owner decided to update the committers list. However, changing this for featured and beta plugins is at least a step in the right direction.

Posted on

WordPress 6.0 Might Ship a Feature for Picking a Block Pattern on Page Creation

I once said that full-page patterns were the missing link for block theme development. Theme authors have been able to include such layouts since the patterns feature was rolled out in WordPress 5.5 last year. However, core WordPress has never provided an experience built around them.

This may be changing when WordPress 6.0 ships next month. There is a bit of an 11th-hour push to land the first iteration of the feature. It is expected to ship with Gutenberg 13.0 and WordPress 6.0-beta-1 for testing (grab the Gutenberg nightly ZIP to test now).

Earlier this week, Jorge Costa merged an implementation that made full-page patterns part of the page creation experience.

WordPress add new page screen. There is an overlay modal with a 2x2 grid of content patterns from the theme.
Pattern modal when adding a new page.

There does not seem to be an official name for this new feature. “Full page” might not be the most appropriate terminology. In reality, it is more of a content-pattern inserter.

The goal is to present users with pre-built layouts that they can insert and customize—plug-n-play style. A modal appears when creating a new page if the theme has any registered patterns for the content. Insertion is as simple as finding a starting point and clicking.

WordPress page editor with a full pattern inserted into the content canvas. It features a colorful background and a centered section for profile content.
Inserting a content template on page creation.

Of course, users can also choose to start from scratch as usual by hitting the “x” icon to close the modal.

There has always been a disconnect between what WordPress themes are capable of and users recreating what they see in the demo. Everything developers have attempted in the past—from shortcodes to theme options—has often fallen a few steps shy of creating an ideal user experience. This new feature could bridge the gap in a way that we have not seen before.

Want to build that portfolio page from the theme’s demo? Just go to Pages > Add New, select the Portfolio pattern, and you got it.

Want that contact page layout? Yeah, same process.

There are still some pieces of the puzzle to figure out. The most notable is the initial user experience. There should be an option to disable this entirely for users who prefer to start with a blank content canvas.

Riad Benguella also recommended a config flag for custom post types to enable or disable it by default. The pattern inserter only appears for pages right now.

There is a high chance that the feature could land in WordPress 6.0 because it does not add any new APIs or special pattern categories. Instead, it piggybacks off the existing blockTypes flag when registering custom patterns.

Theme authors who want to give it a spin can register patterns for the core/post-content block type:

register_block_pattern( 'namespace/slug', [
        'blockTypes' => [ 'core/post-content']
        // ...
] );

After spending more time than I am willing to admit testing the feature, I am happy with the initial implementation. In the long term, there might be more that it could do.

When I think of starting points like this, I often want to hand over control of the entire page’s output. This includes everything from the header down to the footer. Remember, this feature focuses directly on the content. Depending on the theme, such patterns might work well alongside a “Blank” template:

WordPress page editor. The page sidebar panel highlights the template section. A Blank template is selected.
Selecting a “Blank” page template.

Templates like this are typically open canvases that only display the content. In a possible future version, I would like to be able to trigger the selection of such a blank template when specific patterns are chosen. Or, perhaps, there might be a mechanism for choosing between “content” and “full page” patterns.

For now, allowing users to select a pattern on page creation is sure to be a boon for theme authors. It makes me want to step back into the theme development game for a bit, if for nothing other than to see what limits I can push with it.

Posted on

Phi Phan Launches Block Enhancements WordPress Plugin

WordPress developer Phi Phan has been making small splashes lately, but in a sea of 1,000s of plugins, it is increasingly tough to make a wave. Over the weekend, he released the Block Enhancements plugin, the first pass on a project that he plans to iterate on with new ideas.

WordPress post editor with four different buttons in the content canvas. The inspector panel shows a set of icon related options and the "fill" color is highlighted for an SVG icon.
Adding icons to buttons with Block Enhancements.

However, this is not his first block-related plugin. Last year, he launched Content Blocks Builder, a plugin that allows developers and users to create blocks from others, patterns, and variations. In February, he released Meta Field Block. He then followed it up with the launch of SVG Block and Block Enhancements last week.

I have quietly tested each as they strolled into the WordPress plugin directory, but they kept getting relegated to the back of the draft posts list. Most seemed like solid plugins at the time, and a reminder from two different people in the past week to check out Phan’s work lit a fire under me. It was time to share what he has been doing with WP Tavern readers.

The SVG Block plugin is a unique take compared to some existing solutions. Users can output the SVG as an image or implement it as a divider.

Phan is not short on ideas for new blocks and enhancements. He rattled off a hefty list of features that he plans to build when questioned.

“A simple separator with an icon,” he noted as an idea. “I’ve tried to support icons in the core/separator, but it requires changing the markup. So I may create a new tiny block just for it. Maybe a wavy divider designer block. I know there are already some on the plugin directory, but they are not fit for some use cases. I’m kind of obsessing with SVG stuff. A ‘toggle’ button block for showing modal, off-canvas, or collapse layout.”

BoldBlocks is his upcoming website, which he will eventually use to promote his plugins. He has yet to launch it—likely because he has been too busy developing new projects.

“[Content Blocks Builder] is my main business focus in the long term,” said Phan. “It’s a tool allowing users to create blocks from other blocks. It helps to create responsive ‘boring’ grid layouts or carousel layouts easily without touching code. I used to create layouts like those with the ACF repeater field, but I didn’t like that kind of workflow in the Gutenberg world anymore. That plugin has many more features than the description on the plugin page, but I’ve not finished rewriting the description and user guides.”

The Block Enhancements Plugin

Block Enhancements is not a block in and of itself. It takes a similar route as EditorsKit and Editor Plus, adding features on top of the system.

The first version of the plugin adds a single feature that allows end-users to stick icons into the core Button, Heading, and List blocks.

WordPress post editor with a Heading and List block in the content canvas. Both have custom icons selected with different fill colors. The inspector panel shows a list of icon-related options.
Inserting icons for the Heading and List blocks.

Maybe the plugin does not offer enough features to grab everyone’s attention, but it is off to a solid start. Phan does not go overboard with the UI, keeping it simple and following WordPress standards. The icons feature had just the right amount of customizability that I never felt like I needed anything more.

While not listed anywhere in the plugin description, the default library looks to be a mix of Ionicons, Bootstrap, and core WordPress icons. In total, there are over 3,500 options for users to choose from.

Popup overlay screen in the WordPress post editor that lists a library of icons in a grid.
Block Enhancements icon library overlay.

If the library does not offer enough choices, the block allows users to directly paste in SVG code.

This is the start of something new, and Phan has already created what looks to be an exciting to-do list for Block Enhancements’ future. Some potential features include:

  • Box-shadow builder.
  • Multi-border design options.
  • 2D transformations via translate, rotate, skew, and scale.
  • Fancy border-radius implementation a la 9elements’ project.
  • Responsive text alignment.
  • Animated reveal effects.
  • Copy/paste styles.
  • Child blocks selector.

If Phan continues iterating on Block Enhancements with these and other features, it will be a plugin to keep an eye on.

Block Enhancements
Posted on

Featured Cover Blocks and the Future of Binding Data to Generic WordPress Blocks

Over the past year, I have been on a mission. I have eagerly awaited each release of the Gutenberg plugin, followed tickets, and chimed in when I could. I have been holding out some sliver of hope for one feature in particular.

I wanted to use featured images within a Cover block. That day has finally arrived.

In particular, my mission was to create the following layout entirely from the WordPress editor—no code involved:

Three blog posts stacked atop one another, each with the featured image as the background.

This was a part of a set of patterns I had designed for a faux photography portfolio in 2021. The general layout has long been possible in WordPress via the editor. However, it was not dynamic, which meant that each Cover block and its image had to be manually added instead of loading post featured images.

Two weeks ago, Andrei Draganescu added a pull request that changed everything. It implemented a toggle for the Cover block that allowed it to use the post’s featured image instead of a static image:

WordPress editor with a Cover block. Highlighted in the toolbar is the "use featured image" toggle.
Switching the Cover block to use the featured image.

Two days ago, that enhancement landed in the Gutenberg plugin. It is expected to ship with version 13.0 next week.

I am unsure why I have been so obsessed with this specific pattern. It is not overly complex. Deep down, perhaps a part of me felt that when WordPress reached the point where I could create it from the editor, we would be at a place where anything was possible. In reality, I know that there is much more ground to cover and features to implement, but this still feels like a significant milestone that should not go unnoticed.

Even the pattern itself is not entirely possible via the editor. As shown in the following screenshot, there are gaps between each of the posts:

Query Loop block in the WordPress editor that shows the featured image for posts as the background of a Cover block.
Unwanted gaps between posts in the Query Loop block.

I had to cheat a bit and collapse those with CSS. There is a ticket to bring dimension controls to the Query Loop and/or Post Template blocks, but it has yet to be implemented. Theme authors must currently add a custom “no gap” block style to address the shortcoming, but the layout is now doable.

While I may be singularly focused on this particular design, the change opens a world of layout possibilities to theme authors. One style is to use the featured image as a background behind the site and post headers, as shown in the following screenshot:

A single-post view on the front end of a WordPress site. It has a Cover image behind the site header and post headers.
Cover block using post featured image when viewing a single post.

That is now possible directly from the site editor.

I was able to recreate it in minutes by editing my active theme’s single template. I wrapped the Header template part in a Cover, toggled on the featured media switch, and added the Post Title and related blocks.

WordPress site editor with the single template in view. The site header and post header areas are inside of a Cover block.
Cover background with featured image switched on.

This change will give some freedom to block themers that they have not had since building atop classic WordPress. Users will also be able to make their own tweaks to the output.

This enhancement is a win for theme authors and users. However, it also represents another shift that could create new possibilities for blocks in the future.

WordPress has a blocks problem. Those added by core alone are starting to overcrowd the inserter UI, and when you add a few plugins in the mix, things can become unwieldy. Many blocks are, essentially, variations on base HTML elements. For example, Post Title is merely a variation on the <h*> element, and WordPress already has a Heading block.

These variations duplicate developer efforts, create scenarios where each block supports different features, and often litter the interface.

Cory Birdsong opened a ticket in January that seeks to address this issue. His proposed solution:

Instead of making tons of individual blocks for this sort of thing, it seems like it would be better to create systems for using site/post metadata within existing generic blocks.

Reusing the post featured image seemed the most obvious starting place. Theme authors have long been clamoring for more control over its output, and the dedicated Post Featured Image block has been lackluster at best. There are tickets to bring the same “featured cover” implementation to the Media & Text and Group blocks.

With WordPress 6.0 landing next month, we will not see full-scale support for binding dynamic data to more generic blocks. However, it could have implications for the future.

What if, instead of plugin authors creating individual blocks, they could merely offer a switch to display content via a custom data source? There are certainly some use cases beyond core WordPress where this could be handy.

For now, at least, I am likely to spend the rest of the day tinkering with featured images and Cover blocks.

Posted on

Gutenberg 12.9 Adds Block Locking UI, Automatic Pattern Registration, and Full Theme Exports

Gutenberg 12.9 landed in the WordPress.org plugin directory today, and it is a beefy release, packed with a little something for everyone. Even after tinkering with new features over the last few days, I have yet to explore everything as much as I would like. Given the practical limitation of time, I will not be able to dive into everything in this post, but I will attempt to introduce you all to some of the highlights.

The following are some selected items that I was unable to dive into, but I still encourage readers to check out:

Block Locking UI

WordPress site editor. Block Lock popover is open with options selected to disable movement and prevent removal of a block.
Customizing a locked block.

Gutenberg 12.9 introduces a new UI for locking blocks. Under the “more options” dropdown in the toolbar, users can select the lock option, which will bring up a screen with two options:

  • Disable movement: Disallows moving the block itself. However, sibling blocks can be moved around it.
  • Prevent removal: Prevents the block from being deleted.

Andrei Draganescu noted the following in the 12.9 announcement post:

When a block is locked, users are either unable to move it, remove it, or both. This is particularly useful with site level blocks like Post Content which many themes will want to lock down.

However, that definition does not entirely explain block-level locking. There is a caveat: this new UI hands end-users the key to the lock. Technically, they already had this capability via the code editor, but it is now available through the interface.

From a theme dev perspective, block-level locking merely requires additional steps of the user to move and/or remove blocks. It is not a “forced” or “permanent” lock. It is a welcome feature, but themers should understand its limits and that this new UI offers more power to users, not less.

Block Gap Support for Galleries…Sort Of

WordPress post editor with a five-group set of images in the Gallery block.
Block spacing for the Gallery block.

One of the features I was most excited about with this release was the addition of support for spacing between Gallery images. Theme authors have relied on specialized block styles to give users choices, usually limited to default and a “no gap” options. The latter would remove any spacing between the images.

Unfortunately, the feature is broken in 12.9 when users manually set a gap. Checking the source code, it is outputting an Array instead of valid CSS. On the front end, the following warning displays:

Warning: preg_match() expects parameter 2 to be string, array given in ...wp-content/plugins/gutenberg/build/block-library/blocks/gallery.php on line 51

I am sure this will be corrected in 12.9.1. Until then, I suggest not using the “Block Spacing” control.

Theme author warning: This is a breaking change for themes that target the --gallery-block--gutter-size to control the default gap for galleries. This previously-reliable CSS custom property no longer exists in the code. It is unclear why this variable was removed altogether, and there was no mention of it in the ticket.

A new --wp--style--unstable-gallery-gap variable seems to do a similar job. However, as the unstable part of its name suggests, it may not always be around. It is also defined on the .wp-container-* class instead of the gallery itself. I have yet to do enough CSS testing to figure out how to overwrite it for the default gap. If anyone has a solution, please post it in the comments for others.

Children Collapsed by Default in List View

WordPress block editor with the list view panel opened on the left. Its blocks are collapsed by default.
Opening a collapsed set of nested blocks in the list view.

I have often shied away from the list view in the editor for most real-world scenarios, at least for pages with many nested blocks. With every level open by default, it was a bit of a nightmare to browse through and locate a specific block. It was easier to take my chances clicking around in the content canvas.

However, the latest Gutenberg release may just change my usage of it. Version 12.9 collapses all child blocks by default.

Automatic Pattern Registration for Themes

Theme authors can now let Gutenberg handle pattern registration for them. They only need to follow a few rules:

  • Add block patterns inside PHP files in a /patterns folder.
  • Add pattern data to the file header.
  • Add pattern content, of course.

Individual pattern files should look like the following:

<?php
/**
 * Title: A Pattern Title
 * Slug: namespace/slug
 * Description: A human-friendly description.
 * Viewport Width: 1024
 * Categories: comma, separated, values
 * Keywords: comma, separated, values
 * Block Types: comma, separated, values
 * Inserter: yes|no
 */
 ?>
 <!-- some-block-content /-->

Only the Title and Slug header fields are required. Each option matches a register_block_pattern() function argument.

Theme authors who want to use this feature now but provide backward compatibility with WordPress 5.9 can check for the existence of the gutenberg_register_theme_block_patterns() function. That is the function name for the moment, at least.

This change further builds on top of the existing standards for block themes. Authors now have clear-cut guidelines on registering most features via standard files and folders:

  • /parts – Block template parts
  • /patterns – Block patterns
  • /styles – Global style variations
  • /templates – Block templates
  • theme.json – Global settings and styles

Aside from custom block styles and variations (not to be confused with global style variations), nearly everything is covered. This well-rounded set lowers the barrier to entry for future theme authors. Even seasoned developers should appreciate the simplicity of what to name things and where to put them. It is one less thing to worry about. It will also continue simplifying the WordPress.org theme review system.

Theme Exporting and Template Building

Speaking of lowering barriers, creators can now build an entire theme from the site editor. Well, assuming they start from an existing block theme.

Gutenberg 12.9 introduces two vital features to the site-building process. The first allows users to export a copy of their active theme directly from the editor:

Gutenberg site editor with the options dropdown open. The export button is selected.
Exporting the active theme with customizations.

The downloaded ZIP file from this export is a fully-functioning theme. It includes all user customizations alongside every file that already exists in the original.

There are still a few things that are not yet possible from the editor, and these will need to be manually adjusted before public release. The theme name and other data in style.css will remain the same as the original theme. There is also no method for snagging a screenshot of the customized version and bundling it in the ZIP.

This is a leap forward for democratizing design, but other flows will need to be considered. Users should be able to export as a child theme with only their customizations or even as a *.json file (global style variation).

But, there is a more immediate and practical use case. Users can download their customized themes and upload them to another site.

The second crucial update for development within the site editor is support for more templates. Users can now create the following from the templates management panel in addition to the existing ones;

  • Author
  • Category
  • Date
  • Tag
  • Taxonomy
Gutenberg templates panel open. The "add new" dropdown is open with the Author template highlighted.
Adding a new Author template.

The new templates are welcome additions, but the template-creation feature still has limits. There is no way to create variations on those templates via the UI, such as category-wordpress, taxonomy-genre, or the dozens of other possibilities. However, it will happen one day.

Posted on

Text Selection Across Multiple Blocks Is Coming to WordPress

Yesterday, Ella van Durpe merged a long-awaited feature into the Gutenberg plugin that allows users to select and modify text across multiple Rich Text blocks. It should land in version 13.0 of the plugin and WordPress 6.0 in May.

Users can currently select text across multiple blocks, but the editor automatically adjusts that selection to all of the blocks themselves, essentially creating a group. The change will allow users to highlight the specific text. This ability should work with any Rich Text block, such as Paragraph, Heading, List, and Quote.

WordPress open to a post with several paragraphs. Text is selected across two different Paragraph blocks.
Selecting text across two blocks.

Anyone who wants to test this feature early can grab a development copy of Gutenberg from the ticket. Click on the “Build Gutenberg Plugin ZIP” tab.

If there is one thing that any text-based editor should do well, it should be to allow users to manipulate text according to standard conventions. Users should be able to select, copy, cut, paste, and generally move characters and words around as they please.

When WordPress 5.0 launched its new block-based editor in late 2018, some of the tools that writers had expected were non-existent. Every paragraph, list, heading, and blockquote was a separate entity and not simply a continuation of the text. Blocks were the sludge that plugged the editing flow.

The block system solved a ton of problems that needed solutions. The new post editor even looked sleeker than its classic predecessor. But, those things did not matter much when stuff under the hood did not meet the demands users needed of an editor. Every missing feature that had become a standard to any particular user or another was a blight, another one-star review, on the revolution the block system was meant to bring about.

If a user could not do something as simple as select and delete text across two paragraphs, what good were all the other bells and whistles?

It is now over three years since the launch of the block editor. Perhaps it is too late to win back some who have chosen a different path for their websites. For others, maybe their writing flows have changed so drastically that the news is inconsequential. For those who have been patiently waiting, knowing that WordPress would one day make this right, it is a moment to rejoice.

Judging by the response to Matías Ventura’s tweet yesterday, it is a reminder of just how much people have wanted this feature:

The implementation does not yet offer complete coverage of capabilities when selecting text across Rich Text blocks. It currently includes the following:

  • Enter: Hitting the Enter key will delete the selected text and create a new paragraph.
  • Backspace: Hitting the Backspace key removes the selected text and merges anything left of the latter block with the former.
  • Delete: Hitting the Del key removes the selected text and forward merges the previous text.
  • Input: Typing will replace the selected text with new input.

The difference between Backspace and Del is relevant when dealing with different block types. For example, when highlighting text from a list followed by a paragraph, backspacing will merge the remainder of the paragraph text as a list item. When deleting, the list items become paragraphs.

WordPress editor with paragraphs and a list. The paragraph below the list has been backspaced into it, leaving an empty list item.
Backspacing selected text across List and Paragraph blocks.

I did notice a bug when backspacing into a list. It leaves an empty list item, as shown in the above screenshot.

There is still no current method of selecting text from two or more blocks and copying or cutting it. Attempting this falls back to the previous behavior. The copy/cut action grabs the entire block code instead of the text itself.

Selected text across two paragraphs in the editor. Both blocks are copied instead of the text itself.
Copy action when selecting partial text.

The new feature does not do away with the ability to partially select text across multiple blocks and manipulate them as a group. Users can still shift their position, copy them, and modify them.

Instead, the text-selection feature is an enhancement to the current tools, and it is one that many will be happy to see land in WordPress. It is not a complete set of capabilities, but this is a win for the project and a necessary step forward.