consequences de [8476] : le critere {origine_traduction} doit donner tous les articles, traduits ou pas, qui ne sont pas des traductions (cf. test correspondant dans criteres/origine_traduction) ; par ailleurs le modele donne dans la dist ne doit pas afficher le bloc si l'article est tout seul (code un peu trop complique a mon gout)

critere {traduction} fonctionne sur un article tout seul (cf. tests/criteres/traduction et http://thread.gmane.org/gmane.comp.web.spip.devel/38931/ (Paolo)

lorsqu'un critere dynamique est present ( {par #ENV{tri}} ), prevoir qu'on peut vouloir faire tri=hasard, la syntaxe {par hasard} pouvant faire croire que c'est techniquement la meme chose que {par id_article} ...

Amélioration de [8308]: le critère se compilant en un Group By admet à présent un champ passé par l'URL comme dans le squelette ci-dessous. Le nom retenu est finalement '''fusion''', mot à la fois français et anglais contrairement au groupby de SQL (lui-meme déjà pas très heureux).

Fil & Emmanuel
{{{
<B_a>#PAGINATION / #GRAND_TOTAL
<BOUCLE_a(SYNDIC_ARTICLES){par date}{pagination}><br />#URL</BOUCLE_a>
<hr />
<B_b>#PAGINATION / #GRAND_TOTAL
<BOUCLE_b(SYNDIC_ARTICLES){par date}{inverse}{pagination}{fusion #ENV{fusion}}>
<br />#URL
</BOUCLE_b>
}}}

la gestion de #INSERT_HEAD quand il n'y en a pas (cf. [8208]) se fait desormais en indiquant dans mes_options (ou tweak ou plugin ...) une ligne qui etend le pipeline affichage_final (+ optimisations diverses)

boucle->modificateur['criteres'][xxx] est positionné a true pour chaque critere xxx rencontré
permet aux plugins de faire varier le contenu par defaut des boucles en fonction des criteres

quand on joue a un champ pour un autre, il faut retourner le nom d'origine car sinon le critere conditionnel ne peut etre appliqué ...

permettre aux plugins de gerer eux memes des jointures ou des criteres tordus pas automatisables par extension de la syntaxe de :
$GLOBALS['exceptions_des_tables']['forms_donnees']['id_mot']=array('spip_forms_donnees_champs', 'valeur', 'forms_index_exception');
-> un troisieme argument optionnel comme nom de fonction qui fait le boulot de index_exception()
$GLOBALS['exceptions_des_jointures']['forms_donnees']['id_mot'] = array('spip_forms_donnees_champs', 'valeur', 'forms_calculer_critere_externe');
-> une dimension intermediaire pour specifier une jointure sur une table uniquement, et un troisieme argument optionnel comme nom de fonction qui fait le boulot a la place de calculer_critere_externe_init()

{pagination 10 ENV{truc,machin}} utilisera debut#ENV{truc} ou debutmachin comme nom de variable debut

preserve l'environnement (2Ko d'economie sur le source quand meme .. :p )

introduction d'un array $modificateur dans la structure des boucles permettant aux plugins d'ajouter des flags issus de criteres
Passage de $tout,$plat,$lien et $fragments dans cet array (ces booleens sont conservés et affectés provisoirement pour compatibilité avec les plugins eventuels)

introduction d'un critere {fragment} pour definir des blocs appelables par ahah ; {pagination} provoque un fragment ; {!fragment} le supprime ; {fragment truc} fixe l'id du div englobant

Suite de [6913] : le hack de co-existence de Having & Group-by ne doit pas s'appliquer si Group-by n'est pas là. C'est l'évidence ? Pas si simple, il faudra y revenir.

Rajouter un Group By dès que le nombre TOTAL de jointures dépasse 1, faute
d'une meilleure analyse.

Bug signalé ici
http://article.gmane.org/gmane.comp.web.spip.devel/35853
mais penser toujours à:
http://article.gmane.org/gmane.comp.web.spip.devel/30555

Bug introduit lors du remplacement du FIND_IN_SET par FIELD+HAVING dans la version [6410] puis [6417] et [6418]. Expliqué  par Gérard T. ici:

http://article.gmane.org/gmane.comp.web.spip.devel/35844

Corroboré par cette mise en garde que le standard SQL exige d'appliquer Having à une fonction d'agrégat:
http://dev.mysql.com/doc/refman/5.0/en/group-by-hidden-fields.html

retour en arriere sur [6909], le probleme venait du cas ou, dans kwote, on faisait pas le spip_abstract_quote a la compil, mais a l'execution : $lisp etant ecrit entre '', il faut garder les ' echappes dedans...
J'espere que ca casse rien dans les autres appels de kwote
ca a l'air vraiment bien comme jeu ... :)

permettre un tri dynamique sur un champ issu de jointure : le champ de tri dynamique n'est préfixé par le nom de la table que si il en fait effectivement partie. Dans le cas contraire, on le laisse tel quel, en esperant que ca matchera un champ issu d'une jointure...

Ne pas provoquer d'erreur SQL si date_thread n'est pas appliqué sur une boucle Forum, essayer plutot une jointure

Dans cette bardée de Warnings sans importance, il y avait un vrai bug qui faisait a nouveau produire plusieurs fois le meme nom pour différents tables de jointures dans le cas de boucles DOCUMENTS.

http://thread.gmane.org/gmane.comp.web.spip.devel/27971
a savoir que le critere {id_secteur} ne marche pas dans une boucle de forum.
Il marche à présent pour les forums d'articles, y compris avec criteres plus
complexes comme {id_secteur IN 1, #ENV{secteur}} etc.
En revanche, il ne marche toujours pas pour les forums de breves, de rubriques
ou de syndication (bof).

* une seule boucle avec pagination intégrée (l'autre méthode marche encore, mais est-ce vraiment nécessaire ?)

* des ancres qui font que ça tourne

* sur un inclure ça marche si on met #SELF en paramètre d'inclusion (sinon gare aux problèmes de XSS) => exemple donné avec la pétition

* une nouvelle balise #ANCRE_PAGINATION si on veut mettre la pagination sous la liste des objets

* une nouvelle balise #GRAND_TOTAL qui fait le #TOTAL_BOUCLE hors limit


Reste à faire :
- nettoyer cette histoire de self() qui prend le var_mode=recalcul (??)
- étendre {pagination 50} par exemple pour fixer la taille de la fenêtre
- ???

Exemple d'ecriture:

<BOUCLE_pagine(ARTICLES){branche?}{par date}{inverse}></BOUCLE_pagine>[
<p>(#PAGINATION{_liste})</p>
]<//B_pagine>

<BOUCLE_liste(ARTICLES){branche?}{par date}{inverse}{pagination}>[
<p><a href="(#URL_ARTICLE)">#TITRE</a></p>
]</BOUCLE_liste>

ca demande encore a etre ameliore

Je me disais bien que [6423] devait etre bancale. Merci Paolo, et désolé pour ces apostrophes en trop.