How to Edit a WordPress Website (Ultimate Guide)

Are you a new WordPress.org user who wants to learn how to edit your WordPress site?

Here at WPBeginner, we have helped millions of beginners build their websites using WordPress, which is the most popular website builder on the market. If you need help with editing your website, then you have come to the right place.

In this article, we will show you the basics of editing a WordPress website.

How to Edit a WordPress Website (Ultimate Guide)

An Overview of Ways to Edit a WordPress Site

As an open-source content management system, WordPress has a lot of features to build and edit your website.

If you installed WordPress recently, then you may have come across Gutenberg, which is WordPress’s drag-and-drop block editor that allows you to customize a page or post. This feature is pretty easy and beginner-friendly.

The Gutenberg block editor interface

You may have also seen the Full Site Editor.

This is an extension of Gutenberg that lets you use the block editor to customize block-based WordPress themes.

The WordPress Full Site Editor

That said, if you use a classic, non-block WordPress theme, then the FSE won’t be available to you. Instead, you will have to use the WordPress Theme Customizer.

This feature doesn’t come with a drag-and-drop function, so it’s not as user-friendly. You have to edit your theme using some menu settings in the left-hand panel.

Using the WordPress Theme Customizer to edit a transportation and logistics website

If you need more customization options that aren’t available in WordPress’s built-in features, then you can install a page builder plugin like SeedProd.

This is what we usually recommend to WordPress beginners. Like Gutenberg, SeedProd has a drag-and-drop feature. However, it offers more ways to get creative, like animation effects and more content block options to build your pages.

Editing the online coaching business theme in SeedProd

Some WordPress users also use the Classic Editor. It’s WordPress’s legacy page and post editor that looks a bit like a document editor.

This feature is no longer enabled by default in the latest WordPress versions. However, some people still use it because they are more familiar with it and want to keep their current website designs.

The Classic Editor Interface

In this article, we will show you how to edit different parts of your WordPress website using the editors we’ve mentioned.

We will also assume that you have WordPress installed and set up already. Otherwise, you will need a WordPress hosting plan, domain name, and WordPress installation.

Want to skip to a specific section in this tutorial? Feel free to use these quick links below:

How to Edit a WordPress Theme

One of the first things you should do after installing WordPress is to choose and customize your theme. We will show you 3 ways to do that.

Customizing a Block Theme With the Full Site Editor

Full Site Editing was introduced in WordPress 5.9. It’s designed to make it easy to edit WordPress block themes using the block editor.

One tell-tale sign that you are using a block WordPress theme is you will see Appearance » Editor in your WordPress admin area. If you see Appearance » Customize instead, then you can skip to using the Theme Customizer.

Clicking Appearance Editor in the WordPress admin

To use the Full Site Editor, you will need to have a block theme installed. You can find plenty of them in our list of the best block WordPress themes for Full Site Editing.

If you want to find some free options, go to Appearance » Themes. Then, click ‘Add New Theme.’

Adding a new WordPress theme in the admin area

After that, just switch to the ‘Block Themes’ tab.

You will then see dozens of block themes on your screen. For installation instructions, check out our step-by-step guide on how to install a WordPress theme.

Finding WordPress block themes in the admin area

Once you have the theme installed, you must go to Appearance » Editor.

Now, you will see the main Full Site Editing dashboard. You can then edit your theme’s navigation menu, styles, pages, templates, and patterns.

We will discuss these topics in the rest of the tutorial, but we will show you briefly how to change the style of your theme.

To do this, click the ‘Styles’ menu.

Clicking Styles in the Full Site Editing interface

Now, you will see a list of the color scheme and typography pairings provided by the theme.

Every time you click on a style, the interface will preview it for you.

Choosing a theme style in the Full Site Editor

Once you are satisfied with your choice, just click ‘Save.’ Alternatively, you can create a custom style.

You can learn more about this and other ways to use the Full Site Editor in our beginner’s guide to WordPress Full Site Editing.

Customizing a Classic Theme With the Theme Customizer

If you use a classic WordPress theme, then you will work with the Theme Customizer to edit it. Simply head to Appearance » Customize from the WordPress admin area to access it.

Opening the WordPress theme customizer

Now, what you can customize here varies by the theme you are using.

For instance, if you have the Astra theme, then you can customize the style of your entire website, header, footer, sidebar, page, logo, and so on.

For this reason, we recommend reading your theme’s documentation for more instructions.

What the Theme Customizer looks like for Astra theme

Our guide on the Theme Customizer can give you more detailed pointers.

Once you’ve made your changes, you can preview the website in different screen resolutions. Then, you can hit the ‘Publish’ button at the top to make your edits live.

Publishing a classic WordPress theme in the Theme Customizer

One downside of the Theme Customizer is its user experience isn’t as flexible or easy as the block editor. If you feel this way, then we recommend using the next method instead.

Customizing a WordPress Theme With a Page Builder Plugin

Many WordPress users who aren’t satisfied with the platform’s built-in design features use a page builder to edit their site. This is a WordPress plugin that can replace the default editor for designing different parts of your website.

Most page builders come with a drag-and-drop functionality, so they are just as easy to use as the block editor. What’s more, they come with more page blocks and templates to personalize your website.

Out of all the page builders we’ve tried, we find SeedProd to be the best. It comes with 300+ templates for various industry categories, from eCommerce and accommodation to services.

SeedProd Website and Theme Builder

Note: While SeedProd comes in a free version, we recommend upgrading to the Pro plan to access the Theme Builder. This is what we will use in this tutorial.

To use SeedProd, you will need to install the WordPress plugin first. After that, go to SeedProd » Settings to activate your Pro plan license. Simply insert your license key and click ‘Verify Key’ to complete this step.

Verifying SeedProd Pro's license key

Next, switch to SeedProd » Theme Builder.

Just click ‘Theme Template Kits‘ to view your theme options.

Accessing SeedProd's Theme Template Kits

As you can see, there are many theme template kits available, from online stores to service sites. Feel free to use the filtering and sorting settings to find the right one for your needs.

Once you’ve made your choice, just hover over the theme template and click the orange checkmark button to use it.

Choosing a theme template kit in SeedProd

Now, just go back to the Theme Builder page and select a theme template you’d like to edit.

For demonstration purposes, we will show you how to edit the style of your SeedProd theme template. To do this, locate the ‘Global CSS’ theme template, hover over it, and click ‘Edit Design.’

Editing a theme template kit's Global CSS in SeedProd

You are now inside the SeedProd page builder and can customize your theme template’s style. Here, you can change your website’s colors, fonts, backgrounds, buttons, forms, and layout.

Let’s see how to change the theme’s default font. To do this, open the ‘Fonts’ menu. Then, just choose one of SeedProd’s many font and color options for the heading and body text.

All the changes you make will show up automatically in the right-side preview.

Changing a SeedProd theme template kit font in the Global CSS theme template

Once you are happy with the style, just click ‘Save’ to make these changes official.

Then, you can go back to SeedProd » Theme Builder and turn on the ‘Enable SeedProd Theme’ toggle in the top right corner.

Enabling the SeedProd theme template kit in WordPress

For more information about editing WordPress themes with SeedProd, you can see our guide on how to easily create a custom WordPress theme.

How to Edit a WordPress Page or Post

If you have updated WordPress to the latest version, then most likely, you will use the Gutenberg block editor to edit a page or post.

You can create a new page by going to Pages » Add New Page. This will automatically make an entirely blank page and direct you to the block editor.

On the other hand, if you want to edit an existing page, like the homepage or blog page, then you can go to Pages » All Pages. Hover your cursor over the page you want to edit, and then click ‘Edit.’

Clicking the Edit button to edit an existing WordPress page

Alternatively, there is also the Quick Edit feature.

This allows you to modify the page’s title, URL slug, and last modified date.

Clicking the Quick Edit button in the WordPress Pages page

You can do various things with the Quick Edit feature.

Examples include setting a password for the page, making it private, assigning it as a parent page, changing the page template, allowing/disallowing comments, and changing the page status.

The Quick Edit feature for WordPress pages

To create a new post, simply head to Posts » Add New Post to make a new blank post and edit it using the block editor.

Like before, you can edit an existing WordPress blog post by hovering your cursor over the selected post and clicking ‘Edit.’

The WordPress Posts interface in the WordPress admin area

The Quick Edit feature for posts is similar but with some minor differences.

Here, you can also add tags, allow/disallow pings, and make the post sticky (featured on your website).

The Quick Edit feature for WordPress blog posts

Once you have opened up a WordPress page or post, there are many things you can do in the block editor.

Typically, you will start by clicking the ‘+’ add block button in the top left corner.

This is where you will find all the available blocks from WordPress and the plugins you use.

Opening the block inserter library in WordPress

You can then drag and drop a block to the main editing area.

After that, you can use the block’s toolbar and settings sidebar to configure the block’s style, dimensions, spacing, and more.

The block settings sidebar in WordPress

If you have installed a WordPress plugin, then you may also see some settings below the editing interface.

For instance, the All in One SEO plugin will show you a section where you can optimize the page or post’s meta title and description for search engines.

The AIOSEO settings in the WordPress block editor

We have plenty of guides for you to learn more about editing posts and pages, so be sure to check them out:

How to Edit a WordPress Page or Post With Classic Editor

If you want to use the Classic Editor, then you will need to enable it. You can read our article on how to disable Gutenberg and activate the Classic Editor to do this.

After that, just create a new post or page by going to Posts » Add New Post or Pages » Add New Page, and the Classic Editor will show up on your screen.

The WordPress classic editor

Unlike the block editor, you won’t add blocks to insert content into your page or post. Instead, you can only type text, format it using the controls at the top of the editing panel, and add media files to your content by clicking on the ‘Add Media’ button.

At the bottom and the sides of the editing interface, there are settings to publish the page/post, set the page or post’s categories/tags, upload a featured image, and so on.

You can also switch between the visual and text editing modes. With the second editor, you can modify the post or page’s HTML code.

The text editing mode in the WordPress classic editor

How to Edit a WordPress Page With a Page Builder

If you already use a page builder like SeedProd to edit your theme, then you can use it to edit a page as well. This way, you can maintain your design’s consistency throughout all of your pages.

You will need to create a new page and open the block editor. If SeedProd is active, then you will see a button at the top that says, ‘Edit with SeedProd.’ Go ahead and click on it.

You can also do this with an existing page. However, do note that the content will not be transferred over, and you will have to create the page from scratch.

Clicking the Edit with SeedProd button in the WordPress block editor

In the page builder, you will see that the SeedProd theme’s header and footer have been added. All you need to do is start building the page.

First, choose one of the 8 layouts to use on the page.

Choosing a layout for the section in a SeedProd theme template

On the left-hand side, you will find all the blocks and sections that you can drag and drop onto the right-hand side, which is the template preview.

You can use these to insert content into the page.

SeedProd's block library

Whenever you click a block or a section, the left-hand side will show the available settings to customize the element.

In the screenshot below, you can see that clicking on the Text block will make the block settings appear. You can customize the text, insert dynamic content, edit the HTML, change the alignment, and so on.

Customizing SeedProd's text block settings

Once you are done editing the page, don’t forget to click ‘Save’ to make the changes live.

For more details, just see our guide on how to create a custom page in WordPress.

If you want to create a custom landing page from scratch, then you can also do that with SeedProd. All you need to do is go to SeedProd » Landing Pages. Then, click the ‘+ Add New Landing Page’ button.

Create a new landing page in SeedProd

For more information, check out our tutorial on how to create a custom landing page.

Alternative: Thrive Architect is another great page builder option for designing attractive and conversion-focused landing pages.

You may also want to edit the WordPress header, footer, sidebar, and other parts of your theme template.

These are sections on your site that are not part of the main page or post content. However, they are essential for giving additional information or helpful navigation.

How you can edit these sections depends on what theme you are using, so let’s go through each option.

How to Edit a Block Theme’s Header, Footer, and Other Template Parts

If you have a block theme, then you can use the Full Site Editor to edit your theme’s header and footer.

In the Full Site Editor, a header and footer are considered template parts. These are also known as WordPress patterns (a set of reusable blocks) that appear throughout your website.

Other examples of a template part include the comment section and the post meta.

For the sake of example, we will show you how to edit your WordPress header, but you can repeat these steps with other template parts.

First, go to Appearance » Editor. Once you are in the Full Site Editor, just click ‘Patterns.’

Clicking the Patterns menu in the Full Site Editor

You will now see a list of patterns provided by your WordPress theme.

Go ahead and scroll down to the Template Parts section. Then, select ‘Header’ and click on the Header template part.

Opening the header template part in the WordPress Full Site Editor

Now, you need to click the pencil button next to the Header text.

This will open the block editor.

Clicking the pencil button to edit the header using the Full Site Editor

The block editor works the same way with template parts as it does with pages and posts. You can add various blocks to the header, configure the block, and update the changes when you are done.

Headers usually include a Site Logo (or the favicon), so feel free to add that here, too.

Adding the Site Logo block to the header in the Full Site Editor

If you want to completely change how the header looks but don’t know where to start, click the ‘+’ add block button in the top left corner.

Then, navigate to the ‘Patterns’ tab and click ‘Headers.’ You will find many ready-to-use header layouts there.

Finding WordPress header patterns in the Full Site Editor

For more information, see our guide on how to customize your WordPress header.

Once you are done changing the header, click ‘Save.’ Since the header is a synced template part, all the changes you make here will apply across all pages that use the header.

Now, if you want to create a new header or any other template parts rather than editing the existing ones, you can go back to the ‘Patterns’ page. After that, click the ‘+ Create pattern’ button and select ‘Create template part.’

Creating a new template part in the Full Site Editor

In the popup, give the template part a name and select the type of template part.

Then, click ‘Create.’ You will then be directed to the block editor and you can edit the template part like usual.

The Create template part popup in the WordPress Full Site Editor

For more details, you can see our complete guide to WordPress full site editing.

How to Edit a WordPress Header, Footer, and Other Widget-Ready Areas in a Classic Theme

In a classic theme, a WordPress widget is basically a block that you can add to widget-ready areas, like headers, footers, sidebars, and so on.

Every classic WordPress theme has different widget-ready areas. Some may include a sidebar, and some may not. So be sure to check your theme’s documentation for more information.

To use widgets, you have to go to Appearance » Widgets. Here, you can add, configure, and remove blocks in the available widget-ready areas.

Adding the FlipBox widget to a sidebar or similar section

You can read more information about widgets in our how to add and use widgets in WordPress article.

Also, check out our guide on the difference between widgets and blocks to understand more about this feature.

How to Edit a WordPress Header, Footer, and Other Template Parts With a Page Builder

One of the benefits of using a page builder is you will have more options to customize headers, footers, sidebars, and other parts of your theme.

If you use SeedProd, you can go to SeedProd » Theme Builder. We will assume that you have installed a theme template kit from earlier.

The kit usually includes various theme templates. This may be a built-in page template, like a 404 or single post, or a part of a page, like a header, footer, pricing tables, and so on.

Go ahead and hover over a theme template. Then, click ‘Edit Design.’

Editing the header theme template in SeedProd

Now, you can edit the header the same way as you would with a page.

Let’s say you want to add your social media links here. What you can do is hover over the header until the blue border appears and click the ‘+ Add Row’ button. Then, go ahead and select a row layout.

In our example, we want to add one more column so that the header can fit the image, menu, and social media links. That means we will need three columns in one row.

Choosing a row layout in SeedProd

You can then drag and drop the blocks from the top row to the new row.

After that, just delete the top row so that your new row becomes the new header.

Deleting a previous row in a SeedProd section

Now, just look for the Social Profiles block in the left-side panel.

Drag it into the right column, and you are done.

Adding the Social Profiles block in the header in SeedProd

For more information about editing template parts, you can read these WordPress tutorials:

How to Edit a Navigation Menu in WordPress

A navigation menu makes it easy for visitors to explore all your content without getting lost on your website. That’s why it’s important to design a menu that shows your essential pages and links to other relevant information.

If you use a block WordPress theme, then you can select the ‘Navigation’ menu from the Full Site Editor page.

Selecting Navigation in WordPress Full Site Editing

Our article on adding custom navigation menus in WordPress can walk you through the rest of the steps.

If you use a classic WordPress theme, then you can go to Appearance » Menus. This is a dedicated page for you to add, arrange, and remove pages/posts and links to your menus.

How to add a WordPress navigation menu to your site or blog

For step-by-step instructions, you can check out our beginner’s guide on how to add a navigation menu in WordPress.

If you use a page builder like SeedProd, then your navigation menu (Nav Menu block) may have been embedded in your header theme template.

The Nav Menu block will already include all of your pages, though you can add new items, too.

First, go to SeedProd » Theme Builder from your WordPress dashboard. Then, find the ‘Header’ theme template and click ‘Edit Design.’

Editing the header theme template in SeedProd

Now, hover over the block that looks like a menu. That should be the ‘Nav Menu’ block.

After that, scroll down on the left panel and click ‘+ Add New Item.’

You can then customize the anchor text, enter the URL, have it open in a new window, and set it as nofollow.

Adding new menu items in SeedProd

Toward the bottom, you can change the links’ font size, spacing, divider, and alignment.

Don’t forget to click ‘Save’ to make the changes live.

Configuring the Nav Menu block in SeedProd

How to Edit a WordPress Site With Code

If you are comfortable with code, then you can also use custom code snippets to edit your WordPress website. That said, we only recommend this method if you have the right technical know-how to avoid breaking your website.

One way you can edit a WordPress site with code is by adding CSS, which is a stylesheet that can change how HTML looks on the front end.

Classic theme users can go to Appearance » Customize and find the ‘Additional CSS’ field in the Theme Customizer.

Here, you can insert CSS code to style different HTML elements like colors and fonts.

This may be handy if your theme’s built-in options aren’t enough for your needs.

Adding custom CSS in WordPress

As for block theme users, you cannot add custom CSS within the Full Site Editor.

Instead, you have to go to the URL below to open the Theme Customizer and find the Additional CSS field. Make sure to replace the domain name with your own.

https://example.com/wp-admin/customize.php

For more details, see our guide on how to fix missing Theme Customizer in WordPress.

Another way to add CSS is with CSS Hero. This plugin makes adding custom CSS to WordPress themes easy, even for beginners. If you are interested in using it, then just check out our CSS Hero review.

How to Edit WordPress Theme Files

At times, some tutorials may require you to edit your WordPress theme files to make changes beyond what your built-in theme features allow. In this case, we recommend:

  • Creating a child theme first. This is like a copy of your WordPress theme that you can safely customize with some coding.
  • Backing up your website. It’s a good measure to do so that you can restore your website to a previous version in case of errors.

Editing a WordPress theme file requires going to your WordPress file directory from the backend. To do this, you will need to open your hosting provider’s file manager or connect to your website with an FTP client.

If you use Bluehost, then you can go to your dashboard and open the ‘Websites’ tab. After that, click ‘Settings’ on the website for which you want to open the theme files.

Opening Bluehost's website settings

Now, simply scroll down to the ‘Quick Links’ section.

Then, click ‘File Manager.’ If you’re not sure where your root folder is, you can check the ‘Document Root’ function to see its path.

Opening Bluehost's file manager

Once inside the file manager, you can go to your website’s root folder (usually named public_html).

Then, head to /wp-content/themes and find your current theme folder.

An example of what the WordPress theme files look like in the Bluehost file manager

After that, you will find all of your WordPress theme files, which you can edit using a text editor.

Here are some things you can do by editing WordPress theme files:

How to Safely Insert Custom Code into WordPress

If you want to add new custom code rather than editing the code that is already within your theme files, then we recommend using WPCode. It’s the best WordPress code snippets plugin for easily inserting and managing custom code snippets.

WPCode - Best WordPress Code Snippets Plugin

With this plugin, you won’t have to worry about accidentally breaking your website. WPCode will let you know if there are errors in the code and deactivate it. Plus, you can create PHP shortcodes for inserting custom content into your website.

To see WPCode in action, you can check out our full WPCode review in the WPBeginner Solution Center.

What Is the Best Way to Edit a WordPress Site for Beginners?

For beginners, we always recommend installing a page builder plugin like SeedProd to edit WordPress websites. The reason is that it’s just as easy to use as the block editor yet gives you much more control over your website design.

If you don’t want to use a plugin, then the next best thing is a block theme with the Full Site Editor. This feature is not entirely developed yet because WordPress is constantly working on the Gutenberg project. But as of now, it’s pretty user-friendly.

The Theme Customizer is not as flexible as the Full Site Editor because it lacks drag-and-drop functionality. That’s why we suggest classic theme users install SeedProd to improve their user experience.

As for coding, we only recommend it if you have created a child theme and backups of your site to avoid errors. But with the WPCode plugin, adding custom code to edit your WordPress site is much safer and won’t cause any errors or break your website.

We hope this article helped you learn how to edit a WordPress website. You may also want to check out our in-depth WooCommerce tutorial to create an online store and the ultimate guide to WordPress SEO.

If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.

The post How to Edit a WordPress Website (Ultimate Guide) first appeared on WPBeginner.

#50 – Fränk Klein on How Gutenberg and Full Site Editing Are Bringing New Opportunities for WordPress Developers

Transcript

[00:00:00] 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, what the future looks like for WordPress developers.

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 forward slash feed forward slash 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, well I’m keen to hear from you and hopefully get you, or your idea featured on the show. Head over to WPTavern.com forward slash contact forward slash jukebox, and use the form.

So on the podcast today we have Fränk Klein. Fränk is a self-taught developer. He started out learning PHP in 2011, and from there found his way to WordPress. Over the years he’s worked for Automattic at wordpress.com, and WordPress VIP, and is now a principal developer at Human Made, an enterprise WordPress agency.

Today on the podcast we talk about how Fränk decided early on that he was going to start developing with blocks and, more recently, with the full site editing capabilities now built into WordPress Core.

We talk about the four phases of the Gutenberg project, content editing, site customization, collaborative editing and multi-lingual, and where full site editing fits into this.

Fränk explains how he sees the adoption of Gutenberg as inevitable. WordPress is moving away from the classic approach of content creation, to a more visual, block based experience. He thinks that it’s important to become an expert at building websites and custom solutions for clients, and for taking the time to learn the new tools that this future will require.

He’s not suggesting that the journey towards expertise in React and JavaScript will be easy, but he does see it as essential for those wishing to continue to use WordPress as their CMS of choice. He also makes the point that now is a great time to invest in yourself as there are more resources than ever, which can assist you in this learning path.

As you’ll hear, Fränk is all in on WordPress, and is very optimistic about the future for experienced WordPress developers.

If you’re interested in finding out more, you can find all of the links in the show notes by heading over to WPTavern.com forward slash podcast, and you’ll find the other episodes there as well.

And so, without further delay, I bring you, Fränk Klein.

I am joined on the podcast today by Fränk Klein. Hello Fränk.

[00:03:34] Fränk Klein: Hey there. How you doing?

[00:03:35] Nathan Wrigley: I’m very well, thank you. It’s very nice to have you on the podcast. We typically at the beginning of the podcast orientate the listeners by asking a very basic and simple question just to tell us who you are, what your relationship is with WordPress, how long you’ve been working in the space, possibly the company that you now work for, and all of that goodness. So, Fränk, it’s over to you.

[00:03:54] Fränk Klein: So my name is Fränk Klein. I live in Luxembourg in the heart of Europe, and I got started with WordPress in 2011. So that’s when I started programming. So the background is that I’m actually a print designer, which at that time, wasn’t really that much of a bright career path. So I switched to programming, bought myself a PHP book, and then discover WordPress, and that’s been my passion ever since.

And, I kind of have a varied background because I was in a small agency, still in Luxembourg. Worked for Automattic as part of the wordpress.com theme team. I worked at WordPress VIP, and then now I’m at Human Made, which is an enterprise WordPress agency where I’m a principal engineer. And so as part of that is my passion has been WordPress, but I also have a big interest in the wider web ecosystem, and so that’s why there is my interest in everything block related.

[00:04:51] Nathan Wrigley: Okay, and that’s going to be the basis of our conversation today. So Fränk’s here to talk about Gutenberg in general, but more specifically about full site editing. And I think probably a good way to begin the conversation to, again, provide a bit of orientation, is just to run through the history of the Gutenberg project and now full site editing. So I don’t know if you are willing to do that. Run through the history of when it all began and what the phases are and so on.

[00:05:17] Fränk Klein: Yeah, so, I think when we talk about full site editing, we cannot forget the wider picture, and that is that full site editing is part of the Gutenberg project, which Matt Mullenweg, the WordPress lead started back in 2017. And the idea behind Gutenberg was really that WordPress ran its course in the way that it was at that time, in that there needed to be a ground up reimagining of a lot of the core components that make up WordPress.

So therefore, there are four phases. The first one is content editing. So that was in 2018 when WordPress 5.0 introduced the block editor, or the content editor how I prefer to call it. Then the next step is site customization. Part of it was in 5.8, but most people will know it from 5.9 when full site editing was introduced.

Then the next phase, which they are starting right now is collaborative editing. So Google Doc style editing of different people on the same content. And then there will be multilingual. So that’s the big picture of the Gutenberg project. And so, full site editing is just part of this. And so the thing about these phases is that the content editing phase that was, by now four years ago, but it’s not really finished because the content editing experience still gets upgrades. It gets stuff added to it. And so that’s how this project is laid out. And even if we now roll into the collaboration full site editing isn’t done, and they will continue to work on it for the future.

[00:06:43] Nathan Wrigley: If we were to roll back the clock prior to Gutenberg, so let’s say, 2015 or something like that, and there were people at that point who were using just the classic editor, they were maybe putting just content in or short codes and page builders and so on, came along. What do you think was the point of having all of this in core?

In other words, it could be left to third parties, it could be plugins or it could be themes that took on the job of the way that your site was presented. What is the promise? Deep down, what’s the sort of kernel of Gutenberg? What is it offering? Where are we headed with it?

[00:07:18] Fränk Klein: This is kind of where the, the bigger picture comes in because, when we just talk about full site editing, it’s called the site customization phase. It’s not called page building phase. It’s not called theme building phase. Those are all things that you can do with full site editing. But really the idea behind full site editing is, there was the customizer, right? So that was the way that you interact with your theme, and that didn’t work out. I think the promise that the customizer had in the beginning didn’t pan out to be what people wanted to be. And so then the idea was that we have something better, which is built up on this concept of blocks.

And so the thing that makes full site editing and then, the customizer very different is that, the customizer, the idea was there was this tool and there are only minimal controls available, and if you want to have your own, there are just APIs and a builder. And so the problem was that everybody built their own controls, and then there was other confusion for users, and themes weren’t compatible with each other.

And then the site editor, or just say the Gutenberg project in general takes a very different approach, in that it says, we’re going to give you a lot of customization options, controlling fonts, controlling colors. And beyond those options, this is like the full menu of everything you can do, we give you the APIs to preset these things, to remove them, to customize them. And so the bigger context here is that this is a customers replacement for the moment, but it also allows you to build new templates.

And the idea is that many of the menus that we have in the WordPress admin are going to be rolled into the site editor. So for example, reading, settings, things like that. There are definitely concepts already exploring how that could be part of the site editor. So really, when we talk about even collaborative editing, that’s going to require changes.

Multilingual is going to require changes. That all is just wrote into this Gutenberg project, of which full site editing is one part. The promise is kind of that based on this concept of blocks, we are going to be able to reimagine how people interact with WordPress, both as users and also as developers. And it’s going to be done much more through visual interfaces that are a lot easier to understand and to work with.

And that way really we’re going from the old word of WordPress to the new WordPress, which is then going to be able to be around for a decade or more. So that’s the big picture vision behind the whole project.

[00:09:48] Nathan Wrigley: Yeah, sort of future proofing if you like. Given all of that, let’s just put the conversation about blocks to one side and about what they offer, we can come back to that in a few moments. I want to talk just for a moment about how it is that such a large proportion of the community, and when I say large proportion I don’t really have any figures. Not claiming it’s 10, 20, 50, 70, whatever. Percent, but there’s been a certain amount of people within the WordPress community who have not got such an optimistic approach to full site editing and the Gutenberg project more broadly. In many cases, they don’t really want to have much to do with it.

They’re happy with the tools that they’ve got, and they’re happy with the systems that they’ve got in place, whether that be a page builder or whatever it is. I’m just wondering if you have any thoughts on how the communication went, introducing Gutenberg and full site editing. Do you think that the promise was explained from the beginning? Maybe the promise wasn’t fully realized. Or do you think that there were some PR missteps along the way.

[00:10:49] Fränk Klein: Well, yeah. There’s several parts of it. I think that when Matt introduced it, he wrote this post called we called it Gutenberg for a reason, and that very much painted a broad picture. In my opinion it went a little bit overboard comparing it to the invention of the printing press. It’s just my personal sentiment about it, that’s maybe overdoing it by a lot. But he definitely had this vision where he explained what problems this project was trying to solve.

And that was around for a bit. And then we went right into the details. So the block editor was introduced, all these APIs, and so at that point we just focus very much on the what, and not the why. Why is this there? And instead of just saying, hey, here’s this paragraph block, and it works this way. There never was really a step taken back in where there was an exploration of, here are these tools and these are all the possibilities that you now have with these tools.

And to adapt that to the different profiles that we have in the WordPress space, because we have end users, we have power users, we have theme developers, plugin developers. And kind of this translation from the nitty gritty to the bigger picture and also let’s say the potential that is there, because there definitely is a lot of potential. That was missed, unfortunately, and I think that’s why, if all you just see is a bunch of stuff getting thrown in your face and nobody really explains to you what you’re supposed to do with it, and why they’re adding all it. Then unfortunately that’s, I think the situation where we were in where just a large part of the community didn’t see the point. And so the project is doing a lot more of trying to fix these mistakes. So they are a lot better about showcasing the things that you can do. So I’m very hopeful in that, that we’ll get to those bigger picture conversations.

[00:12:37] Nathan Wrigley: I guess, for me at least, when Gutenberg rolled into Core, it came with some default blocks, which you could use. But they very much were the kind of things that you could have done and could have achieved in all the previous versions of WordPress. So you could put in a paragraph and whilst you could move that paragraph independently, it was still a paragraph. And so not tremendously exciting. And the same with images. You’ve always been able to do something similar to that. I’m just wondering if there was a wow moment that got missed there.

In other words, when that came into Core, right at the beginning, if some bizarre, let’s use that word, some bizarre, extraordinarily clever block could have been shipped, just to give everybody that aha moment. But it didn’t happen that way. We just got a fairly ordinary pallet of blocks to choose from. And so people perhaps got disinterested and never came back. And now we’re in the process of trying to show people what those aha moments are.

And certainly from my point of view, I’ve. Implementation’s left, right and center of really incredibly difficult and complicated things built inside a really small, tiny UI in the block editor, and it is amazing. But I, I do wonder if that moment was missed and it’ll be difficult to ever get that excitement back?

[00:13:52] Fränk Klein: Well, I think there are two parts with it. I think that one might discuss the point at which the block editor was introduced. So for sure, in the beginning it was a bit rough. And so if already having trouble to have the time to find polish, to polish this product, they probably didn’t have the time to build a lot of showcasing tools because they were just trying to get this done to include it into Core.

Okay, this was the situation and it is how it is. They could at least showcase the potential of in, blog posts after the release. But I think the big opportunity that was lost is just to look at the ecosystem and just to go out to agencies, product companies, whatever, that were using blocks and to take the things that these people were building and then to show it.

I think that’s a big missed opportunity. Just a case study. This was the problem and this is the solution that was developed, and this is the reason why it was developed. And these are the outcomes. Right, so talking much more in business language, not really in they used this API and that API, which might change and which is really not interesting.

There was a lot missed on that. I know we have the state of the world and then there is a maybe three second slide for some project which was super impressive. But all it gets is this three seconds in the presentation. Frankly speaking all people don’t even watch. So I think that was a big opportunity which got missed.

[00:15:12] Nathan Wrigley: In your learning about the construction of blocks and all of the different technological pieces that you had to acquire along that road. How difficult has that journey been for you? So, Let’s say, for example, there’s somebody listening to this, and by the end of this they are indeed convinced that this is the way to go. What’s the learning path like? Did you find that to be a fairly difficult experience? Was there a lot to learn that meant that you couldn’t progress until you’d got over several hums? Was it easy, was it hard? What was it like?

[00:15:39] Fränk Klein: Well, I was lucky enough to already know, let’s say modern JavaScript in quotes and React, before I start with blocks. So that’s definitely a big hump to get over if you are coming from a traditional PHP background and you, you know, maybe write jQuery, some of it, but, uh, you don’t really have a lot of JavaScript affinity. That’s actually one big issue.

Just building the blocks was rough when I did it, because it was so early. I think the first project that I did, it was still with the Gutenberg plugin, like it was before 5.0. But I think that at this point it’s a lot easier. It’s just that the documentation has got a lot better. There are tons of material for people to learn this. But over time my thinking has shifted on that, because if you would know how to build a block, like technically speaking, that’s good, but this is really just the base level. The challenge really is to, how do I design all the experiences for my users, my end users, so that they fit into this paradigm.

So you can have a custom blocks that works, that’s entirely PHP rendered. You might have JavaScript run in the editor. You might add a plugin to the editor. You might have a custom control. You might have customizations of core blocks. And that’s really knowing all of these tools that are available and when to use them, how to use them. That’s really the difficult part.

That being said, I think that, for me it’s always, even when it’s difficult, I kind of have the opinion of this is why I get paid. I get paid to solve the hard issues. And so if there is a hump to get over, I am, I’m ready to do it. But I think just in the wider picture, you need to just start doing it, and just keep doing it, even if it’s frustrating, because that’s just how it is with anything. If you try and learn the guitar, I’m going to tell you it’s not going to be easy. But you just need to keep with it. And then over time this will just become second nature.

Because that’s also the question, you know, it’s the chicken and egg problem somewhat, is well, how do I become a JavaScript developer? Well you write a lot of JavaScript. You know, honestly, that’s how easy it is. It’s just like doing pushups. You wanna be good at doing pushups, you need to do a lot of pushups. That’s pretty much the solution. And once you accept that there is no magic solution that will just come down and allow you to continue to write PHP, and take advantage of all of these new opportunities. That doesn’t exist.

I know a few projects out there say that you can write PHP and you will have will all of the capabilities to build blocks, but that’s definitely not the case. So it’s just a matter of taking the decision to learn it and then sticking with it. But I have a actually a tutoring program for building blocks. All it takes is six weeks, but it’s going to be intense, six weeks. But after that you know the basics. Then we can move on to the more important things, which are the experiences that you should build for your end users.

[00:18:27] Nathan Wrigley: I will definitely link in the show notes to your WPdevelopment.courses website, where you can go and check out what Fränk’s got on offer there and, the six week program. I think there’s a couple different things on the website, but we’ll definitely link to that. But do you feel sanguine now that there’s more information out there that, it is now possible? And in the day when you were doing it, it was probably more of a slog than it is now. Where do you turn to when you’ve got problems? Is it colleagues? Do you turn to friends, relations? Who are you looking towards when you are trying to solve the problems in your own work?

[00:19:00] Fränk Klein: Colleagues, so I’m very lucky to have a lot of colleagues that are a lot better than I am in different things. And that’s really the magic of being in a larger company. I know that if I struggle with this piece, I go to this person. If I struggle with that thing, I go to this other person.

So I’m very lucky with that. That being said a lot of the problems that I encounter very much also React or JavaScript problems, so there’s always the wider ecosystem for that. I do think though that even if you are alone and all you have is just the official documentation, it is entirely possible to learn this. And I’m very upfront with, when I have a program or a course, I’m just selling you a time saver. I’m saving you time and frustration, but you definitely could do it with just the default stuff that is out there.

And I think that the WordPress learn website, they’re adding more and more stuff to it. Of course, it’s not as polished as something which is really starting to end a learning path. That’s just the downside of this being free documentation. But it is definitely possible to learn. And especially when we talk about just the people that want to get maybe deeper into JavaScript and React. There’s a ton of courses out there where people teach you that stuff, which are great and not very expensive.

So I think the difference between, when we got started, 5.0 and now, it’s night and day. It’s not even comparable how much easier it is to learn blocks right now. And, we mustn’t forget that. I see it every day, inside of Human Made and also in community. There are people learning it from all kinds of backgrounds.

Even people that would say that they aren’t really developers. So it’s not like there is some secret source or something that you need to be born with to learn. This is very achievable. But again, you need to put in the work and the time to achieve it.

[00:20:41] Nathan Wrigley: Yeah, achievable, but there will be some element of struggle along the way. But it’s nice to know that there are options out there. And you mentioned Learn, and like I said, we’ll link to the bits and pieces that you provide as well. You are clearly very into all of this. This is something that you’ve staked your future on, I guess to some extent. You’ve learned all of these skills and how do you feel about the broader picture for people in the future?

So agencies, freelancers, and what have you, who have yet to embark on this journey and are still doing things in the way that they have been doing. Do you see that the future for them is going to be more difficult in the work that you do? Do you see that the potential is paying off? Are clients coming to you and you are able to build things more quickly, potentially have a user interface which they like more, and so on? I just wondered what your thoughts were about the future for freelancers, agencies, and and so on.

[00:21:33] Fränk Klein: I think that when we talk about the work that I do, we have the chance to work with bigger budgets, so that gives us a lot more, let’s say free space to build out certain things. But, the thing inside Human Made is that Human Made hasn’t built a website without blocks ever since the block editor got introduced.

That was just the default, because we saw the problems that this was solving. Because the classic editor, for our clients, even the clients in the publishing industry, like it didn’t work. We were having solutions to deal with certain issues, the workarounds that we all knew, but these were just not up to the task. And so when we saw the block editor, not only what was there in terms of the starting blocks, which is paragraph and image, which wasn’t very exciting, but the whole framework surrounding it to build a custom blocks we said, okay, these and these, and these are going to be the problems that we can solve with this.

And it’s going to take us a lot less time. It’s going to be more efficient because we can reuse certain things a lot easier. And also it’s going to be a lot better experience for the end users. And the thing that we need to understand is that, as I alluded to in the beginning, full site editing is just one part of the bigger picture.

So you can say, maybe I don’t want to use this part of full site editing, or I don’t want to use that part. And that is fine because we are in a transitionary phase, where we are transitioning really from a very classic theme development approach to this new paradigm of building themes. But if it just flat out say, I don’t want to use blocks at all, never ever, then probably, at least as I see it, then you’re going to need to stop using WebPress at one point or another. Which is fine because I think a lot of the careers in WordPress are incidental in that people just found WordPress and then they started using it, but there was, for most, not a point where they said, this is really WordPress and this is why I use it.

And so WordPress is just a tool, if at a certain point a tool doesn’t work for you, then choose something else. I think that’s just something where you need to be honest with yourself. The other part is that when we think about what an agency is, if you choose WordPress because you say this is the best solution for us, then you need to be all in with it.

You can’t really say, I’m going to choose WordPress, but not these and these parts of WordPress, which I don’t like, which are just key to experience. And how content is edited and how themes are built, that’s a very key part of the CMS. So you can’t just ignore those. But the difficulty is, what I alluded to before, is that you need to really understand how a block theme works, how the site editor works, how I guess the end goal works.

And then once you have understood what that experience is, then you can come back and say, well at this point, for this project, I don’t want to have full on block templates. I’m going to use more hybrid approach where maybe the users can change this part or that part to the editor. And that’s all fine because you are making a very conscious decision of choosing features that fit best with that specific project.

But you know what the possibilities are, and you know what to pick next, once you get over that initial phase where we just build partial websites. For example, landing pages are something which you can already build now with blocks and you could for a while. Now it’s just a lot easier to do. So it really depends a lot on your specific use case.

And for that, if your work is building websites with WordPress, you need to have the experience of making the right choices. So if you’re just pushing the point at which you do the switch in the future and into the future, into the future, there’s going to be a time at which somebody comes in an agency that says, well we have been building with this since 2018, and you only started in 2024 for some reason.

That’s a lot of time and a lot of experience that you’re missing out on. So it’s just like with building blocks. You have to jump into the pool, and wobble around with your legs and arms and try to swim. And you will see, it gets easier and easier. But, I think what we need to just understand that, WordPress has been the same for so long, and we think that’s normal, but it’s definitely not. Because the wider web development space has changed so dramatically just in the last five years.

And so we cannot expect to keep the same solutions that we’ve built always with meta boxes and what have you, and then expect this to be a solution which is competitive in two years, in five years. It’s not going to be the case. The world is moving on whether we want it or not, and we just need to get onto the train if we want to be a part of that.

[00:26:03] Nathan Wrigley: Couple of questions from that. The first one is you mentioned that there’s a competitive edge to be had here. I’m just wondering if you can give us some sort of insight into that. I realize you can’t talk about particular clients or anything like that, but what do you feel the advantage is that you can offer to clients? Are there conversations that you can have where the full site editing picture, the Gutenberg picture, the blocks picture, you can explain that promise to the clients, and you believe that they are persuaded by that?

[00:26:31] Fränk Klein: Well, I think that there are a couple of things. You need to start somewhere. I started early when it was still in the plugin and my colleagues at Human Made weren’t far behind. And so the thing is always that when the first project, we kind of had to convince the client, but not really, because we showed them the editor and it was like miles better what they had.

They say, Oh yeah, you know, we definitely like this with visual previews, because I mean it wasn’t even up to the classic editor, what they had before. So that was an easy win to be honest. And maybe that was luck, but. Then when the next client comes around and they ask what’s with this new editor thing? And we’re like, oh yeah, we did this project for this client and these are the custom blocks that we built, these are the problems which we solved. That’s an easier conversation because it doesn’t feel super outlandish to them anymore because, well this client did it, then, it seems a good solution, then why shouldn’t we do it?

And so you need to build up that repertoire of just social proof to be honest. And so when a new client comes around and we having these sales talk, and they are explaining a problem to you. I can always say, we had this client, they had this problem, we built this solution. And so, when you just not only explain it to them, also show it to them, which we like, you know, we like to demo stuff. Then they definitely see it.

And we are not even talking about this is a block and this is an extension of this default control because the client doesn’t care. They don’t know what is in Core and what isn’t. If it’s custom not. If it takes you an hour to do all week, you know, in a sense, they don’t care. They just want to have a solution that fits their needs. That’s just the competitive advantage of really knowing this thing very well. Which is why I said, if you don’t understand what full site editing is trying to do, you cannot really apply pieces of it.

The other part is of course, that maybe you are reluctant to learn JavaScript and React, but honestly it’s a very good thing to know, because if you ever were to get out of WordPress, a JavaScript developer, React developer, tons of jobs available. That’s also for me, when I look at my personal career, I always need to prepare for the case when WordPress might disappear overnight, for whatever freakish reasons. Then I’ll be fine. I just go and do a JavaScript, which I also enjoy. But I think that’s something which maybe a lot of people are missing it or they don’t want to think about it that much.

But the run of the mill WordPress developer with just a non WordPress development skills, is quite far behind the larger web development ecosystem. And that is fine if you say well, I’m not really a developer, just, maybe I’m a marketer, salesperson and I just build websites because I need one. But that’s not really what my core skill is.

If you say well, I’m a developer and I build custom solutions for my clients, that’s really, my core skill is what I sell to my clients, and you are not able to work with what has been in WordPress for by now four years, custom blocks and this whole system that has been introduced. That’s not a great situation to be in.

So unless you want to be tied to a specific page builder, theme, and you want your stake, your fortune to the fortune of that company, then this is something which you just have to get with because, it’s very important for your own career and it’s very important for your own business. If you want to stay around for the next couple of years, this is not something that you should be sleeping on.

[00:29:39] Nathan Wrigley: Yeah, it’s interesting. I feel that there’s probably quite a lot of people who are fearful of some of the things that you mentioned. Learning React and learning JavaScript deeply, and they’re struggling just to use the time that they’ve got to output the work that they need to output to make ends meet. And so all of this extra, that they’ve suddenly got to learn becomes a little bit daunting. But it’s nice to hear that you feel at least that there’s opportunities there and perhaps in your imagination at least anyway, the window of opportunity is bigger, looking forwards with full site editing. And it’s closing with the old way that things have been done with PHP and themes and all of that kind of stuff. So that’s interesting.

You kept saying the word custom solutions which I found curious. I’m guessing that on the enterprise level, the kind of clients that you are dealing with, that is the kind of work that you are involved with. You know, they come to you with websites which have a heavy burden of, it needs to be very custom. It’s got to be exactly what we want. The budget can accommodate that, and so you can really spend time drilling down. And so your knowledge of what’s possible with blocks and so on and so forth can really assist them.

You know, you might have a block for some very specific task within the broader website, that you can build and there’s time and what have you for all of that. Whereas, I would imagine quite a lot of people listening to this, they really aren’t going to be doing that. It’s just a simple website. It’s a brochure website, four or five pages and that’s kind of it. And maybe they feel that they still don’t need it. But, anyway the custom solution piece I think is interesting. Can you talk to us about that?

[00:31:09] Fränk Klein: Ah, yeah, sure. I just wanna take the opportunity to circle back a bit to finding the time. And this comes from Brian Gardner, so thank you, Brian. He said there’s is five for the future, which WordPress says you should invest this time into the project so that it can sustain itself. And he proposes these five for your future, which just means well take 5% of your time and invest it into learning because that’s going to make it possible for you to have a sustainable future.

So I think that’s a very important concept. Cause I definitely do understand the need to make money and stay up to date on all of these things, and it’s not different when you are in an enterprise agency as when you are in a small agency. I mean, the struggle is always the same. I mean, everybody needs to make money, and the way to make money is to produce work for your clients.

But I think just if you are aware of the fact that you need to stay up to date, and you make it a priority. It’s the same as with any other thing in your business. It’s like accounting, everybody needs accounting and you can just not do it. And at some, you’re going to be screwed or you say, yes, I need to do my accounting and I need to take the time it takes to do it right.

I mean, everybody needs time to write their invoices. And so people make time for that. And if you make this the same level of urgency and importance as writing invoice so you get paid, then learning is just going to be a natural part of that.

There’s a piece of learning where you just need to get the basics, but then there’s a lot of learning on the job where you run into an issue and you figure it out and then you work some more, you run into another issue. So a lot of learning that you’re going to do is pretty much on the job. So that’s how it was for me. And to come back to the question of custom solutions. In general, when we talk about a website project where they cost $5,000 or $500,000, the challenge is always the same. There are certain pieces in the website that you need to have, so there needs to be navigation, there needs to be a list of content, posts. All these things are there, and it’s the same whether it’s small budget or big budget.

The challenge is what do you focus your energy on in that budget? And so that’s a conversation which we have with our clients where, for example, it’s a stupid thing, but we get the mock up, right? And there is this pagination on the bottom. And this pagination kind of looks tricky. I would say, look, that pagination, if we build it that way, it’s going to take us like a day to build it.

And honestly, nobody cares what your pagination look like. We can switch it out with just the full pagination. We got all the functionality. It doesn’t look the same, but who cares about the pagination? And most clients, if we don’t say it that way, if they say little bit more nicely, most clients will be like, yeah, okay, understand, the pagination. because for them, they didn’t even see the pagination, right? It just slipped their mind. And so there’s this negotiation where you need to take all of the pieces which you can simplify and use something which is pre-done, that you do this way. And then you really have the time to focus on the pieces that are important to your client.

Because I always talk the language of money. What makes you money? How do you make money? How can we help you make money? And that is the point where you’re going to invest a lot of your energy, and that is where the custom solutions come in. So we had a client that problem was that. They had a CMS, and it took their editors 25 minutes to just enter the content into the CMS because it was so complicated. They need to manually resize images, all of that. So we just took WordPress. We did some custom work, not a lot to be honest, just for that specific piece. And we brought it down to five minutes. At top, takes them five minutes to get an article entered into the system, published on the website, has all of the metadata for social media and everything like that.

And that’s a case where you can present to a client how you make them a lot of money by saving them time, because they still have the same editors, but the output is a lot bigger. The important thing is to not be tied to things that you think should be custom, because let’s say a menu, a main navigation. Do you need a custom menu with all this and that, or can it just be dropdowns? Normal dropdowns. It’s a question. Maybe the answer is no, because you have, I don’t know, an e-commerce website and you need to have a more complicated menu. Or the answer is just yes. Just a menu, as we all know, is going to be fine.

And so that’s really the struggle that you find the things that you can standardize and WordPress is going to help you with that. Because a lot of the things that we needed custom solutions before now are standardized, or at least the way that you build it is standardized. So custom blocks are really difficult to build.

You know, a bunch of stuff is already there. A lot of components are there. And the challenge is that when we talk about the smaller budgets, the $5,000 project’s not going to go away, what you need to deliver for that amount, that’s going to go up. And so here, when we talk about full site editing, since a lot of the pieces already predone for you, you can assemble these pieces, you can customize them, and that will allow you to build a solution which corresponds to the needs of your clients. And it doesn’t take you a lot of time to do it.

So that’s the big idea behind is that, previously WordPress was very much, I give you these APIs, but there wasn’t really much in there. So now it’s completely different way. There’s a ton of stuff in there, but you need to really curate the experience that fits for your client and then you add the stuff that is not by default in there onto that. If it’s a plugin that you can use, great. We use tons of plugins at Human Made that just do things that we always do. And if it’s really a custom piece, then that’s where you write the custom code. And so through combinations of these factors, you’re going to be able to achieve the results for your clients.

[00:36:42] Nathan Wrigley: Yeah, I do like the piece that you mentioned there about having the client suddenly realized, that must have been a real aha moment. Something previously took 25 minutes. So if you did that twice, you’re approaching an hour to do, whatever that task was twice. And with the custom solution that you built, perhaps that was a block with the fields arranged differently, I don’t know. But the principle that could enter the same amount of data, you could do that twice in 10 minutes, you really have sold it I think at that point.

Nobody’s going to deny that’s a better experience. And if it can, in the background, be doing things like creating the images and creating all of the metadata that goes with those images for the different social networks and so on and so forth. All of that stuff can be built inside of this custom solution. Yeah that’s fabulous. Like you said, the budget may not allow for it, in which case there’s still going to be a, the $5,000 website.

I do think you are right as well that the expectation for what that $5,000 will buy you is only going to go up. It’s going to continue to be, $5,000 this year will get you this amount of functionality. And now that people are building with custom blocks and what have you, I imagine customers are going to be able to determine for themselves that, well, actually, no, for my $5,000 I’m expecting there to be a lot more on the back end that I can play with and for it to be customized just for my use case exactly.

[00:37:56] Fränk Klein: Right, and I think that, when we think about a traditional website project, there’s this waterfall model where development is at the very end. And if you approach it this way, you’re kind of ready, all of these decisions have been pre-made for you because, there is this custom pagination, I don’t know, but pagination is one of my pet peeves, so there’s this super expensive pagination, this weird menu, like stuff is all over the place. But those are the mockups that the client said, we’re going to build this, and now you are having to deal with the task of, okay, how I’m going to build this, in this amount of time? And then we just are at the same starting point where everybody else is, like, we have a website that pretty much looks like all other websites, because usually, unless the design is very expensive, it’s pretty much going to look like a lot of other stuff, obviously.

And so If you think of yourself as an engineer, you know, maybe that’s your title, but that’s not really what you are. You need to come in very early in the process and then already talk to the client in the very beginning, in the discovery phase, and find out what the pain points are and then try and make a note of these and also come out with a few possible solutions that you might deploy to do this.

And then you go in and you need to collaborate with the graphic designers. I need to collaborate with the client on how you put this website together. So since we now have a framework, which is WordPress, where we have all of those pieces to build a website. We need to be involved a lot earlier and also explain to designers what these pieces are. How far it can be customized and all of this. Because the approach as we did, by now maybe 15 years ago, where really we sold websites by the . Page and it was this mockup and that mockup, and that was how websites were sold, right, by the page. You paid this much per page. That is just gone. Now we need to build up these small pieces and we assemble them into bigger pieces and bigger pieces, and that’s how we build out the whole website from the small components.

That is both the case in terms of the design. So we start with the button, which is done part of a larger pattern, which is then part of the whole page design, or a call out box, whatever. You build up the design out this way, but it’s also the functionality. And a lot of the functionality that you build out, you’re going to have to deal with the data.

How do I model the data? How is it stored in the database? How does it get accessed? How do I store it in way that is all performant? And so, you as an engineer, you kind of need to talk the language, both of the client and the designers. And still know all of the background of what you need to do when it comes time to write code.

Cause let’s not kid ourselves, at a certain moment, you’re going to need to open that editor and start writing out code. Even when you’re dealing with, you know, full site editing. Then at that point you have everything lined up in the way that you can deliver the results that the client wants, within the time, and then also the budget that they have.

So that’s really the big challenge, and it’s going to require us to step away from a lot of that old waterfall thinking because, really when you have projects that I tend to do tend to be quite long. You know, sometimes three months, six months, a year. So if you have a project that runs a year, you’re not going to come in with a list of all the stuff that you’re going to do in a year.

So it’s a constant, discovery, negotiation, building stuff. But at each point you are building something which already has value. And so if at the end of the project the budget runs out, and maybe we missed a few nice to haves, the client’s not going to, they’re not going to care, because they’ve got everything which they wanted and which is producing the results for them.

So that’s really the idea that we need to take forward. And to be honest, I don’t have all the answers on that. It’s just, I think that a more iterative approach where you build out pieces one by one in order of priority, and we have something which is working, which is going to produce results at any point. That’s the way that we’re going to do it, and it’s a lot easier to do that, just assemble pieces and then you add your little custom stuff to it. If you just start everything from scratch and it already takes you three days to come up with, you know, the basic site layout, I think that’s just outdated.

[00:41:58] Nathan Wrigley: Interesting. So it almost feels like you are using bricks to build a wall. You might substitute the word bricks for blocks, which is a nice metaphor. Just before we end, it sounds like you’ve decided that this is the way that you’re going to do things in the future. You’re fully into this. The promise with new technology is always, we’re going to make your life easier. I do wonder, and maybe you can speak to this, have you simply swapped a bunch of problems that you used to have, for a new set of problems that you now have? So whilst in the past you were wrangling with different things, templates and themes and so on and so forth, you’re now just wrangling with a different set of problems.

What I’m trying to say is, is your job easier now, harder, or just the same?

[00:42:42] Fränk Klein: It’s the same, but it’s not. I think that we shouldn’t be, how can I say that, we shouldn’t look back on the past and, oh, imagine when we didn’t have to do this and didn’t do that and paint the pretty picture of how it was. Because the past, it wasn’t great. I’ve been in web development for a while now, and there never was this super bliss that somehow got destroyed with everything that is here.

But the thing is that it’s been the same. But for me, the way I look at it, it’s that you are always going to have problems, but I want to have bigger problems and better problems. So there’s a myth that, oh, a thousand dollar client is going to bicker and then a $10,000 client just going to wire the money.

And I don’t know where these people come from, but that’s definitely not the case. All clients are difficult at all price ranges. That’s just how it is. You’re trying to build this thing together. And there’s going to be a few confrontations, and that’s just normal. But the thing is more is that, how can I say that? If I have to write one more stupid post list, I’m just going to be out of this. Who wants to go into an editor and be like, oh, this is going to be a list, and then I will get the title. I have zero interest in that, doesn’t interest me at all. It’s just I don’t want to do the same thing over and over.

If I can abstract that away, great. And that’s really the idea behind is that I want to go to the things, just in terms of my career, I want to get closer to where I can produce outcomes for the client and rewriting a list of posts, how much of an outcome are you producing? I’m not really sure.

And so everything that I take, all of these tools is just, I want to deal with bigger problems, better problems, and that way I’m going to be able to make more money, frankly speaking. And so if you just get bogged down into this small, kind of, small thinking where we need to say, oh, I need to write everything from scratch. No you don’t. there are huge parts of projects that I didn’t write myself, but I know which solutions are out there. And so, I don’t come up with an SEO framework. I use a plugin for that. I don’t come up with a bunch of things. But because I have solved all these problems, I can then have better problems.

That’s the idea that I want to take. I want to get to the really hard stuff and yeah, definitely full site editing helps with all of that. It abstracts away a lot of the theming stuff that’s very repetitive. Blocks are a lot more portable. Even if we do write custom code, there’s a way to make it more abstract so that we can pull in libraries and things like that.

So that way you are kind of building up, project by project and not only building up experience, but you’re also building up your toolbox so that when you come to a problem, you’ll reach in to the toolbox, you pull it out, you can solve the issue, and then you’re onto the next one. Which hopefully is going to be more interesting than how does the pagination look.

[00:45:20] Nathan Wrigley: Nice answer. Fränk, I’m afraid we’re probably just going to have to knock it on the head because of the time. But just before we do, just before we call a close to the podcast episode. I’m wondering if people have listened to this and have been inspired and would like to get in touch with you, what other best ways or way to do that?

[00:45:36] Fränk Klein: First, it is my website, so WP Development Courses. So check that out. Feel free to email me like there’s a contact tab. I like to hear from people. I don’t have all the answers for sure, and I like to hear from people and understand all the different backgrounds.

And then I’m on the WordPress.org Slack. If you wanna DM me. And of course you can find me on Twitter. So if you have a question, if you have a problem, if you have a viewpoint, if you disagree, let me hear it. I’m very interested in hearing all of your perspectives and your struggles.

[00:46:04] Nathan Wrigley: Fränk Klein, thank you very much for chatting to us on the podcast today. I really appreciate it.

[00:46:09] Fränk Klein: Thank you. It was a pleasure.

On the podcast today we have Fränk Klein.

Fränk is a self-taught developer. He started out learning PHP in 2011 and from there found his way to WordPress. Over the years he’s worked for Automattic at WordPress.com and WordPress VIP, and is now a principal developer at Human Made, an enterprise WordPress agency.

Today on the podcast we talk about how Fränk decided early on that he was going to start developing with blocks and, more recently, with the full site editing capabilities now built into WordPress Core.

We talk about the four phases of the Gutenberg project: content editing, site customisation, collaborative editing and multilingual, and where full site editing fits into this.

Fränk explains how he sees the adoption of Gutenberg as inevitable. WordPress is moving away from the classic approach of content creation to a more visual, block-based experience. He thinks that it’s important to become an expert at building websites and custom solutions for clients, and for taking the time to learn the new tools that this future will require.

He’s not suggesting that the journey towards expertise in React and JavaScript will be easy, but he sees it as essential for those wishing to continue to use WordPress as their CMS of choice.

He also makes the point that now is a great time to invest in yourself as there are more resources than ever which can assist you in this learning path.

As you’ll hear, Fränk is all-in on WordPress and is very optimistic about the future for experienced WordPress developers.

Useful links.

Fränk’s WP Development Courses

7 Full Site Editing WordPress Themes for 2022

WordPress has undergone quite a few changes as of late. In the past few years alone, there have been major updates to WordPress core, changing how people interact with the CMS in major ways. The biggest innovation is the addition of full site editing to WordPress. We’ve already gotten acquainted with Gutenberg and how the Block Editor has transformed the way blog posts and pages are created. But now, the aim is to adjust how we customize entire websites from within WordPress as well.

And while this might sound a bit scary at first, rest assured, there are still plenty of WordPress themes created every day that incorporate this new feature and make it easier than ever to design and customize websites in WordPress.

That’s precisely what our focus will be here today. Let’s take a look at 7 full site enabled WordPress themes that make full site editing accessible and familiar.

Your Designer Toolbox Unlimited Downloads: 500,000+ Web Templates, Icon Sets, Themes & Design Assets

Twenty Twenty-Two

Twenty Twenty-Two Full Site Editing Theme

The TwentyTwenty-Two WordPress theme was created with the belief that everyone deserves a website that is truly one-of-a-kind. The theme’s understated styles take inspiration from birds, which are themselves known for their diversity and versatility. The typography in the theme is light yet strong, the color palette is inspired by nature, and the layout elements are designed to sit gently on the page.

Twenty-Two is meant to be easily customizable, taking advantage of WordPress 5.9 Full Site Editing capabilities. This means that the colors, typefaces, and site layout of each individual page on your site can all be altered to match your preferences. It also includes several block patterns for you to use in creating professionally designed layouts with just a few clicks.

Catch FSE

Catch FSE

Catch FSE is a responsive, minimal WordPress theme with a dark or light color scheme. It’s been created using Twenty Twenty-Two and is ideal for blogs and corporate sites, alike. You can select your site color style in WordPress 6.0’s Global Styles feature and start creating your content with the easy drag-and-drop interface by utilizing block patterns.

It’s free and easy to use, with a clean, modern aesthetic. It allows you to create a distinctive site by providing 15 distinct block patterns, 15 FSE Templates, and 9 Template Parts so you can build your own website the way you want it.

Bricksy

Bricksy Full Site Editing WordPress Theme

Bricksy is perfect for those who want to build their own modern website without having to code or design from scratch. With an easy drag-and-drop interface, you can use the premade block patterns to create beautiful pages in minutes.

The theme takes full advantage of WordPress’ Full Site Editing features, making it easier than ever to create a professional site that looks great and functions as you want – no compromises required.

Allele

Allele Full Site Editing WordPress Theme

Allele is a WordPress theme that comes with pre-defined block patterns and full-page templates. It has a modern, clean design and provides full site editing support. This theme is perfect for creating professional websites that need to be edited often.

Other features of this theme include support for multiple languages and RTL, it’s accessibility-ready, it’s SEO friendly, and it’s lightweight, too.

Avant-Garde

Avant-Garde Full Site Editing WordPress Theme

Avant-Garde is a simple, experimental block theme for WordPress. It features an easy-to-use interface and a minimal design, perfect for those who want a streamlined blog or website.

The theme is fully responsive and retina-ready, ensuring that your content looks great on any device. Avant-Garde is also translation-ready and supports the WPML plugin, making it easy to create a multilingual website.

The simple design here would lend itself well to a wide variety of content types and topics. And, if you’re wanting to experiment with a new design direction for your website, Avant-Garde could be the perfect theme to help you do just that.

Frost

Frost

The Frost WordPress theme is a well-designed and feature-rich theme that can be used for a variety of website types. The theme includes a hero section with an image and text, as well as a portfolio section to showcase your work. The theme also includes calls-to-action, testimonials, and more.

This versatile, mobile-optimized WordPress theme makes it easy for designers, developers, and creators to build a sophisticated website in minutes. With a user-friendly interface and a wide range of features, Frost is perfect for anyone who wants to create a powerful online presence.

Wabi

Wabi

Wabi is a WordPress block theme created to assist you in telling your story in the most effective way possible. The clean lines, beautiful typefaces, and dynamic accent color system used to aid with your storytelling. This is all further emphasized through the use of simple curves and lovely letterforms. Wabi comes with three different style variants (light, dark, and dynamics) for maximum expressiveness and flexibility.

Which Full Site Editing WordPress Theme Will Serve Your Next Project?

These are only a few of the hundreds of Full Site Editing WordPress themes available. But hopefully, this gives you a starting point for finding the perfect one for your next project. Good luck!

WordPress Contributors Consider Renaming Full-Site Editing

WordPress Executive Directory Josepha Haden Chomphosy is proposing contributors rename the terms “full-site editing” and “full-site editor” to something more user friendly. The terms came into use as WordPress moved into the Customization phase and are still used to differentiate the work being done on site editing as opposed to content editing in the block editor.

Haden Chomphosy has identified two issues with using the term “full-site editing:”

  • It was already possible to edit every part of a WordPress site using code. The term “full site editing” differentiated between phases of a project, rather than a new capability in the CMS.
  • To us, “full site editing” implies the use of blocks, but for new users there’s no reason for them to expect anything else. The term isn’t descriptive of what makes it unique.

Contributors who work in WordPress every day may not be fully aware of how specialized some of these terms are and how little they mean to a newcomer. Haden Chomphosy proposes WordPress adopt a new term that is “immediately meaningful for new users of our software, while also being an easy to reference term for all of us building and supporting the software.”

She opened a conversation today on updating our shared lexicon to use a new term for this aspect of editing and asked for feedback on additional contexts that need to be considered.

Ideas are already pouring in as it’s much easier to name something than to build it. “Site Editor” has been one of the must popular suggestions so far, but participants in the discussion have also suggested “Template Editor” and “Theme Builder,” as well as “Builder” and “Site Builder.”

“Future view, looking back from collaborative editing, what I would want to tell a user: The Editor,” Rob Glidden said. “In the WordPress editor you and your team can edit posts, pages and themes in the same, consistent user interface.”

WP Engine developer advocate Nick Diego suggested it’s too late to unring the bell on full-site editing and that WordPress should stick with the term.

“Many still refer to the Editor as Gutenberg,” Diego said. “I would be hesitant to introduce a new name when ‘Full Site Editing,’ now that it has been so publicly talked about, will likely live on for years and years to come.

“I kind of like the term ‘Full Site Editing.’ For new users in WordPress, it implies that they will be able to edit their entire site, which is true. Of course, there are many Classic themes and page builders that also allow you to do the same thing, but a theme that supports FSE differentiates it from traditional Classic themes.”

The discussion was just opened today and the community is invited to participate with comments on the post. Those who have knowledge of what users, clients, and people outside of WordPress call the editor in the context of full-site editing should also weigh in to help contributors get a better picture.

Axton: A Free Block-based Portfolio Theme with Full-Site Editing Support

Axton is a beautiful new addition to the WordPress Themes Directory from the team at Catch Themes. Those who have been waiting for more full-site editing-enabled themes that go beyond a simple blogging layout should have a look at Axton, as it is suitable for a portfolio, photography showcase, or even a business website.

The theme boasts more than 15 block patterns, 17 full-site editing (FSE) templates, and nine template parts. Users can showcase their work with Header media, Hero Content, and Featured Content patterns anywhere on the site.

Axton full-site editing theme

The entirety of the theme’s demo site is available in pieces as patterns, so users can drag and drop and mix and match them to suit their needs. Even the style guide can be placed in the content via a pattern. Axton’s header is also available as the “Header with Search Bar” pattern that places the blocks in a pre-designed arrangement that is perfectly responsive on different device sizes.

After activating the theme, the Customize button launches the Site Editor with a homepage that nearly matches the demo so that users don’t have to start from a blank slate.

Some layout options that users might previously have implemented via a page template prior to FSE, are now available as customizable patterns. For example, Axton offers “Blog Sidebar on Left” and “Blog Sidebar on Right” patterns that can be placed within a template and users can easily manipulate the alignments, background color, typography, and more

The “Contact Us” pattern works with the Contact Form 7 plugin. Users are prompted to install it after placing the pattern.

Axton includes 17 full-site editing templates and nine template parts that enable users to quickly make changes to the layouts of the front page, single posts, the blog page, search results, and more. It also includes a Blank template for a clean slate when creating completely custom pages.

Overall, Axton is a beautifully designed theme that gives users a strong starting point for launching a portfolio or business website with more flexibility and template options than most sites will ever need. Catch Themes also has a Pro plugin that includes custom blocks for a Case Study, Popup Video, Tabs, Masonry, Header Search, and a Skills Bar, along with advanced patterns like pricing tables, logo display, and testimonials.

Check out the documentation on the Catch Themes website for a tour of how to use the theme’s features. Axton is available for free from the WordPress Themes Directory. Its release brings the directory’s count of block themes to 94.

New Video Explores Site Building Progress From WordPress 5.0 to 6.0

Do you remember what it was like to use WordPress 5.0? Three years and ten major releases have radically changed the site building experience, but it’s not always easy to see recognize when focused on some of the smaller, iterative changes that slowly add up. Anne McCarthy, WordPress product liaison at Automattic and co-release coordinator for 6.0, has created a short 13-minute video that shows the immense amount of progress contributors have made on site building features.

McCarthy takes viewers back in time to WordPress 5.0, released in December 2018, which introduced the block editor and the Twenty Nineteen default theme through the work of 400+ contributors. She demonstrates using the Customizer with the default theme. These were simpler days and it’s clear now how limited the Customizer was for implementing the most basic changes.

The video contrasts that experience with the upcoming 6.0 release, which features the work of 500+ contributors on features that didn’t exist three years ago.

McCarthy quickly demonstrates the 6.0 site editing experience, swapping out template parts, and showcasing the breadth of the customization available for images, colors, typography, controlling the posts that are displayed, style variations, and the impressive array of design tools available.

Ten major versions later, nearly every aspect of a WordPress site is customizable through the site editor. For those who have not yet made the leap into full-site editing – it’s essentially like the old Customizer but with super powers, better instant previews, and the interface is a panel on the right. At this point, I don’t think the usability is at a level where someone can just get in there and immediately know what they are doing. It takes a little bit of exploring, but it’s moving in the right direction.

Videos like this one show what is possible and just how far WordPress has come since it first introduced the block editor. It also indirectly answers Joost de Valk’s recent claims that the full-site editing project not being done yet is partially to blame for WordPress’ recent decline in market share.

While WordPress remains the uncontested market leader among CMS’s, some say this small percentage of a decline is inconsequential. Matt Mullenweg has stated in previous interviews that he views market share stats as a “trailing indicator” in the quest to create the best possible experience for users and developers. A growing market share, in that sense, is a signal of user satisfaction.

WordPress jumped into the block paradigm at the right time, just as many other apps began adopting the concept of composable blocks for creating content and designs. Full-site editing is the extension of that vision but it takes time to make it something polished and delightful to use. McCarthy’s video is a good reminder of the limitations that users previously labored under while trying to edit their sites, and the “why” behind all the effort going into FSE.

“As someone who’s currently on the WordPress 6.0 Release Team, I can attest that the project needs more contributors,” WordPress contributor Nick Diego said in response to the recent market share discussion. “The fact that FSE has taken so long is not a lack of effort. There are many contributors pouring their hearts and souls into the project. We just need more help.”

Does WordPress Need 1,000s of Block Themes in the Era of Full Site Editing?

“I have so many design ideas in my head that I am about to make it my mission to singlehandedly fulfill [Matt Mullenweg’s] vision of 5,000 Full Site Editing #WordPress themes in the directory,” tweeted Brian Gardner earlier today.

Daniel Schutzsmith responded:

I’m just not seeing the need for more than one theme for FSE as long as I can override the look of it.

Would appreciate someone explaining why one theme like @frostwp COULDN’T just be the standard.

Making more themes feels like it defeats the concept of FSE altogether.

It is not the first time someone asked whether more than one block theme is necessary. In 2019, Rich Tabor proposed adding a base theme to WordPress itself, one upon which others would be built, if at all.

Even that was not the first time someone had pondered similar one-theme utopias throughout the platform’s history. Many framework-style parent themes have all made a run for it.

Let us assume for a moment that WordPress has reached a state where all themes no longer need custom PHP and CSS code. We are nowhere near that point yet, but we can imagine such a day might be possible in the relatively distant future. In this ideal world, templating, styling, theme-supported features, and plugin integration are neatly packaged into something configurable from the admin. In practice, users could control any aspect of their site’s front-end through the interface.

The problem is that someone still needs to make those customizations, and not everyone has a knack for design. One person’s ability does not automatically translate to all other users.

Perhaps a more crucial point is that not everyone wants to customize their site’s design. Some people simply want to find something that suits their style and move along.

There are alternative routes for arriving at the same destination, but themes are currently the only reliable vehicle.

Schutzsmith tweeted the following in response to Jamie Marsland, who likened the notion to asking Picasso for the canvas instead of the finished painting:

Themes and swapping out the whole thing is an old way of thinking. Sure a theme could = painting but I’m saying why can’t we just swap out the theme.json and get the same result? Why the need for themes at all when all we need to change is theme.json.

That is a future that I would not mind striving for. It is not insurmountable, but there is an uphill climb that WordPress will undoubtedly struggle with. Without a standardized CSS toolkit in place, switching theme.json files simply does not work. If WordPress tackles that problem, it takes us one step closer.

But theme.json only represents settings and styles. It says nothing about the structure of a website. Pre-configured templates are still necessary. Right now, that job sits squarely on top of the theme author’s shoulders.

If and when a well-designed user experience for full-page patterns lands in WordPress (related ticket), the template argument becomes less relevant. With such a system in place and enough variety from the pattern directory, some users might not require themes to handle this.

Starter templates or page patterns selector for inserting full-page content into the WordPress editor.
Starter page templates proposal.

The only worthwhile argument I have for multiple — even 1,000s of — themes is the promise they make to the user: install this thing, and you get this result.

For example, a pizzeria owner installs WordPress on their site and begins looking for a design for their online presence. This is likely someone working all day in a hot kitchen and comes home exhausted at night. However, they hop on the computer to update tomorrow’s specials or tinker with a new homepage layout for a few minutes. Everything about that experience should be catered to their use case. As an owner, chef, spouse, and parent, they need to quickly get things done and spend the rest of the night with their family.

This and 1,000s of similar scenarios are why themes are as important today as they ever were. Not everyone has the privilege of time, the skillset, or the inclination to piece their sites together.

When done well, block themes offer a controlled experience that cuts out all the cruft. They feel like they were built for an audience of one while being flexible enough for public release.

Schutzsmith later tweeted in the thread that he liked Elementor’s Kits. These are predesigned website designs that span multiple industries.

Pattern category types, which are not currently in WordPress, could evolve into that role. The Block Pattern Explorer plugin enables the feature, but themes must add support for the types to appear.

In the following screenshot, I have created a “Profile Cards” type in a theme of mine, but it could be industry-specific:

Block pattern explorer opened to a specific block pattern category type.
Block pattern category types.

It should be as easy as locating an industry-specific type and finding patterns for the pizzeria owner. A theme can offer that by either packaging patterns or pointing to those hosted in the directory.

I could see this evolving into more of a kit-like solution.

I disagree with Schutzsmith’s conclusion of needing only a single theme but not the questions he is asking. Our design community cannot simply say that themes should be “this one thing” because that is what they have always been. Its members need to continually ask: What is a WordPress theme?

The answer may be different to various groups of creators and users. If someone can get everything they need from the pattern directory without switching from Twenty Twenty-Two, maybe themes are irrelevant. If a creator simply likes building global style variations (theme.json files), WordPress should make it easy to use them on a wide range of sites.

However, many users will still need turnkey design solutions, and themes can be the best way to facilitate that. I do not know if that is 100, 1,000 or 5,000, but we will see how it goes.

FSE Outreach Round #12: Building a Site Header With Blocks

On Wednesday, Anne McCarthy announced Round #12 of the FSE Outreach Program. As always, everyone is free to join by testing features and providing direct feedback on problem areas with the design tools in WordPress. Anyone interested should respond by March 16.

For this round, volunteers are tasked with testing some oldies but goodies. Early in the program’s history, anyone who joined did a lot of site header and navigation work. Round #12 asks that users revisit some of these essential tools.

This was an exciting call for testing for me. In early 2021, I had my fair share of frustrations with the FSE experience. There were so many designs I wanted to tackle, but I far too often fell short of creating what I wanted.

Therefore, I hopped back in time and revisited a header design from Round #4 of testing in March 2021. At the time, the WordPress leads were weeks away from deciding whether some FSE-related components would land in WordPress. My conclusion of the tools at the time was:

I came to the realization that attempting to do anything remotely advanced with the site editor was simply not going to happen…As someone who prides himself on near-infinite patience, Round #4 sought to crack me.

I had wanted to recreate elements from the UK-based Pho Cafe page header during testing. It was a tall order that could not be filled.

Screenshot of the Pho Cafe website page header.
Pho Cafe header.

However, almost a year later now, how much has changed? Is it possible to create an exact replica of the site’s header from the block editor?

Yes and no. As usual, it depends.

As a developer and designer, I am confident that I could do it with custom code. Considering this would likely be a one-off design for a paying client, I would be comfortable with that.

Creating this as a part of a publicly-released, general-purpose theme would have a ton of roadblocks with that level of customization. However, it would be possible to capture much of the character, the essence, of the design.

As for building it directly from the block editor, there are still some severe limitations. However, that is what I challenged myself to do. I wanted to get a feel for where the site editor was at without writing CSS code.

The following is the result:

Pizza restaurant header with a logo, menu, and buttons at the top right. In the middle is a demo slogan followed by another button-like menu.
Pizza restaurant header.
Pizza photo credit: Jennifer Bourn

Technically, I did write a little code to load the KG Happy font. Outside of that, I just forked a block theme I had on hand and changed the “wide” size. I created everything else 100% from the site editor.

Here is a screenshot of the design from the editor itself:

Pizza restaurant header within the site editor.  The current view of the header template is selected.
Custom header template part in the site editor.

On the whole, this went surprisingly well. In a year, the site editor has become far more powerful.

As I said, it still has its limitations. Anyone who has worked with block themes will likely tell you the issue with the layout in the above screenshot. The problem area is the Columns block used for the Site Logo, Navigation, and Buttons across the top. You might as well hang up any hope of that working well on smaller screen sizes.

Mobile view of a restaurant header. Menu area is out of alignment.
Mobile view of header.

Is it entirely unusable? No, but it is not anywhere near close to ideal.

Without responsive controls on layout-type containers like the Columns block, designing anything complex with the site editor can sometimes feel like one giant hack. At this point, this is not a revelation of any sort.

There are tons of improvements with block design tools in comparison to last year. The core block gap, margin, and padding controls are a godsend for adjusting vertical and horizontal spacing. Back then, even the thought of having any control over this was a headache-inducing affair. Except for a few blocks still missing these options, it is now [mostly] stress-free.

I hit no spacing-related problems in this experiment. That feels gratifying to say after over a year of testing FSE features.

However, I did hit some other roadblocks. The Navigation block may be my least favorite thing about the site editor. I have yet to see how it will offer a universal system that plays well with the 1,000s of design variations that theme authors will want to employ. Classic nav menus are still vastly superior for custom design.

I ran into two primary issues with this experiment. One of the problems I had a year ago with FSE Outreach #4 was creating a menu that had button-like links. This basic design is still impossible with the Navigation block, at least with the core design tools:

Four button-like links with red backgrounds and white text.
Button-like navigation items.

Users can add a background to the entire Navigation block but not to the individual menu items. How did I do it? I used a Buttons block instead.

The more I think about it now, the more I like the Buttons block alternative. However, there is no way to wrap this in a <nav> tag to define it as a navigation element.

One missing piece of the header I was attempting to replicate was a mobile menu at the far right of the layout. WordPress’s mobile Navigation menu icon provides no customization options. Users can customize the overall background and text color but not target the button directly. I faked it a little by narrowing down the column:

WordPress site editor with a mobile-only Navigation block highlighted.  It is aligned to the right of a Buttons block.
Mobile Navigation menu icon next to Buttons.

There was no way to make the mobile icon larger or give it any padding to align its size with the Button blocks next to it.

The Navigation block, despite its progress, is still one of the weakest links in FSE. It only covers a handful of simple use cases out of the box. Anything beyond that requires a deep level of customization and the hope that an end-user does not break the delicate balance struck to make it work.

Twice during testing, my Navigation block disappeared on the front end. I suspect it had something to do with me trying to adjust the outer Column block’s width. However, I was unable to replicate the issue at will.

Testing is all about finding problems to solve. I did not run into any crashes or the types of bugs that I would have seen long ago. The experience of designing from within the site and template editors feels pretty smooth these days. The holdups are more about missing capabilities than anything. Making the leap from an impossible header layout to an almost possible one in 11 months is significant.

Ask the Bartender: Where Are the WooCommerce Block Themes?

At what point are FSE theme developers going to start integrating and considering WooCommerce for their themes? WooCommerce has almost always seemed to lag behind all other considerations. It’s a bit like it’s an afterthought to simply scramble in the elements of a solid WooCommerce store. Where is a persistent cart header? Where are the templates for /single-product? There’s all kinds of elements which can be developed right along side of other teams working on FSE, but it seems to (again, consistently) not happen.

I’ve taken Blockbase and all the other FSE themes for a spin on LocalWP, and none of them have any WooCommerce elements in them. Again, one should not expect perfection at a “developmental” stage. However there does seem to be a behavioral pattern of WooCommerce elements being a bit of an “afterthought” that simply brings up the rear about a year or year-and-six-months afterwards.

Why not get everyone on the same page immediately? That way theme authors can address putting the cart elements in the header template. (Yes, WC can be run, but w/out a cart header, shoppers don’t know where to click after an item is in their cart). And, if theme authors and WP core developers always, Always, ALWAYS started simultaneously with one or two WooCommerce folks on board, it would absolutely shorten the time needed for store owners to receive the benefits of FSE (and remove some of their pagebuilders!) and for WordPress to get more Shopify business over to WooCommerce. But that seemingly never happens because WooCommerce always seems to be the “afterthought.”

Brad

First, I want to make sure all of our readers are on the same page. WooCommerce is a third-party plugin. It is unrelated to the core WordPress and Gutenberg projects. Granted, WooCommerce is owned by Automattic, one of the largest contributors of resources and people. So, there is likely some crossover among developers.

It is still crucial that we make a distinction between the two. When looking at some of the recent block themes that other developers have released, I have yet to see any integrate with the WooCommerce plugin. I cannot say whether any of their authors have plans to do so in the future. I imagine that some will and others will not. Like with any third-party plugin that outputs something on the front-end (e.g., bbPress, Easy Digital Downloads, etc.), it is the theme author’s choice of whether they want to take on the burden of supporting integrations with projects that are not their own. It can be a maintenance nightmare at times, particularly when it comes to free themes. However, I have no doubt that we will see more block theme authors catering to WooCommerce users as we move forward.

All of this is a long-winded way of saying the responsibility of WooCommerce working in a block world is on WooCommerce itself. When it gets to that stage, theme authors will follow.

One of the things I love about the block system is that it creates a standard for all themes and plugins to build from. The long-term goal of plugins like WooCommerce should be to work without theme support. If a user wants a cart item in their nav menu, it should be as simple as adding a block via the site editor. The same should be said for any other element of creating an online shop.

I reached out to Darren Ethier, an engineering team lead within Automattic who works on the intersection between WooCommerce and Gutenberg. He agreed that the block system could make it easier for things to simply work without specialized theme support.

“That’s definitely the target we’re shooting for,” he said. “Whether or not we will land it in the first iteration is still unknown.”

However, the answer is more complex than that. WooCommerce is a heavy plugin with a history entrenched in the pre-block era of WordPress and has an ecosystem of third-party add-ons it must be careful not to break. The team is making progress and has a few things shooting through the pipeline. It will take some time, but you will not see block themes showcasing WooCommerce shops without the plugin first laying the groundwork.

Block templates are a high priority. Top-level templates like single-product.html, archive-product.html, taxonomy-product-cat.html, and taxonomy-product-tag.html will be available to any block-enabled theme soon.

“This initial iteration will be a straight port of the existing PHP templates and have a placeholder for the rendering of the template in the editor,” said Ethier. “We’re essentially wrapping the rendered PHP template in a dynamic block. This is definitely not the end goal. It just is the initial step of moving towards our vision of ‘Store Editing’ where merchants are able to completely customize the layout of their stores using all the opportunities available through the block and site editors.”

This is more of a stopgap measure than full-blown support. However, it is a step in that direction.

“We decided to take this approach because it more quickly helps bridge the gap between the current PHP-based templates and block themes so that folks can start to see the potential (and still add blocks around the PHP-rendered content),” he said. “We also know it’s going to be a complex job to more fully implement the vision of Store editing with block themes while supporting (and inspiring) the rich existing ecosystem of WooCommerce extensions. So, this allows us to incrementally improve things over time.”

This may not be the news all block theme authors want to hear, but the changes will be enough for them to start exploring tighter integration with the plugin.

The team is currently aiming to add block template support in the next release of the WooCommerce Blocks plugin. If all goes well, the feature will be ported to WooCommerce 6.0, which should be in time for the WordPress 5.9 release.

“It’s important to set expectations, though (which is why I’m mentioning this again),” said Ethier. “This initial iteration definitely will not be the final iteration of Woo Block templates.”

He also highlighted several things from the roadmap:

  • “Product Element Blocks” – which are the Woo equivalents to the WP template blocks. So, things like “Product Title,” “Product Description,” “Add to Cart Button,” etc.
  • Integrating with the WP Query Loop Block (for products).
  • “Mini-Cart Block” – which should allow for insertion into header/footer template parts.
  • Commerce Patterns.

“All these things (and more) will help us with iterating on the various components of a store that are visually represented via templates, template parts (i.e., think of things like reviews on the single product page, etc.),” said Ethier.

For a deeper look at what is ahead, read Peek into the WooCommerce Blocks Roadmap. Warning: it is dense and geared toward developers, but it must be. The solutions for a project the size and scope of WooCommerce are not simple.

“One key strategy we’re trying here is to provide default WooCommerce store editing templates and functionality out of the box with Woo Core that should in theory ‘just work’ with any block theme,” said Ethier. “There’s so much that theme.json and global styles unlock to make this possible. Themes will still be able to override the default WooCommerce templates and template parts if they want, but they won’t need to.”

While it may feel like block-based storefronts are lightyears away, we must remember that block themes are in their infancy. There are only about a couple dozen in the directory, and most of those are experimental.

I am as excited as anyone about what this could mean for projects like WooCommerce. At the same time, I also know that the road might be longer than what we have in mind, but the WooCommerce team is already traveling down it.

FSE Outreach Round #9: Building a Higher Ed Header

It feels like it has been ages since the WordPress community has had a call for testing Full Site Editing (FSE) features. The FSE Outreach Program was on a small hiatus. However, the WordPress 5.8 launch was also underway last month.

The program is an open call for testing various components of FSE. Thus far, volunteers have successfully provided feedback on features that have already landed in core WordPress, such as block-based widgets and template editing. Testers have delved into others that have yet to be released. Each testing round is open to anyone who can spare a little of their free time and share their findings. The goal is to break things and point out problematic areas of the user experience.

FSE Outreach #9 is a community-driven suggestion that calls for building a Higher Ed site’s header. Volunteers are asked to follow a 26-step process using the site editor beta feature in the latest version of the Gutenberg plugin and the TT1 Blocks theme.

I am a fan of this take on testing, and program lead Anne McCarthy seems to favor doing more of it in the future. “If you’d like to suggest an idea for a call for testing, know it’s very welcomed and all ideas will be weighed against current project priorities to figure out what makes the most sense to pursue,” she wrote in the announcement.

Since the project was all about Higher Ed, I decided to pay homage to my alma mater and use the colors that I wore proudly around campus for five years — and still do to this day. The following screenshot is the end result:

Fictional university website header with logo, title, description, navigation, and featured image.

Before going forward, I must admit that I cheated to get that final look. The call for testing asked that we build from the TT1 Blocks theme. I was able to get close to that result, but I had to switch to a custom theme I have been working on to get past a few hurdles.

I went through each stage of testing with TT1 Blocks and will cover the issues I encountered.

Building a Higher Ed Header

Just getting off the ground, I ran into my first issue, which turned out to be a non-issue. The internet gods decided to play a trick on me, disallowing me from editing both the Site Title and Site Description blocks. I really wanted my fictional university to be “Gutenberg University,” but I could not do so without saving my progress and refreshing the browser tab. I was unable to replicate the issue, so I am hoping it was simply a fluke.

Using the Navigation block still seems the most troublesome area of site editing. I know how much work the development team has put behind the user experience for this feature but cannot help but wonder if there is a point where users can opt into managing its content (the links) via the traditional Nav Menus screen in WordPress. The site editor works fine for the design aspect, but I have yet to feel comfortable using it to manage links.

This stage of testing calls for adding multiple page links as both top-level and sub-menu items. When clicking the + button to add a link, my first instinct is to search for the page itself. However, the available field is a block search rather than a page search.

Navigation sub-block search field with text that is meant to search for a page link.
Accidentally searching for link in block search field.

To add an actual link, users must first add the Page Link block. Then, they can search for a specific page. This two-step process gets me every time.

I ran into the issue for nav menus mentioned in the call for testing where there is no space between items when used inside a Columns block. It pains the purist in me to admit it, but I had to use the Spacer block between each item to fix this. I did not need to do this with my custom theme because, I am guessing, I addressed this somewhere along the way.

The “space between items” option also failed to work with the Navigation block, ruining one of the early design ideas I had. I decided to go in a different direction.

Using right-alignment with the Search block did not work. Therefore, I used the 100% width option to align it with my right-aligned nav menu.

Time and time again, I needed to rely on the Spacer block to make adjustments. Part of this was because default margins and paddings are inconsistent among different blocks. The still-missing margin controls on nearly every block also played a hand in this. This is not particularly noteworthy. The development team is aware of and working on extending spacing controls — they just can’t get here fast enough for some of us.

A spacing issue is what led me to ditch TT1 Blocks and switch to a custom theme. The following screenshot is my final work with the former. You may notice the gaping green background between the nav menu group and the header image below it.

Fictional university website header with logo, title, navigation, search, and image.
TT1 Blocks theme version with gap in header.

No amount of tricks or rearrangement of blocks seemed to remove that space, and I simply could not live with that. I had already solved about 90% of Gutenberg’s spacing issues with my own theme and did not feel like writing any new CSS to address this. Making the switch also meant that I could get rid of several Spacer blocks I had in place.

Aside from dropping in a header image, one other modification I made was skipping the addition of a Button block for the latest “Covid update.” I could not bear looking at TT1 Blocks’ overuse of padding. Instead, I nested a paragraph with a link within a column alongside a Navigation block.

As always, I enjoyed the process. This post is meant to be critical of specific areas in the hopes that it helps build a better WordPress. For all its faults, many other parts offer a solid user experience. Overall, the Gutenberg development team continues to impress.

FSE Outreach Round #8: A Developer-Centric Call for Testing Theme JSON Configuration

Round #8 of the Full Site Editing (FSE) Outreach Program began yesterday. Instead of the user-centric call for testing features from the UI, program lead Anne McCarthy asks that volunteers dive into code. The new adventure is all about testing theme.json files.

The twist is likely to limit the pool of usual volunteers. However, it could open it up to an audience that may have been sitting on the sideline for the previous tests: theme developers.

Before jumping headfirst theme JSON files, we should probably all get on the same page.

I have been calling theme.json the tipping point between the old WordPress and the new WordPress. When version 5.0 of the core platform launched in late 2018, it was a revolutionary step forward, but not on the surface. A new editor is just a new editor. Some will love it; others will hate it. And, it was more often clunky than not. For the most part, WordPress was still WordPress.

The core software was due for an upending. Newer technologies were not only democratizing publishing in their own ways, but they were also bringing that same concept to design.

The introduction of blocks was merely foundational. The new editor was an imperfect tool, often feeling like the proverbial round peg being shoved into a square hole.

The only way to live out the early vision of the Gutenberg project was to continue bridging the gap between what the user sees in the admin and what gets output on the front end. That is what the theme.json file is all about. It is a translator that allows users, themes, and WordPress to all speak the same language.

What does this mean exactly?

From a user’s viewpoint, they see all sorts of controls for changing their blocks. Color, font size, alignment, and other options are tools that allow them to customize their content.

A profile card designed in the WordPress block editor.
Customizing a profile card for my cat using block options.

There are severe limitations with what is possible in the current system. Theme authors can register a handful of options. Outside of that, the theme and block systems can feel like they are pitted against each other for control.

That is where the theme.json file comes in. It allows themes and WordPress to get on the same page, creating a standardized system that improves the user experience.

This file that lives a theme’s root folder hands over the power to configure dozens of presets (e.g., color and font options), custom CSS properties, and default styles for blocks and HTML elements.

It also gives themers the power to enable or disable specific features. For example, developers can turn off the ability for users to set a custom font size but provide access to their perfect scale of choices that fit into the design’s vertical rhythm.

However, it will move beyond the simple configuration of blocks in the content editor. When the global styles system launches alongside the site editor in the future, users will customize many of the presets and overwrite the default block styles. Because everyone is speaking that same language, fewer conflicts arise.

As designer Tammie Lister pointed out in her piece for Ephermeral Themes, Theme.json inspires, themes have been stuck. The software, the community, has put too much responsibility on the shoulders of themers over the years. They have had to innovate and build the systems that should have been coming from WordPress. Not only did the core platform need to be turned on its head, but the design system deserved an overhaul.

“I am very aware that saying ‘first major theme process to core’ in years is quite a statement,” wrote Lister. “Theme.json to me is that though. I don’t say this ignoring iterations and improvements, WordPress is a project flowing with the energy of those. However, themes were on life support stuck in a land when the rest of front end development was moving on. It wasn’t for some trying to change that, mostly when they did the time wasn’t right and as it didn’t come from core it was always a harder change.”

It is time for a new front-end design era. But, first, we must test.

Testing Theme JSON

Screenshot of a theme.json file in a code editor.
Real-world theme.json file.

The more I journeyed into this call for testing, the more I realized it did not feel right for me. Over the past couple of months, I have already been in the thick of working from the theme.json file. I know most of the little quirks and see the gaps. The tricks for working with it feel second nature to me.

I have performed all of the beginner and intermediate steps dozens upon dozens of times. I have already filed tickets for any issues I have run into. Or, someone else has already beat me to the punch.

Those stages of this testing round need fresh eyes. The best feedback will be from theme authors who will be viewing the problems through a different pair of lenses. If you are in this group, there is no time like the present to test and provide feedback.

The advanced stage calls for recreating a classic theme using theme.json. It is best to stick with something simple. Otherwise, you could be looking at a weeks-long experiment. McCarthy recommends Twenty Twenty or Storefront. I have already been performing this song and dance too. My test project was an old theme that I gutted and turned into a block theme.

There is one overarching issue that I keep coming back to. It is that theme authors must work from a JSON file at all.

I understand the “why” behind using JSON. It is a universal format that we can pass around from JavaScript to PHP. Third-party APIs can understand it.

However, I am currently sitting on top of 900+ lines of code in my theme.json. I have heard from a couple of other theme authors who have been doing deep work with similar numbers. I expect it to only grow.

“Number of lines” is not necessarily some metric where a specific total is a dividing point between “good” or “bad.” The problem is that comments are not allowed in JSON files. One of the cornerstones of sound development is documenting code. Skipping out on documentation of a few dozen lines is not so bad. However, when you speed past 900, things can get out of hand.

Plus, at a certain point, you start wanting to split pieces into their own groups. This much code is begging for better organization.

The thing that is currently missing is a PHP layer for theme authors to use. Remember, JSON is a universal format. It is easy to convert PHP to JSON and vice-versa. Building in this layer for theme authors would accomplish two things:

  1. They can organize what will likely be 1,000s of lines of code.
  2. It will be easier to transition to the new system.

The latter point is likely the most salient. PHP has been the language of theming since the theming has been around. Developers know it and are comfortable using it, and WordPress should meet them in the middle. If we are closing gaps, this is the one that needs filling before more configuration possibilities are added and theme.json files balloon into unwieldy, 5,000-line behemoths.

FSE Outreach #7: Building a Portfolio in the Upcoming Template-Editing Mode

Feedback for round #7 of the FSE Outreach Program opened today. Like round #6, the focus is once again on template-editing mode, a feature that is slated to ship with WordPress 5.8. All hands need to be on deck for it to have a chance of a successful landing.

I have been eager for this round of testing. FSE Outreach lead Anne McCarthy asked volunteers to follow a 16-step plan for building a portfolio template. Unlike the previous six tests, this one gives users more leeway, room to explore template editing.

As usual, the base set of tools is the latest version of the Gutenberg plugin and the TT1 Blocks theme.

For my portfolio, I decided to approach it as a hypothetical photographer who wanted to drum up some new clients and show off his latest work. The following screenshot is the end result:

Example portfolio page with a cover header, projects section, testimonials, and footer.

Anyone is welcome to grab the HTML block code for this template. I saved it as a GitHub Gist. The image URLs are to my local machine, so you will need to update those if you decide to give it a spin.

I had a lot of fun with this. And frustration. Some more fun. And…you guessed it…some more frustration.

The editor and I got off to a rough start. After adding my Cover block, I wanted to add a Columns block inside. Error. The dreaded invalid block message. I switched over to the code view to see if there was anything odd. It was empty. After switching back to visual, the Columns block seemed to be working. I was able to inconsistently reproduce this issue in template-editing mode.

I used a Columns block because it is the only way that I know how to create a left-aligned container covering 50% of its containing element. It is a bit of a hack, but you can set the block to one column and adjust its width to whatever size you need. Ideally, users would be able to do this with the Group block.

It was the underpinning of my template header area. I went with the traditional hero/cover intro that spanned the width of the page.

Adding a Cover block in the WordPress template editor with inner columns.
Header section of template using Cover block.

Adding a site logo and navigation is where I hit my second snag. The navigation worked fine, mostly. On mobile, the responsive menu overlay is partially covered by the WordPress toolbar on the front end. However, I already knew this. Responsive nav menus are a work in progress.

I was unable to use the Site Logo block. Whenever I attempted to add it, it had a continual spinner icon that never went away. So, I opted for an Image block — you make do with the tools you got or the ones that are working.

Spinning site logo block with a real image underneath.
Second test of adding a site logo in different section.

The next section of template testing consisted of adding a Query pattern and customizing it. I have a love/hate relationship with queries in Gutenberg right now. The Query block itself works well. It has a solid balance between advanced usage and simplicity for the most part. I am amazed at what the development team has done over months upon months of iteration.

The downfall is that the Query block is merely a wrapper. It is only as good as its weakest sub-block. Most of its nested blocks are for post-related data, and the weakest among them is Post Featured Image. It limits everything that can be truly fun about building queries. It does not even cover a basic sub-set of the Image, Cover, and Media & Text options.

It is frustrating because users and theme authors cannot build out their visions. I know it will get there someday. Today, we are limited to the basics without any themes offering highly customized Query patterns.

It is tough to go wrong with a simple grid, so that is what I did.

A three-column grid of portfolio project images, titles, and dates.
Grid-style portfolio layout (first image is out of line in editor)

I followed that section with two Columns blocks nested inside another Columns block for a testimonials group. Then, I wrapped it up with a basic footer, running into the same issue with uploading a site logo. The most prevalent problems in these sections were inconsistent spacing.

Some of the limitations with these tests are not from the template editor in Gutenberg. Instead, they are from the TT1 Blocks theme. However, I suppose that depends on your philosophy about what the future of theme development should be. If most front-end styles should come from WordPress/Gutenberg, it is not a theme issue.

Vertical alignment is inconsistent in the best of times. Liberal use of the Spacer block is not ideal in real-world projects to align blocks. It can be a handy tool when needed, but it should not be a crutch for correcting foundational issues. The block system adds a few potholes in the road, but a well-rounded and tested theme can mitigate most of these problems. And, TT1 Blocks just does not do this. It relies almost exclusively on the core block styles without swerving left or right when it needs to.

The current padding controls for a few blocks like Group help with this. However, most users are not going to micromanage every pixel of every page on their sites. The same can be said for the margin controls when they become available. Again, both are useful and necessary tools, but users should not lean on them too heavily to correct design issues. In the long run, it will create more problems as site owners eventually swap themes.

Mismatched output in the editor versus the front end can become a headache at times. This is a known issue and noted in the call for testing, so I won’t harp on it.

I enjoyed the process — yes, I revel in both the fun and frustration. Aside from everything that I think is broken, the overall system is pretty dang sweet. There are far more things that the development team has nailed down than there are that feel janky. However, calls for testing are all about finding the problems. I encourage all Tavern readers to join in and report your feedback.

Bricks: Laying Down a Foundation in the WordPress Page Builder Market

In a mature and ever-growing market of WordPress page builders, Thomas Ehrig decided to bring a new product to the ecosystem. Joined by Luis Godinho, the initial team launched Bricks in March. Unlike most other builder plugins, the project is bundled as a theme.

As a small, 100% bootstrapped company, the team decided against going the freemium route. Pricing currently starts at $59 for a lifetime license, but that could change as the business model evolves. Potential customers are encouraged to test the product out via the open playground demo site.

A restaurant header with several cooked steaks in the Bricks builder.
Creating a restaurant menu via the Bricks demo site.

“Bricks aims to provide an all-in-one site-building platform that empowers you to create beautiful, fully-fledged, and responsive sites that rank,” said Ehrig. “Without having to buy and rely on dozens of expensive and disjointed plugins.”

One of the problems that the team wanted to avoid was end-users trying to find a Bricks-compatible theme. Instead of offering a default or placeholder, Bricks serves as an all-in-one bundle.

The difference between a theme and a plugin is mostly a semantic one in WordPress. Aside from a few small things, a theme can do anything a plugin can do and vice versa.

“The main advantage I see providing it as a plugin is from a marketing perspective,” said Ehrig. “Elementor has done a fantastic job in this department. As you can see on the many free and premium themes that it comes bundled with. This greatly helped boost its exposure in the early days.”

Aside from a few users trying to install it as a plugin, he said the team has been happy serving Bricks as a theme.

He described the builder as a “theme that aims to tame the plugin madness.” The focus is on customization, design, and performance, but the development process is user-driven. All of this is done in the open via the project’s idea board, forum, and Facebook group. Users can submit feature requests, which others can vote and comment on. The team builds its development roadmap from this foundation.

Voting systems like this often work well in a project’s early history. However, they can become unruly as audiences grow. We will have to check in with Bricks a year or two down the road to see how their feedback system has evolved.

“We don’t build in secret,” said Ehrig. “Our public roadmap makes sure everyone knows at all times what to expect and what’s next. It also keeps us accountable. If you are not only looking for a beautiful builder that is fun to work with, but where you have an actual say about its development, I think you should take Bricks for a spin.”

Bricks is bringing in its third team member to develop predesigned templates. However, they are already looking to grow the team more. Their current need is for a Vue.js and WordPress developer.

Building in an Established Market

Editing a slider panel in the Bricks page builder system.
Slider element in the Bricks builder.

Elementor has become the de facto standard for third-party page builders. Others have made dents, and WordPress is launching several sub-components of its Full Site Editing experience in version 5.8. It is getting crowded, but Ehrig believes there is plenty of seats left at the table.

“The WordPress builder market is well established,” he said. “This actually gave me the confidence to start this project in the first place. It’s been heavily validated, and it’s not going away anytime soon.”

Not wanting to launch a half-baked builder, he said the team forwent a deadline for their version 1.0. They wanted to create an MVP with all the essentials and hit the ground running. Based on the initial feedback in the past couple of months, he said it is clear there is still space in the market.

Personally, I think there is always going to be space. After all, we are talking about tens of millions of WordPress sites that need to be launched, re-built, managed, and constantly optimized. It’s also not a winner-takes-all market, which is nice.

Your users’ trust and loyalty have to be earned every single day. If not, many move on to a different solution. As the web design and development landscape evolves, so has your product.

All those moving pieces ensure that no single player can rest on his/her laurels for long. Meaning there are always going to be opportunities if you take the time to look out and execute on them.

While the builder is somewhat of a competitor against the core platform it is built upon, it works alongside WordPress. Users can convert their block-built pages into Bricks data. This data conversion works the other way around too.

“So there is no lock-in effect,” said Ehrig of the feature, which his team made available from Day 1. “Which I think is really important. If someone decides to move away from Bricks, we don’t want him/her to be tied to our platform.”

The team is also exploring the concept of creating blocks visually within Bricks. The goal is to enable more integration between the two, but they must wait to see how Full Site Editing evolves in the coming months to know what that might look like.

Version 1.2 and Beyond

Bricks template builder screen.
Inserting a Container element from the sidebar.

Last week, the Bricks team launched version 1.2 of its builder. It is touting its new “Container” element, which is essentially a box to put other items in. Users can control its display settings, and it already supports flex layouts, which many designers will welcome. Grid layouts are forthcoming, according to Ehrig.

“After that, I am currently very excited about the upcoming visual WooCommerce builder,” he said. “It’s a very challenging integration to get right. Not just code-wise, but also from a UI/UX perspective.”

Of the several things he thinks the team has gotten right, he mentions data integration with popular plugins like Advanced Custom Fields, Meta Box, Pods, and CMB2. He also said the version-1.0 features like global theme styles, responsive editing modes, and color palettes were things the team nailed down.

“But the one thing we are most proud of is not even a feature and something no one has really any control over,” said Ehrig. “And that’s the community that has formed around Bricks and its cause.”

In two months, its Facebook community has grown to 2,000+ members. “Very active, positive, and helpful,” he said. “You can’t put a price tag on that.”

FSE Outreach Round #6: Building a WordCamp Landing Page via the Template Editor

As has almost become ritual at this point, I am always looking forward to the next testing round for Full Site Editing (FSE). Spearheaded by core contributor Anne McCarthy, the FSE Outreach Program’s fortnightly user tests are usually fun and offer everyone a chance to get involved, regardless of their experience level.

This latest testing round is all about whether users can create a custom template on a per-post basis directly from the editor. The answer? Why, yes, they absolutely can.

Round #6 asks for volunteers to use the new template-editing mode, which is expected to land in WordPress 5.8, to build a WordCamp landing page. The goal is to offer a discount code and attract attendees from another event to join.

Anyone interested in discovering issues and providing feedback should give this testing round a shot. There is a 36-step guide that will walk you through building a custom landing page. It should take no more than 15 minutes, maybe more if you are putting a unique spin on the design — that is half the fun for me.

Feedback is open through May 26. Just follow the instructions and leave a comment on the post.

The closest thing to a local WordCamp I have is Birmingham, AL, known for its “WP Y’all” name. I am hopeful that the WC Birmingham team would not mind me borrowing their logo for this experiment. The following is the WordCamp landing page I built with the TT1 Blocks theme:

Full page screenshot of a reimagined WordCamp Birmingham landing page.

Other than the known Nav Menu block issue noted in the post, I ran into no technical problems with any of the 36 steps. Everything worked as expected. However, that does not mean that everything was perfect.

Problems, Mostly Trivial

Before diving into the actual user-experience issues with building templates, I noticed a problem with the custom template system. After finishing the testing round, I wanted to see what my template looked like with other themes. However, I could not do this. Upon activating another theme, my custom template seemed to disappear.

The problem is that custom templates are tied to the theme. I see the logic in this. Certain aspects could be specific to the active theme (colors, fonts, etc.), and it is always how custom templates have worked. However, the block template system is different. From a user viewpoint, I feel like my custom-created templates belong to me rather than the theme.

I can see a user switching themes after a couple of years and building a dozen or so templates having a poor experience in this situation. If the feature remains the same, there should be more clarity.

One of the more frustrating aspects of the template editor is the lack of space at the bottom of the frame. I am accustomed to the post editor’s extra whitespace, focusing the active workspace toward the top of the screen.

Screenshot of the template editor showing the limited space at its footer.
Limited space at the bottom of template editor.

I just want to put the current piece of the layout I am working on higher up the page. I am not sure how this would look when dealing with a template editor because it needs to clearly mark the end of the document.

The other issues were primarily around the TT1 Blocks theme or missing features with the current Gutenberg plugin.

When adding a horizontal Buttons block, there is no space between individual buttons. Vertical alignment is better, but it could use a slight bump (on the front end, not in the editor).

Two horizontal buttons with no space in between them.
Buttons a little too close.

And, I feel like I cannot be the first to say this: I am ready for Button block padding controls so that I can adjust TT1 Blocks’ abnormally large button output.

When inserting a full-width Columns block, the text on the left butted against the side of the page. Because neither the Columns nor the inner Column blocks currently have padding controls, the only way for users to “fix” this is to add a background color. Gutenberg automatically adds padding in that case.

Text in a left column butts against the side of the page because of no spacing.
No horizontal spacing.

The last trivial fix I had to make was adding a Spacer block above the custom footer section. This was not included in the testing instructions. Without it, the footer had no spacing between it and the content above it.

I did question one aspect of the testing instructions. Templates are generally a sort of wrapper or design layout. Content is a separate thing that typically lives independently. In this test, the content is housed within the template. There are scenarios where the test case makes sense. However, I would have preferred a flow where the content portion of the template was a part of the post and output via the Post Content block.

That sort of moving back and forth between post and template editors may have opened up some more usability hangups that would be worth exploring.

Classic Widgets Plugin Disables WordPress 5.8’s Upcoming Block-Based Widgets System

Yesterday, WordPress released a core plugin named Classic Widgets. Core contributors Tonya Mork and Andrew Ozz created the plugin under the WordPress Contributors account. It allows end-users to disable the upcoming block-based widgets system. Support is expected through 2022 or as long as necessary according to the plugin description.

Decided last month by a small group of core leads following a demo, WordPress 5.8 will ship several sub-components from its Full Site Editing project. FSE encompasses several self-contained parts that grant users broader control over the design and layout of their sites. One of those pieces is an overhaul of the widgets system.

Widgets will one day become a legacy feature of the platform. However, they are not disappearing any time soon. During the transition from the pre-block era of WordPress to the eventual incorporation of all the sub-components of FSE, users and theme developers will sometimes need smaller stepping stones. Block-based widgets give users more ways to work with blocks outside of the post content area without diving head-first into an entire block-based experience.

This is the first time many in the larger WordPress user community will be exposed to blocks in a new context. The editor that launched in WordPress 5.0 focused solely on the post content. The widgets system in 5.8 turns classic sidebars into block containers.

In short, users will be able to stick any block in any sidebar.

Widgets screen that turns each theme's sidebar into a block container.
Block-based widgets screen.

This is a welcome step in transitioning users in the long run, especially those who use classic themes, which is still the majority of all users. However, there are cases where the Classic Widgets plugin will be necessary. The biggest will be:

  • Broken themes or quirky output.
  • Users simply preferring the old system.

Whatever the case may be, the plugin handles the switch.

For those wondering why the core development team is not making sure block-based widgets work with all themes, it is because the two systems are not exactly alike. Plus, every theme design handles its sidebar output in its own way. There is no way to ensure 100% coverage.

Many themes will have no issues at all. Some sidebars, depending on the design, could entirely break down. More likely than broken, custom sidebar and widget designs could simply look “off” on the front end.

For example, compare a Heading block followed by the Archives block (first image) against the classic Archives widget (second image) when using the Twenty Fifteen theme:

The typography of the Heading is different, and there is too much space below it. That is not an end-of-the-world scenario. It is the sort of quirk that may be common with many themes, at least until theme authors have had time to push out updates.

What Happens When Activating the Plugin?

The traditional WordPress widgets screen with draggable widgets and sidebars.
Classic widgets screen.

Classic Widgets has no settings screen or anything to configure. It is a set-it-and-forget-it plugin. Its goal is to simply return users to the traditional widgets system in which they are familiar.

If you start using the new block-based widgets system, you will lose all of your widget blocks upon activating the plugin. There is no going back, so be sure this is what you want. The former blocks will not reappear if you change your mind and deactivate Classic Widgets.

However, if you add traditional widgets to your theme’s sidebars while the plugin is active, you will not lose them. They will still appear on both the front and back end if you deactivate the plugin.

Full Site Editing Is Partly a ‘Go’ for WordPress 5.8

Today, Josepha Haden Chomphosy announced the results of yesterday’s “go/no-go” demo and decision on whether Full Site Editing (FSE) would land in WordPress 5.8. The site editor and global styles are not landing in the next release. However, several other features should launch and allow users to build their sites with blocks in new ways.

The following people attended the demo:

  • Matías Ventura – Demo Host and Gutenberg Project Lead
  • Matt Mullenweg – WordPress Project Lead
  • Helen Hou-Sandí – Lead Developer
  • Josepha Haden Chomphosy – Executive Director
  • Héctor Prieto – Technical Project Manager
  • Chloé Bringmann – Assisting with administrative and operational logistics

Ventura walked the group through the various FSE features that could be ready for WordPress 5.8, taking questions and discussing along the way. There was also a discussion afterward that focused on ideas beyond the next release.

The following FSE-related features are expected to ship:

  • Improvements from Gutenberg 9.9+.
  • New theme-related blocks like Query, Site Logo, Navigation, and more.
  • theme.json integration, which allows themes to define block defaults and settings.
  • Template-editing mode for the block editor.
  • Block-based widgets screen and customizer integration.
  • New block design tools, such as duotone (SVG filters for images), layout controls, padding, and more.

“Not all of the above are currently ready but there’s some level of confidence that they can be by the time of 5.8,” noted Haden Chomphosy in the post.

This list feels like a solid compromise between launching some of the more polished FSE features and trying to force in those that are probably out of reach for a July 2021 release. The features also provide current users access to new block tools without activating a block-based theme.

The group focused on the Query block for much of the early discussion. The Gutenberg development team will likely change the block’s user-facing name to something less confusing. It also needs a bit more polishing to make things more user-friendly. I am interested in seeing how theme authors use this in conjunction with patterns once this launches.

One other feature that users should look forward to is the pattern directory. While it is not ready for integration into the WordPress admin UI, it does not need to be. Users will be able to copy patterns from the directory and paste them directly into their editor. In time, it should become a part of the built-in experience.

The group seems to have made a good call on which features to include. It is easy to want to push forward and get everything into the hands of users. It can be tougher to pull back and compromise.

Full video of the demo:

I had two takeaways that stood out to me more than anything in the meeting.

Takeaway #1: Page Template Editor

In WordPress 5.8, users should gain access to the template editor. On the page-editing screen, it allows users to switch out of content-editing mode. From there, they can work on the overall template. Essentially, for this release, it would serve as a landing page builder.

This is a sort of middle ground between just the block editor and the eventual site editor. I like this route because it does not overwhelm end-users with a complete site-editing experience at once. It is a helping hand, a transition from the current phase to the next, allowing users to familiarize themselves with more advanced tools.

The template editor will work for all users too. They will not be required to run a block-based theme to access it. Because each template would be a one-off use case, WordPress can serve this up without theme authors opting into it.

Many block-ready themes have already been including an “open canvas” type of template. This would remove the need for those unless also including it for third-party builders. It would also solve the portability issue when users switch from a theme that bundles the template and one that does not.

Takeaway #2: Many Block-Based Themes

At the end of the discussion, the group was more or less spitballing some ideas beyond version 5.8. In particular, Hou-Sandí shared a vision of what theme development for the official directory could look like in the era of FSE.

“Because the full site editing, like from a user-facing point of view, is not about page building all the time,” she said. “It’s about tweaking what’s there. Yeah. So I feel like the correct thing for core to do in terms of bundled themes is actually a bunch of small bundled themes.”

I have previously written about how work on Twenty Twenty-Two should already be underway instead of waiting until the last moment to piece a new default theme together for the end-of-the-year launch. The yearly default theme system has served the community well for over a decade now. I am already warming to the idea of turning it on its head and forging a new path.

With FSE, developers do not necessarily have to follow all of the rules of traditional themes. Themes like Kjell Reigstad’s Carrd-like, two-column landing page theme would be well-suited to such an experiment. Smaller, more experimental projects like this could replace the old Twenty* theme system with something new or even complement it.

Hou-Sandí also threw out a few ideas around building block-based themes via a library of CC0 images, the patterns directory, and copying/pasting things from WordPress.org. She likened it to the CSS Zen Garden era. It could even open the possibility of bypassing the theme review process since everything would be pre-vetted.

But, these are thoughts for tomorrow. For now, we are at least getting some initial FSE components.

FSE Outreach Round #5: Venturing out a Query Quest

The Full Site Editing (FSE) outreach program is chugging along. Since December, it has called for and completed four rounds of testing. The latest round asks volunteers to provide feedback on the Query block, arguably one of the most crucial pieces of the FSE-puzzle.

Automattic Developer Relations Wrangler Anne McCarthy has been overseeing the program since its inception. Each round of testing asks participants to follow along with a set of instructions while testing a specific feature related to FSE. They can then provide feedback on what does or does not work. Thus far, the program has tested and identified issues for template-editing mode, building a custom homepage, creating a 404 page, and wrangling a restaurant-themed header.

Volunteers for the program should install the latest version of the Gutenberg plugin and the TT1 Blocks theme. Participation is open to all, and further details are available through the announcement post.

The latest test is all about the Query block — McCarthy is dubbing it a “Query Quest.”

“Not many blocks get an entire milestone dedicated to them but the Query Block did!” she wrote. “As the name implies, this is a pretty powerful block allowing you to display posts/pages on your site and customize them as you see fit. For example, you could easily use this block to show off all of your favorite recipes by setting it up to show a specific category of posts.”

Generally, theme authors will primarily work with this block. However, for those end-users who will inevitably want to customize post output on their sites, they may need to at least have some basic familiarity with it or its block variations.

Building With the Query Block

Following the instructions for the testing round netted fairly consistent results between the editor and front end. Each step walks participants through the process of assembling a two-column page with posts from separate categories. Within just a few minutes, I built a few demo posts with custom categories named “Veggie Garden” and “Fruit Trees” (side note: these are pics of my plants). I sped through the process with no issues.

Adding two Query blocks to the WordPress editor, each in their own columns.
Using Columns to output two category-based Query blocks.

However, I am a bit of a pro at this point with the Query block. It is one feature I have been eyeing at least every week for months.

The two primary issues I ran into were with the “read more” link and spacing. For the more-link, it simply did not appear on the front end. When viewing the source code, the wrapper HTML was there, but the actual text was nowhere to be found.

As for spacing, this is more of a theme problem. I have harped on this issue in past testing rounds, and it is the same ol’ tune. TT1 Blocks failed to produce consistent spacing between the front and back end. One example is when using the Post Featured Image block followed by the Post Excerpt block. In the editor, there is little whitespace between the two. On the front end, there is ample room.

Some might say it is the most vital part of page building — nailing down the layout. I have voiced my concerns ad nauseam on spacing, so I have nothing new to report on the subject.

I decided to take a few extra steps and move beyond the basic testing instructions. Because it is springtime, I have been enjoying the outdoors a bit more as of late. I wanted to spruce up my Query block design. I wrapped the initial design in a Cover block with a garden-related background image, dropped in some header and intro text, and created boxes for my posts with the Group block. With a splash of color, some font-size changes, and a Spacer block here and there, I built something with a tiny bit more personality.

A cover block with background image behind a two-columned posts list.
Custom layout with the Query, Cover, and Columns blocks.

Testing never has to be boring. I encourage participants to grab inspiration from their own lives as they venture out on their Query Quest.

While I have my complaints about the site editor and realize we are miles away from the long-term vision, it is also amazing what is now possible. Even six months ago, building something as simple as this was not happening. More and more each day, I believe a public beta of the site editor and other FSE components in WordPress 5.8 is not such a bad idea.

Will Full Site Editing Land in WordPress 5.8? A Decision Is Forthcoming

Yesterday, Josepha Haden Chomphosy announced the roadmap for deciding whether Full Site Editing (FSE) will land in WordPress 5.8. After the launch of Gutenberg 10.4 on April 14, a small group of core leads will participate in a go/no-go demo.

The following people will be on the call:

  • Matias Ventura – Gutenberg Project Lead who will host the demo.
  • Matt Mullenweg – WordPress Project Lead.
  • Helen Hou-Sandì – Lead Developer.
  • Josepha Haden Chomphosy – Executive Director.

The meeting’s agenda is simple. Ventura will host the demo, and the group will discuss and cover implementation questions.

If there are no blockers, they will share a plan for merging FSE into WordPress. The more likely outcome is that they will find at least a few items that must be addressed. In that case, they will share these publicly with a plan to tackle them before a second go/no-go date of April 27.

The first beta release of WordPress 5.8 is set for June 8, with a general public release for July 20. The team needs to decide on inclusion early in the release cycle to give theme and plugin developers time to prepare.

While many are on their toes awaiting a final decision, everyone needs to have a little patience at the moment. Everything needs to be carefully weighed by the project leaders. There is a good chance we will not know the outcome until that second, April 27 deadline.

Most of the FSE transition would be a beta run for a subset users. Including these features in core does not mean that WordPress immediately flips the switch and enables everything for 40% of the web. For the overall FSE experience, users must make an explicit choice to install and activate a block-based theme.

With that in mind, the onboarding experience should be a welcoming one that invites users into site editing while letting them know the potential issues. If it is a built-in beta, they really need to understand that improvements are forthcoming.

An in-core beta run like this is also welcome, given the project’s launch of the block editor a couple of years ago. Regardless of whether people loved or hated the block editor, the rollout was not smooth for everyone. WordPress dropped end-users into an overhauled system, which was a shocking change for many. The project has a chance to do better this time around by incrementally introducing features to users and allowing others to immerse themselves in the new experience of their own choice.

“The most important context to share is that it isn’t shipping as the full, default experience for users,” wrote Chomphosy in the post, noting that the team is growing beyond past mistakes. “One of the clearest pieces of feedback from the Phase One merge process was that there wasn’t enough time for our extenders (agencies, theme authors, plugin developers, site builders, etc.) to prepare for the upcoming changes.”

The decision-makers may also decide to ship some pieces but not others. FSE is a project made up of several components.

“The whole full site editing project is sort of an umbrella term for a collection of tools and projects, so it would be possible for some pieces to ship while others don’t,” said Haden Chomphosy. “There are probably some exceptions to that, as you mentioned, but many of these can ship as they are ready.”

The exceptions she was referring to are components that make more sense together. For example, block-based themes via a theme.json config file and most of the site-editing blocks are not as useful when separate.

Of course, there are cases where something like the Query block could be used outside of the site editor. Users might create custom queries within a page without the benefit of the site editor, for example.

My primary concern is not with features related to the site editor but with block-based widgets. It is a transitional tool for users on traditional themes. Along with the new nav menus screen, it is not a part of the block-based themes experience. The goal is to allow users to start using blocks in more places. However, this will result in a broken UX in many cases.

The widgets experience is still partially broken, treating each block as a separate widget. Users must learn to put a Heading (widget title) and another block (widget content) into a Group (widget wrapper) for the correct widget-related classes on the front end of the site. For some themes, whether users do this will be a non-issue. For others, it will look ugly at best and break the layout at worst. Putting this responsibility on the shoulders of end-users was deemed an acceptable solution.

I wanted to focus on this issue because it is one of those things that may simply be flipped on for all users. I am still afraid that transitioning from a functioning system to a potentially broken one will make for a bumpy ride.

The WordPress 5.6 release team decided not to ship block-based widgets. Hou-Sandì, as the core tech lead for 5.6, provided a historical account of the decision and why it was not ready for inclusion:

My question for features that affect the front-end is “can I try out this new thing without the penalty of messing up my site?” — that is, user trust. At this current moment, given that widget areas are not displayed anything like what you see on your site without themes really putting effort into it and that you have to save your changes live without revisions to get an actual contextual view, widget area blocks do not allow you to try this new feature without penalizing you for experimenting.

While widgets have arguably improved, I still see the answer as being the same as last October. I have not seen enough buy-in from the theme development community to support the block editor itself, much less new block-related features. However, at some point, the project simply needs to move forward. Themers will just need to keep up.