Pour pouvoir l'intercepter depuis un pipeline formulaire_* par exemple et faire des choses en fonction du type (vérifier une valeur, copier un fichier...)

Evitons les confusions

C'est une fonctionnalité trop spécifique qui alourdit l'UI

Tester l'existence des tables avant de les supprimer
Supprimer aussi les données de spip_auteurs_liens

* les balises, dans blocks_fonctions.php
* les utilitaires, dans inc/blocks.php

(oué, je fais un lot, je fatigue là...)

Un squelette vide, et la bonne déclaration cvt

On ne se base plus sur le constructeur de formulaires et un objet éditorial `blocktype`, mais sur des fichiers de config en .yaml, à l'instar des modèles gérés par inserer_modeles
Cela implique donc de la suppression de code et de fichiers (toute la gestion des objets `blocktype`) et de nouvelles fonctions pour gérer proprement des fichiers de config.
La fonction principale `blocktypes_lister_types` met tout ça en cache pour le hit (en static), et des fonctions utilitaires viennent taper dans ce cache.

Il y a une procédure de migration (cf README.md), qui sera peut être déportée dans un deuxième plugin à part dans lequel je mettrai aussi des démos de blocks de base, pour alléger le code et les fichiers de celui ci.

Restent à traiter les notions de block conteneur, et les contraintes parent/enfant, ne peut contenir que / être contenu que dans.
Et une todo list qui s'allonge...

Les blocktypes ne sont plus gérés dans le privé avec une table dédiée et un constructeur de formulaires, mais se basent sur des fichiers blocks/*.yaml (comme saisies, compositions, inserer_modele etc.)
Une procédure de mise à jour / migration est prévue, cf README.md

Quand on modifie en ajax, l'id_block revient dans l'url de la page courante et peut provoquer des conflits

Ref #10

Ref #10

fix: Ne pas afficher le bouton "Ajouter un bloc" dans la deuxième partie du formulaire, et ajouter le type de bloc dans l'entête

Fix #7

Ne pas masquer (replier) le panel de l'accordéon quand on est sur la deuxième étape (saisie des paramètres)

Refactoring de l'interface : ajout d'un accordéon sur les blocks qui permet de les replier pour occuper moins d'espace, et qui garde les choix en session (cookie)

Passer le type de block parent au formulaire d'édition de block, qui le redescend sur la saisie qui permet d'ajouter un type de block

- création d'une table de liaisons blocktype -> blocktype, avec un role [parent|enfant]
- mise à jour des rôles sur la page d'édition d'un blocktype et contrainte d'intégrité (si un blocktype A ne peut être contenu que dans un blocktype B, alors le blocktype B peut forcément contenir le blocktype A)
- chaines de langue