Je viens ici partager mon expérience suite à une migration de mon site SPIP entre l’hébergeur Proxgroup et Pulseheberg.
Depuis la migration nous obtenions une erreur 503 lors des tentatives d’accès au Backoffice, alors qu’apparemment les environnements étaient sensiblement les mêmes sous PHP 8.0 / Mysql.
Le support technique après une longue recherche a identifier une ligne dans le code SPIP qui posait problème et je vous le partage ici pour information :
Citation
Après beaucoup de recherches, et en remontant tout le code PHP de SPIP en sens inverse, j’ai réussi à trouver l’origine de l’erreur : C’était une instruction PHP « eval() », visiblement mal formée, qui faisait planter SPIP.
Je ne sais pas trop pourquoi cette instruction fonctionnait avant, et plus maintenant, peut-être que nos infrastructures sont plus strictes au niveau de cette erreur, mais ça me paraît étonnant.
Pour esquiver l’instruction, j’ai modifié la première ligne des fichiers /prive/squelettes/inclure/barre-nav.html. J’ai remplacé la ligne
Bienvenue MrRon
C’est dans le squelette prive/squelettes/inclure/barre-nav.html ?
Dans spip 404, c’est en 1ère ligne de ce squelette,
et donc #GET{contexte} est vide à cet endroit, voir null.
Donc ton code est équivalent au code plus simple : #SET{contexte,#REM|definir_barre_contexte}
ou #SET{contexte,#VAL|definir_barre_contexte}
Par contre ce n’est pas équivalent à la version originale, car cette dernière fait le calcul à chaque affichage de la page alors que la tienne met le résultat en cache.
Tu dit PHP 8, mais c’est quelle version de SPIP ?
Ceci dit je vois pas le rapport avec une erreur 403.
Oui c’est bien dans le fichier squelette :
prive/squelettes/inclure/barre-nav.html
Que se trouve une instruction EVAL() qui bloquait l’affichage du backoffice après l’authentification et redirigeait sur une page erreur serveur 503 (et non 403).
Je ne suis pas compétent sur ces questions de code mais la modification de la ligne a permis de résoudre le pb d’accès au backoffice.
Peut-être faudrait-il optimiser cette ligne de code pour une prochaine mise à jour de Spip?
Le 05/02/2022 à 05:47, MrRon via Discuter de SPIP a écrit :
Peut-être faudrait-il optimiser cette ligne de code pour une prochaine mise à jour de Spip?
Bé non puisque ça ne fait ça absolument que chez toi, ça marche bien chez des dizaines/centaines d’autres sites, donc c’est pas forcément cette ligne le problème, il faut creuser plus. On ne peut corriger une chose que si on arrive à reproduire le même type d’erreur.
Notamment en quoi cet eval() serait « mal formé » ? Son contenu n’est pas mal formé du tout, puisque c’est un simple appel de fonction, c’est parfaitement ok de mettre ça à l’intérieur d’un eval.
Le contexte en question ne doit surtout pas être mis en cache puisqu’il doit dépendre de la page en cours. Il ne faut donc surtout pas transformer ça en simple appel de filtre.
Et ça fait 11 ans que ça marche bien chez tout le monde :
Si tu gardes ta version modifiée, ajoute #CACHE{0} au début de ton squelette modifié. C’est pas du tout recommandé pour la charge du serveur mais comme ça tu auras les mêmes résultats générés qu’avec le #EVAL.
