Blocks

Principle

Pages are core blocks and patterns. A custom block exists only when a core block cannot express the component. The block still renders when an optional plugin is missing.

Why

Note

A custom block is a maintained product. Core blocks, block styles, and patterns are already in the editor. register_block_style() covers most visual variants.

get_field() and the same family of calls are plugin functions. A call with the plugin inactive is a fatal error, and the front end stops while the header is still rendering.

How

1. A core block, plus a block style registered on that block for a visual variant.

   functions.php

   register_block_style( 'core/button', array(
       'name'  => 'brand',
       'label' => 'Brand',
   ) );

2. A pattern: registered markup made of those blocks, which an editor inserts whole.

3. A custom block, as a directory with a manifest and a render template.

   blocks/text-and-image/

   block.json
   render.php

   block.json

   {
     "name": "theme/text-and-image",
     "title": "Text and image",
     "render": "file:./render.php",
     "supports": { "html": false, "align": ["full"] }
   }

Registration walks blocks/*/block.json. A hand-maintained list drifts from the folders.

supports.html is false when the block owns its markup. align is limited when the block owns its width.

Field groups are JSON in the theme (acf-json/ or the plugin’s equivalent), named after the block. A hash filename is harder to review. render.php reads the fields and passes them to a template part. Output is escaped. A heading component takes the level as an argument. It does not always print h2, and it does not echo raw editor HTML.

A plugin function is guarded. The template still renders when the function is missing:

render.php

$heading = '';
if ( function_exists( 'get_field' ) ) {
    $heading = (string) get_field( 'heading' );
}

The same guard covers have_rows(), the_field(), and any other plugin API. A block that means nothing without that plugin has the plugin in the image. It is not an optional activation.

A classic theme may use PHP for the document shell. A numbered template per campaign (01-hero.php, 02-pricing.php) is a second composition model beside the blocks. A block theme does not call remove_theme_support( 'block-templates' ). That call belongs only to a classic theme that uses blocks inside post content and nowhere else.

How to check

Tip

grep -R -l -E 'get_field\(|have_rows\(|the_field\(' --include='*.php' . \
  | while read -r file; do
      grep -q "function_exists" "$file" || echo "unguarded $file"
    done

for dir in blocks/*/; do
  test -f "${dir}block.json" && test -f "${dir}render.php" || echo "incomplete $dir"
done

The guard check is per file, not proof that every call sits inside the if. Any path it prints gets opened.

Avoid

Danger

An unguarded get_field(), have_rows(), or the_field(). The request fatals.

A heading partial that always emits one level, or that prints editor HTML with escaping disabled.

supports.html set to true on a block that also tries to own its layout.

remove_theme_support( 'block-templates' ) in a block theme.

A parallel set of PHP page templates that duplicate what the blocks already compose.