Ancien code PHP après déploiement WordPress : vérifier OPcache et la bonne livraison

Distinguer un ancien résultat d’un ancien programme exécuté

Après le remplacement d’un fichier PHP, WordPress semble conserver le comportement précédent. Une fonction reste absente, un message cite une ancienne ligne ou la correction disparaît selon la requête. OPcache peut intervenir, mais le seul affichage d’une ancienne page ne suffit pas à l’identifier.

OPcache conserve une version compilée du programme PHP pour éviter de le préparer à nouveau à chaque requête. Ce cache de code est différent du cache qui conserve une page HTML ou des données WordPress. Vider les cookies du navigateur ou le cache d’objets ne remet pas nécessairement ces programmes à jour.

Le résultat recherché est que le processus Web utilise la livraison attendue, avec un mécanisme de renouvellement cohérent. Nous allons d’abord confirmer les fichiers et la destination, puis examiner la politique de validation et d’invalidation. Une purge générale ou un redémarrage de tous les services pourrait faire évoluer le symptôme sans expliquer pourquoi la livraison n’a pas été prise en compte.

Confirmer les fichiers et tous les serveurs qui répondent

Dans le processus de déploiement, comparez le fichier prévu et celui réellement installé à son chemin actif. Une copie correcte dans un ancien dossier n’est pas utilisée si le domaine pointe ailleurs. Un lien de livraison peut également viser une autre version que celle consultée dans l’accès aux fichiers.

Si plusieurs serveurs répondent, vérifiez leur cohérence avant d’accuser le cache. Une requête peut atteindre un nœud à jour puis un autre resté sur l’ancienne livraison. Un numéro de version lu sur une seule machine ne décrit pas tout le service.

1. Notez la version livrée, le fichier concerné et le comportement attendu.
2. Confirmez la racine et le chemin réellement utilisés par le domaine.
3. Comparez en privé le contenu et les informations de fichier avec la livraison connue.
4. Faites vérifier chaque nœud actif lorsque l’architecture en comporte plusieurs.
5. Si les fichiers diffèrent, achevez d’abord la livraison cohérente. Ne forcez pas une invalidation pour masquer une copie incomplète ou un mauvais chemin.

Écarter un cache de page avant la couche PHP

Une réponse HTML ancienne peut être servie sans exécuter le fichier que vous venez de modifier. Comparez une requête réellement passée par PHP dans le parcours prévu, à l’aide des journaux privés ou du mécanisme de diagnostic du prestataire. Ne supposez pas qu’un paramètre ajouté à l’URL contourne tous les caches.

Si seule une page conservée est ancienne, traitez sa génération et son invalidation dans le cache de pages concerné. Si un processus qui exécute bien PHP utilise un comportement incompatible avec les fichiers confirmés, le cache de code devient une piste plus pertinente. Les deux phénomènes peuvent coexister.

Conservez l’heure et la requête du contrôle. Évitez de modifier un contenu commercial ou d’envoyer un formulaire pour obtenir une preuve technique : utilisez une copie représentative et une lecture sans effet externe. Une ligne d’erreur peut aussi correspondre à une version antérieure si vous consultez un vieux journal ; vérifiez sa date. Le but est d’établir une différence actuelle entre le code livré et le code utilisé, pas de vider successivement toutes les couches jusqu’à voir une page changer.

Identifier le contexte PHP qui sert le domaine

Relevez la version PHP et le mode d’exécution du site dans les informations disponibles, puis faites confirmer par l’exploitant le service qui traite ses requêtes. Un accès au terminal peut employer un autre exécutable et un autre fichier de configuration. Le résultat d’une commande locale ne prouve donc pas ce que fait le domaine.

Dans le diagnostic privé déjà prévu par l’hébergement ou la chaîne de livraison, demandez la configuration OPcache effective du contexte Web, notamment la validation des dates et sa fréquence. Les fonctions opcache_get_configuration() et opcache_get_status() renseignent l’instance qui les exécute ; la seconde décrit le cache mémoire, pas le cache sur disque. Leur accès peut être restreint par l’exploitant.

Ne créez pas de page publique affichant phpinfo() ou l’inventaire des scripts. Ces informations peuvent exposer des chemins internes. Si aucun outil privé n’est disponible, transmettez au support le domaine, l’heure, le chemin et la version attendue pour qu’il fournisse un relevé ciblé. Conservez séparément les résultats Web et ceux du terminal. Un cache vide observé en ligne de commande n’annule pas l’hypothèse d’un cache Web ancien.

Préparer une modification avec un retour vérifiable

Choisissez une seule hypothèse avant de modifier le service. Si la livraison est incomplète, corrigez les fichiers ; si la politique de déploiement exige une invalidation, examinez cette étape ; si les dates devraient être contrôlées automatiquement, vérifiez les valeurs effectives. Cette décision évite de cumuler une modification de configuration et une purge dont les effets seraient difficiles à séparer.

Conservez une sauvegarde privée de la configuration active et la référence de la livraison actuellement installée. Une copie de préproduction aide à reproduire le comportement, à condition que son mode PHP et sa politique de cache soient comparables. Elle ne garantit pas que la production partage les mêmes réglages.

1. Identifiez le responsable du service PHP et le périmètre des autres sites éventuellement concernés.
2. Notez les valeurs effectives, le fichier ou le panneau qui les impose et la procédure d’application documentée.
3. Préparez le contrôle sans écriture qui montrera la version réellement utilisée.
4. Définissez le retour à la configuration précédente et le responsable de son application.
5. Effectuez une seule correction, puis comparez les résultats au relevé initial avant d’envisager une autre piste.

Rétablir la validation des dates lorsqu’elle est prévue

Quand la validation automatique est activée, OPcache vérifie les changements selon sa fréquence de revalidation. Lorsqu’elle est désactivée, réduire cette fréquence ne résout rien : le déploiement doit renouveler le code par un mécanisme explicite. Confirmez d’abord si cette désactivation était volontaire.

Sur un site dont les fichiers sont remplacés en place et dont la politique prévoit leur détection automatique, l’exploitant peut rétablir les valeurs suivantes dans la configuration PHP appropriée. Deux secondes correspondent ici à la valeur par défaut documentée ; ce n’est pas une promesse que chaque livraison sera entièrement visible dans ce délai. Une fréquence nulle vérifie à chaque requête, avec un coût à évaluer.

Cet exemple est une configuration INI, pas du PHP à coller dans wp-config.php. Ne l’ajoutez pas simultanément à plusieurs fichiers en espérant que l’un soit lu. Dans une livraison volontairement immuable, gardez la politique validée et réparez plutôt l’étape d’invalidation ou le renouvellement du service prévu par l’exploitant.

opcache.validate_timestamps=1
opcache.revalidate_freq=2

Appliquer la configuration dans le service concerné

Un fichier enregistré sur disque et une valeur active sont deux états différents. Le mode de chargement de la configuration dépend de l’intégration PHP. Utilisez le mécanisme documenté de votre hébergement ou de votre exploitation pour appliquer la modification au service qui sert ce domaine, puis relisez la valeur effective dans ce même contexte.

Ne choisissez pas une commande de redémarrage trouvée au hasard : le nom du service, sa version et son périmètre diffèrent selon les installations. Un panneau peut gérer plusieurs versions PHP sur le même serveur. L’opération doit viser celle du site et respecter les autres applications qui en dépendent.

Un retour de succès du panneau signifie d’abord que l’action a été acceptée. Contrôlez ensuite la disponibilité du site, les nouvelles erreurs et le comportement attendu. Si l’application échoue, restaurez la configuration sauvegardée avec la même procédure documentée. Ne laissez pas un fichier invalide en place pour attendre un prochain redémarrage. Si vous ne gérez pas le service, demandez au support la confirmation de la valeur après application plutôt que de multiplier les fichiers de configuration locaux.

Invalider un fichier dans une procédure privée existante

Si le déploiement utilise une invalidation ciblée, faites vérifier son chemin et son contexte d’exécution. L’appel doit atteindre l’instance PHP Web concernée par une procédure privée déjà protégée et administrée. Un appel lancé depuis un terminal ou wp eval peut concerner un autre contexte : sa réussite n’établit pas que les visiteurs utilisent le nouveau programme.

L’exemple suivant illustre l’invalidation d’un fichier connu dans cette procédure existante. Remplacez le chemin par celui du fichier réellement livré. Le second argument demande l’invalidation indépendamment de la comparaison des dates. Selon la documentation PHP actuelle, l’entrée correspondante du cache de fichiers est également invalidée lorsque ce cache est activé.

La valeur de retour ne prouve pas que toute l’application est à jour : une réponse positive peut aussi signifier qu’il n’y avait rien à invalider. Une livraison modifiant plusieurs fichiers doit être traitée de façon cohérente par son responsable. Ne transformez pas cet exemple en fichier public reset.php, en lien accessible anonymement ou en appel exécuté à chaque visite WordPress.

opcache_invalidate( '/chemin/absolu/du/fichier.php', true );

Réserver la remise à zéro générale à un périmètre maîtrisé

Une remise à zéro peut être adaptée à une livraison complète, mais elle doit faire partie d’une procédure connue. opcache_reset() concerne l’ensemble du cache mémoire de son instance et ne supprime pas le cache de fichiers sur disque. Ce n’est donc pas une gomme universelle pour toutes les couches de stockage ni pour tous les serveurs.

Demandez à l’exploitant quelles applications partagent cette instance et quelle opération son infrastructure recommande. Après une remise à zéro, les programmes doivent être préparés de nouveau ; observez la charge et les erreurs pendant cette reprise. Ne répétez pas l’action à chaque rafraîchissement si le résultat tarde : vous pourriez perturber le service sans corriger le mauvais chemin ou le mauvais nœud.

1. Confirmez l’instance et les sites inclus avant toute remise à zéro.
2. Privilégiez le mécanisme privé intégré à la livraison lorsqu’il existe.
3. Vérifiez que l’action a été appliquée au contexte Web attendu.
4. Contrôlez une requête qui exécute le nouveau code après l’action.
5. Si le résultat reste ancien, conservez les preuves et revenez au diagnostic de livraison, de contexte et d’architecture au lieu de programmer des purges répétées.

Traiter le préchargement et les architectures multiples

Le préchargement PHP demande une attention particulière. Des déclarations chargées au démarrage persistent dans le processus ; le manuel indique qu’un redémarrage du processus PHP est nécessaire pour les effacer. Une invalidation ordinaire ne doit pas être présentée comme le remplacement garanti de ces déclarations. Faites confirmer si la livraison utilise réellement opcache.preload avant de retenir cette piste.

Une application peut aussi associer des liens vers des versions successives, plusieurs nœuds et un cache de fichiers. Le chemin logique consulté par l’équipe n’explique pas à lui seul le chemin utilisé par chaque processus. L’exploitant doit examiner cette architecture et son mécanisme de bascule. Ne supprimez pas récursivement des répertoires de cache partagés pour tester une hypothèse.

Si le symptôme alterne, rapprochez les requêtes des nœuds et versions dans les journaux privés. Un serveur oublié peut recréer le problème après une correction parfaitement appliquée ailleurs. La bonne alternative est alors d’achever la livraison et son renouvellement sur toutes les instances prévues. Ajouter une extension WordPress pour purger davantage de données ne remplace pas cette cohérence. Conservez une description courte de l’architecture dans le dossier de déploiement afin que le prochain incident ne reparte pas d’une hypothèse de serveur unique.

Vérifier le code utilisé après la correction

Reprenez le même contrôle qu’au départ sur une requête dont l’exécution PHP est confirmée. Le comportement doit correspondre aux fichiers livrés et rester cohérent lors de plusieurs lectures raisonnablement espacées. Si l’architecture comporte plusieurs nœuds, faites vérifier chacun dans le parcours prévu par l’exploitation ; un succès isolé ne suffit pas.

Examinez ensuite les nouvelles erreurs, sans mélanger les événements antérieurs à la correction. Un ancien numéro de ligne dans une entrée datée d’hier n’invalide pas le résultat actuel. Inversement, un message récent associé à la mauvaise version indique qu’une partie du problème subsiste. Une réponse correcte provenant du cache de pages ne démontre toujours pas quelle version PHP serait exécutée.

1. Notez l’heure de l’action et la livraison attendue.
2. Confirmez les valeurs effectives lorsque la configuration a changé.
3. Exécutez le contrôle de lecture préparé avant l’intervention.
4. Comparez le résultat et les journaux récents sur les instances concernées.
5. Vérifiez un parcours public et un accès d’administration sans opération commerciale.
6. Consignez la conclusion : fichiers corrigés, validation rétablie ou étape de déploiement réparée. Si les preuves restent contradictoires, transmettez-les à l’exploitant sans annoncer la résolution.

Revenir à la livraison précédente sans oublier ses dépendances

Si le nouveau programme produit une erreur fonctionnelle après son chargement réel, le cache a peut-être seulement rendu visible un défaut de la livraison. Revenir à l’ancienne configuration OPcache ne constitue pas un retour applicatif fiable : les processus pourraient garder un mélange de programmes selon leur activité.

Utilisez le mécanisme de retour prévu par votre déploiement pour restaurer une version complète et cohérente, puis appliquez sa procédure de renouvellement du code. Si la mise à jour a aussi modifié la base, examinez la compatibilité de cette base avec l’ancienne version. Restaurer seulement quelques fichiers peut aggraver une migration inachevée. Le responsable doit choisir une restauration coordonnée à partir de sauvegardes vérifiées lorsque c’est nécessaire.

Pour une modification de configuration seule, remettez les valeurs sauvegardées, appliquez-les par le mécanisme documenté et relisez leur état effectif. Contrôlez ensuite la disponibilité et les erreurs récentes avec le même protocole. Gardez les différences et horaires dans le dossier privé ; ils permettent de comprendre si l’échec venait du code, de son chargement ou du service. Une purge ne répare ni les données déjà modifiées ni les messages déjà envoyés par une version défectueuse.

Prévenir le retour d’un ancien code à la prochaine livraison

Documentez une seule politique de renouvellement par environnement. L’équipe doit savoir si PHP détecte les fichiers modifiés ou si une étape explicite accompagne chaque livraison. Une option désactivée volontairement peut être parfaitement cohérente avec une infrastructure donnée ; elle devient un incident lorsque la procédure qui la compense disparaît du déploiement.

Ajoutez au contrôle de livraison un résultat observable de la version attendue, sans publier de chemins sensibles ni de données d’exploitation. Vérifiez aussi les retours à la version précédente : leur étape de renouvellement mérite le même soin que la mise en place initiale. Conservez l’inventaire des nœuds et du service PHP avec les accès réservés aux responsables.

Ce diagnostic ne demande pas d’installer une nouvelle extension de cache. Les outils natifs de l’exploitant, une comparaison des fichiers et une procédure de livraison cohérente répondent au problème identifié. Si seuls des visiteurs voient une page ancienne alors que PHP exécute le bon programme, reprenez le diagnostic du cache de pages et de sa portée. Si une erreur récente persiste avec la bonne version, traitez cette erreur de code séparément : renouveler OPcache de nouveau ne change pas un programme déjà chargé correctement.