← All posts

FanCoolo WP 1.5.0: Static Gutenberg Blocks Written in PHP

fancoolo

When you write a Gutenberg block in PHP, it is a dynamic block. The editor does not know its markup until PHP renders it on every load. FanCoolo WP 1.5.0 can now store that output as static Gutenberg blocks, so you still write PHP and HTML but get the saved markup of a React-built block. This release also adds symbols you can edit per block, WordPress values for symbol attributes, attribute autocomplete and a few UI changes that were often requested.

UI updates: full screen and a context menu

In earlier versions the FanCoolo editor could overlap the WordPress top bar, and managing many blocks took a lot of clicks. The editor now sits below the top bar. If you need more room, switch to full screen, and press the same button again to go back to the dashboard.

Each block in the left list now has a three-dot context menu with:

  • Duplicate
  • Rename
  • Export
  • Delete

You can also multi-select blocks, so you can delete or export several at once.

Static output for PHP blocks

Every dynamic block costs extra work. Gutenberg stores only a placeholder comment and has to call PHP to find out what the block contains. A block written in React saves its full HTML into the post instead. FanCoolo can now do the same for blocks you write in PHP.

The demo uses a simple DPlugins card block:

  1. Create a block and write its markup in the Content tab, e.g. an <h2> inside the wrapper div.
  2. Insert the block on a page. In the page's code editor it shows up only as a self-closing comment: <!-- wp:fancoolo/dplugins-card /-->.
  3. Go back to the block in FanCoolo. In the Settings panel, scroll to Static Output and turn on Store the rendered HTML.
  4. Click Save, then reload the page editor.

The post now contains the full block markup:

<!-- wp:fancoolo/dplugins-card -->
<div class="wp-block-fancoolo-dplugins-card">

    <h2>Dplugins Rulezzz</h2>

</div>
<!-- /wp:fancoolo/dplugins-card -->

Gutenberg now knows the whole structure up front, just like a native static block. On the front end the block no longer needs a PHP render to output its HTML.

When not to make a block static

Not every block can be static. If a block runs a query loop or pulls data that changes, such as the latest posts, saved HTML would go stale and show old content. For this there is a Re-check button under Static Output. It checks the block's template again and tells you whether the block can safely be stored as static. Use it when you are unsure.

Static blocks still support attributes. In the demo, Marko adds a Text attribute named Title with the default Marko in the Attributes tab, then outputs it in the markup. After a reload the block shows the default value, a Title field appears under Block Settings in the editor sidebar, and the edited value loads on the front end.

Symbols with their own styles

If you copy the same button markup into every block, a design change means editing every one of those blocks. Symbols are reusable parts you build once and drop into any block. In 1.5.0 a symbol carries its own styles, so it looks the same everywhere you use it.

  1. In the FanCoolo sidebar, create a new symbol under Symbols. In the demo it is called Button.
  2. A symbol has three tabs: Content, Attributes and SCSS. Write the markup in Content (Emmet abbreviations are suggested as you type) and add a label attribute in Attributes.
  3. Style it in the SCSS tab. The demo sets a 1rem padding, a background color, black text and removes the border, then changes the background to yellow.
  4. Insert the symbol in the block's Content as a tag, e.g. <Button ... />.

Since the styles belong to the symbol, every block that uses <Button> picks them up. When you change the symbol, the change shows up everywhere it is used.

Symbol attributes the editor can change per block

A symbol with a fixed label is not much use to content editors. They need to click a block and change the button text right there. 1.5.0 connects symbol attributes to block attributes to handle this.

When a block contains a symbol, a SYMBOL ATTRIBUTES panel appears under the block list, with a label field for the Button. Text you type there is a fixed value for that block. To make it editable in Gutenberg:

  1. Open the block's Attributes tab and click + Add attribute.
  2. Add a Text attribute named Button Label with a default value.
  3. In SYMBOL ATTRIBUTES → Button → label, open the dropdown and choose the Button Label attribute instead of the fixed text.
  4. Save and reload the page editor.

Now a BUTTON LABEL field appears in the block's sidebar next to TITLE. Whatever the editor types there updates the button right away. If you build another block that needs a button, you reuse the same symbol and its styles come with it.

WordPress values as symbol attributes

Sometimes the value you need already lives in WordPress, such as the post title, and adding a field for it just means typing the same thing twice. The same label dropdown now offers WordPress values.

  1. In SYMBOL ATTRIBUTES → Button → label, pick WP: Post title (it shows a PHP badge).
  2. Save and reload.

FanCoolo writes the binding into the markup for you. Here is the final Content of the card block:

<div <?php echo get_block_wrapper_attributes(); ?>>

    <h2>
        <?php echo esc_html($attributes['title'] ?? 'Marko'); ?>
    </h2>
    <Button label="$wp['post_title']" />

</div>

After renaming the page to "Blocks Test Page 22222", the button on the front end showed the new title with no edits to the block.

This is how you build a small design system. Atoms like buttons live in one place as symbols, blocks use them, and editors get only the fields they need. Marko notes that you can also add Tailwind CSS classes inside symbols. Any change to a symbol is made once instead of in every block.

Attribute autocomplete in the code editor

Going back to the Attributes tab every time to check an attribute name slows you down and leads to typos. In the Content editor, type $ to get autocomplete for all attributes of the current block, e.g. $attributes:title and $attributes:buttonLabel, labeled Block attribute · text. Press Tab to insert one.

As Marko sums up, none of this needs npx or a build step. You write HTML markup with a bit of PHP, and FanCoolo turns it into a block.

Who is this for

  • WordPress developers writing blocks in PHP who want static, saved markup without moving to React and a build step.
  • Agencies building design systems who want one button or card defined once and reused in every block, so a style change is one edit.
  • Site builders handing sites to clients who want editors to change labels in the block sidebar instead of in code.
  • Anyone with dynamic blocks that never change that are rendered by PHP on every load for no reason.

FAQ

Can I make a PHP Gutenberg block static with FanCoolo WP?

Yes. In 1.5.0 open the block's Settings, go to Static Output and turn on Store the rendered HTML. After saving, Gutenberg stores the block's full HTML in the post instead of a placeholder comment.

Should every block be static?

No. Blocks that run query loops or show changing data, such as the latest posts, must stay dynamic or they would show outdated content. Use the Re-check button under Static Output to check whether a block can be static.

Do attributes still work in static blocks?

Yes. The demo adds a Title text attribute with a default value. It appears in the block sidebar, can be edited, and the new value shows on the front end.

How do I let editors change text inside a symbol?

Add a block attribute (e.g. Button Label), then under SYMBOL ATTRIBUTES set the symbol's label to that attribute. Editors then get a BUTTON LABEL field in the block sidebar.

Can a symbol use the post title?

Yes. Choose WP: Post title in the symbol attribute dropdown. FanCoolo writes label="$wp['post_title']" into the block markup, and the button follows the page title.

Get FanCoolo WP → dplugins.com

Related posts