Définir le résultat et conserver le fichier reçu
Un assistant IA vous a proposé du PHP pour ajouter une mention à une page WordPress. Avant de choisir où le placer, écrivez ce que le code doit faire en une phrase vérifiable. Dans notre exercice, un paragraphe « Repère local PHP 731 » doit apparaître une fois en fin de contenu sur la page « Atelier test PHP », sur une copie locale. La page voisine doit rester identique. Le texte saisi dans l’éditeur doit rester inchangé. Après désactivation, le paragraphe doit disparaître sans restauration de la base.
Ces critères séparent trois contrôles. Le premier dit si PHP peut analyser le fichier. Le deuxième dit si WordPress exécute le code au bon moment et dans le bon périmètre. Le troisième dit si vous pouvez arrêter son effet et, lorsque le code a modifié des données, les remettre dans l’état attendu. Une réponse positive à l’un ne préjuge pas des deux autres.
Conservez le fichier reçu dans un dossier local de travail et faites une seconde copie pour vos corrections. Notez la date, la provenance, l’effet attendu et la version de WordPress visée. Ne placez encore aucun de ces fichiers sous le répertoire servi par WordPress. Si plusieurs extraits sont proposés, séparez-les et commencez par un seul. Vous pourrez ainsi relier une différence visible à la version exacte qui l’a produite.
Un simple ajout de texte peut se faire directement dans le bloc Paragraphe. Si cela répond au besoin réel, cette solution évite une dépendance au PHP. Le cas ci-dessous utilise volontairement un filtre pour apprendre à contrôler le moment où le code intervient. Remplacez le cas d’école par votre propre objectif seulement après avoir reproduit les vérifications avec des données fictives.
Lire les effets avant d’exécuter le code
Cherchez d’abord la première instruction qui s’exécute au chargement du fichier, puis les fonctions raccordées à WordPress. Une action ou un filtre est un point d’entrée que WordPress appelle à un moment précis. Pour chaque point d’entrée, identifiez les pages ou opérations concernées, les conditions qui doivent être vraies et ce que la fonction renvoie ou modifie. Un commentaire peut annoncer « uniquement sur cet article » alors que le code ne vérifie jamais l’article courant.
Distinguez une chaîne renvoyée pour l’affichage d’une écriture durable. Un appel à update_option(), à wp_update_post() ou à la couche de base de données peut changer l’état même si la page reste visuellement identique. Relevez aussi les tâches planifiées, les créations de comptes, les suppressions de fichiers et les opérations au moment de l’activation. Demandez-vous pour chacune quel élément exact serait affecté, avec quelles autorisations et quelle opération inverse. Pour un formulaire ou une action administrateur, l’autorisation et la protection contre une requête forgée sont deux vérifications distinctes.
Repérez les sorties possibles. Un envoi de courriel, une requête HTTP ou un appel d’API peut partir dès le premier affichage. Un code qui assemble dynamiquement le nom des fonctions, décode un bloc opaque ou charge un fichier que vous ne pouvez pas lire ne permet pas cette relecture. Une liste de fonctions suspectes aide à s’orienter mais ne suffit pas à prouver l’innocuité. Examinez aussi les fonctions appelées indirectement et les fichiers inclus. Si vous ne pouvez pas expliquer un effet ou une destination, arrêtez-vous à la lecture.
Gardez le code et les observations dans vos fichiers locaux. N’envoyez ni extrait, ni journaux, ni copie de la base à un correcteur PHP en ligne ou à un assistant. Même un fichier banal peut contenir un domaine privé, des chemins internes ou une valeur qui donne accès à un service. Consultez une référence publique par son nom de fonction lorsqu’il manque une information.
Contrôler la syntaxe avec le bon PHP
Si vous avez un terminal et un interpréteur PHP local, placez-vous dans le dossier de travail où se trouve atelier-test-php.php. Sous PowerShell, Get-Command php vous aide à repérer le programme utilisé. La version CLI est celle de la ligne de commande. Comparez au minimum sa version majeure et mineure avec celle que WordPress indique dans Outils → Santé du site → Informations → Serveur sur l’environnement visé. Une copie qui utilise une version plus récente que la cible peut accepter une syntaxe que la cible refuse. Utilisez si possible la même version et notez aussi la version précise et les extensions nécessaires.
Les deux commandes ci-dessous sont indépendantes. La première donne la version, la seconde demande à PHP d’analyser le fichier sans l’exécuter. Dans PowerShell, $LASTEXITCODE lu juste après le contrôle donne le statut de la commande. Dans un terminal compatible POSIX, utilisez echo $?. Attendez un statut zéro et le message de réussite. Si le terminal ne trouve pas PHP, utilisez le chemin de l’interpréteur de votre environnement local ou demandez le contrôle à la personne qui dispose de cette version. N’utilisez pas un service de vérification en ligne en remplacement.
Le fichier d’une extension commence par <?php. Si le code reçu est destiné à un champ qui entoure lui-même le PHP, fabriquez un fichier de travail avec une seule balise ouvrante pour le contrôler. Sans balise ouvrante, PHP peut traiter le texte comme du contenu ordinaire et annoncer qu’il n’a trouvé aucune erreur alors que les instructions n’ont pas été analysées. Contrôlez le fichier final, et relancez le contrôle pour chaque autre fichier PHP livré avec lui. En cas d’erreur, corrigez une chose à la fois, relisez aussi la ligne précédente et vérifiez de nouveau.
Un lint réussi ne vérifie pas que les fonctions WordPress existent, que le bon nombre d’arguments est fourni au moment réel de l’appel, ni que les requêtes et les droits sont appropriés. Il ne vérifie pas davantage ce qu’un fichier inclus fera une fois chargé. Ne lancez pas php atelier-test-php.php pour essayer un extrait inconnu. L’étape suivante se fait dans un environnement WordPress isolé après relecture.
php -v
php -l atelier-test-php.phpPréparer une copie sans données sensibles
L’option la plus simple est un WordPress neuf sur votre machine, avec deux pages fictives et aucun connecteur réel. Installez les versions du thème ou des extensions dont dépend le comportement, à partir de fichiers autorisés, puis déconnectez les intégrations de test. Si la panne n’existe qu’avec une configuration particulière, reproduisez cette configuration avec des entrées factices. Une copie des réglages utiles suffit souvent. Si une vraie copie est indispensable, travaillez avec une version assainie avant de démarrer WordPress et conservez-la sur votre machine.
Vérifiez l’URL locale, la séparation de la base et du dossier de fichiers ainsi que l’absence d’identifiants de services réels. Une base partagée avec le site en ligne annule l’isolation. Une adresse qui ressemble à une préproduction ne suffit pas non plus. Désactivez les envois externes et les intégrations de paiement, de CRM ou de synchronisation sur la copie. Bloquez les sorties réseau de l’environnement de test si vous examinez du code qui n’a pas encore fait ses preuves. Un réglage WordPress de blocage HTTP ne couvre pas à lui seul toutes les façons dont du PHP pourrait établir une connexion. L’exercice ci-dessous se fait sans aucun envoi ni service.
Dans le wp-config.php de la copie seulement, recherchez WP_ENVIRONMENT_TYPE. Si la constante est absente et que votre configuration le permet, ajoutez define( 'WP_ENVIRONMENT_TYPE', 'local' ); avant le chargement de wp-settings.php. Si elle existe déjà, vérifiez la valeur et évitez une seconde définition. Cette valeur est un repère lu par le code, elle n’isole pas la machine. Vérifiez séparément l’adresse et la base. Si la copie est gérée et que vous ne pouvez ni la configurer ni arrêter un chargement, choisissez un WordPress local neuf.
Prenez un point de retour avant activation, avec les fichiers et l’état de la base de test si vous avez prévu des écritures. Pour cet exemple d’affichage, gardez surtout le moyen d’accéder au dossier de l’extension sans ouvrir l’administration. Ouvrez cet emplacement avant le premier essai. Notez aussi les versions du thème et des extensions qui pourraient modifier le même contenu.
Construire le témoin sur une seule page
Dans Pages, créez « Atelier test PHP » et « Page témoin PHP ». Réglez la première pour que son identifiant d’URL soit exactement atelier-test-php. Donnez à chacune un paragraphe distinct, puis publiez ces deux pages uniquement dans la copie locale isolée. Rouvrez la page cible dans Pages → Toutes les pages. Dans l’adresse de son écran de modification, notez le numéro qui suit post=. Remplacez 314 dans 314 !== get_queried_object_id() par ce numéro local, sans guillemets. La comparaison porte directement sur l’identifiant WordPress. Un autre titre ou un autre identifiant d’URL, même numérique, ne peut pas être pris pour cette page. Ouvrez-les en visiteur avant l’essai et cherchez « Repère local PHP 731 ». Il doit être absent des deux. Prenez une note de ce que vous voyez sous le paragraphe, par exemple le début du pied de page, pour repérer un éventuel ajout au mauvais endroit.
Le fichier suivant constitue une petite extension ordinaire. Sauvegardez-le en UTF-8 sans marque d’ordre des octets, sans ajouter de balise PHP fermante. Contrôlez le fichier exact avec le lint puis, dans la copie seulement, placez-le à wp-content/plugins/atelier-test-php/atelier-test-php.php si votre installation utilise les chemins par défaut. Dans le cas d’un répertoire de contenus déplacé, trouvez d’abord le vrai dossier des extensions. Gardez un exemplaire contrôlé hors de ce dossier. Quand le fichier est en place, le libellé « Atelier test PHP » doit figurer dans Extensions → Extensions installées.
Le code retourne sans s’enregistrer hors de l’environnement local. Dans la copie, il ajoute le texte au résultat du filtre the_content seulement dans la boucle principale de la page demandée. La comparaison entre le contenu courant et l’objet demandé écarte aussi une autre fiche dont le contenu serait évalué au milieu de la page. Le test de l’API REST écarte ce contexte lorsque WordPress l’a signalé. Rien ici ne modifie l’article enregistré. Si vous voulez faire apparaître une phrase sur une page réelle, utilisez une solution validée pour ce besoin. L’extension de l’exercice est conçue pour rester dans le bac à sable.
<?php
/**
* Plugin Name: Atelier test PHP
* Description: Témoin d’affichage sur une seule page d’une copie locale.
*/
if (
! defined( 'ABSPATH' ) ||
! function_exists( 'wp_get_environment_type' ) ||
'local' !== wp_get_environment_type()
) {
return;
}
add_filter( 'the_content', static function ( $content ) {
if (
is_admin() || is_feed() || is_embed() ||
( defined( 'REST_REQUEST' ) && REST_REQUEST ) ||
! is_page() || 314 !== get_queried_object_id() ||
! in_the_loop() || ! is_main_query() ||
get_the_ID() !== get_queried_object_id()
) {
return $content;
}
return $content . '<p>Repère local PHP 731</p>';
} );Comparer les cas positifs et négatifs
Activez « Atelier test PHP » dans la liste des extensions de la copie. Chargez la page cible en visiteur, puis la page voisine dans le même navigateur. Recommencez sur une session connectée. Une phrase visible dans la page cible permet de confirmer le cas positif, à condition qu’elle ne soit présente qu’une fois et au bon emplacement. L’autre page, la liste de pages et les zones autour de l’article servent de témoins négatifs. Ouvrez ensuite la page cible dans l’éditeur. Le marqueur doit rester absent du texte enregistré.
Si l’administration indique « active » mais que le repère manque, vérifiez l’adresse, le numéro de page dans le fichier et le type d’environnement avant de toucher au filtre. Inspectez aussi le rendu du thème. Un modèle qui ne passe pas par le contenu principal peut ne jamais appeler ce filtre dans les conditions attendues. Comparez au besoin avec un thème standard sur la copie seulement, puis rétablissez le thème initial. Une différence entre deux thèmes signale une dépendance de rendu à expliquer. Elle ne justifie pas d’enlever les conditions jusqu’à ce que du texte apparaisse quelque part.
Si un message d’erreur apparaît, notez l’heure et la page demandée, puis relevez le premier message correspondant dans le journal PHP local. Avec le débogage WordPress, gardez l’affichage des erreurs désactivé côté visiteur et choisissez un journal privé. Désactivez ce réglage de diagnostic quand il n’est plus nécessaire. Une erreur de fonction inconnue après un lint propre se rattache souvent à un mauvais contexte de chargement ou à une dépendance absente. Un HTTP 200 sans le résultat prévu est également un échec. Vous validez le résultat et son périmètre en plus du chargement.
Si l’objectif réel concerne un formulaire, un rôle ou une commande, remplacez cette comparaison par des cas équivalents. Utilisez par exemple un utilisateur factice autorisé et un autre qui ne l’est pas, puis vérifiez qu’aucune action n’a lieu pour le second. Pour une modification enregistrée, notez en plus l’état avant et après sur chaque objet concerné. Un essai de l’affichage ne couvre ni l’autorisation, ni la persistance, ni les traitements qui peuvent arriver plus tard.
Choisir le mode de chargement
L’extension ordinaire convient quand vous avez accès aux fichiers de la copie et que le code doit agir indépendamment du thème. Elle donne un nom à la modification, un fichier à comparer et un interrupteur dans Extensions. Placez le code dans son propre dossier. Évitez le fichier d’une extension tierce et les fichiers du cœur, qui peuvent être remplacés par une mise à jour. Un chargement obligatoire depuis mu-plugins ne propose pas le même interrupteur. Pour un premier essai, gardez le fichier sous le dossier des extensions ordinaires.
Si votre équipe gère déjà des extraits dans une interface dédiée, vous pouvez utiliser ce même circuit sur la copie. Créez une entrée inactive, identifiez la portée d’exécution et contrôlez séparément une éventuelle option qui force un chargement partout. Lisez les instructions de votre outil sur les balises PHP. Le fichier complet ci-dessus comporte un en-tête destiné à WordPress et une balise d’ouverture ; il n’est pas à coller tel quel dans un champ dont l’éditeur ajoute déjà la balise. Dans cette approche, le retour consiste à désactiver l’entrée précise. Assurez-vous de connaître la procédure documentée de secours si cet écran devient inaccessible. La présence d’un contrôle intégré à l’éditeur ne remplace ni le lint du fichier de travail, ni les témoins sur la copie.
Si le besoin est attaché à un modèle de thème, un thème enfant peut convenir lorsque ce thème enfant est déjà maintenu par l’équipe. Cette voie demande de comparer le fichier concerné avec une version connue et de pouvoir la restaurer depuis les fichiers. N’ajoutez pas le filtre d’exercice à functions.php pour essayer. Un mauvais essai dans ce fichier peut empêcher tout le thème de se charger et le retour porte alors sur le fichier entier. Pour un changement purement éditorial ou de style, cherchez d’abord le réglage du bloc ou du modèle qui obtient le résultat sans PHP.
Sur WordPress.com ou un hébergement administré, les possibilités d’installation et d’accès aux fichiers dépendent de l’offre et de la configuration. En multisite, un test sur un seul sous-site ne vérifie pas une activation réseau. L’exercice est prévu pour une installation locale simple. Si l’environnement réel diffère sur un point qui conditionne l’effet, notez-le comme une limite du test.
Répéter le retour arrière avant de décider
Tant que l’administration de la copie répond, allez dans Extensions → Extensions installées et cliquez sur Désactiver pour « Atelier test PHP ». Rechargez la même page cible sans réutiliser une réponse mise en cache, puis la page voisine et l’éditeur. Le repère doit disparaître sur la cible ; les autres contenus doivent rester tels qu’ils étaient. Si le marqueur persiste, vérifiez d’abord si la réponse est ancienne ou si une seconde copie du code est chargée dans le thème ou dans un gestionnaire d’extraits. Ne supprimez pas de page pour faire disparaître un paragraphe ajouté au rendu.
Si l’administration ne répond plus, utilisez le gestionnaire de fichiers de la copie. Renommez uniquement le dossier atelier-test-php en atelier-test-php-arret sous le dossier des extensions, puis ouvrez Extensions → Extensions installées et rechargez la page cible et la page témoin. WordPress ne retrouve plus le fichier au chemin qu’il utilisait. Vérifiez le statut de l’extension avant de remettre le nom initial et gardez-la inactive jusqu’à ce que l’erreur soit comprise. Cette manœuvre concerne l’extension ordinaire de l’exercice. Pour du code également chargé par le thème, un chargement obligatoire ou un autre outil, déplacez ou restaurez le fichier réellement en cause selon sa procédure propre.
Si WP-CLI est déjà disponible sur la copie, vous pouvez désactiver l’extension précise en demandant au programme de démarrer sans la charger. Exécutez la commande ci-dessous depuis le dossier de cette installation locale après avoir confirmé que c’est la bonne cible. L’option de saut ne désactive pas l’extension à elle seule. Si une autre cause bloque encore WP-CLI, repassez par les fichiers. N’utilisez ni une désactivation en bloc, ni une option réseau pour ce cas.
Désactiver le code coupe son exécution future. Une option, un article ou un fichier qu’il a déjà changé peut rester modifié. Pour un vrai extrait qui écrit, il faut donc une seconde étape de remise en état : remettre la valeur ou la version antérieure de l’élément touché, ou restaurer l’instantané prévu sur la copie et vérifier son contenu. Un courriel déjà expédié ou une opération effectuée par un service distant ne s’annule pas avec un clic sur Désactiver. C’est précisément pourquoi les sorties restent neutralisées lors des essais. Ici, le retour est limité au chargement du filtre, car le code n’effectue aucune écriture.
wp plugin deactivate atelier-test-php --skip-plugins=atelier-test-phpSavoir quand écarter l’extrait
Gardez une petite fiche avec le fichier exact contrôlé, les versions, l’adresse locale de la page cible, le cas témoin, les résultats avant et après activation et le résultat après arrêt. Notez si vous avez seulement lu une dépendance ou si vous l’avez réellement exercée. Une fonction dont la syntaxe est valide peut encore échouer lorsque le site reçoit une donnée vide, un compte non autorisé ou un cas absent de la copie. Ajoutez ces cas lorsqu’ils sont plausibles pour votre changement.
Si le code déborde du périmètre, si vous ne savez pas quelle donnée a changé, ou si la procédure d’arrêt dépend d’un accès que vous n’avez pas, conservez l’extrait inactif. Faites de même lorsque le résultat repose sur une version PHP, un thème ou un plugin que vous n’avez pas pu reproduire. Pour transmettre une demande à votre équipe, décrivez d’abord l’effet attendu, la condition qui échoue et le message d’erreur réduit au nécessaire, selon vos règles internes. Il n’est pas nécessaire de fournir une exportation du site à un assistant pour constater que le test ne passe pas.
Votre décision porte sur la version contrôlée. Si quelqu’un renomme la fonction, ajoute un fichier inclus ou déplace l’extrait vers un gestionnaire qui le charge plus tôt, recommencez le contrôle de syntaxe, les témoins et le retour arrière. Dans le cas d’école, le résultat attendu est simple à relire : un seul paragraphe ajouté au rendu de la page fictive, aucun changement enregistré et un retrait vérifié sur la copie.
