ACF recently released their much anticipated update which allows for Gutenberg blocks to be easily created with included, related meta-boxes. This has vastly reduced the complexity and time it takes to make custom Gutenberg Blocks.
It’s arguable that developers should try and avoid plugin dependency as much as possible, so should the blocks be created independently of ACF, even though much more time would need to be invested up front?
Whilst it’s clear that ACF makes building the blocks MUCH easier and arguments against can be made, the article below describes the challenges associated with this goal.
Custom development of blocks and markup.
There’s some useful tutorials out there, showing how to build your own Gutenberg Blocks. Here’s some of the resources I uncovered to find out about Gutenberg Block Building:
- https://www.youtube.com/watch?v=Mv68Sa-iHyo
- https://github.com/LearnWebCode/simple-block-boilerplate (associated with the above video).
- https://developer.wordpress.org/block-editor/tutorials/block-tutorial/writing-your-first-block-type/
- https://developer.wordpress.org/block-editor/developers/filters/block-filters/#editor-blockedit
- https://www.smashingmagazine.com/2018/10/gutenberg-testimonials-sliderblock/
The authors have done a good job of explaining how to get up and running with your own blocks, what the different parts are and why they’re necessary. I have listed the resources in my opinion of how directly they address building custom blocks for Gutenberg. The LearnWebCode video was concise, accurate & I found it easy to understand. What’s more, there’s a link below the video to the LearnWebCode github account which has a repo of this very lesson.
In particular, I found the process of creating React based Javascript with https://babeljs.io to be simple and enlightening. I had never made any React code before this tutorial and the Babeljs website made the process easy and fun.
Then ACF came along and cleared all before it. The speed and simplicity of setup when using the plugin was a significant difference from the other techniques outlined above. It’s not just that it’s fast at setting up the blocks but the content and the meta boxes that have to populate the blocks is a breeze to create with ACF as well.
What is ACF?
ACF (Advanced Custom Fields) is a WordPress plugin which allows you to add extra content fields to your WordPress edit screens. These extra content fields are more commonly referred to as Custom Fields and can allow you to build website’s faster
https://www.advancedcustomfields.com/resources/
Not everyone wants to support a plugin dependency – especially a paid one – but in this case, it saves so much time in creating the blocks we’re going to need, that, at least for the MVP, it’s worthwhile doing.
~ Full disclosure, I have to confess, I do love this plugin. It’s been very useful in building all the meta content boxes’ custom fields for pretty much every WordPress site I’ve ever built. I don’t like using plugins as a rule but I’ve known ACF for years and always found it a worthwhile inclusion.
Now that a solution for the block creation has been found, I can get on with the other parts of my challenge. The blocks included by default are many. If you’re installing WordPress for yourself and playing around with themes and curating content for yourself, there could be a use for many of these blocks but since we’re not in the business of letting clients make design choices, we actually want to restrict what could be put into any given page, to make sure it fits with our markup and the layout of the site. That means turning off, or ‘blacklisting’ all the blocks we don’t want to appear as choices on a given theme. Since we also want our own custom markup on every block, so that we’re catering to a single css styles system, we actually want to remove almost all of the default, out-of-the-box blocks.
This is where the age of Gutenberg becomes an issue. Usually, the shear size of the WordPress community means that there’s lots of articles written to help with almost any subject you’d care to research but Gutenberg is so new and is being applied in all sorts of exciting new ways. It’s very flexible and it has changed a lot about the way WordPress is going to be used in the future. All this, in turn, means that there isn’t the usual number of articles describing the thing you want to find out about, so corroborating the best technique to do something can be a little more time consuming than normal.
~ So hopefully, I can save you some time:
If you’re using WordPress 5.2 or higher, you can toggle the blocks available within the page options. That’s the 3 vertically aligned dots at the top right of your edit page. Toggling blocks on and off on a per article basis doesn’t sound very developer-y though, there’s surely some programming that can be used to achieve the same thing…
This method described by Jason Bahl might be of interest:
https://jasonbahl.com/2018/05/29/whitelisting-blacklisting-blocks/
~ by his own admission, it’s quite possibly a fragile method – this article’s over a year old now but worth a read in case you come across this method in your own search. However, there may be a better way of tackling this challenge.
https://rudrastyh.com/gutenberg/remove-default-blocks.html
Misha Rudrastyh has written a more recent article about a PHP solution for custom block selection. He’s included a very handy list of core blocks you may wish to use (or not). It’s this method that I’ve chosen to be able to add/remove blocks from Custom Post Types and general site content areas.
// remove unwanted default gutenberg blocks
add_filter( 'allowed_block_types', 'llwp_gutenberg_allowed_block_types' );
function llwp_gutenberg_allowed_block_types( $allowed_blocks ) {
$allowed_blocks = array(
'core/preformatted',
'core/html',
'core/image',
'core/paragraph',
'core/heading',
'core/list',
'acf/testimonial'
);
return $allowed_blocks;
}
The first six items of the array are the core out-of-the-box blocks that we want to keep. The last is the first test block, made with ACF. Naming convention is important to show the blocks that you want. If it’s a core block, start the definition with core/, start ACF built blocks with acf/.
Full Width Gutenberg Blocks
Selecting blocks that break out of the css content wrapper are one of the exciting aspects of this technology. There’s more on preparing to add the full width aspect to your theme found here: http://jschof.com/gutenberg-blocks/gutenberg-block-alignment/
To support full width with ACF built blocks, add 'align' => array( 'wide', 'full' ) to the attributes list . Here’s what the code looks like in full for the definition of my first test block:
// ACF gutenberg blocks testing
add_action('acf/init', 'my_acf_init');
function my_acf_init() {
// check function exists
if( function_exists('acf_register_block') ) {
// register a testimonial block
acf_register_block(array(
'name' => 'testimonial',
'title' => __('Testimonial'),
'description' => __('ACF testimonial block.'),
'render_callback' => 'testimonial_block_render_callback',
'category' => 'formatting',
'icon' => 'admin-comments',
'keywords' => array( 'testimonial', 'quote' ),
'align' => array( 'wide', 'full' )
));
}
}
One page to rule them all? (maybe this goes in a later article about the wider challenge of building the sites we’re after?)
Nerdy note: If TYPO3 happens to be your weapon of choice for the majority of your sites. It has a built-in configuration language (typoscript) which means that configuration meta-data about clients, such as ‘strap-line’, address & contact details, google analytics and API codes/keys all have a natural place in the setup.ts document in the root of every site. It would surely be a good idea to have something similar in WordPress. So the plan is to make a theme options page to support the basic meta-data, that’s useful site-wide and doesn’t have one specific page that’s an obvious home for it. Typically containing everything you’d normally find in the root typoscript docs…