Build Editor Blocks for Clients With the Genesis Custom Blocks Plugin

In early September, WP Engine announced the launch of Genesis Custom Blocks, a block-creation plugin made possible by its StudioPress team. The concept should feel familiar to developers who have made use of Advanced Custom Fields and similar plugins. However, the focus of this new plugin is entirely on blocks.

The plugin is more of a framework than a plug-and-play extension for WordPress. It requires some PHP knowledge to handle the front-end output. The goal is to make it easy for developers to create custom blocks without JavaScript knowledge. It allows them to render blocks on the server-side via custom templates.

Genesis Custom Blocks handles all the dirty work on the backend while leaving the basic PHP, HTML, and CSS of the front end completely up to developers.

The plugin seemed to slip through the cracks of the plugin directory’s guideline against frameworks — the Plugin Review Team started disallowing new framework-type plugins in 2016. Team rep Mika Epstein confirmed that the plugin should not have been approved. She also said that she would talk to the developers, explain why it’s not good, and see about finding a path forward.

Setting guideline issues aside, the plugin is a nice addition to the toolbox of any developer who needs to quickly knock out custom blocks for clients.

How the Plugin Works

Genesis Custom Blocks is currently a lightweight field manager for custom blocks. It provides an admin interface for creating, editing, and managing those blocks. Developers use this interface to essentially create block options in which a user can configure via the editor.

The free version of the plugin includes 13 standard form fields, such as text, image, URL, color, and more. The commercial version includes an additional six field types and allows users to import or export their custom blocks.

Genesis Custom Blocks block-editing screen.
Editing the test block included with the plugin.

For the block to output anything on the front end, the developer must create custom templates and use the Genesis Custom Blocks API. This template will render the output in the editor too, at least until the user clicks on the block, which takes them into editing mode.

Editing a block from Genesis Custom Blocks in the WordPress editor.
Inserting and editing a custom block in the editor.

Without anything other than a cursory reading of the docs, I was able to build a custom block and its associating template in minutes. What makes the plugin stand out is the simplicity of its system. It does not try to do too much. It provides enough basic fields for most developers to create the custom blocks they need for clients. I am certain that many of them will get a ton of mileage out of it.

It also does the extra things that developers should expect from a StudioPress-caliber product like allowing developers to create custom block categories, pick an icon, and set up keywords for each block.

One missing element is the ability to set custom blocks to full and wide-width. Developers may need to write custom CSS for both the editor and front end to handle such use cases. They can create custom inspector (block options sidebar) controls for width or alignment too. However, it would be a nice bonus if the plugin handled the standard WordPress alignments.

The Big Problem

The plugin commits the greatest sin of WordPress development. It fails to prefix or namespace its custom functions. It is a mistake that is expected of rookie developers. However, for a seasoned company such as StudioPress to create block_field(), block_value(), and similarly-named functions in the global namespace is almost unforgivable.

The problem this creates, particularly given the size of the Genesis development community, is that it is basically stealing potential function names from WordPress. If the core platform ever decides to add these functions, fatal errors will ensue on 1,000s of sites.

If the functions were limited in scope to the plugin itself, it would be an easy fix. However, these functions are meant for direct use by developers who are building with the plugin.

Given the plugin’s short time out in the wild, I hope the development team reconsiders their naming scheme and transitions it to something that does not run the risk of a future fatal error.


8 responses to “Build Editor Blocks for Clients With the Genesis Custom Blocks Plugin”

  1. Besides the Framework issue, I don’t really understand at all how this plugin was approved with those function names. The prefix rule is fairly straightforward.

    Aside from that, I have to admit I’m not really a fan of these types of plugins that just embed forms in the block editor. It completely takes way from the idea of WYSIWYG and what really makes Gutenberg special IMO.

    It is also distressing to me that developers still aren’t taking the time to learn JavaScript and build native blocks.

    • There is a clear need for dynamic blocks, even in WordPress itself (e.g., categories, latest posts, etc.). Genesis Custom Blocks is a great option for building those.

      I do agree that much of what will be built with plugins like these would be better handled as static blocks via JavaScript. However, there is also the transitional period to consider. These types of plugins help many developers move beyond their old methods and to plant a foot in the block world. While it’s not the ideal way to build blocks, it is a step that many might not have otherwise taken.

  2. I’ve found the learning of JavaScript intimidating and unclear even where to start. I’ve experimented with ACF Pro’s Blocks and tried out Genesis Custom Blocks recently.

    I figured out how to distribute a block and its field definitions in a plugin:

    It doesn’t seem as heavy as ACF Pro so it might be an option for those, like me, that aren’t quite ready for the jump to pure JavaScript block development.

  3. I’ve tried out this plugin, and it’s easy to create blocks for those of us who don’t know much javascript, but are able to use PHP.

    While creating a block uses only fields, the block developer is supposed to create a template to display the fields in both the front and backend. So it does become WYSIWYG, at least the way I did it, it was. The fields are simply the controls that most blocks have in the sidebar, but they appear in the editor content when you click to edit the block.

    I’ve also used ACF, but this just seems lighter to me, if I need to create a custom block for a client.

  4. I have been using Block Lab a couple of years. This is it’s successor.

    The main point is to avoid making custom shortcodes and as client to insert them. The second point is to avoid page templates for something that can be templated by just one block, or a group of blocks (in columns and such).

    Server rendered blocks are important in a transition phase over many years. And many prefer dynamic blocks to be rendered on front without javascript.


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.