Building Blocks - What is your strategy?

[cim]

I recently saw This 4-level plan to build blocks and it seems to me like a good approach:

---

(Victor Ramirez Sep 2020)

Level 1

• Style the editor and core blocks to match the client theme.
• Disable custom colors & fonts to keep the client on brand
• Disable all core blocks your client doesn’t need per post type. Too many options are confusing. (Optional)

Level 2

• Customize the core blocks by adding block styles (think body styles on a car)
• And extend existing functionality
• Example: You don’t need a custom testimonial block. You need a block quote with a custom style and link attribute!

Level 3

• Build Gutenberg block patterns by grouping together core blocks and styling with CSS.
• Pro-tip: also disable columns. They’re too messy & your patterns can cover these.

We still have not created a custom block, installed any plugins, or added dependencies

Level 4

• Build custom blocks via ACF. We are only adding ACF for ease of use. Fields, custom post types, taxonomies, & user roles are all core WP.
• Less time training developers, training users, & maintaining systems (the hardest part!)
• 6-Step Guide To Custom Post Loop Gutenberg Blocks by Joey Farruggio

---

But I am really curious to what strategy people on this forum have to build their block themes.

For instance, do you:

1. Build blocks yourself a lot?

2. Build them with ACF-composer or something else?

3. Use block patterns?

4. Use block plugins? Which ones? (e.g. Kadence blocks seems pretty good at a first glance).

5. Have some general advice/lessons you learned?

I’d love to learn from you!

[cim]

Oh well, I guess I’ll just have to live on in a state of perpetual curiousness

[aitor]

I’m in a early stage of the block developing learning path. I join your questions.

[brinkofblink]

Likewise, I’m new to block development and React. Though I’ve used Vue a fair bit so the concepts are familiar. @cim I really appreciate the resources you linked.

I’ve opted to build blocks myself but sifting through the docs is exhausting!

We build websites for clients, so I’m trying to make the experience easy and useful for them, while keeping some consistency.

A couple of useful parts it took me a while to find:

• limit controls on existing blocks using theme.json. Such as removing the border radius controls.
• Add different versions of core blocks using css classes. Such as creating a few predefined button styles.

I’ll almost definitely be creating some block patterns after creating the blocks I need.

The main lesson I have learned is that it’s really hard to find definite answers about the right way of doing things because so much has changed with blocks in the last few years!

Sage makes it easy to register block scripts and styles using the editor.js and editor.css files. And Log1x/Poet makes using the blocks on the front end easy. It doesn’t handle registering the block types in the editor js though.

[EHLOVader]

I too am interested in what others are doing, and am new to working with Gutenberg in themes. I think you compiled a lot of great resources. Like brinkofblink said I didn’t see block styles but registering them and unregistering them are useful, I’m still learning more about that.

I think that limiting the blocks is good, and you can also while creating blocks limit the blocks available to add to the innerBlocks. I’ve used that for content panels where I have an image alongside content that could have headers, copy, and buttons.

I do use ACF blocks for those types of things sometimes, especially when there are properties about the content blocks that I want custom inputs to control, above and beyond the typical styles.

I think Log1x/acf-composer is really great for that.

Also mentioned later are block patterns, that is a way to provide predefined structure. brinkofblink also mentioned Poet which I think is a good option. But I am not a fan of configuring those things in the php config files. I like a fluent functions or classes, and each element having a file so I load my block patterns in through a file glob, like the Fields folder. That said the php configuration is a lot better imho than all these json configs, I don’t like the direction we are going with those.

@brinkofblink

Sage makes it easy to register block scripts and styles using the editor.js and editor.css files. And Log1x/Poet makes using the blocks on the front end easy. It doesn’t handle registering the block types in the editor js though.

Poet doesn’t register the blocks or patterns in the editor.js however it does register them I thought, through php. you can register them through php now and it may switch to always doing it that way, someone where I found this said that would be the case, but I don’t think we are losing the client side stuff.

One thing to note with the unregistering is that you can’t unregister things registered in JS through the PHP api, so that might be an important consideration.

[cim]

Thank you!

It’s good to see some people chime in! Let me join you with a few things I learned/experienced during my first steps in the world of blocks

• I define a color palette, breakpoints, font sizes etc for a theme in tailwind.config.cjs.
  If I want I can get access to for instance the tailwind breakpoints in js files:

import tailwindConfig from '../../tailwind.config.cjs';

//aplication code
console.log(fullConfig.theme.screens.md);

I also define the same color palette and font sizes in theme.json. (I hope to figure out some day how I can define a color palette in one place and use it everywhere, including in ACF color pickers).

• I tend to set $mode in ACF-composer to auto instead of preview for my ACF-blocks. I have the feeling this is more intuitive for clients because it means they don’t have to manually switch between modes, or ’ discover’ the fields in the side menu to add content. Plus it gets messy quickly in the side menu when using repeaters or many fields.
  I also add sample content for blocks that don’t have content yet. E.g. a gray block or picture with the text Click here to add an image

• (In the meantime I am still trying to figure out how to make use of inner blocks in ACF blocks, because inner blocks only work in preview mode I believe. Also, you can only have one inner block per ACF block, so you have to nest blocks if you want to have multiple inner blocks).

• Become better at understanding what blocks can do by trying to create complex layouts without coding. Watch this: Nick Diego: Builder Basics – Designing Advanced Layouts with Core Blocks (July 15 2022)

• Finally I actually enjoy building my own blocks, but I am also asking myself regularly: am I reinventing the wheel and are existing blocks (core or plugins) not the way to go in most of the cases?

[igor_sumonja]

For tailwind colors to sync with theme.json I use this…

“@_tw/themejson”: “^0.1.2”,

It basically sync all colors you define in wordpress theme.json and add it to color option of tailwind classes, so you can have like one source of truth for colors…

Regarding the theme development my workflow is the following…

1. keep only core block I need like paragraph, headings, list…
2. remove all layout block like columns, text-media, I only leave group block as it is super usefull sometimes…
3. remove gutenberg styles from frontend

I have coded my own version of text media block in JS which I use for two columns layouts, the styling is non existing so I just add whatever styling I need in my current theme. Sometimes I also add block styles there so I have like 2-3 version of styling for 2 column block… I used to have this done as ACF custom block before with InnerBlocks but having this in JS is much better experience for user. ACF blocks tend to be slow on editor sometimes…

I do also ACF block as per need in theme design with awesome library “mwdelaney/sage-acf-gutenberg-blocks” that make process of making all blocks a breeze. Making all blocks with JS is just not profitable to me as I would need too much time to implement all this… For block I need like 5 minute in ACF that had repeaters, images, buttons and even sub repeaters I would need like day if not more for same block in JS…
So I just combine them and leave the ACF blocks in the auto mode, so when user click away it can see the design but on click inside the edit mode appear… Client don’t really ask why some block behave like this so it is not big issue to me…

For backend styling I tend to make it as close as possible to frontend but not going into too much details, I just reimport the scss file from frontend for that block and fix some small stuff if it look super bad, as editor sometimes have different structure than front…

[aitor]

This answer from @kellymears might be helpful in keeping the blocks organized within the theme.

Bud config for outputting multiple css files (from scss for ACF Blocks)

Personally, I’d keep the blocks grouped by domain. It’s easier to work with. My example uses this structure: ├── app │ ├── blocks │ │ ├── block-a.php │ │ └── block-b.php ├── resources │ ├── blocks │ │ ├── block-a │ │ │ ├── index.css │ │ │ └── index.js │ │ └── block-b │ │ ├── index.css │ │ └── index.js Here is the asset mapper I came up with: const {basename, join} = require('node:path'); const {globby} = require('@roots/bud-support'); const ma…

[brinkofblink]

I’m finding it nice and easy to get stylesheets for custom blocks on the front-end.
Not finding as simple to get some of the built-in styles working.

Does anyone know if there are any classes we have to provide for built-in gutenberg stuff as theme developers?

For example, when I’m using the Align feature on blocks like Cover, the alignwide class is added and the styles work in the editor but not on the frontend. Is this the correct behaviour or should WP be adding this?

[igor_sumonja]

You should be resposible to make sure all WP classes work as they cannot add it to frontend as each theme structure is different, so it is impossible to implement alignwide class out of the box…

[brinkofblink]

Ok thanks. Are you aware of any lists of WP generated classes which a theme has to support?

I found this page on wordpress.org which lists wp core generated classes but can’t find anything similar for blocks.

It seems some css comes down the wire with the blocks and some doesn’t. Another example is a gallery inside a columns block. The top level column styles work as expected, but the 2-column gallery inside doesn’t. All looks fine in the editor, but is missing on the front-end.

[igor_sumonja]

Are you sure that you are not removing the styles withing themes ? Gutenberg core block should work on frontend same as on backend if you haven’t removed styling but the align wide and align full supportd need to be added by theme… Evertyhing else should work unless you removed the styles yourself with filters…

[AlexHay]

I follow an almost identical method to Igor for working with blocks.

In case it’s helpful, i’ve found ‘Disable Block Editor FullScreen mode’, ‘Resizable Editor Sidebar’ and ‘ACF Autosize’ helpful for making ACF blocks a bit easier for users to edit. We default blocks to preview but let users toggle to edit mode.

ACF have announced changes to the ACF block system in v6 which suggest our previous method of adding blocks is technically going to be legacy. Mwdelaney’s repo hasn’t been updated in years so i’m moving to acf-composer/poet which offers quite a few more features and is actively maintained.

One thing I would be curious to know is how you guys integrate Tailwind into your workflow? I love building blocks from scratch using Tailwind, but i’ve found some frustrating drawbacks in the backend; primarily with default Gutenberg styling overriding utility classes due to greater specificity. I use Tailwinds important option to fix this but it feels dirty.

I feel like Wordpress are making it harder to develop themes from scratch, but when you’re trying to make pixel perfect designs, just working with block styles and css tweaks isn’t enough.

[cim]

@AlexHay

I use Tailwinds important option to fix this but it feels dirty.

I also decided to do this in the end (after reading this), but I don’t like it either

[cim]

@AlexHay

In case it’s helpful, i’ve found ‘Disable Block Editor FullScreen mode’, ‘Resizable Editor Sidebar’ and ‘ACF Autosize’ helpful for making ACF blocks a bit easier for users to edit. We default blocks to preview but let users toggle to edit mode.

Those are good tips. I think I prefer auto mode when the edit view is roughly the same size as the preview, and preview mode in other cases. But maybe a consistent experience for users is better…
How do you deal with blocks that have a lot of fields/repeaters? In my experience that can get messy in the sidebar.

[igor_sumonja]

Now you got me worried with new block API, but look like API 2 is opt in, so your block must declare support and “old” block would still work. I also installed the ACF PRO 6.0 RC1 and don&y see any breaking changes for now, one thing with Gutenberg is that it is constantly evolving.

I will keep using Mwdelaney’s for now, but for next project will have a look at poet if they update support to block API 2…

Not sure why are you having issues with CSS or how good the backend should look for you but I don’t have any big issues with editor look, I usually just make it to look similar to frontend I don’t chase pixel perfect background

[brinkofblink]

@AlexHay

One thing I would be curious to know is how you guys integrate Tailwind into your workflow?

I discovered that the theme.json supports css custom properties so I’ve been extracting some Tailwind styles like colours and font sizes into a scss file which I then import into editor.scss. I then define them in the theme.json like this:

"palette": [
    { "slug": "grey-100", "color": "var(--color-grey-100, #141413)", "name": "Grey 100" },
    { "slug": "grey-200", "color": "var(--color-grey-200, #58484E)", "name": "Grey 200" },
    { "slug": "grey-300", "color": "var(--color-grey-300, #6A6D72)", "name": "Grey 300" },
    ...    

and

"fontSizes": [
    {
        "slug": "xs",
        "size": "var(--font-size--2)",
        "name": "XS"
    },
    ...

Still end up with duplicate classes but this way the tailwind config is the source of truth.
That said, we’re only using Tailwind sparingly, rather than for all the styling like in this talk: https://www.youtube.com/watch?v=5uhIiI9Ld5M

The script mentioned in the talk to extract tailwind classes into scss is here: https://github.com/hankchizljaw/CUBE-with-tailwind

[tedw]

FWIW been using this for a few years to speed up custom block dev and it’s been great!

GitHub - MWDelaney/sage-acf-wp-blocks: Composer library for generating ACF...