Renommer toutes les fonctions parents/enfants pour eviter tout risque de collision avec le plugin historique declarer_parent qui pourra donc coexister et assurer une transition douce du code. Les pipelines sont aussi renommes

objet_trouver_parents() passe au pluriel et est agnostique : puisqu'on a potentiellement plusieurs liens de parentés (car plusieurs méthodes de parentés et certaines méthodes pouvant remonter plusieurs liens), la fonction ne choisit pas et retourne l'ensemble des parents symétriquement aux enfants.
Une option de la fonction permet de se limiter aux parentées directes, ce qui ne veut pas dire pour autant qu'on a qu'un seul parent car on peut avoir sur une table un id_parent1 et id_parent2 qui pointent vers 2 parents.

(C'est juste une feature de confort, car de toute façon le retour de la fonction objet_trouver_parents() permet de filtrer les parents directs et les parents trouvés par une table de lien)
Le pipeline est renommé en conséquence.

(La compatibilité fonctionnelle avec l'API au singulier du plugin https://git.spip.net/spip-contrib-extensions/declarerparent pourra être assurée par ce dernier qui aura juste à retenir le premier parent de la liste retourné par la fonction du core pour produire le même résultat qu'auparavant et eviter de casser les consommateurs qui ne supportent pas de multiples parents)

RastaPopoulos a rédigé 4 years ago et cerdic a validé 3 years ago

Cette API a été développée et testée en amont dans le plugin Déclarer parent, puis utilisée dans plusieurs plugins.
Elle comporte 4 fonctions :

- 2 pour connaitre les types parent et enfants d'un type donné (que objet),
- 2 pour connaitre les contenus parent et enfants d'un contenu donné (objet + id_objet).

Un filtre est ajouté pour connaitre le parent d'un contenu facilement (cas le plus courant).

On déclare le parent pour les articles et les rubriques.
Une fois intégré, il faudra ajouter les autres déclarations qui étaient fournies par le plugin pour les plugins-dist : syndic, mots, et forums.

L'icone de tous les dangers : une icone svg pour les auteurs et autrices, aussi neutre que possible, qui reprend la convetion du cercle et le code couleur des statuts auteurs et autrices

thx francky aka mr paquet.xml

- une constante _DEBUG_TRACE_QUERIES a mettre a true pour activer le tracage des requettes SQL
- un pipeline trig_trace_query qui voit passer chaque requette

- plus d'icone dans les petits boutons du formulaire de traduction mais le code de langue a la place
- icone traduire et icone langue identiques utilisant une bulle avec 2 caracteres d'un alphabet different. La bulle pointe vers le haut pour degager de l'espace a l'icone dans le bouton d'ajout

Passons a des icones SVG pour le bandeau, le menu developpement est un peu bidouille mais il fait le job
On prefixe les icones avec un menu- pour eviter la collision avec d'autres nommages et on enleve le -48 qui ne veut rien dire ici

- 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.

ref #4350

au passage, on n'indique que la version mini de PHP (pas de borne max)

Ref https://core.spip.net/issues/4350#note-10 & Fix #4409

retour sur r24453

Ajout des necessite mini au paquet.xml du core pour PHP et les libs mysqli, xml & gd (sans version pour celles-ci)

Fix #4350

Ticket #4353 : On adapte les champs déclarés 'TIMESTAMP' en mysql versions récentes (8 par exemple) afin qu’ils se comportent comme on les attends
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.

migration des logos en base - les eventuels logos en doublons ou fichier artonxxxxx parasite sont deplaces dans IMG/logo_erreurs/
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

Ticket #4300 : permettre de se passer de la présence de certains plugins dans le core en retirant des critères spécifiques à ces plugins (ici {id_mot?}).

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).

Fix #3804 : les fonctions cvt multi etapes sont appelees par le core explicitement pour passer apres les pipelines
+ 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

Augmentation de la taille du champ 'prefs' de spip_auteurs, afin d'éviter d'éventuels problèmes sur la sérialisation des contenus qu'il reçoit.

Introduction d'un pipeline 'formulaire_receptionner' qui est exécuté au moment où une personne poste un formulaire, mais avant de passer dans la fonction de vérification prévu par ce formulaire.

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 :)

Amélioration plus pérenne des ajouts d'hier : on supprime le pipeline "chercher_logo" qu'on remplace par un pipeline "quete_logo_objet" dans une nouvelle fonction API du même nom. Ce déplacement fait que ce n'est plus que pour l'affichage, sans rapport avec le formulaire d'édition de logo. Merci cerdic :)

Nouveau pipeline "chercher_logo", qui permet de compléter ou ajouter des infos de logos après que SPIP ait cherché avec sa méthode classique. On peut donc fournir autre chose, et surtout on peut définir un logo si SPIP n'en a pas trouvé avant (exemple : prendre la première image jointe trouvée, comme dans Logo auto de Tetue). Sans avoir à surcharger salement ni bloquer d'autres méthodes ensuite.

un pipeline auth_administrer permet de personaliser le retour des differentes fonctions d'auth (par exemple pour renforcer la verification du mot de passe, quand flux['args']['fonction']=='verifier_pass'

- 3 pour les liens rapides du bandeau
- 1 pour l'entrée de menu phpinfo

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