Bug: Font Hero + Bricks 2.4.3 — custom font id custom_font_fh_1 resolves to WP post title “Hello world!” instead of the real family

I’d like to report a compatibility bug between Font Hero and Bricks Builder where a Font Hero font selected in Bricks renders with the wrong family name on the frontend.

Environment

• Font Hero: 2.3.3
• Bricks Builder: 2.4.3
• WordPress: 7.1.3
• PHP: 8.5.10

Summary When I select a Font Hero font (in this case “Plus Jakarta Sans”, Font Hero font id 1) on a Bricks element, the Bricks builder preview shows the correct font. But the generated frontend CSS outputs font-family: "Hello world!", and no @font-face exists for that name, so the browser falls back to a default font. The element is on a Heading, but this affects any element using a Font Hero font via Bricks’ Typography → Font family control.

Reproduction

1. Register a font in Font Hero (here: “Plus Jakarta Sans”, id 1).
2. Add a Heading in Bricks and set Typography → Font family to that Font Hero font.
3. The element setting is stored as _typography.font-family = "custom_font_fh_1".
4. Save and view the frontend.

Actual result The generated CSS is: #brxe-rpfcmr { font-family: "Hello world!"; font-weight: 200 } There is no @font-face rule for “Hello world!”, so the heading falls back to a system font.

Expected result font-family: "Plus Jakarta Sans" (the actual family), using the family Font Hero registers.

Root cause (appears to be in Bricks, triggered by Font Hero’s id format) Font Hero’s Bricks integration (FontHeroIntegrationsBricks::registerCustomFonts()) registers fonts into BricksCustom_Fonts::$fonts with the id custom_font_fh_{font_id} — e.g. custom_font_fh_1 with family “Plus Jakarta Sans”. The Bricks builder picker reads that array, so the preview is correct.

However, Bricks’ CSS generator (themes/bricks/includes/assets.php, in the case 'font-family': block) does not use that array. Instead it does:

$custom_font_id = strpos($font_value, 'custom_font_') !== false ? filter_var($font_value, FILTER_SANITIZE_NUMBER_INT) : false; if ($custom_font_id) { $font_value = get_the_title($custom_font_id); }

For custom_font_fh_1, filter_var(..., FILTER_SANITIZE_NUMBER_INT) yields 1, so Bricks calls get_the_title(1). On a default WordPress install post ID 1 is the sample post titled “Hello world!” — which is exactly the (wrong) family name that ends up in the CSS.

So Bricks assumes custom font ids are custom_font_{numeric_post_id}, while Font Hero uses custom_font_fh_{id}.

Impact Any Font Hero font selected in Bricks resolves to an arbitrary WordPress post title (post id = Font Hero font id). On a fresh install, Font Hero font id 1 collides with the “Hello world!” sample post. This makes Font Hero fonts unusable through Bricks’ font-family control.

Request Could you please:

1. Confirm this is reproducible on your side, and
2. Check whether Font Hero can register fonts in a way that Bricks resolves correctly (e.g. using native Bricks font posts, or another supported mechanism)? Bricks has no public filter for third-party custom fonts, so I understand there may be constraints.
3. If the correct fix is on Bricks’ side, I’d appreciate it if you could raise/push it with them as well, since this is part of your advertised “Bricks Builder integration.”

Happy to provide a screen recording, the exported page JSON, or temporary access to a reproduction site if that helps.

Thanks,