As more folks are using the WordPress block editor, I’m seeing more than the occasional Twitter poll asking which set of blocks web builders prefer. It’s a question that makes sense, I suppose. You want to figure which set of building blocks is going to form your baseline toolset.
A lot of people like the Kadence set of blocks, though I think there’s a historical element there: Kadence had better controls available for their blocks at a time when you couldn’t do some fundamental things (like set margins for individual blocks). There’s still a delta, but you have a lot more control over the current iteration of core blocks.
Anyway, Kadence is a good set of blocks, but trying to ask which is best misses an important point: you don’t actually have to choose. You can load up Kadence but then use something else to provide specific additional blocks. You can use Kadence blocks for most things, but then use single blocks from other developers to handle the display of posts for your blog.
This is something you’d be hard-pressed to do with Divi or other traditional page builders. You might be able to buy a third-party add-on built specifically for Divi. But if you really fall in love with that Divi block and later switch to Elementor, you’ve lost the use of your fancy extra block.
Not so if you’re using the WordPress block editor, though. If you’ve chosen Kadence and you want to throw in a block that animates blocks in various ways, no problem. But it’s also no problem if you went with another block-based set of blocks, or if you’re using nothing but core blocks. So far, however, people don’t seem to be taking too much advantage of this important capability.
And there’s a bit of a complication, at least in terms of how people mentally organize blocks: if you load two of the “full complement” block sets—Kadence and Greenshift, say—you can’t (from the UI) turn off all the blocks you don’t want, at least not natively. Actually, there is at least one set of blocks that has a configuration screen for selecting the ones you want to use—a great feature but I’d love to see it as a settings page natively built into WordPress core.
The functionality for controlling which blocks are seen in the inserter is already built into both the back end and the client side of core, and if you’re willing to duck under the hood, you can set only an allowed list to show, or set a list of blocks that won’t be shown, or control things by categories within the inserter. Here, for example is code for a very short list of allowed blocks (pretty much entirely lifted from the Codex page on the subject):
function filter_allowed_block_types_when_post_provided( $allowed_block_types, $editor_context ) {
if ( ! empty( $editor_context->post ) ) {
return array( 'core/paragraph', 'core/heading', 'pz/pzvideoform' );
}
return $allowed_block_types;
}
add_filter( 'allowed_block_types_all', 'filter_allowed_block_types_when_post_provided', 10, 2 );This has the effect of, well, giving you a rather limited set of choices in the inserter:
Even if you leave all the blocks in the inserter, it’s not the problem it might seem to be, because the blocks you don’t use don’t have any impact on the front end of the site, and they have very little impact (just extra registration calls) on the back end. Certainly it can be confusing to have zillions of block choices in the editor’s block inserter panel. Once you’re fairly familiar with the blocks you’re using, though, you can just type the first few letters and have the block turn up right there.
One other potential issue is that the full-complement block plugins could at least potentially have share configuration information among their blocks in a way that might assume that if you’re using a given block X that you will also used (and caused configuration info to be set) in block Y. The thing is, this kind of scenario is pretty contrived, at least given the usual blocks one encounters, like blocks for countdown counters and information cards and text blocks that replace the core paragraph block.
PeakZebra blocks are one example where blocks do interact with each other’s data, but even there, the presence of other blocks doesn’t matter in the least. And indeed there are always lots of other blocks in play, because PeakZebra’s blocks handle pretty specialized form and table display application building, not all the other things that might be included on a page alongside them.
So don’t overlook the possibilities of mixing and matching. And don’t forget that if you need a block that does a particular, specialized thing, you can search for that capability right in the block inserter panel and see any relevant singleton blocks that WordPress.org knows about.