Nederlands
Français

·

The font was installed, but the site didn’t show it

For the new version of this site I wanted to keep the fonts of the old one: Playfair Display for headings, Mulish for text. In the Ollie block theme you install them with a single command, and WordPress then hosts them itself. No connection to Google needed anymore.

Cover: Playfair Display

Mulish worked right away. Playfair Display showed up neatly in the list of fonts, but the headings stayed in the default font. And when I tried again, Ollie refused to use the font: “not registered”.

The cause was a small bug in Ollie Pro, with a big effect. When installing, Ollie writes the new font into the site’s central style settings. Something goes wrong there with quotation marks. “Playfair Display” needs them because there’s a space in the name, “Mulish” doesn’t. The result: the style settings were silently damaged. No error message, just a font that didn’t appear, and another font that disappeared from the list along the way.

The intro block on the front page: the heading Henk van den Bor in Playfair Display, with text in Mulish below it.

What I learned

An installation that reports “success” is not yet a working result. From now on I check the page source to see whether the font is actually loaded, not just whether it’s in the list. With Poppins (on an earlier client site) it never showed up, simply because that name doesn’t need quotation marks.

I fixed it the way WordPress does it itself. I reported the bug to the makers of Ollie on 23 September, with the place in the code and the fix. As soon as a version with the correction is out, I’ll mention it here.

For the techies: what exactly happens

Tested with: Ollie Pro 2.8.3, WordPress 7.1.2, fonts via the ability ollie/manage-global-styles → install-font.

The bug. After installing, Ollie registers the font in the theme’s wp_global_styles post with wp_update_post(), but without wp_slash(). WordPress strips one level of backslashes when saving. The escaped quotes in "fontFamily": "\"Playfair Display\", serif" lose their backslash, and the JSON becomes invalid:

{"fontFamily":""Playfair Display", serif", ...}

After that, json_decode() returns null. Previously registered fonts are gone, and update refuses the font with *”Font family is not registered”*.

Two more pitfalls:

  • If the theme has no wp_global_styles post yet (freshly activated, Site Editor never opened), update fails with *”No global styles post found”*. You can create it with WP_Theme_JSON_Resolver::get_user_global_styles_post_id(), but do that as a logged-in user (WP-CLI with --user): without a user the post is created without its theme term, and a new one is added every time.
  • The registration contains no fontFace. WordPress then doesn’t output an @font-face, and the font doesn’t load, even without the escaping bug. The Site Editor does add that data. It’s in the post_content of the wp_font_face posts.

Fix. Build the global styles JSON yourself (fonts with fontFace, colours, font assignment) and save it with wp_slash( wp_json_encode( $data ) ). Then read it back and parse it as a check.