un ami vient de me demander de réparer son site sous SPIP 3.0.20 avec le squelette SARKA-SPIP Reloaded (Sarka-SPIP 4.5.1) hébergé chez OVH.
Il fonctionnait très bien jusqu’à il y a quelques jours.
Après quelques investigations OVH affichait que la version PHP était en 4.4, alors que normalement le site avait été mise en ligne en 5.4 (c’est très étrange).
En outre OVH a modifié le nom de la base de données (au format .mysql.db ), mais après avoir vérifié le fichier /ecrire/inc_connect.php, le nouveau nommage de la base de données y est bien correctement indiqué (ce qui est bien abscons pour moi également, OVH aurait une procédure automatique pour modifier ce fichier de configuration ?).
Pour tenter d’y voir plus clair, j’ai ajouté dans le fichier « mes_options.php » de quoi visualiser les erreur PHP et j’obtiens (suivant les pages appelées) des :
Notice: Undefined offset: 3 in …/ecrire/inc/urls.php on line 176
Notice: Trying to get property of non-object in …/ecrire/public/criteres.php on line 851
Notice: Undefined index: page in …/ecrire/public/styliser_par_z.php on line 91
Notice: Undefined index: type-page in …/ecrire/public/styliser_par_z.php on line 92
Fatal error: Call to undefined function typo_couleur() in …/plugins/auto/sarkaspipr/v4.5.1/sarkaspipr_pipelines.php on line 15
etc…
Avez-vous une idée pour m’aider à remettre ce site en état ?
Y a t-il d’autres fichiers de configuration où indiquer ce nouveau nom de la base de données (et mot de passe) ?
un .htaccess (avec 1 seuledirective « deny from all »)
-. ok (vide)
ecran_securite.php
remove.txt (me disant « Vous pouvez effacer ce fichier sans dommage »).
Pour info, ce site a été migré en 2015 sur SPIP 3.0.20 + le squelette SARKA-SPIP Reloaded.
Certains fichiers étaient historiquement placés à d’autres endroits si j’ai bien compris l’évolution de Spip.
Ce n’est pas normal que tu n’aies pas de connect.php sous config/, c’est
ce qui permet au site d’accéder à la base de données pour démarrer.
Peut-être est-il masqué car il contient en clair les données d’accès (id
et MDP). Vu que le site fonctionne (même mal), ce fichier doit bien être
présent.
Est-ce que tu arrives à t’identifier?
Christian
Le 05/03/2022 à 11:31, Oly via Discuter de SPIP a écrit :
Je n’ai aucun fichier …/config/connect.php
Dans …/config j’ai uniquement :
un .htaccess (avec 1 seuledirective « deny from all »)
-. ok (vide)
ecran_securite.php
remove.txt (me disant « Vous pouvez effacer ce fichier sans dommage »).
Pour info, ce site a été migré en 2015 sur SPIP 3.0.20 + le squelette
SARKA-SPIP Reloaded.
Certains fichiers étaient historiquement placés à d’autres endroits si
j’ai bien compris l’évolution de Spip.
1/ Non je n’ai aucun fichier /config/connect.php, j’utilise Filezilla (sous Ubuntu) et vois très bien le fichier .htaccess dans ce répertoire donc il n’y a pas de « fichier caché ».
En revanche dans /ecrire j’ai bien un fichier « inc_connect.php ».
J’ai accès au sauvegarde du site de 2015 et en local (lors de test) c’est bien avec ce fichier ecrire/inc_connect.php que le site pouvait se connecter à la base de données, car j’en ai une copie (identifiée _DEV) avec les instructions :
$GLOBALS[‹ spip_connect_version ›] = 0.3;
spip_connect_db(‹ localhost ›,’’…);
Et une autre version (identifiée _PROD) avec le bon nom de la base de donnée et non « localhost ».
2/ J’arrive à m’identifier à l’admin, mais je ne peux accéder à rien, la plupart des menus de l’admin sont absents et une ribambelle de : Notice: Undefined variable: langue_du_site in …/www/plugins-dist/sites/inc/syndic.php on line 204
Et aussi de :
Undefined index: page in …/www/ecrire/public/styliser_par_z.php on line 91
NB. Le site en 2013 tournait sous SPIP 1.9 et a été migré en 3.0.20 en 2015.
Existe-t-il une façon d’exporter la base de données pour retrouver les textes des brèves et des articles et pouvoir les importer dans un nouveau Spip tout neuf ?
A mois que l’on puisse réussir à restaurer ce site ?
Le 05/03/2022 à 00:49, Oly via Discuter de SPIP a écrit :
Il fonctionnait très bien jusqu’à il y a quelques jours.
Après quelques investigations OVH affichait que la version PHP était en
4.4, alors que normalement le site avait été mise en ligne en 5.4 (c’est
très étrange).
Il y a quelques mois, j’ai eu aussi un site OVH planté qui affichait un
Php 4.4 au lieu de 5.6. C’est revenu tout seul le (sur-)lendemain.
Merci pour ce retour (cela me prouve que je ne suis pas seul).
Mon ami a constaté fin décembre 2021 que sur OVH la version PHP indiquée était 4.4, mais il n’y a pas prêté attention, ce n’est que suite à son appel à l’aide il y a quelques jours qu’en auditant son site et son historique que je me suis rendu compte que normalement il devait tourner en 5.4.
Malheureusement même en le rebasculant en 5.4, le site est toujours bien planté '(
Le fichier inc_connect.php est un reste de Spip 1.9. Donc peut-être migration vers 3.0 mal passée.
C’est le cas, OVH a lui-même modifié de très nombreux fichiers connect.php en mettant à jour le nom d’accès à la base de donnees.
Si tu as les bons accès à la base de données, ce que je proposerais, c’est de supprimer tous les dossiers de SPIP (sauf IMG, voire plugins), et de réinstaller un Spip 3.0 tout propre, avec les identifiants BdD que tu as, il créera le fichier config/connect.php.
Et avant ça tu peux passer directement en php 5.6.
Au sujet du fichier inc_connect.php je suis surpris, car depuis 2015 le site tourne ainsi, mais je te crois sur parole et pour ce qui est de la modification de ce fichier par OVH, merci de m’avoir confirmé ce que je subodorais.
Supprimer tous les dossiers de SPIP et en réinstaller un tout propre m’effraie un peu, mais bon s’il faut en passer par là. As-tu des conseils pour ne pas louper cette nouvelle installation du coup ?
La réactivation des dossiers « squelettes » et du « plugin sarka », se fera automatiquement seulement en rebaptisant ces dossiers (en…OLD) ? Ou faut-il faire d’autres chose par ftp ?
Le renommage les rendra inopérants, et permettra au squelette par défaut de Spip de (tenter de) reprendre la main.
Tu peux aussi renommer la racine du dossier « Auto » dans Plugin, pour les désactiver tous.
