Error 500 au-delà d'un certain volume de texte

Général
#1

Bonjour,
Sur SPIP 4.2.8 + PHP8.1 chez OVH.
Une situation totalement insolite pour moi: après avoir chargé un nouvelle article, je me suis rendu compte, qu’à l’exception de la session du navigateur utilisé pour éditer l’article (Firefox), donc mémorisant la session, la page retournait systématiquement une Error 500.

Tous les autres articles publiés jusque-là, utilisant exactement les mêmes conditions s’affichent normalement. Je ne suis pas au bout de l’espace de stockage, j’ai vérifié les droits, j’ai vidé caches et fichiers temporaires. Rien à faire.

Ce n’est qu’en remettant le contenu de la page petit à petit que je suis arrivé au constat que la page plantait si j’intégrais le texte au-delà d’un certain volume (ou d’un certain type de contenu que je n’ai pas réussi à identifier).
J’ai fait un test en publiant un autre texte, beaucoup plus long, après et ça s’affichait normalement.

J’ai caché la misère en ajoutant un fichier joint au format texte :no_mouth:

La page est disponible ici:

Bien cordialement

#2

Erreur 500 → erreur Fatal PHP dans 99% des cas. Il faudrait voir au niveau de ton hébergeur si tu a accès aux LOG php pour connaitre l’erreur fatale en question.

En attendant ton texte est d’une taille plus que raisonnable, et je ne vois pas pourquoi cela buguerait. Je supputerai plutot un problème de caractère spéciale, mais je ne reproduis pas en local.

Donc : difficile de dire sans aoir l’historique des logs PHP.

#3

Il est possible que je me trompe mais les seuls log d’erreur que j’ai trouvé chez OVH ne sont pas des log php. Il s’agit d’une liste de "script not found or unable to stat: " indiquant à chaque fois l’adresse IP du client, le host et suivi du chemin d’accès du fichier.

À l’endroit où la page commence à retourner l’erreur 500 j’ai effectivement inséré dans mon texte le raccourci « accolades » pour mettre un mot en italique mais cela a été fait aussi plus haut sans que cela pose de problème.

Une autre piste serait peut-être à trouver du côté des retours à la ligne forcé qui sont ici en surnombre…

En tous cas un grand merci pour ta réponse :slight_smile:

#4

effectivement ce ne sont pas des logs PHP. Peut être sont-il ailleur?

#5

Bonjour,

Je sais pas pourquoi, mais ça me rappelle ce vieux bug : Limite à la longueur des paramètres d'un modèle (#4230) · Tickets · spip / textwheel · GitLab

Est-ce que tu pourrais partager le texte qui fait planter ici : https://pastebin.mozilla.org/ ?

#6

https://pastebin.mozilla.org/XHZDkkEQ

#7

Effectivement, il y a un problème.
Qui se trouve être un caractère invisible dans ton texte : U+200B Espace sans chasse (ZWSP)Caractère Unicode (compart.com)

Sans ce caractère, ça passe crème.

PS : merci NotePad++ pour l’affichage des caractères spéciaux.

#8

J’ai créé un ticket pour référencer ce bug : Impossible d'enregistrer un texte (d'article) contenant le caractère Espace sans chasse (ZWSP) (#5947) · Tickets · spip / spip · GitLab

#9

Super ! Merci mille fois :slight_smile:

#10

Bon, ceci dit, si tu vas lire le rapport de bug et les réponses, on a trouvé que c’était pas ton texte à proprement parler, mais l’encodage de ta base de données qui ne doit pas être en utf8.

#11

Bah là… j’avoue que je ne me souviens pas avoir porté une attention particulière à l’encodage de la base de données lors de l’installation (2009). En tous cas c’est la première fois que ce problème m’arrive. Je sais au moins d’où ça vient. Merci encore

#12

En 2009, c’était probablement latin1 par défaut.

Mais depuis, il aurait fallu passer à utf8.

La méthode recommandée maintenant est avec SPIP CLI :
spip sql:convert:toutf8

#13

N’étant pas geek, c’est vrai que j’ai tendance, si ça continue de rouler, à toujours faire les MAJ de SPIP, tout en laissant le truc en l’état, sans vraiment me préoccuper des incontournables notes de mise à jour, décrivant les tout aussi incontournables évolutions technologiques. J’ai déjà été obligé de revenir sur les squelettes ainsi que sur le paramétrage de la version de PHP. Je vais désormais essayer de m’atteler à la migration de l’encodage de la base. En tous cas, merci encore pour l’info.

1 « J'aime »
#14

De retour sur ce sujet, après quelques instants de suspension :slightly_smiling_face:
Je n’ai pas modifié l’encodage de la base mais j’ai essayé de voir caractère après caractère à partir de quand arrivait le problème. C’est sur le « e » final du mot enclosure (6e strophe). Là encore pour régler le problème j’ai utilisé un vieux rafistolage: mettre le mot en capitale. Et ça permet de garder la page. Je ne pige rien à cette histoire, je me permets donc de vous retourner le truc.
Merci encore pour vos réponses.
Frçs

#15

Si tu retournes voir Impossible d'enregistrer un texte (d'article) contenant le caractère Espace sans chasse (ZWSP) (#5947) · Tickets · spip / spip · GitLab tu verras que c’est vraiment un problème d’encodage de ta base en latin1 au lieu d’utf8.

Et que ton texte contenait des caractères invisibles.
Que tu as certainement enlevés en effaçant les minuscules et en mettant des majuscules.

Bref, tu fais du Vaudou alors que la cause est claire et identifiée.

#16

@feld il me semble en effet que la piste proposée par RealET est celle qui a le plus de chance de résoudre ton problème :slight_smile:

1 « J'aime »
#17

Oui, bien entendu, c’est un problème d’encodage de BDD. J’en ai déjà convenu. Ma remarque ne visait pas à être présentée en tant que résolution du problème mais comme un bidouillage (plutôt honteux), dont il me semblait intéressant de rendre compte (probablement à tord). Ce bidouillage m’a pris exactement 3 minutes, soit beaucoup moins de temps que de réinstaller le site sur mon ordi et de coder correctement la base, tel qu’indiqué. Mais j’y viendrai quand même.

1 « J'aime »
#18

Oui l’astuce marche - quand on édite le texte manuellement on finit par arriver à supprimer les caractères non tolérés par la base de données, en tâtonnant.

Mais c’est assez fastidieux à faire, surtout si tu dois aussi faire du support pour d’autres rédacteur.ices qui peuvent avoir le même problème. Je pense qu’à la longue c’est plus efficace de faire le changement d’encodage de la base, qui résoud le problème définitivement :slight_smile:

En cherchant sur internet « migrer base de données spip vers utf8 » on trouve des tutoriels et des conseils pour faire ce travail, je pense qu’il vaut mieux allez lire comment d’autres personnes ont fait cette migration avant de procéder :slight_smile:

#19

Effectivement, la procédure n’a pas l’air triviale, surtout pour moi. Merci pour ton message.

#20

Méthode officielle actuelle :wink: