Static or Dynamic rendering of a block

Topics

  • Static rendering
    • How to define static rendering for a block
  • Dynamic rendering
    • How to define dynamic rendering for a block
    • HTML representation of dynamic blocks in the database (save)
  • Additional Resources

The block’s markup returned on the front end can be dynamically generated on the server when the block is requested from the client (dynamic blocks) or statically generated when the block is saved in the Block Editor (static blocks).

The post Static vs. dynamic blocks: What’s the difference? provides a great introduction to static and dynamic blocks.

Static rendering

Blocks with static rendering diagram

Blocks are considered “static” when they have “static rendering”, this is when their output for the front end is statically generated when saved to the database, as returned by their save functions.

Blocks have static rendering when no dynamic rendering method has been defined (or is available) for the block. In this case, the output for the front end will be taken from the markup representation of the block in the database that is returned by its save function when the block is saved in the Block Editor. This type is block is often called a “static block”.

Top ↑

How to define static rendering for a block

The save function, which can be defined when registering a block on the client, determines the markup of the block that will be stored in the database when the content is saved and eventually returned to the front end when there’s a request. This markup is stored wrapped up in unique block delimiters but only the markup inside these block indicators is returned as the markup to be rendered for the block on the front end.

To define static rendering for a block we define a save function for the block without any dynamic rendering method.Example of static rendering of the preformatted core block

Blocks with dynamic rendering can also define a markup representation of the block (via the save function) which can be processed in the server before returning the markup to the front end. If no dynamic rendering method is found, any markup representation of the block in the database will be returned to the front end.

The markup stored for a block can be modified before it gets rendered on the front end via hooks such as render_block or via $render_callback.

Some examples of core blocks with static rendering are:

Top ↑

Dynamic rendering

Blocks with dynamic rendering are blocks that build their structure and content on the fly when the block is requested from the client. This type of block is often called a “dynamic block”.

Blocks with dynamic rendering diagram

There are some common use cases for dynamic blocks:

  1. Blocks where content should change even if a post has not been updated. An example is the latest-posts core block, which will update its content on request time, everywhere it is used after a new post is published.
  2. Blocks where updates to the markup should be immediately shown on the front end of the website. For example, if you update the structure of a block by adding a new class, adding an HTML element, or changing the layout in any other way, using a dynamic block ensures those changes are applied immediately on all occurrences of that block across the site. If a dynamic block is not used then when block code is updated, Gutenberg’s validation process generally applies, causing users to see the validation message: “This block appears to have been modified externally”.

Top ↑

How to define dynamic rendering for a block

A block can define dynamic rendering in two main ways:

  1. Via the render_callback argument that can be passed to the register_block_type() function.
  2. Via a separate PHP file (usually named render.php) which path can be defined at the render property of the block.json.

Both of these ways to define the block’s dynamic rendering receive the following data:

  • $attributes – The array of attributes for this block.
  • $content – Rendered block output (markup of the block as stored in the database).
  • $block – The instance of the WP_Block class that represents the block being rendered (metadata of the block).

Example of dynamic rendering of the site-title core block

Top ↑

HTML representation of dynamic blocks in the database (save)

For dynamic blocks, the save callback function can return just null, which tells the editor to save only the block delimiter comment (along with any existing block attributes) to the database. These attributes are then passed into the server-side rendering callback, which will determine how to display the block on the front end of your site. When save is null, the Block Editor will skip the block markup validation process, avoiding issues with frequently changing markup.

Blocks with dynamic rendering can also save an HTML representation of the block as a backup. If you provide a server-side rendering callback, the HTML representing the block in the database will be replaced with the output of your callback, but will be rendered if your block is deactivated (the plugin that registers the block is uninstalled) or your render callback is removed.

In some cases, the block saves an HTML representation of the block and uses a dynamic rendering to fine-tune this markup if some conditions are met. Some examples of core blocks using this approach are:

If you are using InnerBlocks in a dynamic block, you will need to save the InnerBlocks in the save callback function using <InnerBlocks.Content/>.

Top ↑

Additional Resources

最終更新日: