Erreur 500 lors de la mise à niveau vers PHP 8

 
 
Erreur 500 lors de la mise à niveau vers PHP 8

En novembre de l’année dernière pHP 8 débarqué. J’ai annoncé quelques améliorations de performance, de vitesse et de sécurité.

Comme tout bon bricoleur, j’ai couru pour mettre à niveau la 7.4, plus précisément la 7.4.16, la version qui tourne actuellement sur le serveur.

plof ! une belle erreur 500 m’accueille et casse tout le site. Aucune URL ne se résout.

J’ai fait le test typique pour désactiver tous les plugins et utiliser le modèle par défaut. L’erreur 500 ne disparaissait pas.

J’ai été choqué, mais j’ai passé l’affaire en étant convaincu qu’il était encore trop tôt pour effectuer une mise à jour et, comme ils l’ont conseillé, la meilleure chose à faire était d’attendre que tous les auteurs de plugins et de modèles mettent à jour leur code pour le rendre compatible avec PHP 8

Près de sept mois plus tard, j’ai réessayé et l’erreur 500 était toujours là.

Le premier indice que l’origine de l’erreur se situe uniquement dans ce blog est que dans les deux autres installations WordPress que j’ai sur le même serveur, tout fonctionne correctement.

Comme une erreur 500 peut apparaître pour de nombreuses raisons. L’étape logique suivante consiste à consulter les journaux d’erreurs pour essayer de trouver ce qui ne va pas. Vous obtenez une série d’avertissements comme celui-ci :

PHP Warning: Use of undefined constant minor – assumed ‘minor’ (this will throw an Error in a future version of PHP) in /home/xxxxxx/public_html/blog/wp-config.php on line 11

Avertissement PHP : Utilisation de la constante non définie minor – supposée ‘minor’ (ceci entraînera une erreur dans une future version de PHP).

C’est-à-dire que la constante est censée être entourée de guillemets. Je vais dans wp-config.php et bien sûr, mineur apparaît sans guillemets sur cette ligne

define (‘WP_AUTO_UPDATE_CORE’, minor);

En cherchant dans le forum WordPress, je trouve que beaucoup de personnes ont eu ce même problème en mettant à jour également les versions précédentes de PHP en raison de conflits avec un plugin ou un template.

On ne peut pas non plus exclure que le problème soit lié à l’installation de WordPress ; j’ai quelque chose de cassé, comme on me l’a dit dans un ticket que j’ai envoyé à LucusHost.

Dans certaines des réponses que vous recevez, il est dit que pour résoudre le problème, il suffit d’ajouter les guillemets à ‘minor’, alors essayez et c’est ce que je fais.

define (‘WP_AUTO_UPDATE_CORE’, ‘minor’);

WP_AUTO_UPDATE_CORE vous permet de contrôler les mises à jour du noyau de WordPress pour les versions mineures, majeures et de développement. Cette constante peut être définie de plusieurs façons. La suppression de cette ligne n’est pas une bonne idée.

#Disables all core updates:

define( ‘WP_AUTO_UPDATE_CORE’, false );

# Enable all updates, including minor and major updates:

define( ‘WP_AUTO_UPDATE_CORE’, true );

# Enables minor updates:

define( ‘WP_AUTO_UPDATE_CORE’, ‘minor’ );

Bonne et mauvaise nouvelle.

La bonne nouvelle est que maintenant, en utilisant PHP 8, l’erreur 500 a disparu.

Tout semble fonctionner correctement à première vue, tant les plugins que les postes.

La mauvaise nouvelle est que l’index est cassé et ressemble à ceci.

Erreur 500 lors de la mise à niveau vers PHP 8

J’ai décidé d’attaquer d’abord le modèle de courrierligne, réalisée avec Elementor Proau cas où le constructeur aurait laissé des déchets cachés, mais après l’avoir parcouru et refait entièrement, j’ai exclu que l’erreur vienne de là.

Maintenant, je suis toujours en train d’expurger le modèle (GeneratePress Premium) dans un environnement de test et au moins je sais où il se brise, mais je cherche surtout dans WordPress, qui est, je pense, le nœud du problème, un code périmé traîné, un filtre bouché par la graisse ou autre.

Je laisse cette note ici au cas où quelqu’un aurait eu un problème similaire et que cela lui soit utile, ou s’il en sait beaucoup sur WP et peut fournir quelques indices supplémentaires pour le résoudre.

Dès que je trouve le correctif définitif et l’explication possible, je mettrai ce post à jour.

Mise à jour

Le journal des erreurs, après avoir activé le DEBUG, donne des indices que GeneratePress se plante quelque part, peut-être à cause d’un hook ou d’un filtre que j’ai mis dans son module Elements (ou autre)

Comme j’ai un modèle enfant de GeneratePress, je suis perdu et je ne sais pas où aller d’ici, mais comme j’ai quelques soupçons, je ne considère pas encore la mission comme ratée.

Fatal error : Uncaught TypeError : Unsupported operand types : string + int in /home/ public_html/blog/wp-content/themes/generatepress/inc/structure/post-meta.php:169 Stack trace : #0

/home/ public_html/blog/wp-content/themes/generatepress/inc/structure/post-meta.php(419) : generate_do_post_meta_item() #1

/home/ public_html/blog/wp-content/themes/generatepress/inc/structure/post-meta.php(538) : generate_posted_on() #2

/home/ public_html/blog/wp-includes/class-wp-hook.php(292) : generate_post_meta() #3

/home/ public_html/blog/wp-includes/class-wp-hook.php(316) : WP_Hook->apply_filters() #4

/blog/wp-includes/plugin.php(484) : WP_Hook->do_action() #5

/blog/wp-content/themes/generatepress/content.php(48) : do_action() #6

/blog/wp-includes/template.php(732) : require(‘/home/ …’) #7

/blog/wp-includes/template.php(676) : load_template() #8

/blog/wp-includes/general-template.php(204) : locate_template() #9

/blog/wp-content/themes/generatepress/inc/theme-functions.php(587) : get_template_part() #10

/blog/wp-content/themes/generatepress/index.php(37) : generate_do_template_part() #11

/blog/wp-includes/template-loader.php(106) : include(‘/home/ …’) #12

/blog/wp-blog-header.php(19) : require_once(‘/home/ …’) #13

/blog/index.php(17) : require(‘/home/ …’) #14

{main} lancé dans /blog/wp-content/themes/generatepress/inc/structure/post-meta.php sur la ligne 169

c’est réparé ! Eh bien, presque

Heureusement, la première ligne était la clé, c’est là que toutes les erreurs de cette longue liste ont été déclenchées :

Fatal error : Uncaught TypeError : Unsupported operand types : string + int in /home/ public_html/blog/wp-content/themes/generatepress/inc/structure/post-meta.php:169

Erreur 500 lors de la mise à niveau vers PHP 8

Le mystère de l’erreur résidait dans une opération non prise en charge de ce fichu get_the_time

Pour faire le lien, les soupçons sont confirmés. L’erreur a été causée par ce snippet de fonction que j’ai utilisé pour afficher le jour et l’heure de la mise à jour comme une extension de la méta-date.

Pour couronner le tout, je ne sais pas comment, mais il est resté résident après avoir désactivé Extraits de code et de vider le cache.

Erreur 500 lors de la mise à niveau vers PHP 8

Morale de l’histoire, n’utilisez pas des fonctions qui fonctionnent bien pour d’autres car chaque page a son histoire particulière et il est très probable qu’elles finissent par mettre le bazar si vous les oubliez, mettez à jour WP, PHP, un template ou un plugin et qu’elles ne sont plus compatibles.

En supprimant ce snippet, tout fonctionne bien et la page d’accueil est redevenue normale.

Pas de deux sans trois, une autre erreur. Maintenant Feedzy

Mais ne partez pas encore, car maintenant le plugin Feedzy (je suppose) ou quelque chose de connexe casse la page des nouvelles.

Erreur 500 lors de la mise à niveau vers PHP 8

Je dois ouvrir un ticket de support, car il s’agit d’une version payante, pour faire savoir aux développeurs du plugin s’il est 100% compatible avec PHP 8 (et s’il casse parce qu’il ne l’est pas) ou pour obtenir un indice de leur part.

02/07/2021 – Feedly a reproduit l’erreur fatale en utilisant PHP 8 et a transféré le problème à ses développeurs. Nous devons maintenant attendre qu’ils publient une nouvelle version du plugin qui corrige le problème.

05/07/2021-La description du bug est ici vous pouvez trouver dans leur Github.

06/07/2021 – Bien qu’ils n’aient pas encore répondu ou publié une nouvelle version avec le correctif, dans ce commit ils ont déjà les lignes de code qui le corrigent. Je l’ai testé et, en l’absence d’un bon test approfondi, il semble que PHP 8 ne casse plus rien.

Pour récapituler

Pas mal. Passer d’une erreur 500 qui a cassé tout le blog à une erreur uniquement dans la page d’accueil et enfin dans une seule page« secondaire » pour finir par trouver une solution est suffisant pour être satisfait des heures investies dans la réparation.

La clé de tout est dans la recherche, passez tout votre temps à chercher l’origine et ce qu’elle provoque dans d’autres parties de votre blog. Ne vous lancez pas dans l’essai de solutions rapides sans avoir suffisamment d’indices, car vous perdrez votre temps ou, dans le pire des cas, vous casserez autre chose.

Je ferai une nouvelle mise à jour lorsque j’aurai réussi à battre le nouveau bug avec Feedzy ou quoi que ce soit d’autre cette fois-ci.


Suscríbete por email para recibir las viñetas y los artículos completos y sin publicidad
Artículos relacionados