'jour,
Sur la dernière version de dev récupérée ce matin (désolé, je n'ai pas accès au
numéro d'où je suis), j'ai cette erreur au premier clic de l'install
(ecrire/?exec=install&etape=1&chmod=493) :
Parse error: syntax error, unexpected ')', expecting '(' in
/ecrire/req/sqlite3.php on line 31
Ah, Booz vient de tomber dessus aussi…
Voici le problème : une instruction PHP5 tue la lecture de PHP4, en l'occurrence les «::» de define('SPIP_SQLITE3_ASSOC', PDO::FETCH_ASSOC);
Je contournais le blem en ne chargeant que req/sqlite_generique.php pour tester les versions de SQLite disponibles, avant de tenter de charger les autres fichiers. J'y indique par ailleurs un commentaire (sans plus d'explication il est vrai) :
«
// infos :
// il ne faut pas avoir de PDO::CONSTANTE dans ce fichier sinon php4 se tue !
// idem, il ne faut pas de $obj->toto()->toto sinon php4 se tue !
»
Emmanuel a changé la procédure de test de portages disponibles en http://trac.rezo.net/trac/spip/changeset/14269. Sa méthode est effectivement plus adéquate… mais en même temps, elle charge chaque fichier de req/ et badaboum, du coup, en PHP4…
Voici le problème : une instruction PHP5 tue la lecture de PHP4, en l'occurrence les «::» de define('SPIP_SQLITE3_ASSOC', PDO::FETCH_ASSOC);
...
Emmanuel a changé la procédure de test de portages disponibles en http://trac.rezo.net/trac/spip/changeset/14269. Sa méthode est effectivement plus adéquate… mais en même temps, elle charge chaque fichier de req/ et badaboum, du coup, en PHP4…
----
Je ne sais pas qu'elle est la meilleure correction à réaliser. Mais je me demande si on doit encore longtemps s'agacer de PHP4…
En fait c'est ballot de charger tous les fichiers PHP du répertoire req, il faudrait se limiter aux principaux.
Je pense qu'on devrait remplacer le
preg_match('/^(.*)[.]php$/', $f, $s))
par
preg_match('/^([^_]*)[.]php$/', $f, $s))
dans inc/install.php
car aucun serveur SQL ne contient de "_" dans son nom, ça suffirait.
Mais est-ce que les fichiers sql_lite sont bien organisés pour que le reste suive ?
Committo,Ergo:Sum
Dans l'état actuel : non.
Il faudrait renommer «sqlite_generique» en «sqlite» et «sqliteX» en «sqlite_X» dans ce cas.
Cependant, je pensais, un jour d'élan et de volonté, (il faudra bien en plus que je modifie sqlite pour prendre en compte tes dernières améliorations), supprimer «sqlite_générique» et n'avoir que les fichiers sqlite2 et sqlite3 avec chacun leurs spécificités, quitte à dupliquer certains codes. Mais ça ne peut pas se faire si on garde ce chargement là AVEC une compat php4.
SPIP 2.1 n'est pas si prêt de sortir je crois… je me demande vraiment si garder php4 ne soulève pas plus de problème qu'il n'en résous à l'heure actuelle (de plus en plus de lib externes sont codées direct PHP5 et utilisées par les plugins).
Hello,
Et ensuite quand on cherche à afficher le sommaire, il appelle debusquer.php qui fait un beau property_exists() et flingue php4 aussi.
BoOz
ça, un @ devant devrait régler le pb, c'est moins lourd à corriger.
Committo,Ergo:Sum
Committo,Ergo:sum a écrit :
Hello,
Et ensuite quand on cherche à afficher le sommaire, il appelle debusquer.php qui fait un beau property_exists() et flingue php4 aussi.
ça, un @ devant devrait régler le pb, c'est moins lourd à corriger.
Ca n'a pas l'air de suffir (page blanche).
BoOz
Est-ce que tu as un comportement différent en PHP5 sur exactement la même erreur ?
Parce que l'instruction qui dépendait de ce property_exists n'est pas si fondamentale.
Committo,Ergo:Sum
Committo,Ergo:sum a écrit :
Est-ce que tu as un comportement différent en PHP5 sur exactement la même erreur ?
Je ne suis pas sur de comprendre la question.
Si j'installe spip 2.1 avec php5 (en local) je n'ai pas d'erreur, et si je mets un @ ca ne fait pas de page blanche.
Et toi as tu un comportement similaire en php4 ?
BoOz