SOLVED: Adobe Fonts not loading in specific instances due to incorrect assumptions in Bricks code

Bricks v1.10.3

I am using Adobe Fonts to serve web fonts for my project. I noticed that some specific font choices prevented the Adobe Fonts stylesheet from being enqueued on the front end. (These fonts render correctly in the Bricks Builder.)

After a bit of digging I’ve tracked down the source of the issue.

Bricks generates an inline CSS block which declares the font family using the first member of the css_names array on the settings object defined in the Database::$adobe_fonts which is derived from the JSON retrieved from the Typekit API.

However, when Bricks is determining which stylesheets to enqueue, it is looking in the inline styles for an occurrence of the value of the setting object’s slug attribute, rather than looking to match the value of css_names[0].

In the vast majority of cases these two values are identical. However for the specific font I want to use in my project they are different. I have since identified a number of other fonts where this also true.

The erroneous code is the conditional statement at line 872 in bricks/includes/assets.php.

// Check if Adobe font is in use in inline CSS
if ( ! empty( $adobe_font['slug'] ) && strpos( $inline_css, $adobe_font['slug'] ) !== false ) {
    $adobe_fonts_in_use[] = $adobe_font['slug'];
}

Some fonts that demonstrate this issue are…

FF Amman Sans Pro
slug: ff-amman-sans-web
css_names[0]: ff-amman-sans-pro

FF Cocon Pro Extra Condensed
slug: ff-cocon-pro-extra-condensed
css_names[0]: ff-cocon-pro-extra-cn

FF Amman Serif Pro
slug: ff-amman-serif-web
css_names[0]: ff-amman-serif-pro

FF Nuvo Pro
slug: ff-nuvo-pro
css_names[0]: ff-nuvo-web-pro

FF Prater Block
slug: ff-prater-block
css_names[0]: ff-prater-block-web

N.B. With FF Prater Block the style sheet is enqueued because the slug (ff-prater-block) is matched in the css_names string (ff-prater-block-pr).

FF Basic Gothic Pro
slug: ff-basic-gothic-web-pro
css_names[0]: ff-basic-gothic-pro

FF Providence Pro
slug: ff-providence-pro
css_names[0]: ff-providence-web-pro

FF Angie Open Pro
slug: ff-angie-open-web-pro
css_names[0]: ff-angie-open-pro

FF Mach Wide Pro
slug: ff-mach-wide-pro
css_names[0]: ff-mach-wide-web-pro

FF Mach Pro
slug: ff-mach-pro
css_names[0]: ff-mach-web-pro

I’m sure there will be others.

Over to you :slight_smile:

Hi Duncan,
Welcome to the forum and thanks so much for your report!

Unfortunately, I cannot reproduce the issue. Would you be so kind as to provide a live link and a screencast using https://jam.dev showing and explaining what’s happening?

Best regards,
timmse

Here’s a jammy screencast.

I’ve published a site to demonstrate the issue here.

I can reproduce the issue consistently on different hosts. If you are trying to reproduce locally with fonts enabled in Adobe Creative Cloud that may mask the issue.

Thanks so much for the additional information!

I just saw that we already received a report on this two days ago, and the problem has already been fixed on our dev server - which also explains why I couldn’t reproduce it :smiley:

Long story short: the problem will be fixed in the next version :v:

Excellent—thanks for following up.

Hi guys,

We’ve fixed this issue in Bricks 1.11 BETA, now available as a manual download (Bricks – Account)

Please let us know if you are still experiencing issues.

You can see the full changelog here: Bricks 1.11 Changelog – Bricks

As with any beta release, please do not use it on a production/live website. It is only meant for testing in a local or staging environment.

Best regards,
Matej