- on ne cherche que les champs id_xxxx et c'est uniquement la fonction de calcul du critère qui fait le travail et on rajoute id_secteur si un id_rubrique existe.
- on ne permet plus l'injection d'autres types de champs : le pipeline lister_champs_selection_conditionnelle devient exclure_id_conditionnel dont l'objectif n'est que de lister les id à exclure du critère.
dans SPIP, c’est à dire avec une mise à jour de la date à chaque update.
On migre les champs des tables connues.
Cependant, sur les tables crées auparavant avec une version de mysql récente, la colonne avec TIMESTAMP accepte les valeurs NULL et les accepte et en contient toujours après cette migration.
Il faudrait peut être une autre migration pour appliquer une valeur sur tous les NULL pour pouvoir enlever cette indication dans la déclarationd du champ que nous n’avions pas auparavant.
Autrement dit, on obtient 'TIMESTAMP NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP' à la place de 'TIMESTAMP default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP'.
Mais ça ne doit pas être très gênant.
A noter : le core migre les logos de tous les objets connus au moment de l'upgrade, mais si un plugin se desactive car pas compatible, ses logos ne seront pas migres. Il y a donc une fonction generique logo_migrer_en_base() generique que chaque plugin sera avise d'ajouter a ses upgrades pour SPIP 3.3
Pour ce faire, et après quelques discussions, on introduit un critère `{id_?}`.
Ce critère, va en quelque sorte s’expanser en autant de critères conditionnels `{id_article?}{id_rubrique?}...` adaptés à la boucle en question.
Ce critère sera très pratique dans les squelettes de listes d’objets filtrables.
On calcule la liste des champs à insérer avec la fonction lister_champs_selection_conditionnelle() (qui peut être altérée par le pipeline du même nom).
Ces champs sont :
- tous les champs id_xxx de la table de la boucle. (id_article, id_rubrique, id_secteur, id_trad pour la boucle ARTICLES)
- le champ 'objet' de la table de la boucle si elle en a un (par exemple dans la boucle FORUMS)
- les champs id_xxx clés primaires de tables qui peuvent être liées facilement à cette table (par exemple avec une table de liaison).
+ on ajoute un pipeline formulaire_verifier_etape qui recoit le numero d'etape en args et permet donc de traiter les cvtmulti proprement depuis les plugins
Cela permet pour l'usage que j'ai, de modifier $_FILES (sauvegarder / compléter) avant que la fonction verifier() s'en occupe. Notamment, si on utilisait le pipeline 'verifier' on arrivait trop tard.
La clé 'data' du pipeline n'a pas d'utilité pour l'instant et pour mon usage, du coup je la laisse à null. Peut être que quelqu'un·e trouvera un usage un jour :)
La constante _DEV_PLUGINS qui ne marchait pas très bien est remplacée par la constante _DEV_VERSION_SPIP_COMPAT qui indique que la branche est compatible avec une autre version de SPIP et que tous les plugins qui marchent avec cette autre version sont présumés marcher avec la version courante.
Pendant la phase de dev on definit cette constante par defaut à la dernière version stable, pour faciliter l'utilisation avec le parc de plugin qui fonctionne dans cette version stable. Quand on passera en beta/rc/release, la definition de la constante sera supprimée
Du coup f_jQuery et f_jQuery_prive sont traitée derogatoirement pour être inserrees avant les js issus des paquet.xml
Attention a l'ordre de chargement des JS : on a donc
- les js de f_jQuery (et donc jquery_pipeline)
- les js des paquet.xml
- les insertions de insert_head
Ex :
```<script source="http://example.org/test.js" type="public" />```
```<style source="test.js" type="prive" />```
Ce menu n'est pas visible par défaut.
Il n'est affiché que si l'utilisateur le demande explicitement (préférence utilisateur).
Il faut donc utiliser ce menu pour les plugins de ce type.
marcimat@rezo.net
