Ajouter du code WordPress sans casser votre site

Si vous avez déjà vu un écran blanc après avoir collé “juste un petit snippet” dans WordPress, vous savez que le vrai risque n’est pas le code… c’est l’endroit où vous le mettez, et la façon dont vous le chargez.

Le problème / Le besoin

Vous voulez souvent ajouter une petite fonctionnalité sans installer un plugin de plus : un message dans le pied de page, un script de suivi, un shortcode, une modification de l’admin, un champ sur un formulaire, etc. Les débutants (et beaucoup d’intermédiaires) collent ça dans functions.php du thème actif, ou pire : dans un fichier du “core” WordPress. Résultat classique : erreur PHP, site inaccessible, ou code qui disparaît au prochain changement de thème.

Ce guide s’adresse aux blogueurs WordPress débutants (et aux pros pressés) qui veulent ajouter du code proprement sur WordPress 6.9.4 (avril 2026), sans casser le site, sans perdre la modification lors d’une mise à jour, et avec une méthode reproductible.

À la fin, vous saurez :

où coller du code selon le type de modification (thème enfant, plugin perso, mu-plugin) ;
comment charger CSS/JS “à la WordPress” (enqueue) ;
comment sécuriser une action en admin (permissions + nonce) ;
comment tester sans stress (staging, logs, mode debug) ;
comment revenir en arrière si un snippet casse tout.

Avant le premier bloc de code : où coller le code ? Pour éviter de casser votre thème, je recommande une approche “plugin” pour tout ce qui n’est pas purement visuel. Dans ce guide, vous collerez le code dans un mu-plugin (un plugin “must-use”) : un fichier PHP placé dans wp-content/mu-plugins/. Il est chargé automatiquement, même si vous changez de thème.

Les fonctions WordPress que vous allez croiser (avec docs officielles) :

add_action() : accroche une fonction à un évènement (un “hook” d’action).
add_filter() : modifie une valeur via un “hook” de filtre.
wp_enqueue_script() et wp_enqueue_style() : charge JS/CSS correctement.
wp_nonce_field(), wp_verify_nonce() : protège un formulaire (anti-CSRF).
current_user_can() : vérifie les permissions.

Résumé rapide

Vous allez créer un mu-plugin “bpcab-safe-snippets” (copier-coller, prêt à l’emploi).
Ce mu-plugin ajoute une page “Snippets sûrs” dans l’admin, avec un exemple de code activable.
Il montre la bonne façon de charger CSS/JS (enqueue), et d’ajouter un bouton dans l’admin.
Il inclut des garde-fous : permissions, nonce, logs, et désactivation rapide en cas de crash.
Vous repartez avec une méthode : staging → mu-plugin → hooks → tests → déploiement.

Quand utiliser cette solution

Vous voulez ajouter une fonctionnalité “site” (indépendante du thème) : shortcode, redirection, tracking, nettoyage admin, mini-API, ajout de rôle/capacité.
Vous changez régulièrement de thème (ou vous utilisez un page builder) et vous ne voulez pas perdre vos modifications.
Vous avez besoin d’un endroit stable pour déposer du code, versionnable (Git) et testable.
Vous gérez plusieurs sites : la structure mu-plugin vous évite les bricolages dans functions.php.

Quand ne PAS utiliser cette solution

Petites modifications purement visuelles (CSS) : utilisez de préférence le CSS additionnel (Apparence → Personnaliser) ou un fichier CSS dans un thème enfant. Un mu-plugin peut charger du CSS, mais ce n’est pas toujours le plus simple.
Fonctionnalités déjà couvertes par un plugin sérieux : SEO, cache, sécurité, formulaires. Réinventer la roue est un bon moyen de se créer une dette technique.
Code “jetable” que vous n’assumerez pas de maintenir : mieux vaut un plugin de snippets avec interface et versioning, ou un mini-plugin propre.
Vous n’avez pas de staging : dans ce cas, commencez par ça. J’ai souvent vu des sites e-commerce tomber pour un point-virgule oublié dans functions.php.

Prérequis / avant de commencer

Versions et environnement

WordPress : 6.9.4 ou plus récent.
PHP : 8.1 minimum recommandé (8.2/8.3 souvent mieux si votre hébergeur suit).
Accès aux fichiers : via SFTP/SSH ou le gestionnaire de fichiers de l’hébergeur (évitez l’éditeur de fichiers intégré en production).

Sauvegarde et sécurité

Faites une sauvegarde complète (fichiers + base de données) avant toute modification. Si vous avez un plugin de sauvegarde, vérifiez qu’une restauration fonctionne.
Ne modifiez jamais les fichiers WordPress “core” (wp-includes, wp-admin). Toute modification sera écrasée et peut introduire une faille.
Travaillez idéalement sur un staging (clone) et déployez ensuite.

Outils utiles

Activer le debug proprement (voir plus bas).
Un éditeur de code qui détecte les erreurs : VS Code.
Un client SFTP (FileZilla) ou SSH.

Activer les logs (recommandé sur staging)

Dans wp-config.php, vous pouvez activer des logs PHP/WordPress. Sur un site public, évitez d’afficher les erreurs à l’écran.

/**
 * Debug WordPress (idéalement sur staging).
 * Ne laissez pas WP_DEBUG_DISPLAY à true en production.
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Les erreurs iront dans wp-content/debug.log (si le serveur le permet). Doc : Debug WordPress.

L’approche naïve (et pourquoi l’éviter)

Le scénario typique : vous trouvez un snippet sur un forum, vous le collez dans functions.php du thème actif, vous rafraîchissez… et écran blanc. Ou bien ça marche, puis disparaît quand vous mettez à jour le thème ou que vous passez sur Divi/Avada.

Exemple naïf : code collé dans le mauvais fichier + sortie non échappée

Voici un exemple réaliste (et dangereux) : afficher un paramètre d’URL dans le footer, sans nettoyage.

<?php
// Mauvaise idée : collé dans le footer.php ou functions.php du thème parent,
// et affiche directement une donnée utilisateur.
add_action( 'wp_footer', function () {
	echo '<div class="promo">' . $_GET['promo'] . '</div>';
} );

Problèmes :

Sécurité : XSS (injection de script) via $_GET['promo'].
Maintenance : si c’est dans le thème parent, une mise à jour écrase tout.
Dépannage : si vous faites une erreur de syntaxe, le site peut devenir inaccessible.
Portabilité : changement de thème = code perdu.

Autre piège naïf : charger JS/CSS “en dur”

<?php
// Mauvaise idée : imprime un script sans passer par wp_enqueue_script().
add_action( 'wp_head', function () {
	echo '<script src="/wp-content/themes/mon-theme/js/custom.js"></script>';
} );

Le problème vient de la gestion des dépendances, du cache, de l’ordre de chargement, et du fait que certains builders (ou plugins d’optimisation) déplacent/minifient les assets. WordPress fournit un système prévu pour ça : enqueue.

La bonne approche — tutoriel pas à pas

La stratégie la plus “anti-casse” pour un débutant : un mu-plugin simple, avec des hooks propres, et un exemple de fonctionnalité activable.

Étape 1 — Créer le dossier mu-plugins

Connectez-vous en SFTP/SSH.
Allez dans wp-content/.
Créez un dossier mu-plugins s’il n’existe pas.

Les mu-plugins sont chargés automatiquement par WordPress. Doc : Must-Use Plugins.

Étape 2 — Créer un fichier de mu-plugin

Créez ce fichier : wp-content/mu-plugins/bpcab-safe-snippets.php

Ce fichier va :

ajouter une page d’admin (Outils → Snippets sûrs) ;
enregistrer une option (activer/désactiver un snippet) ;
ajouter un message en footer si le snippet est activé ;
charger un petit CSS proprement ;
utiliser permissions + nonce + sanitization/escaping.

Étape 3 — Comprendre les “hooks” (actions et filtres)

Un hook est un point d’accroche dans WordPress. Il y a deux types :

Action : vous exécutez du code à un moment donné (ex. admin_menu, wp_footer). Fonction : add_action().
Filtre : vous recevez une valeur, vous la modifiez, vous la retournez (ex. the_content). Fonction : add_filter().

La confusion “action vs filtre” est un grand classique. Si vous oubliez de return dans un filtre, vous cassez l’affichage. Si vous essayez d’echo dans un filtre, vous créez des sorties au mauvais endroit.

Étape 4 — Ajouter une page d’admin (avec permissions)

Vous allez utiliser add_management_page() pour placer la page dans “Outils”. On protège l’accès avec current_user_can().

Étape 5 — Protéger l’enregistrement (nonce + sanitization)

Quand vous enregistrez un formulaire en admin, deux protections minimales :

Permission : l’utilisateur a-t-il le droit ?
Nonce : le formulaire vient-il bien de votre site (anti-CSRF) ?

Ensuite, vous nettoyez les données entrantes (sanitization) et vous échappez les sorties HTML (escaping).

Étape 6 — Charger un CSS/JS proprement (enqueue)

Au lieu d’imprimer une balise <script>, vous passez par wp_enqueue_style() / wp_enqueue_script(). C’est ce que les plugins de cache et les builders attendent.

Code complet

Où coller ce code : dans wp-content/mu-plugins/bpcab-safe-snippets.php (créez le fichier si nécessaire). Copiez-collez tel quel.

<?php
/**
 * Plugin Name: BPCAB - Snippets sûrs (mu-plugin)
 * Description: Ajoute une page d'admin pour activer un snippet d'exemple sans casser le site. WordPress 6.9.4+ / PHP 8.1+.
 * Author: BPCAB
 * Version: 1.0.0
 *
 * Ce fichier doit être placé dans : wp-content/mu-plugins/bpcab-safe-snippets.php
 */

declare( strict_types=1 );

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Clé d'option stockée en base.
 */
const BPCAB_SAFE_SNIPPETS_OPTION = 'bpcab_safe_snippets_settings';

/**
 * Retourne les réglages actuels (avec valeurs par défaut).
 *
 * @return array{footer_notice_enabled: bool, footer_notice_text: string}
 */
function bpcab_safe_snippets_get_settings(): array {
	$defaults = array(
		'footer_notice_enabled' => false,
		'footer_notice_text'    => 'Merci de votre visite !',
	);

	$settings = get_option( BPCAB_SAFE_SNIPPETS_OPTION, array() );

	if ( ! is_array( $settings ) ) {
		return $defaults;
	}

	// Fusionne en garantissant les clés.
	return array_merge( $defaults, $settings );
}

/**
 * Enregistre le menu dans Outils → Snippets sûrs.
 */
add_action( 'admin_menu', function (): void {
	add_management_page(
		'Snippets sûrs',
		'Snippets sûrs',
		'manage_options',
		'bpcab-safe-snippets',
		'bpcab_safe_snippets_render_admin_page'
	);
} );

/**
 * Enregistre le CSS de l'admin pour cette page.
 */
add_action( 'admin_enqueue_scripts', function ( string $hook_suffix ): void {
	// Le hook_suffix ressemble à : tools_page_bpcab-safe-snippets
	if ( $hook_suffix !== 'tools_page_bpcab-safe-snippets' ) {
		return;
	}

	// Petit CSS inline : pratique pour un mu-plugin (pas de fichier à gérer).
	$css = '
		.bpcab-box{background:#fff;border:1px solid #dcdcde;padding:16px;border-radius:8px;max-width:860px}
		.bpcab-row{margin:12px 0}
		.bpcab-help{color:#646970}
		.bpcab-code{background:#f6f7f7;border:1px solid #dcdcde;padding:12px;border-radius:6px;overflow:auto}
	';
	wp_register_style( 'bpcab-safe-snippets-admin', false );
	wp_enqueue_style( 'bpcab-safe-snippets-admin' );
	wp_add_inline_style( 'bpcab-safe-snippets-admin', $css );
} );

/**
 * Affiche la page d'administration.
 */
function bpcab_safe_snippets_render_admin_page(): void {
	if ( ! current_user_can( 'manage_options' ) ) {
		wp_die( esc_html__( 'Accès refusé.', 'default' ) );
	}

	$settings = bpcab_safe_snippets_get_settings();

	// Message de succès/erreur simple via paramètre d'URL (échappé à l'affichage).
	$updated = isset( $_GET['bpcab_updated'] ) ? sanitize_text_field( wp_unslash( $_GET['bpcab_updated'] ) ) : '';
	?>
	<div class="wrap">
		<h1>Snippets sûrs</h1>

		<?php if ( $updated === '1' ) : ?>
			<div class="notice notice-success is-dismissible"><p>Réglages enregistrés.</p></div>
		<?php endif; ?>

		<div class="bpcab-box">
			<p>
				Cette page sert de “bac à sable” : vous activez un snippet simple, et vous voyez la méthode propre
				(hooks, permissions, nonce, sanitization, escaping).
			</p>

			<hr />

			<form method="post" action="<?php echo esc_url( admin_url( 'admin-post.php' ) ); ?>">
				<?php
				// Nonce = jeton anti-CSRF.
				wp_nonce_field( 'bpcab_safe_snippets_save', 'bpcab_safe_snippets_nonce' );
				?>

				<input type="hidden" name="action" value="bpcab_safe_snippets_save" />

				<div class="bpcab-row">
					<label>
						<input type="checkbox" name="footer_notice_enabled" value="1" <?php checked( (bool) $settings['footer_notice_enabled'] ); ?> />
						<strong>Activer le message en pied de page</strong>
					</label>
					<p class="bpcab-help">Le message apparaîtra côté visiteurs via le hook <code>wp_footer</code>.</p>
				</div>

				<div class="bpcab-row">
					<label for="footer_notice_text"><strong>Texte du message</strong></label><br />
					<input
						type="text"
						id="footer_notice_text"
						name="footer_notice_text"
						value="<?php echo esc_attr( (string) $settings['footer_notice_text'] ); ?>"
						class="regular-text"
						maxlength="120"
					/>
					<p class="bpcab-help">Astuce : gardez-le court. Ce champ est nettoyé et échappé.</p>
				</div>

				<p>
					<button type="submit" class="button button-primary">Enregistrer</button>
				</p>
			</form>

			<hr />

			<h2>À quoi ressemble le snippet côté code ?</h2>
			<p class="bpcab-help">
				Vous n’avez rien à copier ici : c’est juste pour comprendre. Le snippet réel est plus bas dans ce mu-plugin.
			</p>
			<pre class="bpcab-code"><code>add_action( 'wp_footer', function () {
  // ... affiche un message si l'option est activée
} );</code></pre>
		</div>
	</div>
	<?php
}

/**
 * Traite l'enregistrement du formulaire (admin-post.php).
 *
 * Hook WordPress : admin_post_{action}
 * Doc : https://developer.wordpress.org/reference/hooks/admin_post_action/
 */
add_action( 'admin_post_bpcab_safe_snippets_save', function (): void {
	if ( ! current_user_can( 'manage_options' ) ) {
		wp_die( esc_html__( 'Accès refusé.', 'default' ) );
	}

	// Vérifie le nonce.
	$nonce = isset( $_POST['bpcab_safe_snippets_nonce'] ) ? sanitize_text_field( wp_unslash( $_POST['bpcab_safe_snippets_nonce'] ) ) : '';
	if ( ! wp_verify_nonce( $nonce, 'bpcab_safe_snippets_save' ) ) {
		wp_die( esc_html__( 'Nonce invalide. Rafraîchissez la page et réessayez.', 'default' ) );
	}

	// Sanitization (nettoyage) des entrées.
	$enabled = isset( $_POST['footer_notice_enabled'] ) && (string) $_POST['footer_notice_enabled'] === '1';

	$text_raw = isset( $_POST['footer_notice_text'] ) ? wp_unslash( $_POST['footer_notice_text'] ) : '';
	// Nettoyage conservateur : une simple ligne de texte.
	$text = sanitize_text_field( (string) $text_raw );
	$text = mb_substr( $text, 0, 120 );

	$settings = array(
		'footer_notice_enabled' => (bool) $enabled,
		'footer_notice_text'    => $text !== '' ? $text : 'Merci de votre visite !',
	);

	update_option( BPCAB_SAFE_SNIPPETS_OPTION, $settings, false );

	// Redirection post/redirect/get pour éviter la double soumission.
	wp_safe_redirect( add_query_arg( 'bpcab_updated', '1', admin_url( 'tools.php?page=bpcab-safe-snippets' ) ) );
	exit;
} );

/**
 * Snippet "front" : affiche un message en pied de page si activé.
 *
 * Hook : wp_footer
 * Doc : https://developer.wordpress.org/reference/hooks/wp_footer/
 */
add_action( 'wp_footer', function (): void {
	$settings = bpcab_safe_snippets_get_settings();

	if ( empty( $settings['footer_notice_enabled'] ) ) {
		return;
	}

	// Escaping : on affiche du texte utilisateur en HTML.
	$text = isset( $settings['footer_notice_text'] ) ? (string) $settings['footer_notice_text'] : '';

	echo '<div class="bpcab-footer-notice" style="text-align:center; padding:14px 10px; font-size:14px; opacity:.85">';
	echo esc_html( $text );
	echo '</div>';
}, 20 );

/**
 * Variante propre : charger un CSS front via enqueue au lieu d'un style inline.
 * Ici on reste minimaliste avec un CSS inline (pas de fichier) pour le guide.
 */
add_action( 'wp_enqueue_scripts', function (): void {
	$settings = bpcab_safe_snippets_get_settings();
	if ( empty( $settings['footer_notice_enabled'] ) ) {
		return;
	}

	$css = '.bpcab-footer-notice{background:#f6f7f7;border-top:1px solid #e5e5e5}';
	wp_register_style( 'bpcab-safe-snippets-front', false );
	wp_enqueue_style( 'bpcab-safe-snippets-front' );
	wp_add_inline_style( 'bpcab-safe-snippets-front', $css );
} );

Explication du code

Le choix du mu-plugin (et pourquoi ça évite des drames)

Un mu-plugin est chargé automatiquement, sans écran “Extensions”. Ça a deux conséquences :

Avantage : votre code ne disparaît pas si vous changez de thème, et personne ne le désactive “par erreur”.
Risque : si vous mettez une erreur fatale dedans, elle se déclenche à chaque chargement. D’où l’intérêt du staging et des logs.

Dans mon expérience, le mu-plugin est parfait pour les “mini-fonctions” stables : redirections, snippets de perf, petits ajustements admin, etc.

Options : stocker un réglage sans réinventer la roue

On stocke les réglages avec get_option() / update_option() (API Options). Doc : Options API.

Le code utilise une fonction bpcab_safe_snippets_get_settings() qui fournit des valeurs par défaut. Ça évite les notices PHP du type “Undefined index” quand l’option n’existe pas encore.

Admin : menu + page + formulaire

Le hook admin_menu sert à déclarer des pages dans l’admin. Ici on utilise add_management_page() (menu “Outils”).

Le formulaire est envoyé vers admin-post.php avec un champ caché action. WordPress déclenche alors l’action admin_post_{action}. Doc : admin_post_{action}.

Sécurité : permissions + nonce

Deux lignes font la différence entre “ça marche” et “c’est attaquable” :

current_user_can( 'manage_options' ) : seules les personnes avec les droits d’administration peuvent enregistrer.
wp_verify_nonce() : empêche qu’un site externe force votre navigateur à soumettre le formulaire (CSRF).

Doc nonce : Nonces.

Sanitization vs escaping (la confusion la plus fréquente)

Sanitization (entrée) : vous nettoyez ce qui vient d’un formulaire/URL. Exemple : sanitize_text_field().
Escaping (sortie) : juste avant d’afficher, vous échappez pour le contexte HTML. Exemple : esc_html(), esc_attr(), esc_url().

Vous verrez les deux dans le code : on nettoie à l’enregistrement, puis on échappe à l’affichage (double filet de sécurité).

Enqueue : pourquoi WordPress insiste autant

Le hook wp_enqueue_scripts est l’endroit standard pour déclarer CSS/JS côté front. Ça permet :

d’éviter les doublons ;
de respecter l’ordre de chargement ;
de laisser les plugins d’optimisation regrouper/minifier ;
d’être compatible avec les thèmes/builders qui déplacent des blocs.

Docs : Including CSS & JavaScript.

Variantes et cas d’usage

Variante 1 — Mettre le code dans un plugin “classique” (désactivable)

Si vous préférez pouvoir désactiver depuis l’admin (Extensions), créez un plugin standard dans wp-content/plugins/. C’est souvent plus confortable en phase d’essai.

Structure minimale :

wp-content/plugins/bpcab-safe-snippets/bpcab-safe-snippets.php

Le code peut être identique. Seule différence : vous l’activez/désactivez via l’admin.

Variante 2 — Thème enfant pour les modifications liées au design

Si votre code dépend du thème (ex. ajouter une zone de widget, modifier un template, un style spécifique), utilisez un thème enfant. Sinon, vous allez mélanger “fonctionnalité” et “présentation”.

Doc thème enfant : Child Themes.

Variante 3 — Ajouter un shortcode propre (exemple complet)

Cas d’usage : vous voulez insérer un encart réutilisable dans vos pages/articles (et dans un builder) sans dupliquer du HTML.

Ajoutez ceci dans le même mu-plugin (ou votre plugin custom). Le shortcode s’utilise comme [bpcab_notice text="..."].

add_shortcode( 'bpcab_notice', function ( $atts ): string {
	$atts = shortcode_atts(
		array(
			'text' => 'Contenu par défaut',
		),
		(array) $atts,
		'bpcab_notice'
	);

	// Nettoyage et échappement.
	$text = sanitize_text_field( (string) $atts['text'] );

	// Retour (un shortcode doit retourner, pas echo).
	return '<div class="bpcab-notice" style="border:1px solid #dcdcde;padding:12px;border-radius:8px">'
		. esc_html( $text )
		. '</div>';
} );

Doc : Shortcodes API.

Compatibilité Divi 5 / Elementor / Avada

Divi 5

Divi 5 fonctionne très bien avec :

les shortcodes (ex. [bpcab_notice]) via un module “Code” ou “Texte” ;
les hooks WordPress standard (wp_footer, wp_enqueue_scripts).

Piège que j’ai déjà vu : certains réglages de performance/minification (Divi ou plugin tiers) retardent le chargement JS. Avec enqueue, vous avez plus de chances que tout reste stable.

Elementor

Elementor accepte :

un shortcode dans un widget “Shortcode” ;
du CSS chargé via wp_enqueue_scripts ;
des modifications de footer via wp_footer (à condition que le thème appelle bien wp_footer(), ce qui est le cas des thèmes compatibles).

Si vous ne voyez pas votre message en footer, vérifiez que votre thème n’a pas “oublié” wp_footer(). Ça arrive sur des thèmes très custom.

Avada (Fusion Builder)

Avada est généralement compatible avec les hooks WordPress et les shortcodes. Pour insérer un shortcode :

utilisez l’élément “Code Block” ou “Text Block” selon votre configuration ;
ou placez le shortcode dans le contenu d’une page.

Piège courant : cache agressif (Avada + plugin cache). Après activation d’un snippet, videz :

le cache Avada,
le cache du plugin (si présent),
et le cache navigateur.

Vérifications après mise en place

Dans l’admin : allez dans Outils → Snippets sûrs. La page doit s’afficher.
Cochez “Activer le message”, enregistrez. Vous devez voir “Réglages enregistrés.”
Côté front : rechargez une page publique. Le message doit apparaître en bas.
Si vous avez un cache : videz-le et testez en navigation privée.
Regardez wp-content/debug.log (sur staging) : aucune erreur PHP ne doit apparaître.

Tableau de diagnostic rapide

Symptôme	Cause probable	Vérification	Solution
La page “Snippets sûrs” n’apparaît pas	Fichier au mauvais endroit	Le fichier est-il bien dans `wp-content/mu-plugins/` ?	Déplacez `bpcab-safe-snippets.php` dans `mu-plugins`
Écran blanc / erreur 500	Erreur PHP (point-virgule, parenthèse, caractère invisible)	Consultez `debug.log` ou logs serveur	Corrigez la ligne indiquée, ou supprimez le fichier pour restaurer le site
Message footer absent	Option non activée ou cache	Option cochée ? Cache vidé ?	Activez l’option, videz caches, testez en privé
“Nonce invalide”	Page ouverte trop longtemps, cache admin, plugin sécurité	Rafraîchissez la page puis réessayez	Rafraîchir, désactiver temporairement une protection trop agressive
Le CSS ne s’applique pas	Optimisation qui retire le CSS inline	Désactivez minification/combinaison et retestez	Passer à un vrai fichier CSS et l’enqueue proprement

Si ça ne marche pas

Procédure de dépannage (dans l’ordre)

Respirez : 90% du temps, c’est un chemin de fichier ou une erreur de syntaxe.
Vérifiez l’emplacement : wp-content/mu-plugins/bpcab-safe-snippets.php. Pas dans plugins. Pas dans le thème.
Vérifiez PHP : votre serveur est-il en PHP 8.1+ ? (Outils → Santé du site, ou panneau hébergeur). Une version trop ancienne provoque des erreurs sur du code moderne. Doc PHP : Supported Versions.
Activez les logs (sur staging) et lisez wp-content/debug.log.
Désactivez le cache temporairement (plugin cache, cache serveur, CDN) puis retestez.
Testez avec un thème par défaut (si possible sur staging) pour exclure un thème qui ne déclenche pas wp_footer().
Conflits : désactivez temporairement les plugins “snippets”, sécurité, optimisation. J’ai souvent croisé des plugins qui filtrent agressivement admin-post.php.

Si le site est cassé (erreur fatale) et que vous n’avez plus accès à l’admin

Connectez-vous en SFTP.
Renommez le fichier : bpcab-safe-snippets.php → bpcab-safe-snippets.php.off
Rechargez le site : WordPress ne chargera plus ce mu-plugin.
Corrigez ensuite l’erreur à tête reposée (avec logs).

Pièges et erreurs courantes

Erreur	Cause	Solution
Copier le code dans le thème parent	La modification saute à la mise à jour du thème	Utilisez un thème enfant ou, pour les fonctionnalités, un plugin / mu-plugin
Coller du PHP dans l’éditeur “CSS additionnel”	Confusion entre langages	Le PHP va dans un fichier `.php` (plugin/thème), le CSS dans un fichier `.css`
Oublier un point-virgule `;`	Erreur de syntaxe PHP	Lire le log, corriger la ligne, utiliser un éditeur avec coloration/diagnostic
Utiliser un hook inadapté	Ex. charger un script sur `init` au lieu de `wp_enqueue_scripts`	Utilisez les hooks standards : `wp_enqueue_scripts`, `admin_enqueue_scripts`, `wp_footer`
Confondre action et filtre	Un filtre doit retourner une valeur	Avec `add_filter`, faites `return`. Avec `add_action`, vous exécutez sans retourner
Le code “ne marche pas” à cause du cache	Cache plugin/CDN/navigateur	Videz tous les caches, testez en navigation privée, désactivez temporairement la minification
Tester directement en production	Pas de staging, pas de rollback	Créez un staging, ou au minimum une sauvegarde restaurable + accès SFTP
Code d’un ancien tutoriel incompatible	Fonctions obsolètes, patterns anciens, PHP trop vieux	Vérifiez la doc officielle WordPress 6.9+, adaptez, mettez PHP à jour
“Headers already sent”	Espaces/texte avant `<?php` ou sortie avant redirection	Supprimez tout BOM/espaces, évitez `echo` avant `wp_safe_redirect()`

Conseils sécurité, performance et maintenance

Sécurité : vos réflexes minimum

Jamais afficher des données utilisateur sans escaping (esc_html, esc_attr, esc_url).
Pour tout formulaire admin : permission + nonce.
Évitez de stocker des secrets (API keys) en clair dans la base si vous pouvez utiliser des variables d’environnement côté serveur.

Performance : évitez les hooks “trop tôt” et les requêtes inutiles

Ne faites pas de requêtes lourdes sur chaque page si vous pouvez les limiter (ex. seulement si option activée).
Évitez wp_head / wp_footer pour charger des scripts “à la main”. Préférez enqueue.
Si vous ajoutez du code conditionnel, faites des retours rapides (return;) comme dans l’exemple.

Maintenance : rendez vos snippets “supportables”

Préfixez vos fonctions (ex. bpcab_...) pour éviter les collisions avec d’autres plugins.
Commentez en français, surtout les raisons (“pourquoi”), pas seulement le “quoi”.
Versionnez votre mu-plugin (Git) si vous touchez souvent au code.
Gardez un journal des changements : date, raison, lien ticket.

Ressources

FAQ

Est-ce que je peux tout mettre dans functions.php ?

Techniquement oui, mais vous payez en risques : perte au changement de thème, erreurs plus difficiles à isoler, tentation de modifier le thème parent. Réservez functions.php aux ajustements liés au thème (et de préférence dans un thème enfant).

Mu-plugin ou plugin normal : je choisis quoi ?

Mu-plugin si vous voulez que ce soit toujours chargé et “non désactivable” depuis l’admin. Plugin normal si vous êtes en phase d’essai, ou si un client doit pouvoir désactiver facilement.

J’ai un écran blanc, je fais quoi en premier ?

Renommez le fichier du mu-plugin en SFTP pour le désactiver, puis lisez le log (wp-content/debug.log ou logs serveur). Dans 80% des cas : une erreur de syntaxe ou une accolade manquante.

Pourquoi mon CSS/JS ne se charge pas avec mon builder ?

Souvent à cause d’un mauvais hook ou d’un chargement “en dur”. Utilisez wp_enqueue_scripts / admin_enqueue_scripts. Ensuite, videz les caches (builder + plugin cache + CDN).

Dois-je utiliser un plugin de snippets (type “Code Snippets”) ?

Ça peut être pratique, surtout pour activer/désactiver rapidement. Mais j’ai vu des sites se casser après une mise à jour de plugin de snippets ou un conflit. Pour du code “critique”, je préfère un plugin custom versionné, ou un mu-plugin.

Comment éviter qu’un snippet soit exécuté trop tôt ?

Accrochez-le au bon hook. Exemple : ne chargez pas des scripts sur init, utilisez wp_enqueue_scripts. Ne supposez pas que tout est disponible avant plugins_loaded.

Comment savoir quel hook utiliser ?

Commencez par la doc officielle (référence des hooks), puis cherchez dans le code source WordPress (GitHub) où le hook est déclenché. Quand je doute, je fais une recherche dans wordpress-develop sur le nom du hook.

Est-ce que ce guide est compatible WordPress 6.9.4 et PHP 8.1 ?

Oui : le code évite les APIs obsolètes, utilise des fonctions standard et reste compatible PHP 8.1+. Si votre serveur est plus ancien, corrigez d’abord la version PHP.

Puis-je ajouter plusieurs snippets dans le même mu-plugin ?

Oui, mais gardez une structure : une option par feature, des fonctions préfixées, et des blocs clairement séparés. Si ça grossit, passez à un vrai plugin avec fichiers séparés.

Pourquoi vous utilisez admin-post.php et pas l’API Settings ?

Pour un guide débutant, admin-post.php montre clairement le duo “permission + nonce + sanitization”. L’API Settings est excellente pour des pages de réglages complètes, mais elle ajoute une couche de concepts en plus.

Je peux casser mon site même avec un mu-plugin ?

Oui, si vous mettez une erreur fatale. La différence, c’est que vous avez une procédure de rollback très simple : renommer/supprimer le fichier en SFTP. Et vous évitez les mises à jour de thème qui écrasent votre code.