Nederlands
English

·

La police était installée, mais le site ne l’affichait pas

Pour la nouvelle version de ce site, je voulais garder les polices de l’ancienne : Playfair Display pour les titres, Mulish pour le texte. Avec le thème par blocs Ollie, on les installe en une seule commande, et WordPress les héberge lui-même. Plus besoin de connexion à Google.

Couverture : Playfair Display

Mulish a fonctionné tout de suite. Playfair Display apparaissait bien dans la liste des polices, mais les titres restaient dans la police par défaut. Et quand j’ai réessayé, Ollie a refusé d’utiliser la police : « non enregistrée ».

La cause était un petit bug dans Ollie Pro, aux grandes conséquences. À l’installation, Ollie écrit la nouvelle police dans les réglages de style centraux du site. Quelque chose se passe mal avec les guillemets. « Playfair Display » en a besoin parce qu’il y a un espace dans le nom, « Mulish » non. Résultat : les réglages de style ont été endommagés sans bruit. Aucun message d’erreur, juste une police qui n’apparaissait pas, et une autre police qui a disparu de la liste en chemin.

Le bloc d’introduction de la page d’accueil : le titre Henk van den Bor en Playfair Display, avec le texte en Mulish en dessous.

Ce que j’en retiens

Une installation qui annonce « réussie » n’est pas encore un résultat qui fonctionne. Désormais, je vérifie dans le code source de la page si la police est vraiment chargée, et pas seulement si elle figure dans la liste. Avec Poppins (sur un ancien site client), le problème ne s’est jamais vu, tout simplement parce que ce nom n’a pas besoin de guillemets.

J’ai corrigé le problème comme WordPress le fait lui-même. J’ai signalé le bug aux créateurs d’Ollie le 23 septembre, avec l’endroit dans le code et la correction. Dès qu’une version corrigée sortira, je le mentionnerai ici.

Pour les techniciens : ce qui se passe exactement

Testé avec : Ollie Pro 2.8.3, WordPress 7.1.2, polices via l’ability ollie/manage-global-styles → install-font.

Le bug. Après l’installation, Ollie enregistre la police dans le post wp_global_styles du thème avec wp_update_post(), mais sans wp_slash(). À l’enregistrement, WordPress retire lui-même un niveau de barres obliques inverses. Les guillemets échappés dans "fontFamily": "\"Playfair Display\", serif" perdent leur barre oblique, et le JSON devient invalide :

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

Ensuite, json_decode() renvoie null. Les polices enregistrées auparavant disparaissent, et update refuse la police avec *« Font family is not registered »*.

Deux autres pièges :

  • S’il n’existe pas encore de post wp_global_styles pour le thème (thème fraîchement activé, Site Editor jamais ouvert), update échoue avec *« No global styles post found »*. On peut le créer avec WP_Theme_JSON_Resolver::get_user_global_styles_post_id(), mais en tant qu’utilisateur connecté (WP-CLI avec --user) : sans utilisateur, le post est créé sans son terme de thème, et un nouveau est ajouté à chaque fois.
  • L’enregistrement ne contient pas de fontFace. WordPress n’écrit alors pas de @font-face, et la police ne se charge pas, même sans le bug d’échappement. Le Site Editor ajoute bien ces données. Elles se trouvent dans le post_content des posts wp_font_face.

Correction. Construire soi-même le JSON des styles globaux (polices avec fontFace, couleurs, attribution des polices) et l’enregistrer avec wp_slash( wp_json_encode( $data ) ). Puis le relire et l’analyser pour vérifier.