Deregister blocs et variations about beapi-frontend-framework

[francoistibo]

branche 'issue/164' existante sur repo
méthode JS deregister core blocks variations + deregister embed blocks ok

[francoistibo]

@Rahe : le deuxième point est traité dans cette PR https://github.com/BeAPI/beapi-frontend-framework/pull/178/files pour que tu puisses commenter.

[Rahe]

Du coup, il faudrait utiliser wp_add_inline_script avec un JSON écrit auquel on a attaché en PHP un tableau concentrant

• Les entrées pour unregisterBlockStyle
• Les entrées pour unregisterBlockVariation
  Avec en clef le namespace, en valeur la variation à casse.

Le Js que tu as écrit irai alors lire le tableau JSON généré et faire le deregister en JS
On aurait alors pas besoin de toucher à ton script pour faire les deregister, que le PHP :)

[francoistibo]

OK.

[francoistibo]

et sinon, pour deregister les blocs gut en PHP, il est possible de les whitelister en PHP (n'autoriser que les blocs dont on a besoin)... ce qu'on faisait déjà avec le filtre allowed_block_types.

pour les blacklister (supprimer ceux qu'on ne veut pas), on est obligés de passer par le JS (wp.blocks.unregisterBlockType(blockName)) comme pour les blocs style et les blocs variation, ce qui est cohérent avec ce que j'ai déjà fait (à améliorer).

https://awhitepixel.com/blog/wordpress-gutenberg-control-blocks-remove-and-block-templates/

[Rahe]

Oui, mais ya un problème pour les variations, j'ai tendance à vouloir unifier la manière de le faire.
On utilise ce que l'on peut en PHP, et ce que l'on peut en JS.
Mais la source de données vient du PHP, le service Editor doit gérer ces deux aspects :

• Filtre allowed_block_types pour ce que l'on peut gérer en PHP avec l'allowlist
• Ajout de la partie JS+PHP pour gérer les parties non gérables en PHP pur

[Rahe]

On a pensé aussi à pouvoir de créer une hiérarchie avec parent/enfant, s'il manque par exemple core/buttons alors qu'on a autorisé core/button on devrait pouvoir le remettre automatiquement