panne récurrente : page blanche à l'accueil de mon site spip

Général
#1

Bonjour, depuis quelque temps j’ai une erreur récurrente qui se manifeste par une page strictement blanche à l’accueil (la partie privée également). Je ne m’en sors qu’en réinstallant à chaque fois un spip neuf sur la bdd courante (puis recopier les répertoires squelette, IMG et config).
Je suis sous php 7.4 et le problème survit aux mises à jour de spip (de 3.2 à 4.0, puis 4.1). Le log d’erreur dit à chaque fois :

PHP Parse error: syntax error, unexpected ‹ _08_23 › (T_STRING) in […]/ecrire/inc_version.php on line 453

Merci pour toute piste !

#2

Es-tu certain que les fichiers de ton site ont bien été mis à jour ? Voici le contenu de cette ligne spip/inc_version.php at 4.1 - spip - SPIP on GIT

Si tu n’as pas fait la mise à jour avec spip_loader, qui fait le ménage dans les anciens fichiers, je recommande cette procédure de mise à jour Mettre à jour un SPIP 3 vers SPIP 4 - Le labo

#3

Merci de ta réponse. Pour être précis, j’avais un site sous spip 3.2 qui avait un squelette assez compliqué qui utilisait sarkaspip et centrimage (entre autres). Il s’est mis à ne plus très bien fonctionner (notamment en m’affichant le panneau en travaux de façon intempestive) et j’ai tenté de passer en 4.0.x et c’est là que les vrais problèmes ont commencé (page complètement blanche). J’ai fini par repartir quasiment from scratch, en installant un 4.1.5, en renonçant à quasiment tous les plugins (dont sarkaspip) et réécrivant tous les articles (une quarantaine), renseignements pris à l’aide de phpmyadmin dans l’ancienne base. Ça m’a pris deux jours. Mais le problème de la page blanche est revenu au bout d’un mois et je n’en viens pas à bout.

La méthode employée fait que rien ne subsiste de la version 3.2 !

En fait, j’avais renoncé à spip_loader depuis qu’il y a deux ou trois ans il avait refusé de fonctionner. Mais voici la méthode que j’emploie pour mettre à jour. Mettons que le répertoire de mon spip s’appelle totolehero.

1 — J’installe à côté de totolehero le répertoire de la dernière version de spip téléchargé depuis spip.net
2 — Je supprime le répertoire IMG de spip-v4
3 — je transfère depuis totolehero dans spip-v4, le répertoire IMG de totolehero, le fichier config/connect.php, mon répertoire squelettes (pas très gros !)
4 — Je crée à toute fins utiles plugin/auto/ dans spip-v4
5 — Je renomme totolehero en vieuxtoto et spip-v4 en totolehero.
6 — Je me connecte comme admin (éventuellement la base se met à jour) et j’appelle le site public.

À ce stade, tout est redevenu comme avant et cela dure ce que ça dure… (5 jours la dernière fois !)

Du coup il ne peut pas rester grand chose de la version précédente, sauf bien sûr dans le répertoire squelettes.

Pour la dernière mise à jour, je suis passé à php 8.1 : on verra ce que ça donne. Si problème, je retenterai spip_loader, mais je n’y crois qu’à moitié.

Merci pour ton aide en tout cas !

Et désolé pour la longueur de ce message !

#4

Bonjour,

Eh bien cela a recommencé : page blanche au chargement de
dinosaurus.mathriochka.net

J’ai essayé de régénérer par spip_loader mais j’obtiens

SPIP Loader — 5.3.0

Error

Impossible de récupérer le fichier https://www.spip.net/spip_loader.api

Que je peux pourtant récupérer directement à partir de mon navigateur.

Bon je vais refaire une installation, maintenant j’ai l’habitude (et justement j’ai besoin de mon site!), mais si quelqu’un a une idée…

#5

Bonjour Michel, j’ai un peu de mal à comprendre ton histoire avec totolehero…
As-tu une sauvegarde propre de ta base de données ? (que ce soit par phpmyadmin ou par le dump de spip)
Si tu as une sauvegarde, j’avoue que je tenterai une réinstallation complète et propre de spip, en lui réinjectant ensuite ta sauvegarde.
La procédure en 6 points que tu décris plus haut me laisse perplexe…
Bon courage !

1 « J'aime »
#6

Bonjour, merci pour ta réponse.
Je pense que ce que je fais revient au même que de réinstaller un spip propre et de réinstaller la base.
Car je pars d’un spip propre, je récupère mon fichier de connexion, mon dossier IMG et mon dossier squelettes, ce qu’il me faudrait faire de toute manière si je suivais ta préconisation.
Comme le nom de sous-domaine pointe vers un répertoire nommé « totalehero » une fois que j’ai ainsi renommé le répertoire spip-v4 contenant la nouvelle installation, tout repart comme avant. Et cela fonctionne à chaque fois. Cela suppose bien sûr que la base n’a pas été corrompue, mais le fait que ça reparte prouve justement que ça n’est pas la base le problème, non?

Bon enfin pour en avoir le cœur net, je vais réinitialiser la base avec la sauvegarde que j’ai faite avant-hier, ça tombe bien, je n’ai rien fait depuis : je perdrai juste les statistiques de deux jours…

#7

Quelques précisions : l’erreur est la même que la fois passée. Elle semble survenir de façon aléatoire après une période variable de bons et loyaux services (de 5 jours à quelques semaines jusqu’à présent). Une fois survenu les choses ne revienne pas en place, donc a priori le serveur n’est pas en cause. Voici le message :

[08-Feb-2023 02:07:32 UTC] PHP Parse error: syntax error, unexpected ‹ _08_23 › (T_STRING) in /home2/mat/public_html/362880/ecrire/inc_version.php on line 453

Visiblement le message revient ensuite à chaque tentative d’accès au site.

Une nouveauté cette fois-ci, j’ai découvert deux nouveaux messages d’erreur, non fatale car antérieurs au précédent et vraisemblablement lié à mon passage de php 7.4 ) php 8.1

[29-Jan-2023 20:05:59 Europe/Paris] PHP Deprecated: Implicit conversion from float 16.81 to int loses precision in /home2/mat/public_html/362880/config/ecran_securite.php on line 707

et

[30-Jan-2023 09:19:16 Europe/Paris] PHP Warning: Trying to access array offset on value of type null in /home2/mat/public_html/362880/ecrire/public/quete.php on line 133

Ces deux messages reviennent eux aussi de façon sporadique.

#8

L’erreur que tu cites « PHP Parse error: syntax error, unexpected ‹ _08_23 › (T_STRING) in […]/ecrire/inc_version.php on line 453 » indique le source et il suffit de suivre le lien de b_b pour voir que la syntaxe de cette ligne n’est comprise qu’à partir de PHP 7.4.
Cf PHP Sandbox - Execute PHP code online through your browser
Ton vrai PHP est donc une version 7.3 ou inférieure… au moins quand ça se produit.

1 « J'aime »
#9

Merci !

La version « déclarée » de php est 8.1. Le retour à une version antérieure serait le fait du serveur. Mais je vérifie régulièrement dans la configuration php dans le menu maintenance de spip et je trouve bien (je viens de le faire) 8.1.14.
Je peux bien comprendre qu’un retour ponctuel en arrière n’est pas invraisemblable, mais ce qui est surprenant, c’est que la panne persiste alors que les choses sont revenues à la normale !

#10

Tout ceci est vraiment étrange.
Comme ce n’est pas SPIP qui génère ça (ou alors c’est lié à une configuration spécifique de ton hébergement), est-ce que l’hébergeur a été contacté pour savoir ce qui pourrait se passer ? Peut-être y-a-t-il des logs apache au moment où se produisent ces incidents qui pourraient expliquer le souci ?
Et à tout hasard quel est ton hébergement ?

1 « J'aime »
#11

Même si je ne suis pas forcément fan des voitures de sport, j’ai peut-être une piste ^^

Ton site est accessible à deux adresses www.dinosaurus.mathriochka.net & dinosaurus.mathriochka.net, mis à part le fait que ça n’est pas bon d’un point de vue référencement, peut-être as-tu configuré deux versions de PHP différentes sur ces deux domaines ? ce qui expliquerait que parfois ton site génère une erreur si une des versions n’est pas celle nécessitée par SPIP.

1 « J'aime »
#12

Merci de ta réponse. La première fois que le problème s’est produit, j’ai effectivement contacté mon hébergeur, qui est Webou-pro et je lui ai demandé s’il avait pu y avoir un problème ou un changement au niveau de son serveur php qui expliquerait mes mésaventures. Il m’a certifié que non. Je n’ai pas insisté parce que le fait que la panne était définitive (alors qu’un spip neuf de la même version était parfaitement fonctionnel) ne me semblait pas explicable juste par un problème lié au serveur.

Mais je vais peut-être retourner vers eux quand même…

#13

Allons bon ! C’est que je n’ai rien demandé moi. J’ai un nom de domaine qui est mathriochka.net et mon hébergeur me laisse la possibilité de créer des sous-domaines. J’ai créé dinosaures.mathriochka.net, mais je n’ai rien demandé concernant www.mathriochka.net ou www.dinosaurus.mathriochka.net. Concernant la version php, je pouvais auparavant la décliner domaine par domaine, mais maintenant je ne peux plus. Je choisis une version et une seule qui vaut pour l’ensemble de mes sites (l’hébergeur me l’a confirmé). Enfin dans le menu déroulant de cpanel qui me permet de sélectionner ma versions de php (donc 8.1) la version 5.6 est notée comme native.
Tu as donc raison, je pourrais suspecter que le php des domaines en www soit le natif. MAIS
1 - à ce moment là, les domaines en www ne devraient pas fonctionner.
2 - rien de tout cela ne m’explique pourquoi toutes ces pannes sont définitives une fois qu’elles sont survenues !

Merci pour ton aide !

#14

ce que je m’amuse à faire quand il y a un sous domaine, c’est de revenir au domaine principal, or ce dernier déclare site en travaux
Tous se passe comme s’il y avait deux spip qui fonctionnent en même temps
Un au niveau principal pas ou mal configué,
un au niveau sous domaine dinosaurus.
Un truc à se mélanger les pinceaux lors des mises à jour et à foutre la pagaille si, par exemple, la même base est accédée par les deux.

1 « J'aime »
#15

Tu peux facilement forcer l’usage d’un seul domaine avec un htaccess cf Apache redirect www to non-www and HTTP to HTTPS — Simone Carletti

PS : j’ai oublié de mentionner que c’est aussi mauvais pour le cache du site d’être accessible sur plusieurs domaines.

1 « J'aime »
#16

C’est moi qui ai mis un fichier index.html affichant site en travaux dans le répertoire racine, justement pour ne pas avoir ce problème avec quelque chose qui n’est pas du tout configuré. Le répertoire principal contient ce fichier index.html, les répertoires racines des deux sites qui sont hébergés et qui ont des bases de données bien distinctes, ainsi que quelques répertoires sans rapport avec spip qui me permettent juste de partager des données par des liens.

#17

Et donc l’autre site fonctionne bien ?

1 « J'aime »
#18

L’autre site est celui d’un ami qui n’a pas beaucoup de temps pour s’en occuper en ce moment. Notamment, il est encore en spip 3.2 qui ne supporte pas php 8.1 et je l’ai donc « désactivé » (avec l’accord de l’ami qui veut de toutes façon complètement changer la philosophie de sont site) avec un « site en travaux! » (même méthode que précédemment). Mais il fonctionnait bien sous php 7.4

https://fotoph.fr

#19

Le site ressemble aux squelettes de la dist, mais tu indique avoir gardé ton vieux dossier squelettes.
T’as testé en l’enlevant et en vidant les caches ?

1 « J'aime »
#21

Je suis justement en train de faire le ménage, de façon à ne garder dans le dossier public_html que ce qui m’est vraiment utile. Je vais rapatrier en local les répertoires des sites plantés que j’avais conservés (au cas où j’aurais besoin d’y revenir).

Après, si je regarde la base de données de mon site actuel, elle a bien sûr été mise à jour lors du passage de 4.1.5 à 4.1.7 mais elle garde des entrées pour des choses complètement désinstallées par exemple pour les plugins sarkaspip et sarkaspip reloaded que j’avais testé sous 4.1.5 avant d’y renoncer. Mais supprimer à la main des entrées dans les tables ça ne me semble pas une bonne idée non plus !