Normal view

There are new articles available, click to refresh the page.
Before yesterdayMain stream

Today, WordPress Ended a 16-Year Tradition… Meet Ipsum!

16 September 2026 at 16:51
After 16 years, WordPress just killed one of its most recognizable traditions. The predictable “Twenty Something” default themes are history, and their replacement, Ipsum, signals a surprisingly different vision for what WordPress thinks a modern website should start with.

How to Hide WordPress Blocks Based on Device

9 August 2026 at 09:42

Responsive controls are a long-sought-after feature for the WordPress Block Editor. Changing a page’s design or layout based on a user’s device is a staple of modern web design. Yet, doing so in WordPress has typically required a third-party solution, such as a page builder. Thankfully, that’s changing.

The WordPress project is slowly but surely inching toward responsive block settings. Version 6.9 introduced the Block Visibility feature, allowing you to temporarily disable a block without deleting it from a post. WordPress 7.0 took it a step further by adding options to hide a block based on device.

Perhaps it’s a niche feature. But it’s also quite handy for targeting mobile or desktop users with specific blocks. And it’s also a gateway to more responsive controls landing in WordPress 7.1.

Today’s tip will show you how easy it is to show or hide a block based on a user’s device. Here we go!

Sample Project: Simplify a Hero Area for Mobile Users

Here’s a common scenario: Your website has a large hero area, complete with a high-resolution image, text, and a call to action (CTA). It looks great on a desktop device but is clunky on a phone. The image is too big, and there’s too much text for users to digest. What to do?

The responsive Block Visibility controls will make this a piece of cake. We’ll create two hero areas – one for desktop and another optimized for mobile. The result will be a better user experience for everyone.

Step 1: Create Desktop and Mobile Hero Areas

The first step is to create the two hero areas for our page. We’ll grab one from the WordPress Block Pattern library and see what we can do with it.

A hero area optimized for desktop screens.

Our desktop hero area is beautiful on the big screen! It should also work well on tablets, such as an iPad. However, it may be overwhelming for mobile users.

Let’s simplify. We duplicated the desktop hero and made a few changes:

  • We replaced the image with a cropped version that is optimized for smaller screens.
  • We centered the text and CTA.
  • We replaced the three columns of text with one, shorter passage.
  • Finally, we tightened up the spacing to reduce scrolling.

The mobile hero offers the same immersive look without the extra bulk.

The revised hero area is optimized for mobile screens.

Step 2: Assign Hero Areas to Their Respective Devices

As of now, our page has two hero areas, each contained within a Group block. The next step is to set one of them to display on desktop/tablet devices, and the other on mobile. We’ll use the Block Visibility feature to make it happen.

Desktop/Tablet Devices:

  • Click on the Desktop Hero block we created.
  • Click on the Options menu () and select Hide Block.
  • Choose the Hide on Mobile option.
  • Click the Apply button and save the page.

Hiding the desktop version of our hero area on mobile devices.

Mobile Devices:

  • Click on the Mobile Hero block we created.
  • Click on the Options menu () and select Hide Block.
  • We’ll choose two options this time: Hide on Desktop, Hide on Tablet
  • Click the Apply button and save the page.

Our mobile hero area is now hidden on desktop and tablet devices.

You may notice that the mobile hero no longer displays on the Block Editor canvas. That’s the desired result, as it won’t be in the way when working in Desktop preview mode.

We see the correct hero area in Desktop preview mode.

Switch to Mobile preview mode, and you’ll see the opposite effect. The desktop hero is hidden, allowing the mobile version to take over. You can edit these blocks when in the appropriate preview mode.

Mobile preview mode hides the desktop version.

Note that you can also view and edit these blocks using the Document Overview (List View) feature (Shift+Alt+O). Select the block, click on the Options menu (), and select Show from the menu. You can hide it again once you’re finished editing.

Oh, and be sure to test on different devices! It’s not enough to shrink your desktop’s browser window. You can use your browser’s dev tools to emulate a mobile device if you don’t have one handy.

Use Different WordPress Blocks on Different Devices

It’s often the little extras that make the biggest difference. Targeting different devices via the Block Visibility feature is a prime example. Its release didn’t draw much fanfare. However, it makes WordPress more flexible for designers.

Before WordPress 7.0, we’d have to work around this limitation. That could mean installing a specialized plugin or writing custom CSS rules in a theme. Now, we’re only a few clicks away from choosing which blocks display on a given device.

The feature saves us time, improves the user experience, and won’t hog server resources. Most of all, it’s a sign of things to come for WordPress.

The post How to Hide WordPress Blocks Based on Device appeared first on Speckyboy Design Magazine.

Quick Tip: How To Use WordPress Block Notes

7 June 2026 at 17:11

The WordPress Block Editor is great for creating custom layouts. There are plenty of core and third-party blocks to choose from. They bring a world of possibilities – all without writing a line of code. Add a block theme, and get a browser-based design and development experience.

There is one valuable thing that WordPress blocks left behind, however: code commenting. They’re common when building custom PHP templates and writing CSS. We use them to provide context for what a code snippet does or why it was implemented.

There are times when that extra context is useful in the Block Editor. For example, you might want to share information about a block with clients or colleagues. Perhaps it’s locked or requires a specific setting to display correctly. Sometimes we need to remind ourselves why we did something.

That’s where the WordPress Notes feature comes in handy. Use it to add notes to specific blocks and even keep a threaded conversation. It’s another way to improve your editorial workflow and provide a quick reference for users.

Here’s a look at how the feature works. We’ll show you how to add and retrieve notes to any block on your site. In addition, we’ll share a few tips and hidden gems worth knowing about.

Sample Project: Let’s Collaborate With Blocks

The WordPress Notes feature is part of the larger Gutenberg Collaboration phase. At the very least, it’s a way to add reminders or have an asynchronous discussion with other site users. That second part is what we’ll focus on here.

We’ll simulate a discussion of colleagues regarding a Group block. We promise it will be quick and easy!

Step 1: Choose a Block

The first step is to open a page or post in the Block Editor and select a block. We’ll choose a Group block at the top of the page. We want to discuss its styling with a colleague.

We chose the Group block to add our note

Step 2: Add a Note

Now that we know which block we want to discuss, it’s time to add a note.

  1. Click on the Options menu () and select Add note.
  2. A note dialog appears on the right side of the screen. We can add our note in this space.
  3. Click the Add note button to save the note.

The Add Note feature lives in the block Options menu

For reference, we asked if our Group block should have a background color to stand out from the rest of the content.

We add a note to our Group block

Next, we’ll wait for our colleague to reply to our note. When they click the block in question, they’ll see a user avatar that indicates a note is available.

An avatar icon signals that a note is available for this block

Step 3: Our Colleague Replies

Here’s a handy feature: WordPress will send you an email when someone replies to your note (it’s based on the existing comment system). As such, we don’t have to keep checking our page for the latest news.

Our colleague replied to our note and acted on our design suggestion. When we visit the page, we notice that their avatar has also been added to the block’s note notification.

Our colleague replied to the block note

Step 4: Reply and Resolve

We love what our colleague did to dress up the Group block on the page. The last steps are to reply and mark the note as resolved.

To resolve the note, we’ll click the checkmark on the upper right of the dialog. Keep in mind that the note will stay in place unless we manually delete it from the block.

We marked our note as resolved. It will stay attached to the block until we remove it

An Easy Way To Collaborate in WordPress

The WordPress Notes feature is a great way to relay information to others or remind yourself of something important. And it will continue to be enhanced as more collaborative features are added to the content management system (CMS).

Even better, you don’t need a plugin to get started – it’s already built into WordPress. That being the case, there are ways to customize the experience. We recommend checking out this guide to tapping into that potential.

Whether you’re part of a team or working solo, give WordPress Notes a try. You may wonder how you lived without it!

The post Quick Tip: How To Use WordPress Block Notes appeared first on Speckyboy Design Magazine.

#197 – Johanne Courtright on Enhancing Gutenberg: Agency-Driven Block Editor Innovations

10 December 2025 at 15:00
Transcript

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case, enhancing Gutenberg with agency driven block editor innovations.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. . Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today we have Johanne Courtright. Johanne started working with WordPress back in 2011, moving over from a background in marketing agencies, Dreamweaver and Static HTML sites. Over the years, she’s become a skill developer, focusing on extending WordPress through custom queries, forms, integrations with APIs, and increasingly harnessing the power of the block editor and React.

Johanne talks about her journey from the classic world of agency WordPress development to embracing Gutenberg, and the challenges and wins along the way. She shares her experience in building custom blocks, and enhancing existing ones to better serve agencies. Things like improving break points, color palettes, responsive designs, and navigation, all of which aren’t offered in Core yet. These features come together in her growing open source project Groundworx.

We talk about the shifting landscape from classic themes to block-based themes, and why even in 2025, a lot of agencies and users are still hesitant to make the leap fully. Johanne explains where the block editor falls short for her use, and how Groundworx aims to plug these perceived gaps with a foundation of flexible, performant, agency focus blocks and templates.

You will hear about her approach to building modular themes with theme.json, the realities of client work and scope creep, and how the 80 20 rule shapes what belongs in Core, and what’s best handled by plugins.

We also get into the challenge of discovery in the WordPress plugin ecosystem, her wishlist for block editor improvements, and her take on the future of block-based businesses in WordPress.

Whether you’re a developer eager to modernize your workflow, or just curious about extending Gutenberg for real world use, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Johanne Courtright.

I am joined on the podcast by Johanne Courtright. Hello, Johanne.

[00:03:21] Johanne Courtright: Hi. Nice to be here.

[00:03:22] Nathan Wrigley: Yeah, very nice to have you with us. I put a tweet out not that long ago, seeing if anybody wanted to come on the WP Tavern Jukebox podcast, and Johanne was very kind and reached out to me. And we had a little bit of toing and froing. Not a lot, but a little bit. And I thought that the topic of conversation that she suggested was extremely curious.

As you’ll discover in a moment, Johanne has been working hard trying to make the block editor, well, I’m going to use the word improved. Trying to add things to the block editor to make it more usable.

That conversation though, probably would benefit from us knowing exactly who you are, and what your background is. Maybe if we stick to the WordPress bits and pieces, but would you mind just giving us a little biography? Tell us a bit about you.

[00:04:00] Johanne Courtright: Sure. I got into WordPress in 2011, working for a marketing agency. It solved a big problem at the time coming from Dreamweaver, HTML static pages. My writing to that was a lot of convincing, but it was a very welcome change. WordPress made a huge impact on a lot of agencies.

And so we used it for, primarily for home builders, and it was great. Discovered Advanced Custom Fields, tapped into that. Custom post types. It was a lot of fun for many years and I’ve worked for other agencies after that too, and my specialty has always been around extending as far as I can. Custom queries and forms, tapping into CRM and with APIs and all sorts of things. Anything that can be done with WordPress I was doing it, pretty much.

[00:04:55] Nathan Wrigley: Are you self-taught then, or have you learned on the job? Or did you go through like a university program or something like that?

[00:05:00] Johanne Courtright: Just learned on the job. Just looking for solution, and WordPress felt like it was a great fit. A lot of support online, a lot of documentation, just a lot of people providing enough documentation to be able to explore was very helpful. And there was Joomla and Drupal that was also contenders, but I didn’t like Drupal’s interface, and I wasn’t a fan of how unstable Joomla was from updating versions to versions. So for me, it was a pretty fast decision to go with WordPress.

[00:05:35] Nathan Wrigley: I think WordPress is a really great thing to hang your coat on if you are learning, because there’s so much, like you said, documentation. So much of it is prebuilt, so you can just download a version of WordPress and dig in basically, and see how somebody else over many years, in the case of WordPress, 22 years, how that has been built.

Whereas I always found when I was digging in, so this is prior to me using any CMS, I had those PHP books, paper books, where you try to learn. And you’d always learn from nothing and you’d have to start building up and anything that you did wrong, you kind of really didn’t know what was going on.

And so I quickly moved into the CMS space, and probably a little bit like you, WordPress was able to scaffold my learning. And quite a lot of the things that I thought I wouldn’t be interested in, I could skip over. I don’t know, things like permissions and stuff. WordPress already did that, so I didn’t really have to worry about how all of that was taken care of. So it enabled me to learn more quickly. And then of course, there’s the whole community behind it, and knowledge bases and articles and that whole thing. So I well understand your story.

However, you’ve gone in a much more developer direction, I think, than I ever did. Looking at the bits and pieces that you are doing now, I think it’s fair to say that you have become a really competent developer, not just with things like PHP and JavaScript, but also I think more recently with things like React as well. How are you finding all of that, the new React based WordPress? Is it still maintaining the interest or are you banging your head on the wall a lot?

[00:06:58] Johanne Courtright: I started Gutenberg, I started to use it pretty much around the time it came out. I had a bit of a struggle because I had to learn React for it. I didn’t want to be left behind, so I really tried hard, took a course online to accelerate a bit of my learning. And then I faced a time where it was just too much work to be done.

But the last agency I worked at, I started I think like four or five years ago, they were open. They wanted to tackle it. And so we’re a team of three to start, and we made like a core foundation of blocks that we needed over time, building off projects and versions.

And so it was a lot of fun, but in the same time we were still stuck in the old world with ACF for some of it. And I wasn’t quite pleased on some of it, but I understand sometimes like the budget, because I’m allowed to be fully a hundred percent Gutenberg. So when I decided to start something on my own to solve those things, I went a hundred percent Gutenberg, Interactivity API, no jQuery as much as possible. I decided to dive in completely, a hundred percent, because I believed in it. I knew how to solve those issues.

[00:08:11] Nathan Wrigley: Yeah, all of those things that you’ve mentioned, you know, things like custom fields and things like that, they’re really curious, aren’t they? I mean, they’re really interesting stuff that you can do there, and it’s very much time saving, but it does feel like in the future there are utterly different possibilities there. And blocks, and all of the different bits and pieces that we’ll get into that you are working on, afford the chance to build custom solutions for every single project, without necessarily relying on downloading a plugin. You know, writing a bit of code, which will achieve a bit of functionality for this particular block or that particular block.

However, all of that stuff being said, and the sort of rainbow version that we’ve painted of Gutenberg, it’s pretty obvious to me that during the last few years, there must be parts of the block editor that you’ve found to be lacking. Because as we’re going to discover, you’ve got a project called Groundworx, which is an endeavor in lots of different ways to bring features into the block editor which you feel probably, I’m guessing you feel, should have been shipped a long time ago.

And I think it’s fair to say that your endeavor here is not to create a new suite of blocks, which you would download and replace core blocks. You are trying to enhance the paragraph block or the whatever block it may be. So you’re taking the core block, adding functionality into it. Have I got that right? Is that the endeavor?

[00:09:34] Johanne Courtright: I have some extra blocks, but I did enhance quite a bit of what was already there, but not too much that it would interfere if they were to ever support. I mean, I have to be cautious on what I’m adding. But essentially, if you take WordPress as is, it’s good enough for somebody who’s starting, but it’s not good enough for an agency.

[00:09:57] Nathan Wrigley: What are the bits that you think are missing? And honestly, feel free to just dig deep here. I know for me what I found lacking, but it only maps to the things that I have had to do. But I’m curious what a different person having worked for agencies and built a suite of blocks, what are the, I don’t know, four, five different things that you really feel are missing?

[00:10:15] Johanne Courtright: You have to be pixel perfect with agencies, and they work with break points, and in containers and whatnot. And so you have to really kind of like stretch it further. And you have to also provide user experience efficiencies, for example, colour palettes and things like that. So you have to make it easier. So having presets of colours that already predetermined based on their branding, is ideal. So they can choose those presets, it already applies all the colours and your set. And then they can still override each components, which is amazing. That was something very important.

So efficiencies and ease of use was great. So a combination of some custom blocks, but a lot of pre-made templates that you can make for them, and colour palettes. So the more you embrace Gutenberg, the more you can make it happen. But if you have those solutions that are not quite fully Gutenberg, it becomes a little bit complex because you’re fighting Gutenberg.

[00:11:13] Nathan Wrigley: Did you build your suite of blocks? And we’ll get into what that means in a minute, and we can highlight the different bits and pieces that you’ve got. But did you build that out of frustration or were there, I don’t know, particular things that a particular project needed that was pretty edge case that you thought you’d build? Or is this more a case of, okay, everybody needs these things, it’s curious that they’re missing in Core? What’s the approach? Is it kind of edge case stuff or is it more, everybody could benefit from these?

[00:11:42] Johanne Courtright: It’s a little bit of everything. Most of the time, agencies would need those extra features I brought in. The problem is, I didn’t want to overwhelm normal users as well with so many options. And I think that’s where Gutenberg is shining essentially.

The padding system, for example. It’s got increments, but it doesn’t have an overwhelming amount of like, this is the padding for this break point, this is the padding for this break point. But you can still tap into it by using clamp on your padding to adjust based on your screen resolution. So you can solve that problem without having to specify all those extra padding for each break point.

So there’s a lot of different ways to set up your theme.json to compensate for the lack of extra features per breakpoint. And that’s what I’ve been doing. And my goal is to set up enough blocks and provide, I’ll have a theme.json that I want to share, so it’ll be easy for people to have a starting theme to start with. And I’m planning to release that for free. I was just, there’s a lot to be done and provide documentation. There’s just a lot. It’s hard to get everything done fast.

[00:12:57] Nathan Wrigley: Yeah, no kidding. I mean, have you built your own themes then from the ground up, or do you tend to rely on, I don’t know, a default theme and then modify that?

[00:13:06] Johanne Courtright: I actually prefer to use my own theme. In fact, coming from the old world, you would put everything in a theme. You would put just all your functionality. And then you learn over time that it’s probably better to have a plugin, but then you still had the crossover of the two dependencies. You have to be cautious to not crash your site if one wasn’t, like if you switched a theme or if you switch a plugin.

And then Gutenberg made it easier to create that separation because you can set up, if you set up your theme properly, you can have essentially 90% of your theme set up in a way where it’s accent one for colour, accent two for colour base, and contrast. So if you label your things, your keys properly, all you have to do is change the values. Don’t change the key names. And just create labels that are meaningful. You can create another theme super easy from that initial theme by just changing those labels and those values, and leave the keys alone. Sure, you’ll have probably more colours on certain other themes, but your foundation will help you get there faster.

[00:14:19] Nathan Wrigley: I know that many years ago when Full Site Editing, as it was called back then dropped, and so block themes became a thing. I know that there was a hope that it would, over a fairly short period of time, that it would replace what we’re now calling Classic Themes. There was this period of time where, you know, both were still massively in development. And I think the hope was that over time, Classic Themes would become more obsolete, and then block-based themes would become the default.

It feels from where I’m standing now, so we’re recording this in December, 2025, it feels as if that kind of hasn’t really happened. That promise is still, we’re still somewhere in limbo. There’s a few people out there in the WordPress space who are promoting Full Site Editing and all of the things that that can do, but I also feel there’s a lot of people who are not willing to make that leap.

And I guess part of the problem maybe is that it’s easy for somebody like you because you’re in it day in, day out. You know where every menu is. You know where to put the mouse to achieve the exact thing you want at the exact moment that you want. But I feel that for a novice user, maybe somebody who’s got the job of, I don’t know, finishing off a website or somebody who’s got the job of just tweaking a website once it’s been handed over, I think it’s really hard, and a lot of the interface is kind of counterintuitive.

And when you stand over the shoulder, as I have done, of people who’ve never used WordPress before, and you watch them, you see them flailing around trying to figure out how it works, and you see the constant butting up against a UX problem. I don’t know when that moment’s going to be, where everything is all tied off and perfect, but it doesn’t seem like in the year 2025, the few weeks that we’ve got left, or anytime soon in 2026, as if the Classic Themes are going to go away.

And I don’t know if that concerns you at all, because obviously you’ve really invested in all these blocks and theming and all of that kind of stuff. Does it bother you that this is still a problem that we haven’t solved?

[00:16:18] Johanne Courtright: I think what’s out there right now, the third party, what they’re doing, I mean, they’re solving some issues, but they’re adding a whole new platform on another existing platform, and that’s why I don’t choose those solutions. I prefer embracing the Core vision and try to expand what’s already there.

One of my struggles I have is that, let’s just pick Elementor. You have a lot of great options. I mean, for somebody who knows what they’re doing, it does a lot, but it also comes with a lot of extra bloat of divs and CSS that’s not quite built how I would’ve done it. You have to fight the styling. And WordPress does it so different now. With Gutenberg, it’s the opposite. It does very little, and it allows you to override all the classes. The way it’s built, it’s allowing you to override easily without having to use the important on the styling to override it.

And I think that’s a major change of how you think, and how you approach theming in general. This is the way. This is the way how it should be done. And once I stopped fighting how the new way was, and understanding where they were heading with that, something clicked and it just like, yes, this is what I want, this is what I want. And I made that call that I’m not going back.

No normal users want to touch Divi or Elementor. Somebody who doesn’t have the knowledge of basic CSS even, they don’t want to touch that. It’s overwhelming. They don’t know how to touch it. And in fact, they’re scared. And when you present them with Gutenberg, you give them an hour training over Zoom session, they are in love with it. They make edits themselves. They’re just happy. They rarely come back with more questions. They just know how to use it.

[00:18:12] Nathan Wrigley: I think we’re fast approaching a period in WordPress when a lot of the admin UI is about to change. So there’s a lot of foundational work being put in at the moment to really modify it. So maybe some of that dissonance that users might face in the near future will go away. And maybe those kind of block-based themes, and Gutenberg use in general will spike. There certainly seems to be a lot of work being done in that regard anyway.

Let’s just move on to some of the bits and pieces that you have been doing though. Because obviously there must be, well, dissatisfaction is the wrong word, but there’s obviously bits of the block editor where you feel that work could have been done differently.

And so I’m going to point people in the direction of your work. So if you go to groundworx.dev, and worx is spelt with an X at the end. So it’s the word ground, and then WOR and then the letter X, dot dev. If you go there, you’ll be able to find the product menu. And if you hover over the product menu, you’ll be able to see a bunch of things called Groundworx core and things like that, Groundworx navigation.

And I want to dwell on Groundworx core. So this is your endeavor to improve the blocks that WordPress offers, and offer some new ones and modifications to existing ones. Tell us what the philosophy behind this is then.

[00:19:29] Johanne Courtright: So some of the more fun blocks where they have like animation and all that are custom blocks. But they’re flexible in the way they’re easy to set up, intuitive. But I think for me, offering the capability to someone who wants those type of things that are not offered, it’s not necessarily a frustration for those because it’s just in addition to, it’s nice to have, it’s not a must have, essentially. They’re really nice, already pre-made blocks with the inner blocks and content that you can change.

One of the ones that are, I think, lacking, I know we have the accordion block that came in recently. Mine is different, where I can have an accordion, but I can also have a tab. A tab that can turn into an accordion based on a specific break point. So it won’t go from accordion, to tab, to accordion, back to tab at several different break points, but it will have one point where you’ll tell it to break.

So you can have a tab that can turn into accordion, which is nice to have because, I mean, tabs are not very friendly, but you still want them. You still want them. They’re useful visually at larger desktops, but you don’t necessarily want to deal with tabs at a mobile, unless they’re very small text and very few. So you need something to shift that. And you want to keep consistency. With accordions that you already have, so it looks good altogether. So that’s what I created. I have an accordion, and a tab, but the tab can fall into an accordion as well. And when they do fall into an accordion, they all look consistent and the same.

[00:21:13] Nathan Wrigley: So currently if you, I’ll put the link in the show notes by the way. So if you go to wptavern.com and you search for the episode with Johanne in, then you’ll find all of the show notes. It’s probably easier than me reading out URLs and what have you.

Your kind of block suite falls into two main categories, as far as I’m concerned anyway. So you’ve got your purpose built 11 kind of custom blocks where you are doing something that Core didn’t do. Although we might discuss how Core might tackle some of those things in the near future.

But then also, the bit that I find really interesting is the whole section where you’ve got extension to Core blocks. So as an example, I’ll give you some examples of things which, dear listener, if you don’t use Gutenberg, you may be surprised to know that the block editor currently does not do these things.

So for example, you have the capacity to reverse the order of a stack, which is really nice. So you might want to just, I don’t know, put an image above something on a desktop. And then on mobile, you might just want to flip that, or you might just want to flip it because you are doing, I don’t know, copy and pasting rows, but you want the image left, image right, image left, image right, that kind of thing.

You’ve also added in break points for certain widths. So for example, a tablet break point might be in there. You’ve got a full height sticky for the group block, which is nice and interesting as well. Three breakpoints for WordPress headings and paragraphs. That’s nice. So you could, I don’t know, change the font size or something like that depending on what you’re looking at.

Column counts. So you’ve got the ability to have different breakpoints in the Core list block as well.

You’ve got a whole thing about performance optimisation for the video block, and then you’ve got a responsive setting for any break point that you may set. I probably butchered all of that, but you get the idea. You’ve got a ton of stuff that you’ve built on top of Core WordPress blocks.

Why do you, because I mean, all of that I guess is given away to everybody, but there’s got to be an expectation, I suppose, that some of this stuff will ship in Core. Does that bit worry you? Does it worry you that you put in all this hard work and then somebody maybe in the Core project thinks, oh, that’s a good idea, let’s add that to the roadmap and what have you.

[00:23:16] Johanne Courtright: I mean, it’s always a worry when you release something for WordPress because everything is GPL, but it’s just part of the ecosystem. I mean, I reverse engineered their blocks to learn what I know now.

[00:23:27] Nathan Wrigley: Yeah, that’s a good point. Yeah.

[00:23:28] Johanne Courtright: And if they think it’s great idea then, you know, as long as they give me credit, I guess it’s fine.

But I say, not everyone will need break points. I mean, this is really more like, I’d say agency type things that usually you want those things, those features. They’re nice to have, but break points are not necessarily, I have to have it kind of thing if you are just a normal user. It’s more, if you want fine tuning for, like if you’re a designer and you really want those fine tunings, then they’re there.

[00:24:03] Nathan Wrigley: Does it kind of surprise you though that we are now, oh goodness knows how many years we’re into the Gutenberg project, but it’s many, many years. It’s more than you can count on one hand. Does it surprise you that this stuff is still missing? That somebody like you needs to build this functionality and, well, needs is maybe the wrong word, but desires to build this functionality. Does it surprise you that this kind of thing wasn’t in it when it shipped, that a layout system with all the break points taken care of and all of that completely customisable, does it still shock you that that isn’t there?

[00:24:34] Johanne Courtright: I have not done a whole lot of research, but based on what I’ve read so far is there was no intention to support it. So that’s why I decided to do it because I was like, I’m not going to wait for them to do it because they’re not going to do it.

[00:24:50] Nathan Wrigley: Yeah. So it was never something that was intended that was missing. It was just, it was never, literally never intended. So somebody needed to ship it. It’s kind of like that WordPress 80 20 rule. That’s the other curious thing about WordPress usage. Somebody like you and somebody like me who is constantly in there and fiddling the entire time, you kind of have this expectation that a lot of this stuff, oh, everybody would need this because I need it.

But the reality is, I guess most people are just logging in, changing a piece of text, maybe uploading an image, writing a blog post, clicking publish, and they’re done. And they’re relying on their agencies who’ve got the CSS, JavaScript, all of that React expertise that can build all of the different bits and pieces for them. So maybe it’s just me obsessing about these things because I’m in there all the time and I can see how they’re missing.

[00:25:36] Johanne Courtright: I think the way I build themes these days is like extremely light. It’s like, there’s a theme.json, there’s very little CSS and very, very little JavaScript. Everything is moved towards plugins. It’s really meant for colours, font types, branding type things. I have very little things in my themes these days because I believe that somebody who has a website and tomorrow they want a different theme, even for Christmas, and they decide, oh, I want a Christmas theme, should be able to do it easily by just swapping the theme.

[00:26:13] Nathan Wrigley: Clicking a button and it should all work, yeah.

[00:26:14] Johanne Courtright: Click a button, and all of a sudden it’s the new font, it’s the new palette colour, and it just works with minimal effort to just change anything or tweak anything. That’s how I see it. You shouldn’t have things that are baked in your theme where if you change your theme, now all of a sudden it’s not available for that theme. Don’t lock your clients into essentially a theme with features, and then they’re stuck with your theme.

[00:26:45] Nathan Wrigley: Okay, so that’s an interesting way of kind of spinning my question around in a sense. That whole thing that we have with clients where we have scope creep, you offer something, they agree to it, and then there’s this whole thing after you’ve built what they wanted, where they say, oh, but can we have, and then can we have, and what about this? We’ve got this idea as well. But that’s not the intention. The project was what we said it was going to be.

And so in a sense, the WordPress project is a little bit like that. You know, it’s not trying to be every feature for every human being who ever thought a thing could be achieved. It’s more, here’s the foundational stuff, and if you really want those things, well, either build it yourself or go and find somebody who has built that for you.

That kind of makes a lot of sense, doesn’t it? You know, if you’ve got this foundational platform, and I know the 80 20 rule, like I said, applies within WordPress. If 80% of the people need it, then it comes onto the scope of Core, and if it doesn’t reach that then it really doesn’t belong in Core. That’s kind of interesting because that reframes the whole thing and makes what you are saying true.

Most of the things that you’ve got, that you’ve built on top of Core, and again, I’ll direct people to the URL on the WP Tavern website. They probably aren’t for 80% of the people, they probably are for the 20%, the people like you, the developers, the designers who are building websites. The inexperienced people, the 80%, maybe they don’t need this stuff. That’s an interesting reframing of it.

[00:28:07] Johanne Courtright: Yeah, most people will probably be satisfied with just the basic theme that comes with WordPress. It’s got enough patterns at this point to have a good starting foundation. We need to get away from overbuilding our blocks in such a way where they’re rigid, this is the only thing it can do.

So when I build my blocks, I build in such a way the HTML can be moved around with grid system CSS, where I can move things because I built it in such a way that it’s very flexible. So all you have to do after that is just you create like some styling to accommodate that other different behavior that you want.

[00:28:51] Nathan Wrigley: So we’ve spoken just then about the bits and pieces that, you’ve extended WordPress Core and we described all of those. But there’s obviously bits that you felt were entirely missing that you thought might be useful to have. As I said a moment ago, some of these maybe are things that, I don’t know, maybe you’ll drop in the near future, or perhaps you’ll tweak in different ways because you did say that your accordion block behaves differently. But I know that the accordion block is coming to Core and what have you.

But you’ve got things like an Accordion Block, you’ve got an Accordion Panel Block, a Tabs Block, Tabs Panel Block, Media Section Block, Media Content Split Block, that’s interesting. Card block, Card Reveal Block and many others. This is, I guess, is this you sort of dogfooding projects that you’ve had in the past where a client has wanted a particular thing and you’ve thought, oh yeah, I’ve now built that, let’s see if we can sort of make it more generic and add it into your suite of blocks?

[00:29:43] Johanne Courtright: Those are pretty much blocks that keeps happening and being reused over and over and over. And they kind of become your basic foundation, if that makes sense. And they usually solve 90%, 95% of what you need for a site is essentially what’s part of the Core, is how I solved it. Another one that I solved that is very similar to what WordPress does was the Core Navigation.

[00:30:09] Nathan Wrigley: Oh, you’ve got a whole other thing there, haven’t you? Yeah, that’s interesting.

[00:30:12] Johanne Courtright: Yeah, this one is completely free, so I mean, my navigation falls very similarly what WordPress does, where I have a custom post type, I have blocks in it, and essentially it will use those menus that I can reuse in different parts of navigations. And the major difference is that WordPress is only this big modal and then you have very little customisation. It can go left or right, I think center.

[00:30:43] Nathan Wrigley: That’s more or less it really, isn’t it?

[00:30:45] Johanne Courtright: Yes. And it is annoying because if you choose left or right, well, it also affects your desktop versus modal, I didn’t like that. But I did like the idea of having the blocks sitting into a custom post type. So mine in that way does that too. But I didn’t want to interfere with what WordPress had done, so I created my own custom post type for it. But I’m still following the same principle where I have my blocks sitting in that custom post types be shared so I can reuse them.

[00:31:18] Nathan Wrigley: So you can use Core navigation blocks containing the pages and the posts and things like that. How do you build them up?

[00:31:25] Johanne Courtright: Well, I essentially copied over the link and the sub menu and I brought over some of their features, because I did like how they were, but I changed the HTML in it and what it’s capable of doing. Had a couple different things. That allowed me the flexibility to create accordions, and all sorts of different things without having to worry about having, you know how some sites will have a mobile menu, but they’ll have the same menu for the desktop, but it’s like a clone, but you don’t see it. I didn’t want that. Everything had to be done from the same HTML structure, and all it had to do is just essentially fall back gracefully into that other mode. And what was important also for me was that it was all Interactivity API.

[00:32:20] Nathan Wrigley: Oh, interesting. Okay, you’ve been leveraging that.

[00:32:23] Johanne Courtright: Yeah. So they’re all leveraging that. I was inspired also by Gutenberg Times website to do the vertical menu.

[00:32:31] Nathan Wrigley: Yes. Yeah, they’ve got the, I don’t know which theme they’re using, but that I think was a default theme. Was it 2020?

[00:32:37] Johanne Courtright: I was like, this is different. I want one like that. So I did support it too.

[00:32:41] Nathan Wrigley: Yeah, I see that. So on your navigation block, one of the options is to have this kind of full height column, which you can invoke and the menu, I guess slides out, but it then collapses back into that full size column. Have you had much feedback on that? Because it, I always worry that that’s going to consume quite a bit of the real estate when it’s not being invoked. Whereas, you know, a little hamburger icon, which is sitting at the top of the screen is obviously not consuming anything once you’ve scrolled past the navigation menu. Does it stay there all the time? If you’re not using the menu at that moment, does it live there all the time or, how does it work?

[00:33:14] Johanne Courtright: The bar stays there all the time. It’s up to you to add links that are useful in terms of what you’re doing. But, yes, it does stay there. It takes a little bit of the space, but it’s fine. You can choose also at what break point it will be sitting at the top instead.

[00:33:34] Nathan Wrigley: Oh, I see. Got it. Right. There is an option to remove it. Yeah, yeah, yeah. Okay.

[00:33:38] Johanne Courtright: Yeah. So you’re not, let’s just say you wanted to stop doing that at laptop or something, or tablet, then you just choose the option and it will just break to the other one at the top instead.

[00:33:49] Nathan Wrigley: Okay. And you’ve built a suite of blocks, so six at the moment that work in concert together to build that. So you’ve got the Navigation Block, which I’m guessing is kind of the wrapper for that, I’m not sure. But then you’ve got the Branding Block, which I presume holds logos and things like that. The Menu Block, which is the responsive bit where you can display stack menu items and things like that. Sub Menus, which I guess allows you to create those accordions where there’s a parent item, but things hidden underneath. A Link Block where you can just add a single thing, which I guess isn’t inside any other navigation anywhere. And then a spacer block, just something to create a bit of breathing room to separate one thing from another. And those six things, you just build in your custom post type, and once you’ve built them there, you can then invoke it and construct it entirely in the block editor.

You see this kind of stuff is really cool and really clever. Just the idea that you can build that in a, in this GUI, the block editor. Build it, style it, do all of the bits and pieces that you need to make it look nice inside the settings panel. It’s so great. The promise of Gutenberg delivered, really. This is the kind of stuff that it was always supposed to do, but people only seem to be getting to it now.

[00:34:57] Johanne Courtright: You know, you did ask me a few times if there was a feature I wish was in WordPress, and I do have one right now. Theme.json, you can specify specific colours for your buttons and your texts, your background, but I wish there was a way for us to set up other variables or some other things to specify more colours. So for example, my navigation, I have a lot more colours than two. I wish there was a way for me to set those up instead of using CSS and then the variable name and then manually injecting those.

[00:35:34] Nathan Wrigley: Right. Overriding things. Yeah.

[00:35:36] Johanne Courtright: Allow me to have custom keys or something where I can just say, oh, put your colours here, and then it will just generate whatever it needs to do. So if there was a way for me to have a block and specify, say, this is going to be the selector, this is the selector and this is the key. And then in the theme.json, all the person has to do is set up the key and the colour and it just applies it. That would be a nice feature.

[00:36:04] Nathan Wrigley: Yeah, it’s curious, you know, if for example, I was to go to, I don’t know, Squarespace or something like that and build my website with their technology, I guess there’s an expectation that what you get is what you get. This is it. You know, you pay your $20 a month or whatever it may be, I have no idea, and the features that you have are what you have. Maybe you can put in a support request somewhere and ask for another feature, but basically it’s very unlikely, I imagine, to happen.

Whereas just about everybody on the developer side of things, fiddling with WordPress, is constantly coming up with new ideas and different ways it can be adapted. And so there’s always this sense of, oh, I could build this thing into it, or I could do, and so it kind of breeds, not dissatisfaction, that’s the wrong word, but a curiosity for what it could do.

So you’ve just given a perfect example there. You’ve got this use case, which I don’t think I would probably make much use of. I think I’m probably happy with the two colours, but clearly in your scenarios that’s a way that you would like to adapt it.

And that’s why the platform is so cool. Maybe at some point somebody will listen to that request and will implement that for you in Core. If not, you maybe have to suffer the CSS load that you’ve got in the meantime. But that is really what separates it. You know, we’ve got this idea that, if you contribute, and you put your ideas in and you show up and you, you know, you offer your time, then that kind of stuff can be changed.

[00:37:28] Johanne Courtright: I have to say, I know that it creates a lot of friction at the moment and how they’re guarding and guiding very specifically. And they’re clear in their vision and they want to follow that vision, and it creates some frustration for some people who want things done differently. But I appreciate that they’re doing that because it was a long term project. The frustration probably comes from, I wish it was there, what it is today, many years ago, when it came out. But I do appreciate that there’s somebody with a vision who stick to their vision because I think it’s the right way.

[00:38:10] Nathan Wrigley: Yeah, and interestingly, everybody else’s vision can also be lived. So, you know, there’s a variety of different page builders, and I know that’s not your thing, but it is the thing of many millions of people. They love that, and that’s their preferred way of doing it. You can’t do that on these other proprietary platforms. There isn’t a different entire UX and UI that you can inject into it, but we have that, you know? And if you want to use a page builder, or you want to use whatever it is that you want to use, that’s the way it is.

I suppose the only thing we’ve got to be mindful of is the flame was that sometimes occur. You know, people saying, well, my tool is the best tool. Anybody else that’s using anything else is missing out or what have you, or maybe stronger language than that. And just recognise that, well, the reason that you can do that is because there’s this foundational stuff, the WordPress Core.

[00:39:00] Johanne Courtright: They’re allowing it.

[00:39:01] Nathan Wrigley: Yeah, and it’s allowing you to have that, and you don’t have to use Gutenberg. But it does feel, it really does feel as if in the latter part of 2025, it does feel as if there’s a little bit more excitement around the Block Editor and the different bits and pieces. I don’t know if you’ve picked up on that, but there seems to be more stories. There seems to be more people shipping products that latch onto the block editor. Yours obviously is an example of that.

[00:39:24] Johanne Courtright: The biggest hurdle is to learn it’s a different mindset, different language, it’s different in so many ways. There’s just too much to learn to jump from old way to new way. And it’s very overwhelming for a lot of people. It’s very, very overwhelming.

[00:39:45] Nathan Wrigley: Genuinely don’t know how we bridge that gap, to be honest, because I think you’re right. If you’ve been familiar with using WordPress in its classic form, then it is, it’s seismic. But more or less, every developer that I know has at least some curiosity in Gutenberg and things like that, so probably.

[00:40:00] Johanne Courtright: Once people fully decide to embrace it and take the time to reverse engineer and understand it, they’re like, oh, wow. All the cool stuff I can do. Yes. You know? And they change their mind completely. It’s a bit challenging because I mean, even like, let’s just say Tailwind, which is the CSS framework. I mean, it’s great. Tailwind is amazing, but when you start trying to use it with WordPress, that’s another one that fights WordPress. I stopped using it. I’m just going with SCSS and I build my own stuff. Now I have very little CSS into my blocks and it’s just, there’s no real point to have CSS framework in WordPress. You don’t need that.

[00:40:44] Nathan Wrigley: I’m going to pivot the subject a little bit, and it’s because of a tweet that I saw yesterday, I believe it was. A friend of mine tweeted that he’s yet to see a block solution. So I don’t think that those were the words that he used, but he’s yet to see an out and out successful business built on top of blocks. So the example might be that, for example, on WordPress Core, you’ve got all of these really successful products. So you’ve got things like Gravity Forms and things like that, that have made real, they’ve got a real stable business going on. And he was questioning, have we seen that with blocks yet?

So you are trying to make that happen. You are trying to sell a commercial product. I know that there’s, free versions and things like that, but you’re trying to sell a commercial product. How is that? What is the landscape for that at the moment? Because I’m guessing it’s not like you are printing money at the moment. I don’t know how difficult that is and whether or not it’s been the fountain of cash that maybe you’d hoped it would be.

[00:41:44] Johanne Courtright: I don’t expect it to be a fountain of cash. I love what I do. I do it for myself first, and if other people happen to enjoy it, then But if they don’t, that’s fine, I’m using it.

[00:41:59] Nathan Wrigley: That’s very sanguine approach. I think his thought when he made that tweet is that maybe we’re on the cusp of something. Because it feels like there’s a certain speed that the flywheel needs to achieve before people become really interested in it. I’m not sure that that has yet happened. But give it some more time, give it some more interesting products, some more attention, some more marketing and what have you. And definitely a lot of the stuff shipping in 6.9, which is actually coming out today. And then 7 next year, and all of the AI bits and pieces that are going to be put in as well. You never know. Maybe with a fair wind, we’ll be printing money for you.

[00:42:38] Johanne Courtright: I do have a message for Matt if he listens. He needs to work on his plugin and themes website. It’s not usable at the moment. It doesn’t leave room for new development, new plugins to be seen. It needs to be feeling more like a community.

I come from a background where I did a lot of desktop customisation. We had featured skins and themes and wallpapers and there was, people were excited. There was somebody reviewing. Think about it about how Apple does their Apple store, where they had like featured apps. Somebody went and tested a few of those plugins and featured them. They pick them. We need more, something like that.

We also need to have a better search. Search is awful. It’s all stuffed keywords. And if you’ve been around for a while, if you’re new, there’s no way for you to rank for anything. There needs to be true categories and easier ways to find what you’re looking for.

[00:43:37] Nathan Wrigley: Do you know, that’s a whole interesting other conversation, isn’t it? Maybe we’ll have that one time. But I get what you mean. When the iPhone came out, don’t know if you sort of remember or go back that far, but when the iPhone came out, it was this curious but beautiful object that had a lovely screen and could play songs and things. But the moment the app store came along for the iPhone, that’s I think when it became really interesting.

And it does feel with the advent of blocks, like there’s an opportunity similar to that in that WordPress is no longer just these plugins and themes. We’ve got this whole other thing now, these blocks, these mini applications if you like, which really in many ways have full capabilities like plugins would do. And being able to surface those and find a block or a.

[00:44:26] Johanne Courtright: You should be able to set, are you supporting Gutenberg? Is it using jQuery? Is it using those basic little things like check, check, check? And if some people are looking for those things, they should be able to find you.

Right now it’s useless. It’s very useless, even for me looking for a plugin. Most of the plugins I found these days are because I use Google or AI, or there’s other means, but it’s very hard to find. I don’t even rank in the first 40 some pages for my navigation, so it’s ridiculous. Look for navigation, you won’t find me.

[00:45:04] Nathan Wrigley: Okay, so maybe that’s work to be done in 2026. But hopefully somebody has heard your plea there and you never know. If they have and they want to reach out to you, well, obviously we know that you’ve got the Groundworx with an X, .dev website. Is there another place where you hang out online that people could find you if they wanted to have a chat?

[00:45:23] Johanne Courtright: I’ve been hanging out a lot on X these days. I get a lot more response there. It seems to be WordPress community hangs out there a lot, so I think that’s going to be my platform of choice for a while.

[00:45:36] Nathan Wrigley: Okay. In which case, into the show notes, along with the links to all of the bits and pieces that we mentioned, I will bury the link to Johanne’s X profile as well, so you can go and connect there.

Thank you so much for chatting to me today. It’s really interesting getting your insight into all of the bits and pieces that you’ve done extending Gutenberg, but also all of the bits and pieces that you’ve done with new stuff as well. Go check it out. It’s Groundworx.dev. Johanne, thank you so much for chatting to me today.

[00:46:01] Johanne Courtright: Thank you for inviting me. Thank you so much. It was great.

On the podcast today we have Johanne Courtright.

Johanne started working with WordPress back in 2011, moving over from a background in marketing agencies, Dreamweaver, and static HTML sites. Over the years, she’s become a skilled developer, focusing on extending WordPress through custom queries, forms, integrations with APIs, and increasingly, harnessing the power of the block editor and React.

Johanne talks about her journey from the classic world of agency WordPress development to embracing Gutenberg, and the challenges and wins along the way. She shares her experience in building custom blocks and enhancing existing ones to better serve agencies, things like improved breakpoints, color palettes, responsive designs, and navigation, all of which aren’t offered in Core yet. These features come together in her growing open-source project, Groundworx.

We talk about the shifting landscape from classic themes to block-based themes, and why, even in 2025, a lot of agencies and users are still hesitant to make the leap fully. Johanne explains where the block editor falls short for her use, and how Groundworx aims to plug these perceived gaps with a foundation of flexible, performant, agency-focused blocks and templates.

You’ll hear about her approach to building modular themes with theme.json, the realities of client work and scope creep, and how the 80/20 rule shapes what belongs in Core and what’s best handled by plugins.

We also get into the challenge of discovery in the WordPress plugin ecosystem, her wishlist for Block Editor improvements, and her take on the future of block-based businesses in WordPress.

Whether you’re a developer eager to modernise your workflow, or just curious about extending Gutenberg for real-world use, this episode is for you.

Useful links

Groundworx Core

Groundworx Navigation

Gutenberg Times

Why Agencies Use Low-Code Tools

19 March 2025 at 16:25

Architects can draw up plans by hand, but they’re more likely to use CAD software to realize their version faster, with less expense, and no sacrifice in quality. In a similar vein, web development agencies that use low-code or no-code tools as part of their workflows aren’t abandoning code. Instead, they’re prioritizing where human skill matters most.

Low-code tools handle templated layouts and client tweaks, while developers focus on performance optimization, security, and custom functionality—the structural engineering of a website. The result? Faster launches, happier clients, and fewer burnout-inducing CSS battles over padding adjustments. In this article, we talk to three agencies who use low-code tools as part of their stack, and discuss what advantages they realize from doing so.

King Grizzly’s Client-Centric Philosophy

Brian Erickson is one of the principals at King Grizzly, an agency he co-founded with his brother. The team at King Grizzly has deep web development experience, stretching back to the days before WordPress existed. They have the skills to do everything manually, but Erickson says they use Elementor for two reasons.

“We’ve got the development chops to create full custom websites, but in terms of hours spent, we just work faster using a tool like Elementor where we can,” he says. “The other reason is that it helps to create an understanding with clients. Our clients are typically mid-sized, not enterprise. With Elementor, the marketers and content creators at those organizations can use it to create content themselves.”

King Grizzly uses Elementor to grant clients “curated control.” The agency translates Figma designs into Elementor with centralized global styles—fonts, spacing, colors—ensuring one tweak updates the entire site. This prevents clients from accidentally breaking designs while granting them autonomy for content updates. In addition, if changes are needed down the road, the entire site can be updated from centralized controls instead of going through dozens of pages to make repetitive updates. Post-launch, clients receive video tutorials showing them how to do everything. “We always include one video that’s a technical walkthrough,” says Erickson. “It’s really for some developer down the road, so they can take 10 to 15 minutes and see how we build the site.”

Workflow Optimization

Part of the “curated control” King Grizzly offers is by enforcing strict design systems to avoid chaotic, ad-hoc styling. Global settings in Elementor act as a sort of “GitHub for non-developers,” eliminating hours-long scavenger hunts for inline styles. Custom code isn’t banned, but it is managed strategically: the WPCode plugin tracks PHP/JavaScript changes with revision histories, offering content editors and marketers a form of version control without technical jargon.

Future-Proofing

Erickson notes that the team is open and flexible when it comes to new tools. While Elementor works for 80% of clients, King Grizzly tests alternatives to ensure their chosen solution is still relevant and durable, and to learn approaches available in other tools. “Mid-market clients need reliability, not bleeding-edge tech,” Erickson says. “Clients pay us to solve problems and help their brands grow with tools they can understand, not to code sliders from scratch.”

Matchbox Sidesteps Page Builders with FSE

Cullen Whitmore, co-founder of Matchbox Design Group, notes that his agency often uses WordPress’s native Full Site Editing (FSE), including for content-heavy clients like Midwest BankCentre. The Block Bindings API connects core blocks (e.g., Paragraph, Image) to custom fields, letting marketers update bios or phone numbers without touching designs. “If your site isn’t easy to use, you won’t update it,” Whitmore says. Predefined style variations act as guardrails, allowing layout swaps without brand risks.

Workflow

By binding core blocks to ACF fields, Matchbox sidesteps page builders entirely. Designers prototype in FSE while content teams populate layouts with real data, enabling parallel workflows. “We’re not waiting for design ‘approval’ to start building. It’s agile, not waterfall,” Whitmore explains.

Future-Proofing

Prioritizing native tools over plugins avoids compatibility issues. When Gutenberg introduced block bindings, Matchbox connected ACF fields overnight—no third-party tools required. “No deprecated shortcodes or plugin conflicts,” Whitmore notes.

Adopting FSE requires patience, but Whitmore predicts more developers will learn to juggle FSE, block themes, and React. “The ‘coder vs. no-coder’ debate will feel outdated as core evolves.”

Gorilion: Scaling with Speed and Standardization

Sean Bryant is the founder of Gorilion, an agency he formally incorporated in 2020. He started developing websites while still in high school, eventually moving over to Drupal as it had “…post types and views and all these cool features for manipulating and displaying content,” he says. “I eventually moved over to WordPress because they had page builders and ACF fields and other technology that we needed.”

For Bryant, using Elementor as part of the build process helps to cement WordPress as “the best of both worlds. You’ve got the Squarespaces and Wixes of the world that are easy for mom-and-pops and marketing team members to edit and update. And then WordPress gives you the ability to code custom functionality. We essentially get the best of worlds with Elementor and WordPress. You get that nice, easy interface for the clients to edit and update, and then you’ve got the features to add your own elements and plugins, programming anything you need to go with it.”

Workflow

Gorilion’s formula prioritizes a smooth, speedy workflow: designers create pages with brand-approved assets, developers add custom features like eCommerce hooks, and clients review staging sites pre-loaded with integrations. “Designers aren’t waiting for devs to ‘translate’ Figma—they build most of the site themselves,” Bryant explains. “I QA it, then customize it, put in advanced loops and so on, anything you can’t do in Elementor. It’s helped a lot with our workflow, enabled us to build more sites faster, and made it easier for our clients to edit and market.”

When Coding is Best

Bryant draws a clear line: “If a client needs custom post types or API hooks, we code it—no shortcuts.” But for brochure sites or small e-commerce stores, Elementor reigns. “Why charge the client $100,000 for a fully custom-coded site, when you can do it for much cheaper by blending Elementor and custom coding? The site is easier to edit and manage for the client too.”

“Clients don’t care if you used a page builder, AI tools, or a magic wand,” Bryant says. “They care that you fixed their SSL cert before lunch. Build fast, communicate faster, and let tools handle the rest.”

Conclusion

Just as CAD software transformed architecture without diminishing the architect’s vision, low-code and no-code tools are redefining—not replacing—the craft of web development. The agencies profiled here exemplify how blending automation with expertise creates a win-win: clients gain intuitive control over their digital presence, while developers reclaim time to tackle high-impact challenges that demand human ingenuity.

The true power of these tools lies in restraint. By enforcing guardrails, standardizing workflows, and reserving custom code for strategic enhancements, they can help you to deliver faster launches, lower costs, and enduring solutions tailored to client needs.

As the industry evolves, the “code vs. no-code” debate grows increasingly irrelevant. The future belongs to agencies that wield tools pragmatically, prioritizing outcomes over dogma. The goal remains unchanged: build smarter, empower clients, and focus talent where it matters most. After all, a website’s success isn’t measured by how it’s built, but by how well it serves its purpose—and these agencies prove that sometimes, the right tool is the ultimate competitive edge.

Do you use low-code or no-code tools as part of your development stack? Let us know in the comments!

The post Why Agencies Use Low-Code Tools appeared first on Delicious Brains.

❌
❌