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

fix: Les `.objetblock` ne sont pas forcément les enfants directs de `.sortable`, on ne peut pas utiliser `this.toArray();`

Utiliser le bon nom de classe

La fonction principale _block_charger_block va récupérer elle même les squelettes des blocks enfants si le block en a.
Si on est dans l'espace privé, on inclut `prive/squelettes/inclure/block_objet` qui contient tout ce qu'il faut pour gérer un block (boutons etc), sinon on charge simplement `inclure/block` du squelette public.
Gros avantage pour l'intégration : dans le squelette d'un block qui peut contenir des blocs, on peut placer un `<!--blocks-->` qui sera remplacé par les blocks enfants, et donc on peut les encapsuler dans un markup personnalisé.

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: Masquer visuellement le bouton "Ajouter un bloc" une fois qu'on a cliqué dessus, le réafficher si on clique sur "Annuler"

Ref #10

Nécessite le plugin verifier, pour le constructeur de formulaire (à supprimer si on bascule sur des sources YAML)
Rangement alphabétique des necessite

Ref #9

Ref #12

Ref #4

Fix #1

Fix #7

Fix #6

Ref #4

Ref #4

Ref #4

Fix #3