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é il y a 4 ans et cerdic a validé il y a 3 ans

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