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.
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.
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.
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.
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';
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).
For tailwind colors to sync with theme.json I use this…
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…
keep only core block I need like paragraph, headings, list…
remove all layout block like columns, text-media, I only leave group block as it is super usefull sometimes…
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…
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?
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.
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…
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.
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.
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
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: