Zéro commit, zéro tag, zéro changelog : c’est l’état dans lequel arrive ce thème bloc lorsqu’un cabinet d’avocats confie la maintenance de son site à un nouveau prestataire. Le thème fonctionne, la structure de theme.json paraît cohérente, mais personne ne peut dire ce qui a été modifié depuis la livraison initiale, ni pourquoi.
Le client, lui, ne veut pas entendre parler d’archéologie logicielle. Une échéance approche : une refonte de la page « Domaines d’intervention » doit être livrée avant une audience médiatisée. La checklist qui suit sert justement à sécuriser une reprise rapide sans dépôt de versions, sans tout casser au passage.
Étape 1 : geler l’existant avant toute manipulation
- Copier l’intégralité du dossier du thème actif dans une archive horodatée, hors de la racine WordPress.
- Exporter la base de données au format SQL, même si le contenu semble éditorial et sans enjeu structurel.
- Initialiser un dépôt Git local sur le thème tel quel, comme point de départ zéro, avant la moindre correction.
- Noter la version de WordPress, celle de PHP et la liste des extensions actives dans un fichier texte simple.
Cette étape prend vingt minutes et évite des heures de reconstitution si une modification tourne mal en cours d’audit.
Étape 2 : cartographier templates et template parts
Un thème hybride sans historique cache souvent des surprises dans son arborescence. Il faut lister systématiquement le contenu de templates/ et de parts/, puis vérifier lesquels sont réellement appelés par le site plutôt que résiduels d’un essai abandonné.
find wp-content/themes/cabinet-hybride/templates -name "*.html" | sort
find wp-content/themes/cabinet-hybride/parts -name "*.html" | sortPour chaque fichier, il faut ouvrir l’éditeur de site, sélectionner le modèle correspondant et vérifier dans le panneau latéral s’il porte des personnalisations enregistrées en base plutôt que dans le fichier du thème. La fonction get_block_templates() permet, via un script ponctuel exécuté en WP-CLI, de lister ces overrides sans dépendre de l’interface.
Repérer les modifications enregistrées en base
C’est souvent là que se cachent les surprises : un template modifié depuis l’éditeur de site est stocké dans la table wp_posts avec le type wp_template, et prend le pas sur le fichier du thème. Sans cette vérification, une correction dans le code du thème peut sembler ne produire aucun effet visible.
Étape 3 : isoler les personnalisations à risque
Une fois la cartographie établie, il faut classer chaque écart entre le contenu théorique du thème et son comportement réel observé sur le site en trois catégories : modification volontaire documentée nulle part mais cohérente, bricolage temporaire visiblement oublié, et incohérence pure qui casse déjà quelque chose sans que personne ne l’ait remarqué.
| Constat | Origine probable | Action recommandée |
|---|---|---|
| Template en base différent du fichier | Édition via l’éditeur de site jamais reversée | Exporter en fichier avant toute nouvelle modification |
| Bloc verrouillé sans raison apparente | Verrouillage oublié après un test | Vérifier l’attribut lock dans le contenu du bloc |
| Styles globaux incohérents avec la charte | Révision de styles non nettoyée | Comparer via le panneau de révisions des styles globaux |
Étape 4 : sécuriser theme.json avant d’y toucher
Le fichier theme.json mérite une lecture ligne à ligne avant toute intervention, en particulier la structure des settings et des styles. Une erreur de structure suffit à faire disparaître silencieusement le panneau Styles côté éditeur, sans message d’erreur explicite pour l’utilisateur final.
Sur un dossier sans historique, chaque correction doit être réversible en un clic : c’est la seule façon de travailler vite sans travailler mal.
Étape 5 : livrer sans tout reconstruire
Le cabinet n’a pas demandé une refonte complète, seulement une page supplémentaire livrée à temps. Il ne faut donc pas céder à la tentation de tout réorganiser : ajouter le nouveau template en respectant les conventions déjà en place, même imparfaites, reste la solution la plus sûre à court terme.
En résumé
Reprendre un thème hybride sans dépôt Git impose une discipline précise : geler l’existant, cartographier avant de corriger, isoler les risques, et ne réorganiser qu’une fois le dépôt Git initialisé sur des bases saines. C’est cette rigueur, plus que la vitesse d’exécution, qui permet de tenir un délai serré sans hypothéquer la suite du projet.
