Continuing the discussion from SOLVED: MCP-created component is available in Bricks but missing from Gutenberg despite “Use in block editor” being enabled:
I couldn’t find a tag for v 2.4.1 in the forum so this is actually about 2.4.1 not the beta as tagged
Browser: Chrome 110
OS: macOS / Windows / Linux / etc.
URL: Link to a page that illustrates this issue
Video: Short screen recording that illustrates this issue (free tool: jam.dev)
Environment
- Bricks: 2.4.1
- MCP Adapter: 0.6.1
- WordPress: 7.1.2
- PHP: 8.2.29
- Website: Local development environment
I was using Claude (Anthropic’s AI assistant) via the Bricks MCP/Abilities API to build a couple of reusable components and set them up as Gutenberg blocks. Claude built the components, then diagnosed both of the following bugs by reading Bricks’ own source directly (includes/integrations/block-editor.php), rather than guessing — so I’m passing along its findings pretty much as-is, since it did the actual legwork tracing these to specific lines of code.
Both are distinct from the earlier numeric-ID issue fixed in 2.4-beta3 — all affected components here have standard 6-character alphanumeric IDs (8e0ce4, ccd7c2, dad240), not numeric-only ones.
Bug 1: Component blocks register with a blank title, description, and icon
Description
Any component with “Use in block editor” enabled registers correctly as a Gutenberg block server-side, but with no title, description, or icon — making it effectively invisible/unsearchable in the block inserter, even though registration technically succeeds.
Steps to reproduce
- Create any component and enable “Use in block editor” (blockEditor, blockCategory, blockIcon set).
- Confirm via
WP_Block_Type_Registry::get_instance()->get_registered('bricks-components/{id}')that the block is registered. - Inspect
->title,->description,->iconon the returned block object.
Expected result
title reflects the component’s display name (its root element’s label), description reflects the component’s desc field, icon reflects blockIcon.
Actual result
All three are empty/null, regardless of how the component was created (via the Bricks Builder UI or the Abilities API).
Technical findings
In wp-content/themes/bricks/includes/integrations/block-editor.php, register_component_block():
// Get component name from the first element or use ID
$component_name = ‘’;
if ( isset( $component[‘elements’][0][‘label’] ) ) {
$component_name = $component[‘elements’][0][‘label’];
} else {
$component_name = sprintf( __( ‘Component %s’, ‘bricks’ ), $component[‘id’] );
}
$block_settings = [
‘attributes’ => $attributes,
‘render_callback’ => [ $this, ‘render_component_block’ ],
‘category’ => $component[‘blockCategory’] ?? ‘bricks’,
‘supports’ => [ ‘align’ => [ ‘wide’, ‘full’ ] ],
];
$component_name is computed — clearly intended to become the block’s title — but is never added to $block_settings. There’s no 'title' => $component_name line at all. Same story for description/icon: the component’s desc and blockIcon fields are read/stored elsewhere but never passed into register_block_type().
Possible cause
Looks like a straightforward omission — the variable is built for exactly this purpose one line above where it’s needed, and simply isn’t used.
Bug 2: Rich-text (“editor” type) component properties get corrupted on save via an alternate block registration path
Description
When a component is inserted via Gutenberg and Gutenberg falls back to registering it under an alternate block name (bricks-component-ids/id-XXXXXXXXXXXX rather than the canonical bricks-components/{componentId}), saving the post through the editor’s Update button can corrupt any editor-type (rich text) property value. The corruption is inconsistent: some content remains correctly JSON-escaped, other content ends up with the escape prefix stripped, leaving literal text like u003c and u0026ndash; in place of < and –.
Steps to reproduce
- Insert a component with an
editor-type property (multi-paragraph rich text) via the Gutenberg inserter. - Confirm it initially saves and renders correctly.
- Edit the post again in Gutenberg (even unrelated fields) and click Update.
- Inspect the resulting
post_contentand rendered output.
Expected result
The editor-type property’s HTML content remains valid, correctly escaped JSON on every save, and renders as proper HTML.
Actual result
Literal, unescaped u003c/u003e/u0026...; sequences appear as visible page text instead of being parsed as <, >, and HTML entities.
Technical findings
The raw stored block comment shows a mix of correctly-escaped and corrupted content within the same string:
“prop_text”:“\u003cp\u003eLifeworks trains NGOs … transform lives and livelihoods u0026ndash; … Production of microbial fertilisers … prosperity.u003c/pu003eu003cpu003eWe develop partnerships …”
Note the properly-escaped \u003cp\u003e at the start versus the unescaped u003c\/pu003e later in the same value. This isn’t something a hand-edit would produce — it points to a serialization bug specific to this block’s client-side save logic. This block was registered under bricks-component-ids/id-386530636534 rather than the canonical bricks-components/{componentId} name; other component instances on the same site, registered under the canonical name, don’t exhibit this corruption for equivalent content.
Possible cause
The alternate bricks-component-ids/id-... registration path (which we’ve also seen used when a block can’t resolve its canonical name at insert time) appears to use different/buggy serialization logic for editor-type property values on save, compared to the canonical path.