j'ai installé SPIP (2.1.2) avec une base de données PostGreSQL, ainsi que les
plugins ZPIP (1.7.9), Menu (0.8.3), etc.
J'ai créé un menu, avec deux entrées, et au moment de le visualiser en ligne,
depuis le lien de la page
.../ecrire/?exec=menus_editer&id_menu=1
(le lien est
.../ecrire/?exec=menus_editer&action=redirect&type=menu&id=1&var_mode=calcul)
je recois une erreur 302:
"
Warning: pg_query() [function.pg-query]: Query failed: ERROR: error de sintaxis
en o cerca de «AS» LINE 2: FROM spip_menus AS O LEFT JOIN spip_urls AS U ON
(U.type='me... ^ in /var/www/sitio_atlas/ecrire/req/pg.php on line 151
HTTP 302
Si tu navegador no te redirige automaticamente, pincha aquí para continuar.
"
En utilisant var_mode=debug:
.../ecrire/?exec=menus_editer&action=redirect&type=menu&id=1&var_mode=debug,
j'ai la même erreur, comme si l'erreur avait lieu avant l'appel au déboggueur.
Du coup, je ne sais pas comment voir quel est le problème. Une idée ?
Avec n'importe quel menu, par exemple le plus simple:
* creation d'un menu, avec Titre "toto", identifiant "tata"
* une seule entrée: "Accueil", sans renseigner les champs facultatifs
* clic sur le lien, en haut à gauche, sous "MENU NUMÉRO: 5", "Voir en ligne"
j'ai la même erreur
"
Warning: pg_query() [function.pg-query]: Query failed: ERROR: error de sintaxis
en o cerca de «AS» LINE 2: FROM spip_menus AS O LEFT JOIN spip_urls AS U ON
(U.type='me... ^ in /var/www/sitio_atlas/ecrire/req/pg.php on line 151
HTTP 302
Si votre navigateur n'est pas redirigé, cliquez ici pour continuer.
"
Tu aurais une idée de où chercher pour trouver l'erreur ?
Ah j'ai compris, tu utilises les URLs propres et l'erreur de syntaxe est juste avant la ligne 2:
^
SELECT U.url, U.date, O.
FROM spip_menus AS O LEFT JOIN spip_urls AS U ON (U.type='menu' AND U.id_objet=O.id_menu)
WHERE O.id_menu=1
le "O." est du au fait que la nouvelle table "spip_menus" doit garnir la globale
$table_titre['menus']= "CHAMP1 AS titre, '' AS lang";
ou CHAMP1 est celui qu'il faut.
Le pb est donc dans le plugin Menus qui aurait dû faire ça, mais j'accorde que SPIP devrait anticiper l'erreur.
C'est donc normalement corrigé, mais il me semblait que si on ne déclarait PAS le champ, SPIP essayait de trouver celui ayant le nom "titre", par défaut.
Si ce n'est pas le cas, je pense que c'est ce que ça devrait faire, car c'est le plus commun et donc finalement ça ne serait intéressant de déclarer que si c'est autre chose que "titre". Plus facile pour les devs quoi.
(De mémoire, je crois me rappeler que c'est ce que font les urls arbos, mais pas les urls propres qui pourtant utilisent le titre aussi : incohérence.)
Pour la correction désolé ESJ on a commité presque en même temps, et du coup ma solution annule la tienne, vu que $champ_titre est toujours plein !
Je dirais qu'un objet éditorial et qui donc a des URLs doit *toujours* avoir un champ désignant son titre : soit c'est "titre" donc rien à faire, soit il le déclare explicitement.
Ainsi s'il y a une erreur, c'est de la faute du développeur du plugin.
C'est pas bon parce que rien ne garantit que ce champ existe dans la table, d'où à nouveau une erreur SQL alors qu'on voulait justement les éviter.
Il vaut mieux mettre ton code au niveau de trouver_table, ainsi ça s'appliquera à toutes les variantes de ce genre d'URL, mais celles-ci doivent se protéger de ce que trouver_table n'a rien trouvé.
Chapeau pour la reactivité, les quelques bugs que j'ai rencontrés ont tous été
résolus dans la journée...
Une question... Pour bénéficier des corrections de plugin, il faut aller
chercher les versions de développement avec SVN, ou les .zip dans les pages de
plugins de SpipContrib sont automatiquement mis à jour ?
Tout dépend de l'auteur de l'article. Mais s'il utilise le ZIP externe venant de files.spip.org alors oui, c'est à jour.
Les paquets de spip-zone sont générés toutes les heures.