Bonjour,
Ce très cher spip semble encore trop jeune pour que ça marche. Tester dans une boucle article et syndic_article : critère inconnu à chaque fois. Quelqu’un a une idée ? Ou y a du changement pour l’utilisation de ce type de critère ?
Ah il est possible que ce soit un effet de bord des derniers commits
Pourrais tu revenir a une version d'avant hier et verifier que ça marche ?
Dans tous les cas, le top c'est de coller dans le mail la boucle de test qui ne marche pas chez toi dans ce type de cas,
ça permet de tester et debug sur exactement le même cas plutot que de passer du temps à reconstituer le cas test qui echoue
Cédric
Je suis revenu à l’instant à [17191] (peut être un peu trop en arrière) : ca marche.
De mémoire, ça vient effectivement d’hier, où j’ai constaté une première fois l’erreur.
Ca le fait sur n’importe quelle boucle (enfin, j’ai testé article et syndic_article), y compris sans rien toucher dans les squelettes de l’extension dist2007 c’est pour ça que j’ai pas collé la boucle fautive. Au mieux, la boucle n’est pas exécutée (si on a des sites syndiqués avec des articles qui apparaissent dans le privé, ils n’apparaissent pas dans le public), au pire, ça affiche critère inconnu au recalcul. En enlevant le critère age c’est bon (j’ai tenté aussi de modifier l’opérateur, ça ne change rien). La boucle qui utilise age dans la dist c’est la _syndic, présente dans toutes rubriques.
[(#REM) Sites de la rubrique ]
<B_sites>
2011/2/17 cedric.morin@yterium.com <cedric.morin@yterium.com>
Je ne reproduis plus, ça semble ok ! Ca turbine en ce moment !!
2011/2/17 Guy Cesaro <guy.cesaro@gmail.com>
Ah possible que ce soit http://core.spip.org/projects/spip/repository/revisions/17239
qui a repare, car juste avant plus rien ne compilait en fait, mais on ne s’en rendait compte qu’au recalcul d’un squelette !
Cédric
Il semble qu’il y ait un autre soucis dont je n’arrive pas à localiser le code en faute, dans l’extension mots :
Sur l’édition d’un groupe de mots dans le privé, le formulaire appelé dans prive/navigation/groupe_mots, #FORMULAIRE_EDITER_LOGO{groupe_mots,#ID_GROUPE,’’,#ENV**}
génère une erreur sql afficher ainsi par spip :
SELECT id_rubrique, statut FROM groupemots WHERE =XX (si on est dans le groupe XX)
il manque id_groupe dans la requête ? et groupemots c’est pas groupe_mots ?
2011/2/17 cedric.morin@yterium.com <cedric.morin@yterium.com>
http://zone.spip.org/trac/spip-zone/changeset/44775
doit corriger cela
Impec ! Dans la continuité de ma chasse aux bugs, j’ai encore du nouveau (mais peut être que c’est un peu prématuré de remonter les bugs ? Peut être que j’emmerde plus qu’autre chose ? il faut me dire, j’arrêterai, promis !)
Je me rends compte que le critère id_groupe (ou type_mot) ne fonctionne plus sur une boucle article (j’ai pas tenté sur d’autres objets). Par exemple, dans un site avec des articles publiés rattachés à certains mots du groupe 1 nommé pays :
<BOUCLE_a(ARTICLES){id_groupe=1}>
#TITRE
</BOUCLE_a>
ne renvoit rien alors qu’il y a bien des articles publiés ayant des mots de ce groupe. Je n’avais pas testé ce genre de boucle dans de précédentes versions. Dans le debug :
SELECT articles.titre, articles.lang
FROM spip_articles AS articles
INNER JOIN spip_auteurs_liens AS L1 ON ( L1.id_objet = articles.id_article AND L1.objet=‹ article ›)
INNER JOIN spip_forum AS L2 ON ( L2.id_auteur = L1.id_auteur )
INNER JOIN spip_documents_liens AS L3 ON ( L3.id_objet = L2.id_forum AND L3.objet=‹ forum ›)
INNER JOIN spip_mots_liens AS L4 ON ( L4.id_objet = L3.id_document AND L4.objet=‹ ›)
INNER JOIN spip_mots AS L5 ON ( L5.id_mot = L4.id_mot )
WHERE (articles.statut = ‹ publie ›)
AND (L5.id_groupe = 1)
GROUP BY articles.id_article
ou avec le critère type_mot (titre_mot n’est plus reconnu) :
SELECT articles.titre, articles.lang
FROM spip_articles AS articles
INNER JOIN spip_auteurs_liens AS L1 ON ( L1.id_objet = articles.id_article AND L1.objet=‹ article ›)
INNER JOIN spip_forum AS L2 ON ( L2.id_auteur = L1.id_auteur )
INNER JOIN spip_documents_liens AS L3 ON ( L3.id_objet = L2.id_forum AND L3.objet=‹ forum ›)
INNER JOIN spip_mots_liens AS L4 ON ( L4.id_objet = L3.id_document AND L4.objet=‹ ›)
INNER JOIN spip_mots AS L5 ON ( L5.id_mot = L4.id_mot )
WHERE (articles.statut = ‹ publie ›)
AND (L5.type = ‹ pays ›)
GROUP BY articles.id_article
2011/2/17 cedric.morin@yterium.com <cedric.morin@yterium.com>
Non, point du tout, mais attendons juste quelques heure que j'ai fini de réimplémenter les declarations de table pour verifier cela.
Cédric
2011/2/17 cedric.morin@yterium.com <cedric.morin@yterium.com>
Pour tous les objets de liaison ayant une table "liens", c'est une très bonne idée oui !
Il faudrait que ce soit dans le core automatiquement quand c'est bien déclaré. Et donc même plus besoin du plugin "Critères {mots}". Faut un système qui génère des AND selon soit un tableau soit une liste virgulée quoi. Ça pourrait être un critère à part plutôt qu'un pour chaque objet. {liaisons mots, #GET{liste}} ...
Après ya des cas particulier, pour Polyhiérarchie, si on a A > B > C, on peut vouloir qu'un article lié à C soit ressorti si on fait une recherche sur A. Si on veut les Produits Laitiers il faut que ça sorte ce qui est lié à Roquefort...
Enfin je m'emballe là. Mais c'est parce qu'un critère comme ça : waouh les possibilités quoi, recherche multicritères complexes dans une grosse base...
2011/2/18 RastaPopoulos <rastapopoulos@spip.org>