https://fabian-kaegy.com/feed

Something I have observed over the last few years of working in the WordPress space is that it has become increasingly difficult to use work we develop on Client projects and contribute it back to WordPress Core. To me, that is a really concerning development, and I want to write about some of the things I’m observing to hopefully start a conversation about how we can improve this again. 

How contributions used to happen

When a client approaches us to develop a cool new feature for their website, we are often on a tight deadline and have specific launch dates in mind. We scope out all the work and then build solutions on top of WordPress. These solutions leverage WordPress’s hooks and filters to develop our solutions as custom plugins. 

This method allows us to develop these custom features on our own timeline and iterate quickly. Once we wrap up a project, we often approach our customers to determine whether they would like to contribute some of the things we built for them back to improve WordPress itself. 

That’s a great model that has worked very well for everyone. The client benefits in a few ways because they feel good about having made a larger impact. At the site time, it reduces ongoing maintenance costs for them because they are no longer using a one-of-custom solution but rather a feature WordPress officially supports. And the entire community can benefit from this work.

Besides just custom development work for clients, this model of feature plugins is how most of the larger features in WordPress got developed in the first place. Including the block editor, which started out as a feature plugin and technically remains one to this date. (Even though I would now think of it more as the alpha channel of WordPress core. But that is another topic)

So what changed? 

Since the block editor is in core we are finding it more and more difficult to actually use this model to contribute back to core after a custom feature has been built. The block editor itself is not nearly as extensible as “old WordPress” used to be. That is, in part, due to the nature of JS. Also, the open approach in the core has been misused again and again by plugin authors to degrade the experience of using WordPress. (We’ve all seen sites with ads and notices everywhere…)

However, this change in how extensible things are for 3rd parties now essentially means that any UI explorations, anylarger customization of WordPress can only happen in a feature branch or fork of the Gutenberg codebase itself. So, for custom projects that are on a fixed timeline & budget, that is no option. Instead, we have to resort to building custom integrations that don’t function as they would in core and, therefore, are not really something one can port back to WordPress after a project is complete. 

This problem has only worsened over time because any new innovation in the block editor happens behind private APIs and internals that never get exported. So, it becomes even harder to customize/explore features outside of working on core itself. We cannot get clients to pay for this because there is no clear timeline or even an expectation that the improvements will get merged into core at some point. 

I don’t suggest that this is an easy problem to solve. I have been and still am a big proponent of the introduction of private APIs because we needed to solve our backward compatibility issues. This post is just attempting to showcase some struggles I’ve been running into to continue the conversation about how we can improve this. 

Protecting the Experience

Another reason I often see from members of the Core team is that we want to prevent a similar situation to what WordPress ended up in before: ads and notices injected into all places of the UI, leading to a greatly reduced usability of WordPress.

And whilst I fully agree that WordPress, in particular, has many problems with this issue, I don’t think that it is the right approach long term to outright prevent extensibility to protect us from bad actors. I know it is naive thinking, but I still believe that, in the end, customers will choose which plugins they want to use based on what provides value to them. 

Having to fork all of Gutenberg to experiment with a new experience just doesn’t seem very future proof to me.

I really believe that the ability to extend virtually any part of WordPress core and swap it out for a custom implementation is what helped it grow so much and what, over the years, led to its steady rate of contributions from various sources.Whereas today, you have to essentially be a full-time contributor to the project in order to make a meaningful difference. 

The post WordPress Extensibility and how it used to drive development in core appeared first on Fabian Kägy.

This post originated as a list of quick posts on bsky yesterday and I thought why not expand on that thread a bit in a more suitable format.

---

I’ve been spending a lot more time shipping production sites as fully block-based-theme builds over the past year. And some challenges keep coming up. So with the release of WordPress 6.7 happening it’s a perfect time to identify some of the things that could still use further iteration.

Before I dive into the 9 items that came up over and over I want to preface this post though by saying that overall I am really enjoying this new paradigm and wouldn’t want to go back to building non block based themes.

It took us some time to get here. But as of WordPress 6.5 or so, I have made the switch in my mind to have block-based themes be the new default for any build unless there are really good reasons not to go down that route. (Like I wouldn’t want to use it on a headless build, for example)

With that out of the way, let’s get to my list:

1. Navigation Areas (#45512)

In block-based themes, the concept of navigation areas does not exist. Rather, every navigation block stores the ID of the navigation post it is connected to.

This doesn’t transfer across different environments like local & staging.

What makes it even harder is that when you update the navigation menu assigned to the navigation block, it modifies the template part, and therefore, you are now locked out of code updates to the template part.

One workaround for this is to wrap every navigation block in a template part because then that template part can be modified in every environment without the header actually being modified. So you can still make code updates to the header and keep the unique navigation menus assigned. But this approach still comes short in a bunch of ways.

The ideal solution for this would be to reintroduce the concept of navigation areas or maybe some other approach that would solve all the same problems

2. Restricting template updates in prod

We don’t just change something in prod on large sites with complicated publishing flows. There are procedures in place to track changes and approve things.

As mentioned in the navigation area example above, updating a template locks you out of code updates.

So, it would be really nice to restrict the ability to actually make updates in prod to specific template parts only.

We have experimented with restricting the site editor to super admins only. However, the problem we encountered was that more folks needed the ability to update navigation menus.

So the fact that there is no differentiation between the edit menu capability and the edit templates capability is a problem for us.

3. Seeing which templates/template parts have been modified (#66646)

Building on 1 & 2. If someone actually has modified a template/template part in any environment, the UI should show that much more obviously. Currently, you have to hover over the template and see if the checkbox is disabled or not to see if you are serving the version from Disk or the DB.

I would love to have a clearer indicator showing me which parts have been modified and which parts haven’t.

4. Adjusting the breakpoint at which the navigation block switches to its mobile layout.

The core breakpoint isn’t ideal for most designs. No breakpoint is the right fit for every site, so having some way to adjust it would be super valuable.

5. Synced theme patterns (#59272)

Block patterns are fantastic.

And with the introduction of pattern overrides, they are so much more powerful.

Today, however, those only exist in the DB. So, a user needs to create them in every environment, and changes need to happen in prod.

Defining them in code would be a dream come true.

Since posting this, I have stumbled across this plugin that manually handles the creation/updating of synced patterns across environments for you. Really cool to see a (arguably a bit hacky) solution actually work to solve the problem github.com/pbking/synced-patterns-for-themes

6. Better content-only locking. (#52018)

Content-only locking can create such a nice experience. It is at the heart of pattern overrides and many more features in the core.

However, the fact that we cannot add new list items or additional paragraphs inside a content-only locked area really limits its usefulness.

7. Editable block bindings inside templates. (#66931)

The ability to bind blocks to post meta and even have that meta value editable inline is so cool. We should allow bindings inside templates to still be editable when the post is edited with the preview active. Similar to how the post title block and post featured image blocks work.

8. Typography presets (#66932)

We can have presets for font sizes etc.. But more often than not I don’t just want a size but rather a full set of a type style to apply to an element.

My heading 4 style consists of a size, weight, line height, letter spacing, etc.

Defining reusable typesets similar to how text formatting tools such as Google Docs / Pages etc. work would be really powerful.

9. Border radius presets (#64041)

Design systems often have a few predefined radii that get used throughout a site. Having to insert a px value every time manually makes it very inconsistent and hard for editors.

Also, it is almost impossible to change the radius later in a redesign because that raw PX value has been used throughout the site.

---

This list, of course, is incomplete, not in any particular order of importance. This list simply is a snapshot of some of the things that popped into my head as I was thinking about common issues I keep encountering on builds that I would love to see us tackle in the next few releases

The post Some common pain points I see shipping enterprise Block Based Theme projects appeared first on Fabian Kägy.

I’ve been keeping my eyes on Full Site Editing within WordPress for quite some time now. And have made a few attempts at building a “Block-Based Theme”. The last time I had tried it was in December of 2020. And since then there has been a lot of movement.

So I wanted to try again and this time I was able to successfully migrate my site (the one you are most likely reading this on) over to be powered by a Block-Based Theme.

In this post, I will try to outline a few of the things that really impressed me and also a few areas that I have been struggling with a bit / have open questions about.

Please do keep in mind that Full Site Editing and Block Based Themes are still “experimantal” and activly being worked on. So what I am sharing here may have already changed or still is a work in progress.

This post has been written at the time of WordPress 5.8.1 with the Gutenberg Plugin Verison 11.5.0 activated.

Things I was impressed by:

I have to start this by saying that I am really impressed by the current state of Full Site Editing. Of course, there are areas that are still chunky. But in just over two days I was able to take my existing site and port it over to a block-based theme. And at the same time drastically reduced the amount of custom CSS and PHP needed for the site.

Reduction in Custom CSS needed

In my case, this theme probably already has one of the easiest possible designs to get converted to a Full Site Editing Theme. There are no sidebars, no complex navigation, and the entire site is a one-column layout. So I was able to heavily use color and spacing definitions in the theme.json file and ended up with a reduction of custom CSS written of 36,62 KiB. (46.4 KiB to 9.78 KiB)

This by no means is a scientific test. And I am not saying that the custom CSS I had in place before was super optimized & performant. But it comes to show how little custom CSS actually was needed to give the site back the personality it had previously without needing to write a tone of custom CSS.

Google Lighthouse Metrics

Another thing, that is kind of related to the previous point, I was very aware of while making this transition is the Google Lighthouse metrics of the site. Since I am moving all areas of the site to be block powered and reducing my custom CSS I wanted to, first of all, make sure that the accessibility score was not affected. And it wasn’t. I was actually able to improve all my stores to be in the high 90s or at 100

Custom Propertie all the things

In my previous theme, I always had a variables CSS file where all the custom properties (vars) lived. This has been removed completely in favor of using the custom properties created by the theme.json. And the benefit of going this is that the variables are changeable in the global site settings and just more exposed. Any by dropping IE11 support they also are just much more powerful because we can finally take advantage of the cascade of the custom properties and override values in different blocks.

This isn’t really an advantage that only relates to block-based themes. But since all of the styles coming from the theme.json are using custom properties in elements that already doesn’t support IE11 and therefore it just becomes easier to drop the support

Shared styling between the editor and the frontend

I’ve always been a huge advocate for the visual parity of all the things between the frontend of the site and the editor. And by using theme.json and add_editor_style to include the full frontend stylesheet in the editor makes it sooo much easier.

My site now has no custom CSS that is specific to the editor because the markup is a match and all the things have visual parity without additional effort. So that is great.

I would still love the post editor to go one step further and show all the things that are defined in the “content” section of the given template that is selected for that post. (See #more-elements-in-post-editor)

Open Questions / Ideas:

While working on this refactor there also were several things where I am left with open questions or with ideas/wishes of how things could be improved. Some of these items might be by design. Others might still be a work in progress. So take these with a grain of salt as a snapshot of what my experience was rebuilding my site and not have been super involved in Full Site Editing up until now.

I will also try to add links to Issues on the Gutenberg Repository if I find a related ticket for the items I’m discussing here.

What is the correct way of using Menus in Block Based Themes?

One of the areas I’ve been struggling with the most is dealing with Menus. And I am not sure whether that is because of my familiarity with the old system of the menu editor and having theme locations that can be assigned to navigation areas, or whether there are issues with the current approach.

My first question is how block-based themes should define menu areas with starter content. Is it correct to create a navigation with some items in it that have empty URL’s so that the user of the theme can see what the menu looks like and then needs to go into the template editor to change the menu?

<!-- wp:navigation {"itemsJustification":"center"} -->
	<!-- wp:navigation-link {"label":"Home","title":"Home","type":"page","url":"/"} /-->
	<!-- wp:navigation-link {"label":"About","title":"About","url":"#"} /-->
	<!-- wp:navigation-link {"label":"Work","title":"Worl","url":"#"} /-->
<!-- /wp:navigation -->

If that is the case does this mean that from that point on you are locked out of receiving updates for the template part the menu was located in because you have modified it? I’ll go into more detail around that in the next section (See #locked-out-of-template-updates)

How do you reuse a menu?

Another thing is how do you use the same menu twice on a site? I am very used to the idea of the structure of menus being managed separately from the visual representation of a menu location.

Let’s for example say I have different variations of my header template part. One that gets included on the index.html template and one that gets included in the page.html. Does that mean that I have to edit the items in the menu in two places now? Or should menus now be created as Reusable Blocks? If so what happens when I want the menu to be vertical in one place and horizontal in another?

Is there something that resembled the concept of a “menu location” in traditional WordPress?

What happens to menus when you switch Themes?

Finally, how do you keep your menu structure intact when you switch between themes? Since they are now part of the template that doesn’t transform over.

In “Classic” Themes if a menu location was created it may not be assigned to the correct spot in the new theme. But all you have to do is go into the menu editor and assign it to the correct location. But when it is part of the template a different theme will start from scratch.

Does making modifications to templates / template parts lock you out of recieving updates via the template / template part that ships in the theme?

I already touched on this lightly before in the Menu section, but what happens when you go into the template editor to change the background color of the header or add an item to the main navigation of the site. Are you now locked from receiving updates when the theme itself makes modifications in the header.html template part?

If I am understanding it correctly making modifications in the template editor effectively forks the template and you now have a separate version of that template in the database. And from that point on you are using that template instead of the one that is shipped in the theme.

And this is a really cool and flexible mechanism because it empowers you to make adjustments. I only fear that there isn’t really a path of how you ever are able to receive updates again if the theme adds new features or even minor accessibility improvements. And what worries me most about this is, that even traditional “content” changes like adding an item to the main navigation now are changes in the template part and therefore cause this forking to happen.

Sprcificity of styles coming from theme.json

While working on creating styles through theme.json there were quite a few instances where I needed to write !important into the style declaration in the theme.json itself.

It mostly happened when a global rule like settings.spacing.blockGap created a CSS rule with a higher specificity than a block specific rule styles.blocks.core/paragraph.spacing.margin.top.

{
	"styles": {
		"spacing": {
			"blockGap": "1.5rem",
			"customMargin": true,
			"customPadding": true
		},
		"blocks": {
			"core/image": {
				"spacing": {
					"margin": {
                                            "top":"calc(var(--wp--style--block-gap) * 3) !important",
                                        "bottom":"calc(var(--wp--style--block-gap) * 3) !important"
					}
				}
			}
		}
	}
}

I’m not sure how this can get implemented but semantically to me it would make more sense if styles that are defined on a block have a higher specificity than global rules. And you shouldn’t have to use !important rules in the theme.json unless you are doing some really sketchy things

Vertical Rythem adjustments

A pattern I’ve seen and used very often is that items that are aligned wide or full have larger vertical spacing than other block elements. Right now the blockGap value only targets the margin-top. So the workaround I used is setting the margin-top and margin-bottom value myself any time I wanted to increase the spacing. But I also needed to do that in my themes custom CSS because currently there is no selector in the theme.json to target block alignment.

Being able to target attributes like alignment would be super cool because it would allow you to scope styles to these options that are shared between many blocks.

Very verbosse usage of variables within theme.json itself.

This point is purely aesthetic, but it feels odd to me to be using variables that get created based on values set within the theme.json file within the theme.json file.

Every time you want to reference a specific color for example you are writing out the full custom property var(--wp--preset--color--primary). This has two problems in my mind.

For one there is no autocompletion or level of code hints that we can get from this approach. Which makes authoring these theme.json files a whole lot more difficult. And secondarily it locks the naming convention of the variables in because if there are any changes under the hood the references in here don’t automatically change also. There is this translation layer that transforms the theme.json and creates the custom properties for us. But we are not taking advantage of it in referencing the values.

Something like settings.color.presets.primary maybe a better way to write the same thing. It uses the schema of the JSON file and allows you to understand where the value that you are using is coming from. Without having to do the translation of the theme.json backward in your head.

I do also recognize that it is much more complicated than how I am making it out to be here and using the custom property also comes with benefits because the value of a given attribute is just a string that gets output in CSS. Effectively allowing us to use things like calc or any other CSS functions in our theme.json.

Ability to target styles and custom properties to template parts

In my example, I want to have the blockGap only apply within the actual site-content area and not the site-header or site-footer. But currently, I have to make these adjustments manually in CSS with very verbose selectors to beat the specificity of the theme.json rules.

On a larger note, I’m finding it somewhat difficult treating every single group block on the site the same. In the theme.json, there is no way of targeting specific groups.

This appears to already be discussed in issue number #27233

Difficulty discovering what attributes are available and very verbosse syntax

I’m always having difficulties finding out what block supports what attributes and which of those generate what classNames . Sadly because it is all just HTML comments there also aren’t any code hints being shown like when you create a block.

And also it just feels very redundant having to write out both the attribute and the class that would get generated from the block.

<!-- wp:paragraph {"align":"center","textAlign":"center"} -->
<p class="has-text-align-center aligncenter"><a href="https://wordpress.org">Proudly powered by WordPress</a></p>
<!-- /wp:paragraph -->

I would sometimes almost prefer to write these templates in something similar to the array syntax of InnerBlocks or only the HTML comments for blocks instead of having to write both the block comment and the markup manually.

This will become especially interesting when there are block deprecations. Is there such a thing as template deprecations?

Show more elements defined in the template within the post editor

At the moment the post editor itself still doesn’t look like what my post will look like in the frontend. This is due to the fact that elements like the featured image, post categories, publish date, etc are not shown in the post editor. They still are only metadata that can get set in the page sidebar. But they don’t visually show up in the editor.

This means that even with full site editing I’m still finding myself having to constantly switch back and forth between the actual preview in a new tab and the editor. And by seeing how nice it works in the template editor it seems like this could be fixed

In the case of my site, this here is the single.html template. And if we take out the wp:template-part and render the rest in the post editor that would be a great editorial experience

<!-- wp:template-part {"slug":"header","tagName":"header","align":"full","backgroundColor":"light-primary","textColor":"dusk","className":"site-header","layout":{"inherit":true}
} /-->

<!-- wp:group {"tagName":"main","align":"full","className":"site-content"} -->
<main class="wp-block-group alignfull site-content">
    <!-- wp:post-featured-image {"align":"full"} /-->
    <!-- wp:group {"tagName":"header","className":"entry-header","layout":{"inherit":true}} -->
    <header class="wp-block-group entry-header">
        <!-- wp:post-title {"level":1} /-->
        <!-- wp:post-date /-->
        <!-- wp:post-terms {"term":"category"} /-->
    </header>
    <!-- /wp:group -->
    <!-- wp:post-content {"layout":{"inherit":true}} /-->
    <!-- wp:group {"layout":{"inherit":true}} -->
    <div class="wp-block-group">
        <!-- wp:post-comments /-->
    </div>
    <!-- /wp:group -->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer","backgroundColor":"light-primary","textColor":"dusk","className":"site-footer","layout":{"inherit":true}} /-->

There would need to be some sort of way to semi-lock those items because you don’t want to edit the template by mistake. But with the new locking mechanism and the learnings from reusable blocks, I believe this could be great.

Wrapping up

Coming out of this experience of rebuilding my site I have to say that I am really encouraged by where things are at. There is great progress being made and I’m becoming more and more comfortable with this new way of creating themes. There are still many open questions and I’m sure there will be things that will not be 100% there at the beginning.

My goal in writing this blog post is to share my thoughts and experiences using this experimental feature at this point in time. There are likely things in my findings that I misunderstood or did wrong. Or items that have been discussed several times before.

I was, and still kind of am, afraid of wasting people’s time because I haven’t been actively involved in many of the FSE related discussions and now all of the sudden am raising all these thoughts. So I want to thank Anne McCarthy and Carolina Nymark for encouraging me to share my findings and hope that somebody can gain something from myself sharing my experience.

If you are interested in the code of my theme it is up on GitHub here: https://github.com/fabian-kaegy-org/finn

The post I Rebuild My Site as a Block Based Theme – Here Is What I Learned appeared first on Fabian Kägy.

This Post is a written version of the Presentation I gave at WordCamp Europe 2021.

There are two aspects that we will be focussing on:

1. Who are we optimizing for and what do they value most?
2. What can we do across the board to improve the experience? 

The goal we should be setting for ourselves is that the editor steps into the background and our user can just focus on the content that they are trying to share.

We are going to look at how we can achieve that goal from three different angles. 

1. How we can define who we are optimizing for.
2. Shared principals we can use to improve blocks.
3. What role Themes play in optimizing the editorial experience. 

Good editorial experience means something different to different people.

What one person might consider freeing flexibility is another’s person nightmare of complexity. 

Therefore we have to know who we are building and optimizing our user experience for.

In most of the work I am doing, and therefore what my point of view is biased towards, is building editorial experiences for client sites that have strong defined design systems. In that context it becomes much more important to have consistent elements that are shared across a team of editors. The goal these editors have is to share their information without needing to worry too much how individual elements look. That was pre determined and they now just use these building blocks to give structure to their content.

While this approach may be a great user experience for that group, another group may value really being able to adjust every single detail like border radius, column width or button color.

Based on what type of user experience we are aiming for there are different approaches of delivering on the goal of an editor that gets out of the way.

If we look at this Call to Action design for example. There are several approaches of how we can represent this content in the editor. 

When planing how to convert this design into a block the requirements we come up with may look something like this: 

• A field where the editor can enter the content on the left
• A field where they can enter the Call to Action text
• A field to chose where the CTA should link to.

If we take these requirements at face value this is what we end up with. 

And in theory it meets all those requirements. Editors can provide the content they want to share and thats it. However it fails at the goal we initially defined. The editor has no idea of what that content will actually look like to the end user. 

Ive seen it before where the solution to bridge that gap was adding a button in the toolbar that allows editors to toggle between the editing experience and a preview of the block. Or moving the editable fields to the block sidebar and using the content area to render a preview. 

These approaches come with problems though. An editor first needs to learn where, how and even what they can edit. And that knowledge does not transfer well to other blocks because they might do it differently. And there is a lot of back and fourth context switching that editors have to do. They can never just focus on the content they were trying to share in the first place.

By slightly changing the way we look at this problem we can actually solve for both of the goals we defined. Instead of trying to pull out the items that we need to make editable we can should make them editable inline. 

And this is where my earlier point about different definitions of a great user experience for different audiences comes into play. This is the point where we need to decide wether our target audience of editors values consistency over flexibility or wether they really want the ability to build everything from scratch in the way they want. 

In the case where we are optimizing for consistency we can build a custom block that uses the RichText component to make the portions of the markup we need to make adjustable editable.

We as the designer and developer have control over how a call to action should be represented and the editor can use that wherever they want. The options the have are limited to editing the content and whatever options we want to provide them with. 

If on the other hand we are optimizing for flexibility this can also be build using core blocks. And to make it easier for editors we can register a block pattern for it.

The pattern looks exactly like the design when inserted and can also be used anywhere. But it also allows the editors to modify everything to their liking.

If they want to move the button around to now be on the right or have two buttons stacked on top of another it literally just uses a group, columns paragraph and button blocks. 

So these building blocks can get rearranged to build whatever the editor wants. But keeping in mind that with great power comes great responsibility. 

Having all the options means that editors can make “bad” choices, or at least choices that may not align with the overall design language / aesthetic of the rest of the page.

Taking a step back from this specific example here. 

I am not saying that in version two where we are optimizing for flexibility we don’t need or even shouldn’t build custom blocks. 

But the blocks that we build are more atomic elements that can get used in combination with other blocks to build whatever the user wants. 

While in version one we may build more complete “molecules” to steal from the atomic design verbiage.

Principals for building blocks

Now that we have talked about the fact that there are different audiences we can optimize for, we can look at some principals for building blocks that apply across the board. Starting with the anatomy of a block.

The main content area of the block is the most important part that we need to consider. All common options should be accessible without needing to open the sidebar. 

The principal here direct manipulation of the content. 

Secondary block controls should live in the Blocks toolbar. That way they are still accessible directly without needing to look over to the sidebar.

There has been a great incentive in Gutenberg recently to unify the blocks toolbars by defining a grouping structure that all blocks should adhere to. 

That new structure defines the order and the grouping of individual actions in the blocks toolbar. This graphic is coming from the Block Editor Handbook on WordPress.org and does a great job of showing the structure toolbars should have.

From start to end the toolbar first shows block level controls, these are related to the overall block and not really specific to the content of the block itself.

Then if applicable meta level followed by general tools. These tools affect the overall block and for example alignment controls fall into this section.

The next section consists if inline formatting controls. They don’t affect the entire block but only the current selected text or position of our curser. 

At the end there also is a group of “other” settings and then the dropdown with any additional settings that are not as commonly used. 

https://developer.wordpress.org/block-editor/how-to-guides/designers/block-design/

Any controls that we also want to provide to our editors but are not key controls can be placed in the Settings Sidebar.

The goal we should aim for is that most users should not have to open the blocks sidebar at all. A block should define sensible defaults and then allow users to modify them if it makes sense. But interacting with the sidebar should not be required to using a block.

In the sidebar it also is important to group like controls together in Panels. You can see that here in the example of the Core Paragraph. We have three defined sections in the sidebar. Typography, Color Settings and Text Settings.

Also if we have settings that are really advanced that should only be used when someone really knows what they are doing we should move these settings into the Advanced section by using the `InspectorAdvancedControls` slot.

Going back to the main content editing experience there are a few things that we now need to solve for. 

How do we archive the goal of having our primary controls be inline while still staying true to what the content actually looks like?

We can achieve that by thinking of our block in one of three states, initial setup, selected and passive. 

The initial setup state something that we should try to use as sparking as possible. Most blocks don’t need this and it would even degrade the experience to it to them. 

So in general the best approach always is to have sensible defaults to get someone up and running quickly. 

But if there are actions that an editor needs to perform to get the block up and running before actually having content to edit this how we can get them started more easily.

A great example of this is the core cover block.

When the bock is first inserted the user in only presented with the controls that they need to get started. These controls get presented in a Placeholder component that displays instructions of how to get started.

The cover relies on a background being defined. And the user can choose wether they want that background to be an image or a color. 

The toolbar has some of it’s options disabled and therefore focusses on the things that are important right now. 

Once that initial setup step gets completed or once a block without this step gets inserted, the block enters the “selected” or “active” state.

The main content gets shown like it will get shown to the end user and all controls in the toolbar become available. There can also be additional inline options like placeholders, block appenders for inner block areas and other contextual controls.

In the example of the Cover block there is a resize handle that gets shown to easily change the height of the block. 

The resize handle actually is a great example of something that used to be a setting in the sidebar. But it is a primary control of the block that most editors will need to change almost every time. So it was moved into the main content area and just gets out of the way. 

The final state of a block is it’s passive state. 

By that I mean the state when the block is no loner, or another block is currently selected. That state should be a 1 to 1 representation of what the end user will see when they navigate to the site. 

As you can see here at the example of the Cover block the selected and passive state ideally are very very similar.

They both aim to show the editor what their content will look like. But while the active state may present inline controls, placeholders, block appenders for inner blocks, the passive state shows none of that and only renders the markup with the styles that endusers see on the site.  

What role do themes play in providing great editorial experiences?

And styles actually is a great transition point to start talking about what Themes can do to optimize the editorial experience.

The responsibility of a Theme in WordPress is to control how the content will be presented. That means that a theme will style how everything will look to the end user. 

But defining how things will look to the end user means that themes should also make sure that the editor reflects those styles also. The first step is to load the styles for the blocks both on the frontend and in the editor. If the blocks markup is shared between the editor and the frontend at least the individual blocks will looks as they do to the end user.

But that is not where this stops. Themes should also make sure that all text is showing the correct font, size, line height and color. That includes the representation of the page title. Themes should also make sure that the content widths and breakpoints are similar to the frontend. So if the main content area of the site has a max width, the editor should use that same width for the blocks. 

The next step is getting the vertical spacing to match. If a full width group block by default has a larger space before and after on the frontend this should also be the case in the editor. 

By doing all these micro optimisation of getting these details matching we give confidence to our editors so that they can feel more comfortable just editing a site in the editor without needing to constantly switch back and forth between a preview and the editor.

The core blocks and themes are great examples of how to do it right!

If you are ever looking for inspiration or want to see examples look at WordPress Core. 

The core blocks and themes are great examples of how to do it right!

While the blocks may not all be the correct fit for the audience we are developing for because they may provide too much flexibility in certain places, the way in which they surface controls and let you edit content inline is a great source of inspiration for whatever you are building. 

And the same goes for the core themes. Twenty Twenty-one for example comes with beautiful block patterns and really does a great job of matching styles in the editor. 

Takeaways

If you take one thing from this, it is that the goal we should be aiming for is that the editor steps into the background and users can focus on the content they want to share.

The next time you are looking at implementing a design in WordPress start by asking these two questions. 

Who will be using this? 

And what are they trying to do?

WordCamp-Europe-2021Download Next Steps:

• Take a look at all the cool components in core here: https://github.com/WordPress/gutenberg/tree/trunk/packages/components/src
• Take a look at TwentyTwentyOne: https://github.com/WordPress/twentytwentyone

The post Building great experiences in the new editor – WordCamp Europe 2021 Talk appeared first on Fabian Kägy.

The RichText component in the @wordpress/block-editor package is super powerful in general. But there is once feature that I have not really come across too often. If you want to make elemtns like for example lists editabe you can set the tagName to ul and then add the property multiline with the value of li.

<RichText
    tagName="ul"
    multiline="li"
    value={ ... }
    onChange={ ... }
/>

With that we generate the experience that every time the user hits enter, they get a new list item inserted into the text that they are working with.

The post The Power of <code>multiline</code> in the RichText Component appeared first on Fabian Kägy.

This is super exciting for me!!! I was just confirmed as a Speaker of this years WordCamp Europe. I’m super excited to get to speak about Building great user experiences in the new Editor.

If you know me already you know that this is a real passion of mine and I am thrilled that I get to share my experiences with everyone

If you want to attend the WordCamp you can claim your free ticket here: https://europe.wordcamp.org/2021/registration/

Congratulations to @fabiankaegy, @paultobey, Radost Dacheva, @no_fear_inc and @mardroid for being selected as an esteemed speaker for @WCEurope.

Claim your free seat at https://t.co/3EYHdMQTnS#WCEU2021 #WCEU pic.twitter.com/W2TE88UBrQ

— WordCamp Europe (@WCEurope) May 26, 2021

Edit:

The schedule was just released and my tallk will be on Monday June the 7th at 4:07pm CET. Find more about the session here: https://europe.wordcamp.org/2021/session/building-great-experiences-in-the-new-editor/

The post I’m speaking at WordCamp Europe 2021 appeared first on Fabian Kägy.

Every time I start a new small WordPress plugin I run into the same question. “What’s the fastest / easiest way to get working on the actually project?” And for a while now the answer for this question for me personally has been @wordpress/env.

The @wordpress/env package can get installed through NPM and offers an easy command line interface to manage a Docker Container running WordPress. To add it to a project, like a WordPress Theme or Plugin, you need to run npm install @wordpress/env --save-dev in the directory of the theme / plugin. From there you’ll need to add a new script to the scripts section of the package.json file. This script can be named whatever you want and it runs `wp-env`.

{
    "scripts": {
        "env": "wp-env"
    }
}

The last ting that needs to be done is creating a file called .wp-env.json. This file is the actual config file where we can configure the WordPress installation. We can tell it what plugins and themes we want to install and even configure globals in the wp-config.php file. All of the available configurations can be found here: https://www.npmjs.com/package/@wordpress/env#wp-envjson.

Most of the time I want to just have the WordPress install run one single plugin, the plugin that I am developing. In that cause the .wp-env.json file can look like this:

{
    "plugins": [ "." ]
}

This makes maps the current directory as a WordPress Plugin inside the Docker container.

And that’s it. All that is left from here is running npm run env start (replace env with whatever you called the script) and you will find a message in the terminal pointing you to the port on localhost where the WordPress installation is running.

Happy developing

Links:

• @wordpress/env Package

The post Using the @wordpress/env package for local development appeared first on Fabian Kägy.

Recently I stumbled upon an interesting issue when working on a Block. I used the useInnerBlocksProps hook to manage the InnerBlocks and every time I deselected the Block I got the following error:

Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops.

With a bit of research I found a recent PR on the Gutenberg GitHub Repository that mentioned exactly this problem: https://github.com/WordPress/gutenberg/pull/30274

The Solution is to not define the allowedBlocks inline but rather store them in a variable and referencing it here.

Before:

function BlockEdit(props) {
    const innerBlockProps = useInnerBlocksProps({
        ...
    },{
        ...,
        allowedBlocks: ['core/heading'],
    })

    return (...)
}

After:

const ALLOWED_BLOCKS = ['core/heading'];

function BlockEdit(props) {
    const innerBlockProps = useInnerBlocksProps({
        ...
    },{
        ...,
        allowedBlocks: ALLOWED_BLOCKS,
    })

    return (...)
}

The post Define allowedBlocks outside of JSX for useInnerBlocksProps function appeared first on Fabian Kägy.

I am happy to announce that I will be giving a presentation about building custom Gutenberg Block and how to choose between all of the various options of creating great user experiences for clients in the WordPress block editor.

The Presentation will happen on May 12th at 7pm CET. (it will be happening in German) and you need to register for it here: https://wpmeetupstuttgart.de/2021/custom-gutenberg-blocks/

Zusätzlich zu @JustPhilMarx heute haben wir schon mal die nächsten Termine auf den Plan gesetzt:

Im Mai spricht @fabiankaegy über die Entwicklung von Gutenberg-Blöcken.

Im Juni @ellenbauer und @manuelesposito über Full-Site-Editing und mehr. https://t.co/ecBbjfWdHz

— WP Meetup Stuttgart (@wp0711) April 14, 2021

Update:

Mittlerweile hat es das Video auch auf WordPress TV geschafft. Also hier für die, die es nochmal interessiert:

The post I’m speaking at the WordPress-Meetup Stuttgart (Online) appeared first on Fabian Kägy.

In February 2020 I got to attend my first ever WordCamp. A friend of mine and myself were asked wether we could give a Workshop at WordCamp Prague 2020 about building custom Gutenberg Blocks. And of course the answer had to be yes.

I took my brother with me to Prague and spend the weekend there. It was a lovely experience to meet so many interesting people and have great conversations.

Here are a few more pictures from the trip

• 

• 

• 

The post WordCamp Prague 2020 appeared first on Fabian Kägy.