Block building without JavaScript: Testing ACF, Block Lab, and Lazy Blocks

Not everyone is able or willing to build blocks in JavaScript just yet, and sometimes you have to install three or four block collections until you find the blocks you would like.

There is a third way: plugins that create the blocks for you from a set of specific custom fields, with a template to control the frontend display of the blocks. The three most popular options for doing this include: Block Lab, ACF (Advanced Custom Fields) and Lazy Blocks.

My use case for this test is a small task I set out to accomplish with each of the plugins – to create a block for team members of a company that includes the following fields: first name, last name, headshot, bio, phone number, and email address and use the block on a page in a two-column display with two team members.

For each plugin I will demonstrate

  • how to create the Fieldgroup,
  • how to create the template for the frontend and
  • how to use the blocks to create a team page.

I used Local by Flywheel as my local development tool. The test site ran on WordPress 5.1.1, Gutenberg 5.4 and the Business Theme from

After reading this post you will be able to select the plugin that fits your needs.

Creating a Team Block with Block Lab

Members of the  XWP team built Block Lab and it is available as a free plugin with a commercial version. I used Block Lab first, installed the plugin and then started a new block.

Here is the video on how to set-up the fields.

The next step is setting up the block template

When I looked at the expected location, the template will be made part of the theme directory in a subfolder called /blocks/ That’s something a developer needs to remember, as there is some content lock-in when switching themes.

To create the template, I opened my code editor, created the file block-team-member.php, and added the HTML + and minimal PHP to reference the fields.

<?php block_field( 'first-name' );?> 
<?php block_field( 'last-name' );?>
<p><img class="teamphoto" src="<?php block_field( 'picture' ); ?>"
 alt="<?php block_field( 'first-name' );?> 
<?php block_field( 'last-name' );?> " width="150" style="float:left;padding:4px;margin;2px;"/>
<?php block_field( 'short-bio' ); ?></p>

<p><em>You can reach <?php block_field( 'first-name' );?></em> 
<br/>via email <span><a href="mailto:<?php block_field( 'email-address' ); ?>">
<?php block_field( 'email-address' ); ?></a></span>
 or <br/>
via phone: <span><?php block_field( 'extension' ); ?></span></p>

In the last step, I finished the configuration of this block with the Block Properties

  • I set the icon to a person,
  • selected the “Layout Elements” as Category and
  • added “team member, team” as keywords

All this is necessary for the Block inserter in the editor.

Let’s see how it works.

I added a new Page called Meet our Block Lab Team and added the team members, using the Block “Team Member”.

For now, I decided to have all the information filled within the block editor boundaries. During setup of the fieldgroup, I had also the choice to display form controls in the Block Options tab in the sidebar. For the moment, I have determined that’s it’s just personal preference. Once you click outside the block, the form disappears and the block is rendered similar to its frontend representation.

Now that I have the block finalized, I can add more team members to the page. I decided, I’d like them in a column block with two columns.

So far, so good. I was not thrilled that the location of the template points to the theme folder.

When I want to switch out the theme, I still would like to keep the block and the layout for the block with my site, so I would need to make sure to copy the blocks folder to the new theme’s directory. Another way is outlined in the  documentation for Blocklab on Github. It offers two filters to change the default location of the template:

“To use a different template inside your theme, use the block_lab_override_theme_template( $theme_template ) filter. To use a different template outside your theme (for example, in a plugin), use the block_lab_template_path( $template_path ) filter.”

This was fairly easy to set up, even if you are not a PHP developer, you can probably use the one PHP function block-field() and make sure to reference the right field names.

Block Lab, in essence, provides you with a method to create the fields and configure the block properties in one screen, and then you need to add the corresponding block template to a folder /blocks/ in your theme’s directory.  It’s fairly straight forward.

Creating a Team Block with ACF 5.8

ACF (Advanced Custom Fields) version 5.8 came out with a block builder (only available in the Pro version). For my test I used ACF 5.8 RC 1. The final release is available now.  Elliot Condon is the plugin’s author and the first version was released in 2011. The plugin has grown into a hugely popular developer tool for freelancers and agencies alike and has over 1 million installs.

Its success and versatility make the creation of the field group a more involved process compared to the other two plugins. The Pro version 5.8 contains the first release of its block building tool.

This is the admin view of the Field group “Team Member”.

Now how do I make this into a block? The documentation is comprehensive enough.  Note: In this test I went in a slightly different order…

I started with the Field Group and I needed to get back to that admin screen after I registered the block (see below) .

I  used two files. First, I needed to register the block in the functions.php of my theme. For the template/block rendering code I used content-block-team-member.php also to be stored in the active theme’s folder.

You will see how those two fit together in a second. The rest of the work is done by the plugin in the back end.

So let’s write the Block Code in PHP

The first snippet is the block registration. I gave it a name, title, a description, point to the render template, give it a category, an icon and some keywords, under which the content producer can find the block in the Block Inserter. I scrolled all the way to the end of my theme’s functions.php and added this snippet:

function register_acf_blocks() {
   // register a team member block.
       'name'              => 'acf-team-member',
       'title'             => __('ACF Team Member'),
       'description'       => __('A custom team member block created via ACF 5.8'),
       'render_template'   => 'content-block-team-member.php',
       'category'          => 'formatting',
       'icon'              => 'admin-comments',
       'keywords'          => array( 'team member', 'team' ),
// Check if function exists and hook into setup.
if( function_exists('acf_register_block') ) {
   add_action('acf/init', 'register_acf_blocks');

This code is straight from the documentation and I just changed a few values.

In the next section I created the block rendering template. The file name needs to match the “render_template” attribute in the above text, which is “content-block-team-member.php

I also just followed along ACF’s documentation and only changed a few values and updated the display code.

// create id attribute for specific styling
$id = 'team-member' . $block['id'];

// create align class ("alignwide") from block setting ("wide")
$align_class = $block['align'] ? 'align' . $block['align'] : '';

// Load values and asigning defaults for the block fields.
$short_bio = get_field('short_bio') ?: 'the short bio goes here... ';
$first_name = get_field('first_name') ?: 'First Name';
$last_name = get_field('last_name') ?: 'Last Name';
$image = get_field('picture');
$email_address = get_field('email_address');
$extension = get_field('extension');

" class="team-member ">

" alt="" alt=" " width="150" style="float:left;padding:4px;margin;2px;"/>

As I started with the Fieldgroup, I needed to go back and make sure that the group is associated with the block I just registered.  Below the Fieldgroup screen I created a rule for the Location: It needs to read: “Show this field group if the Block is equal to ACF Team Member.  

Now let’s see how this works in the Block editor when I add two members.

It was an interesting experience. You can use the form in the editor section to enter the data. Another option is to enter the data in the form fields available in the the sidebar and you see the block update in real time. You can toggle between the two methods but clicking on the Button “Switch to Edit” or “Switch to Preview” depending which method you are using right now.

The block editor UI works well. It’s worth going through the more elaborate setup and code necessary.

Creating a Team Block with Lazy Blocks

The third plugin in this test is called “Lazy Blocks” by Nikita of, the same team that also published the GhostKit block collection.

It not only allows me to store information in post_content but I also get a choice to store it in the post_meta table.

Here is a video of using the interface to create the fields.

As this admin screen is focused on getting all the information to create the blocks, on the left I created my fields and in the sidebar.  I filled in the information needed to register a block with the editor.

Underneath,  I was able to add the HTML for frontend and backend. The syntax is even easier than Block Lab, and of course much easier than ACF’s  templating.

I didn’t need to add any code to my theme’s functions.php nor did I need to create additional files with my template code.

You can add it all right here, aided by syntax highlighting and merge tags rather than function calls.  The documentation shows multiple ways to write your template code. I am definitely a fan of Handlebars (semantic templating) as it is in this context much closer to other systems’ merge tags.

I copy/pasted the same code into the “Editor HTML” tab, so I could see the frontend display below the form fields.

Let’s use it.

This seems to work. It was little bit awkward that the form didn’t disappear when I unselect the block. It takes up a lot of real estate in the editor. Although, I wanted to have the team members in a two-column block, I did not succeed in dragging and dropping the two blocks into a Column Block. I mentioned this in my support topic and nK answered: “…hiding controls when the block is not selected is a good feature, that already added in ACF Blocks and will be added in Lazy Blocks soon.” Here you have it – all in due time.

Conclusion: Complex, Evolved, or Easy.  

ACF 5.8  has a very robust block building feature, and every one who has been using the plugin to build sites will be very happy to be able and create dynamic blocks for their customers. It’s well thought through, and developers of all skill sets will get up and running quickly.

Someone, who is not well versed in PHP will have her fair share of trial and error to get it all going. It will get even more complicated when the requirements for the blocks get more involved and beyond this test’s use case. This is not a tool for WordPress beginners or DIY site implementers who don’t write a lot of code themselves.  

For now, only the ACF 5.8 Pro version comes with the block builder feature. Condon is contemplating making it a stand alone plugin. (See what the Twitteratti think about the idea… )

Block Lab is in its early stages of development. It succeeds in abstracting most of the block architecture and reduces the amount of code that needs to be written. The documentation is very helpful. The template is stored in a separate file, and needs to be maintained with the rest of the theme files. If we at my company would use it for any of our projects, we would store the template file with one of our helper plugins, so our customers are able to switch themes without losing the content and display of the blocks built with Block Lab.

The Pro version boasts additional features, such as repeater fields, import/export of blocks, user object fields, map field and many more block features.

XWP is an agency working with enterprise clients on the VIP hosting and other corporations. Their team members are contributing to other big ideas in the WordPress space, including the Customizer,  AMP and Tide. I expect the plugin to stay around and grow with Gutenberg Phase 2 into a robust system for site implementers, agencies, and theme developers.

Lazy Blocks is a delight to set up and as mentioned, I am a fan of the Handelbars templating syntax. It’s easy to learn even for beginners, and with a little practice, a site owner would be able to create specific Gutenberg blocks for their site. The block handling in the editor although functioning, is a little clunky, as the display doesn’t switch between block select state and unselect state at the moment.

If there is a requirement of having additional fields for a page or a section of a post, Lazy Blocks is a great tool to prototype and get quickly from idea to proof of concept.

The only caveat: I was not able to find out who the people are behind and the name Nikita. The website only reveals that it is a young company but nothing more. If you use the plugin, make sure you have Plan B in place just in case the developers abandon the plugin before it takes off.

ACF 5.8 is quite complex; Block Lab is a very flexible and only semi-complex; and Lazy Blocks is adequately named and the easiest to use. None of them lets you get away without writing code, as each block needs some display output in HTML.

Let me know what you think about these three block generating plugins. Also, if you found another plugin that allows you to build blocks without getting into Javascript, I want to know about it! Please share your thoughts and discoveries in the comments!


24 responses to “Block building without JavaScript: Testing ACF, Block Lab, and Lazy Blocks”

  1. Birgit, thanks so much for taking the time to review Block Lab and put this article together!
    Glad the docs on changing the template path were helpful for you. Quite a few people ask about this so it’s something we’re looking at adding as an in-admin option in the block builder screen.
    In-admin templating is also on our radar for this year as well.
    Thanks again. Love your work! :D

  2. At some point I’ve tried all 3 solutions, and settled for ACF for many reasons. There are some very important details missing from this post that many might find helpful. While ACF does not yet support inner blocks, so building sections, containers, columns etc…, are challenging, as a field you can use the whole TinyMCE editor (classic editor), and that’s how I build my sections and containers. Last time I checked, Lazy Blocks has a field to have inner blocks, but does not have the ability to use the classic editor. The classic editor at this point can be very useful as it has the toolbar to generate shortcodes from themes and plugins.

    The most important thing though is that ACF has tons of development documentation, tutorials, and videos all over the internet, and the ability to create layouts not just for the front end, but the backend that looks like a professional block, and not a sloppy, cheap looking block, which is 99% of the cases found today. You can accomplish excellent backsite design results because ACF has the ability to go from edit to preview modes, either manually or automatically, and have the option to organize your fields with Tabs, Accordions, and columns with variable widths.

    However, the biggest plus for ACF is the developer – Elliot Condon. I dealt with him numerous times in the past months, reporting bugs and suggestions to him, and he was always polite, answered in a timely manner, very accommodating, despite the fact that he only recently got married and had a child just a few weeks ago… His pricing, and licensing conditions of the Pro plugin, are one of the most fair and generous deals one can find in the marketplace, and that’s the cherry on the cake…

    Handlebars (used within Lazy Blocks), is easier to learn and use that php, but at the same time, very limited, if you want to create some complex blocks.

    Any of those solutions beats making blocks with React and Javascript, and you don’t have to worry about a million new things to learn and deal with, and when making changes to existing blocks, deprecating things… life is too short !!!

    • RE: PHP vs. Twig, I’ve used Twig within ACF blocks, often in conjunction with the Timber plugin. The PHP file that is used to display the block just needs to gather the data for the Twig template and then render it. It adds a bit more complexity (and two files, a PHP and a Twig, per block) but as Twig is pretty easy for folx to mess with, it’s been a good solution for me.

  3. Great review of all 3 tools. ACF for me clicked because of the credibility of ACF framework as a plugin. And also it’s most intuitive among other tools. It is has huge UI controls already built to make the Block building much easier. It has a lifetime license which is a huge plus. I’ve already built a plugin on top of it, which could be a great source of ACFBlocks examples for developers getting started with ACF.

  4. I think that all three solutions have their place, and it is important to have various alternatives available. “Competition” is also essential and always a good thing for the end user.

    One thing I wanted to add, ACF is also the product of a single-person developer, as is Lazy Blocks. So technically, ACF can also go out of business. Only Block Lab is developed by a team.

    Though, I fully agree that it makes not much sense to hide your name/personality when you are releasing such stuff. Fair enough, there might still be reasons I am not aware of, sure, but I can only but recommend to be bold and also stand with your name and personality behind your product, even if it is a free plugin you are doing. I speak from my experience since 2011 (when I started with plugins) and I have only made good experiences. It helps people to better make “the digital handshake” and have more confidence in what you are doing. And ACF is the best example for that on a bigger scale :-)

    Whith that all said, I already integrated all of these 3 solutions into my Toolbar Extras plugin as well, so you get quick jump links from the Toolbar to the various settings and post type admin pages etc. Can help in day to day work.

  5. All these plugins are nice, but as far as I know they don’t have the option to export created blocks as PHP/JS code so they can be used without the plugin. Something like but for blocks would be really cool.

  6. Good article. “What, no react coding?” some will ask.

    The example is however a limited one.

    Mots blocks I have made (with Block Lab, my simple favourite) contains a loop and no data entry, only search and ordering criteria and layout options. Like looping through a custom post type to create a list, a table or flexible boxes with data from the CPT and the custom fields of each.

    Like listing the departments or subsidiaries of a larger company or organisation (address, map, phone, email, link, number of employees etc). Data is maintained in the CPT, how and what to display in the block. That’s powerful. Before: shortcode or page template, now a block with a template that can be combined with other page/post content in any way.

    In Block Lab it’s very easy to change the location of the template to a plugin you make, which is also the right place to store it.

  7. Hi Birgit,

    Can you post the code sample for the ACF content-block-team-member.php file again. It seems to have pasted funny with a number of > characters added. It didn’t render right when I tried it out. My php is patchy as I only delve into it when needs be.

    Much appreciated

  8. Great roundup! When I found out Gutenberg was going to be JS based I was concerned about the difficulty of using the new APIs to create Blocks based on my past experiences learning the post meta, Customizer, and settings APIs.

    When BlockLab came out I got a huge confidence boost that much of my PHP knowledge could be retained and was able to see just how open Gutenberg was to development.

    Once I got started, I learned very quickly that it is possible to write Blocks with simple JS and that the well-documented WordPress Handbook is the underrated holy grail for Blocks development.

    The custom controls that require so much code to create in the Customizer, settings, and post meta API can be done with a few lines of JS, and without the hassle of data sanitization is a HUGE deal.

    While these plugins make the barrier to entry into Gutenberg development easier, and they have helped me, I would encourage anybody in the business of custom Blocks to give the Blocks JS API a shot and see what is possible on your own; you might be surprised at what you can accomplish!

  9. Not reviewed here, but certainly a viable PHP-only option for creating a block is Carbon Fields.

    A quick comparison:
    – Carbon Fields has no UI within the admin area, which means that the creation of a block is only accomplished via code in a plugin or theme.
    – The creation of the block itself is very easy and follows the same pattern that the rest of the library uses to create meta boxes, widgets, theme options panels, etc.

    I’d love to see the folks at HTML Burger mentioned in the same vicinity as some of the other solutions mentioned above. Their product is comprehensive, easy to use and totally free. :-)


Subscribe Via Email

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

%d bloggers like this: