Mu-plugin « Les Baladins – API CSS additionnel »

Date : 8 juillet 2026 Fichier : les-baladins-custom-css-api.php Emplacement : wp-content/mu-plugins/ Site : les-baladins.ch

Pourquoi ce snippet est nécessaire

Andrea a fourni un accès à l’API REST WordPress via un mot de passe d’application (compte andreBalestrini). Cette authentification permet d’appeler n’importe quelle route exposée sous /wp-json/..., mais uniquement les routes que WordPress ou ses plugins ont explicitement enregistrées avec show_in_rest.

Le CSS additionnel (Personnaliser > CSS additionnel) est stocké par WordPress core dans un type de contenu spécial, custom_css. Ce type de contenu n’est pas déclaré avec show_in_rest => true dans WordPress core — il n’existe donc aucune route /wp-json/wp/v2/... permettant de le lire ou de l’écrire, quel que soit le niveau de permission du compte utilisé. Ce n’est pas une restriction liée au mot de passe d’application : la route elle-même n’existe pas.

Deuxième limite, indépendante : la sauvegarde du CSS additionnel via l’interface du Customizer passe normalement par admin-ajax.php avec un nonce lié à une session de connexion (cookies). Ce mécanisme n’est pas compatible avec une authentification Basic Auth par API — même en théorie, il aurait fallu une session de navigateur connectée, pas un simple appel API.

Conséquence pratique avant ce snippet : chaque ajustement du CSS additionnel devait être communiqué à Andrea sous forme de bloc de code à copier-coller manuellement dans Personnaliser > CSS additionnel. Fonctionnel, mais lent pour des itérations rapides (plusieurs allers-retours ont été nécessaires pour ce correctif de header : bannière, puis logo, puis alignement mobile).

Ce que fait le snippet

Un mu-plugin (“must-use plugin”) enregistre une route REST personnalisée qui s’appuie sur les fonctions internes de WordPress prévues pour manipuler le CSS additionnel par du code (wp_get_custom_css() et wp_update_custom_css_post() — les mêmes fonctions que WordPress core utilise en interne pour le Customizer). Le snippet ne réinvente rien, il expose simplement ces fonctions existantes via une route accessible en API.

Deux endpoints :

• GET /wp-json/les-baladins/v1/custom-css → retourne { "css": "...contenu actuel..." }
• POST /wp-json/les-baladins/v1/custom-css avec un corps { "css": "..." } → remplace le CSS additionnel et retourne le nouveau contenu

Pourquoi un mu-plugin plutôt qu’un ajout dans functions.php

Un mu-plugin (dossier wp-content/mu-plugins/) se charge automatiquement à chaque requête, avant les plugins classiques et avant le thème, sans étape d’activation et sans apparaître dans la liste des extensions désactivables depuis l’admin. Avantages ici :

• Aucun risque de le désactiver par erreur depuis Extensions.
• Ne dépend pas du thème actif : si le thème enfant est un jour changé ou reconstruit, l’endpoint continue de fonctionner.
• Isolé dans un fichier dédié, facile à identifier, à auditer ou à supprimer plus tard sans toucher au thème.

Sécurité

• Chaque route vérifie current_user_can('edit_theme_options') — capacité que seuls les comptes administrateurs (ou équivalent) possèdent par défaut. Un compte sans ce rôle ne peut ni lire ni écrire, même avec un mot de passe d’application valide.
• L’authentification reste celle déjà en place (mot de passe d’application HTTPS Basic Auth) — aucun nouveau système d’auth introduit, aucun secret supplémentaire créé.
• Le endpoint ne fait qu’un seul type d’action (lire/écrire le CSS additionnel) — pas d’exécution de code arbitraire, pas d’accès à d’autres réglages du site.
• Point d’attention : quiconque dispose d’un mot de passe d’application avec les droits admin peut désormais aussi modifier le CSS additionnel par ce biais. C’est le même niveau d’accès qu’un admin a déjà via l’interface — le snippet ne l’étend pas, il le rend juste accessible par API.

Statut

Installé et vérifié le 8 juillet 2026 : une lecture via GET /wp-json/les-baladins/v1/custom-css a confirmé que l’endpoint retourne correctement le CSS additionnel actuellement en production sur le site.

Pour aller plus loin (non fait, à discuter si utile)

• Ajouter un endpoint équivalent pour d’autres réglages non exposés par l’API par défaut (ex. options du thème GeneratePress), si le besoin se répète.
• Restreindre la permission à un user_login précis plutôt qu’à la capacité edit_theme_options, si plusieurs comptes admin existent et que l’accès doit rester limité à Andrea seul.