English
Français

·

Het lettertype stond erop, maar de site toonde het niet

Voor de nieuwe versie van deze site wilde ik de lettertypes van de oude houden: Playfair Display voor de koppen, Mulish voor de tekst. In het blokthema Ollie installeer je die met één opdracht, en WordPress host ze dan zelf. Geen verbinding met Google meer nodig.

Omslag: Playfair Display

Mulish werkte meteen. Playfair Display stond netjes in de lijst met lettertypes, maar de koppen bleven in het standaardlettertype. En toen ik het opnieuw probeerde, weigerde Ollie het lettertype te gebruiken: “niet geregistreerd”.

De oorzaak was een klein foutje in Ollie Pro, met een groot gevolg. Bij het installeren schrijft Ollie het nieuwe lettertype weg in de centrale stijlinstellingen van de site. Daarbij gaat iets mis met aanhalingstekens. “Playfair Display” heeft die nodig omdat er een spatie in de naam staat, “Mulish” niet. Het gevolg: de stijlinstellingen raakten stil beschadigd. Geen foutmelding, alleen een lettertype dat niet verscheen, en een ander lettertype dat onderweg uit de lijst verdween.

Het introblok op de voorpagina: de kop Henk van den Bor in Playfair Display, daaronder tekst in Mulish.

Wat ik ervan leer

Een installatie die “gelukt” meldt, is nog geen werkend resultaat. Ik kijk voortaan in de broncode van de pagina of het lettertype echt geladen wordt, niet alleen of het in de lijst staat. Bij Poppins (op een eerdere klantsite) viel het nooit op, simpelweg omdat die naam geen aanhalingstekens nodig heeft.

Ik heb het hersteld zoals WordPress het zelf doet. De fout heb ik op 23 september gemeld bij de makers van Ollie, met de plek in de code en de oplossing erbij. Zodra er een versie met de correctie uit is, meld ik dat hier.

Voor de techneuten: wat er precies gebeurt

Getest met: Ollie Pro 2.8.3, WordPress 7.1.2, lettertypes via de ability ollie/manage-global-styles → install-font.

De fout. Na het installeren registreert Ollie het font in de wp_global_styles-post van het thema met wp_update_post(), maar zonder wp_slash(). WordPress haalt bij het opslaan zelf een laag backslashes weg. De geëscapete aanhalingstekens in "fontFamily": "\"Playfair Display\", serif" verliezen daardoor hun backslash, en de JSON is ongeldig:

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

json_decode() geeft daarna null. Eerder geregistreerde fonts zijn weg, en update weigert het font met *”Font family is not registered”*.

Twee extra valkuilen:

  • Bestaat er nog geen wp_global_styles-post voor het thema (vers geactiveerd, Site Editor nooit geopend), dan faalt update met *”No global styles post found”*. Aanmaken kan met WP_Theme_JSON_Resolver::get_user_global_styles_post_id(), maar doe dat als ingelogde gebruiker (WP-CLI met --user): zonder gebruiker komt de post er zonder thema-koppeling, en komt er elke keer een nieuwe bij.
  • De registratie bevat geen fontFace. WordPress schrijft dan geen @font-face uit, en het font laadt niet, ook zonder de escapefout. De Site Editor zet die gegevens er wel bij. Ze staan in de post_content van de wp_font_face-posts.

Herstel. De global-styles-JSON zelf opbouwen (fonts mét fontFace, kleuren, font-toewijzing) en wegschrijven met wp_slash( wp_json_encode( $data ) ). Daarna opnieuw uitlezen en parsen als controle.