Éditeur de site et multisite : partager templates et styles entre sites

Un réseau de douze sites vitrines, un par agence locale d’une même enseigne, partage le même thème bloc mais réclame que toute évolution de la charte graphique (couleurs, typographie) se propage sans qu’il faille rouvrir l’éditeur de site sur chacun des douze sites individuellement. WordPress multisite ne fournit, par défaut, aucune brique prête à l’emploi pour ce besoin précis — il faut construire l’architecture soi-même, en connaissant précisément ce qui est partagé par nature et ce qui ne l’est jamais.

Ce que le thème parent commun partage réellement

Un thème activé sur plusieurs sites d’un réseau multisite partage ses fichiers : theme.json, les templates et les template parts du dossier thème sont identiques par défaut sur chaque site, puisqu’il s’agit littéralement des mêmes fichiers sur le disque. En revanche, dès qu’un site personnalise un template ou les styles depuis son propre éditeur, cette personnalisation s’enregistre dans les tables propres à ce site (chaque site d’un réseau multisite dispose de ses propres tables wp_N_posts, où N est l’identifiant du site) — totalement indépendantes des autres sites du réseau, même sous le même thème parent.

Réseau multisite
├── Thème partagé (fichiers, identiques sur tous les sites)
│   ├── templates/*.html
│   ├── parts/*.html
│   └── theme.json
├── Site 1 (tables wp_2_*)
│   ├── wp_template (surcouches propres à ce site)
│   ├── wp_global_styles (styles propres à ce site)
│   └── wp_block (patterns synchronisés propres à ce site)
├── Site 2 (tables wp_3_*)
│   └── ... (même structure, contenu indépendant)
└── ... (site N)

Centraliser les patterns via une extension réseau plutôt que via le thème

Pour qu’un pattern reste identique et à jour sur les douze sites sans repasser par chacun, la solution la plus fiable consiste à le déclarer par code, via register_block_pattern(), dans une extension activée sur l’ensemble du réseau (activation réseau depuis Mes sites > Réseau > Extensions). Un pattern ainsi déclaré n’est pas un pattern synchronisé au sens de l’éditeur (pas d’article wp_block associé) : il se comporte comme un pattern classique, copié dans le contenu à l’insertion, mais sa définition source reste centralisée dans le code de l’extension — modifier le code de l’extension change ce que tous les sites verront lors de leur prochaine insertion, sans toucher au contenu déjà publié sur chaque site.

Synchroniser les styles : un chantier à construire soi-même

Aucun mécanisme natif ne propage un changement de styles globaux d’un site vers les autres sites du réseau. Les approches possibles, aucune n’étant du réseau prête à l’emploi :

• Script de synchronisation via WP-CLI : un script qui extrait le contenu de l’article wp_global_styles du site de référence (via wp --url=site-reference.exemple.fr post get) et le réinjecte sur chaque site du réseau (wp --url=site-N.exemple.fr post update), à exécuter manuellement ou via une tâche planifiée après chaque validation de changement de charte.
• theme.json comme seule source de vérité, styles utilisateur désactivés : retirer, via la capacité edit_theme_options, la possibilité pour chaque site de modifier ses propres styles, pour que seul theme.json — partagé par le thème — définisse l’apparence, au prix d’une perte de flexibilité locale par site.
• Un site de référence versionné, les autres synchronisés à la main : accepter un léger différé entre le moment où un changement est validé sur le site pilote et sa réplication manuelle sur les autres, pour un réseau où les changements de charte restent rares.

Limites du multisite à connaître avant de s’engager dans cette architecture

Le multisite ne propose aucune vue d’administration centralisée pour éditer simultanément le contenu de l’éditeur de site sur plusieurs sites du réseau : chaque intervention nécessite de basculer explicitement de site en site (via switch_to_blog() en code, ou simplement en changeant de site depuis l’interface). Pour un réseau de deux ou trois sites, ce coût reste négligeable ; pour un réseau de plusieurs dizaines de sites nécessitant des ajustements fréquents, il devient vite le principal facteur de ralentissement du travail d’entretien.

En résumé

Le multisite partage nativement les fichiers d’un thème commun, mais rien de ce qui est enregistré depuis l’éditeur de site sur un site donné — templates personnalisés, styles utilisateur, patterns synchronisés — ne se propage automatiquement aux autres sites du réseau. Toute stratégie de partage réel repose sur une combinaison de code centralisé (patterns via extension réseau) et de scripts de synchronisation explicites (styles via WP-CLI), à construire en fonction de la fréquence réelle des changements attendus sur le réseau.