Bonjour,
Sous spip 3.2.15 ( de memoire, ce n’est plus visible), je viens mettre a jour 2 plugins (Helas pas note lesquels).
Et je n’ai plus l’accès à la partie publique du site. le message suivant apparaît:
Parse error: syntax error, unexpected ‹ ? › in /home/users/1/main.jp-monsite/web/mon site.info/plugins/auto/verifier/v2.1.1/verifier/slug.php on line 57
Pas de chance le 1er jour du weekend.
Que puis-je faire?
Bonjour,
Si vous accédez au privé , vous pouvez désactiver « verifier », pour débloquer .
Sinon, vous pouvez renommer le fichier auto/verifier puis raffraichir la page d’administration
des plugins pour désactiver ce plugin verifier. Une fois désactivé vous pouvez le renommer « verifier » pour le désinstaller puis remettre la version précédente.
Le 16/04/2022 à 06:52, Éric Priou via Discuter de SPIP a écrit :
Parse error: syntax error, unexpected ‹ ? › in /home/users/1/main.jp-monsite/web/mon site.info/plugins/auto/verifier/v2.1.1/verifier/slug.php on line 57
@maieul maieuuuuuul, faut arrêter de mettre des trucs PHP 7++ sur des plugins compat 3.2… 
?? et , les deux vont pas
–
RastaPopoulos
Rebonjour,
Merci pour les réponses.
L’horrible coupable est donc verifier.
Je n’ai pas accès au privé. (erreur dans le premier message, la partie publique est visible.)
Par contre je peux utiliser FTP, l’accès chez l’hébergeur, sûrement renommer le fichier.
Comment puis-je rafraîchir la page d’administration pour désactiver le plugin?
Par FTP tu peux renommer le dossier « verifier » en « verifier.mauvais », ainsi il ne sera plus accédé et normalement tu pourras accéder à la partie /ecrire du site.
Ensuite tu peux déziper en local une version ancienne du plugin, et uploader le dossier dézippé dans un sous dossier ‹ plugins/verifier ›.
Et au besoin tu peux alors activer cette nouvelle version via SVP ainsi que les autres plugins qui l’utilisent.
Ben, l’idée c’est qu’une fois le répertoire renommé, le bloquage devrait disparaitre.
Mais surtout, si ton hébergement le permet, bascule en PHP 7.4 !
Et ça résoudra ton problème avec le plugin Verifier.
Merci pour les précisions.
Pour des raisons qui m’échappent filezilla ne veut plus fonctionner chez moi et le FTP intégré au serveur est lunatique.
Verifier doit certainement faire ce que son nom indique mais est-il indispensable?
J’ai l’intention de renommer verifier en verifier. mauvais, attendre la nouvelle version, puis renommer verifier.
Ca pourrait marcher comme cela en attendant?
@RealLET
les messages se sont croisés.
Merci à toi aussi.
C’est effectivement une solution, ca preparera le terrain pour passer en Spip 4.1
J’attends le lundi pour avoir l’aide de l’hébergeur.
Pour le moment le site est visible en public, donc ca me convient.
Verifier ne fait rien en lui-même : c’est un blugin utilitaire pour plein d’autres plugins (tels que saisie, formidable…)
Donc, si tu as verifier sur ton site, c’est que d’autres plugins qui te sont utiles l’utilisent.
D’accord, je passe en PHP 7.4 au plus vite.
arf, damned… j’avais pas fait gaffe qu’on maintenait la compat 3.2
On se ferait pas une branche 4.0 only ? (et la branch 2.x resterait compatible 3.2)
Rebonjour,
Je suis passé en php 7.4
les sites sont bloqués, je n’ai toujours pas accès au privé.
L’hébergeur me dit que mes sites ne peuvent fonctionner que jusqu’à PHP 7.2.
Avant d’aller plus avant dans les expérimentations (j’hésite maintenant à renommer le fichier vérifier en vérifier. mauvais) je fais encore appel à vos lumières.
Merci par avance
Passer en php 7.4 peut creer bien d’autres problemes avec d’autres plugins.
Redescends en php 5, regle deja le probleme a ce niveau de php ou tu n’as qu’UN SEUL ennui facile
a resoudre, avec la methode deja bien expliquee ci-dessus
On Mon, Apr 18, 2022 at 11:06 AM Éric Priou via Discuter de SPIP <noreply@discuter.spip.net> wrote:
Éric Priou liberte
Avril 18Rebonjour,
Je suis passé en php 7.4
les sites sont bloqués, je n’ai toujours pas accès au privé.
L’hébergeur me dit que mes sites ne peuvent fonctionner que jusqu’à PHP 7.2.
Avant d’aller plus avant dans les expérimentations (j’hésite maintenant à renommer le fichier vérifier en vérifier. mauvais) je fais encore appel à vos lumières.
Merci par avance
Voir le sujet ou répondre à ce courriel pour répondre.
Pour vous désabonner de ces courriels, cliquez ici.
Le 18/04/2022 à 07:20, Git Reason via Discuter de SPIP a écrit :
Passer en php 7.4 peut creer bien d’autres problemes avec d’autres plugins.
Euh un peu n’imp, SPIP 3.2 marche parfaitement bien en PHP 7.4, et 99,9% des plugins aussi.
C’est revenir en PHP 5 qui est plus dangereux et moins fiable que de rester en 7.4.
Mais « les sites sont bloqués, je n’ai toujours pas accès au privé » ça veut dire quoi ? T’as quoi comme comportement concrètement ? T’as fait afficher les erreurs PHP ?
–
RastaPopoulos
Bonjour,
J‘ai plusieurs adresses avec extension . info ou .jp qui pointent vers un seul et même contenu.
Ces quelques adresses étaient avant le passage à la nouvelle version de vérifier dans des versions différentes de PHP de 5.6 à 7.1, de mémoire. Je les ai toutes basculées en 7.4.
2 sites sont lisibles (squelette de la distribution) si on va à la bonne adresse. Celui qui abrite les deux autres n’est pas visible côté public. L’accès privé ne fonctionne pas: si je tape ecrire, ca repond qu’il y a un problème SQL server.
Je ne connais pas les erreurs PHP. Je fais comment pour afficher cela?
Au téléphone l’hébergeur dit que le problème venait de mon site qui acceptait jusqu’au PHP7.2
Je ne comprends déjà pas le début de l’explication… Comment peux-tu avoir plusieurs adresses pointant sur le même contenu (donc plusieurs domaines pointant vers le même SPIP, le même serveur) ET avoir plusieurs versions différentes de PHP ? C’est contradictoire là…
Et ça n’a plus rien à avoir avec le problème de départ aussi.
Tu devrais préciser bien plus, là où t’as des problèmes, c’est quel PHP, avec quelle version de SPIP, avec quels plugins, pour chaque endroit où t’as un problème.
// config/mes_options.php
error_reporting(E_ALL^E_NOTICE);
ini_set ("display_errors", "On");
Et aussi si ça dit erreur SQL, faut aussi regarder dans les logs de SPIP, tmp/logs
–
RastaPopoulos
Rebonjour,
Tout marchait bien avant.
J’ai deux noms de domaine: http://mon domaine.info/ et http://mon domaine.jp/ qui mènent au fichier mon domaine.info
Si je tape http://mon domaine.info/ , je peux accéder aux pages publiques mais dans la version de la distribution et ecrire ou le bouton espace privé retournent SQL server.
Si je tape http://mon domaine.jp/ , directement l’erreur SQL server.
La doc de l’hébergeur indique que pour un passage à PHP>7.1 il faut renommer (avant?) le mot de passe de la BD en old-password et passer en native-passeword.
Je vais essayer de comprendre la doc en japonais de plus est, dans le cas de wordpress.
Je n’ai pas noté les versions PHP que j’ai changées, je demande à l’hébergeur.
Merci pour la doc, je m’y mets.
Bonjour,
J’obtiens les infos suivantes. Il semblerait qu’il y ait un probleme de mot de passe pour PHP? Quelle est l’étape suivante?
Quant aux logs du tmp, j’ai trouvé dans spip.log
2022-04-19 22:26:50 157.7.106.87 (pid 55915) :Pub:!INFO: spip_connect: fichier de connexion ‹ config/connect.php › OK.
2022-04-19 22:26:50 157.7.106.87 (pid 55915) :Pub:HS: spip_connect: echec connexion ou serveur 0 mal defini dans ‹ config/connect.php ›.
2022-04-19 22:26:50 69.171.251.11 (pid 55900) :Pub:ERREUR: Le serveur ‹ › version 1 n’a pas ‹ showbase ›
2022-04-19 22:30:54 157.7.106.87 (pid 79957) :Pub:HS: Echec mysqli_connect. Erreur : mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication. Please use an administration tool to reset your password with the command SET PASSWORD = PASSWORD(‹ your_existing_password ›). This will store a new, and more secure, hash value in mysql.user. If this user is used in other scripts executed by PHP 5.2 or earlier you might need to remove the old-passwords flag from your my.cnf file
2022-04-19 22:30:54 157.7.106.87 (pid 79957) :Pub:HS: Echec connexion serveur mysql : host[mysql597.phy.lolipop.jp] port[] login[LA06111483] base[LA06111483-francparler]
2022-04-19 22:30:54 157.7.106.87 (pid 79957) :Pub:!INFO: spip_connect: fichier de connexion ‹ config/connect.php › OK.
2022-04-19 22:30:54 157.7.106.87 (pid 79957) :Pub:HS: spip_connect: echec connexion ou serveur 0 mal defini dans ‹ config/connect.php ›.
2022-04-19 22:30:54 92.247.181.9 (pid 79940) :Pub:HS: Echec : tmp/mysql.f1ecef49.out recent. Pas de tentative de connexion
2022-04-19 22:30:54 92.247.181.9 (pid 79940) :Pub:!INFO: spip_connect: fichier de connexion ‹ config/connect.php › OK.
2022-04-19 22:30:54 92.247.181.9 (pid 79940) :Pub:HS: spip_connect: echec connexion ou serveur 0 mal defini dans ‹ config/connect.php ›.
et aussi
i2022-04-19 22:34:07 147.50.248.119 (pid 102699) :Pub:HS: Echec mysqli_connect. Erreur : mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication. Please use an administration tool to reset your password with the command SET PASSWORD = PASSWORD(‹ your_existing_password ›). This will store a new, and more secure, hash value in mysql.user. If this user is used in other scripts executed by PHP 5.2 or earlier you might need to remove the old-passwords flag from your my.cnf file
2022-04-19 22:34:07 147.50.248.119 (pid 102699) :Pub:HS: Echec connexion serveur mysql : host[mysql597.phy.lolipop.jp] port[] login[LA06111483] base[LA06111483-francparler]
Notice: Constant _TRAITEMENT_TYPO_SANS_NUMERO already defined in /home/users/1/main.jp-franc-parler/web/franc-parler.info/tmp/couteau-suisse/mes_spip_options.php on line 7
Notice: Constant _IMG_MAX_WIDTH already defined in /home/users/1/main.jp-franc-parler/web/franc-parler.info/plugins/auto/escal/v4.5.43/escal_options.php on line 25
Notice: Constant _IMG_MAX_HEIGHT already defined in /home/users/1/main.jp-franc-parler/web/franc-parler.info/plugins/auto/escal/v4.5.43/escal_options.php on line 26
Notice: unserialize(): Error at offset 0 of 670 bytes in /home/users/1/main.jp-franc-parler/web/franc-parler.info/plugins/auto/metasplus/v2.4.0/metasplus_pipelines.php on line 52
Ha ben voilà, tout est là :
2022-04-19 22:30:54 157.7.106.87 (pid 79957) :Pub:HS: Echec mysqli_connect. Erreur : mysqlnd cannot connect to MySQL 4.1+ using the old insecure authentication. Please use an administration tool to reset your password with the command SET PASSWORD = PASSWORD('your_existing_password'). This will store a new, and more secure, hash value in mysql.user. If this user is used in other scripts executed by PHP 5.2 or earlier you might need to remove the old-passwords flag from your my.cnf file
Ton site n’arrive pas à se connecter à sa base de données…