WAW : tout déplier / tout replier dans la vue en liste

Extension WordPress qui ajoute une entrée « Tout déplier » / « Tout replier » dans le menu « … » d'un bloc, dans l'éditeur Gutenberg. L'action s'applique au bloc courant et à toute sa descendance, sur autant de niveaux que nécessaire.

Aucun réglage, aucune page d'options : l'entrée apparaît dans le menu du bloc dès que celui-ci contient des blocs enfants.

Le problème

La vue en liste de Gutenberg ne sait déplier qu'un niveau à la fois. Sur une page FSE réelle (groupes imbriqués, colonnes, requêtes, patterns), atteindre un bloc profond demande une dizaine de clics sur les chevrons, et il n'existe aucun moyen de tout replier après coup pour retrouver une vue lisible.

Cette extension ajoute les deux opérations manquantes, appliquées récursivement à une branche entière de l'arbre.

Installation

Depuis une archive

1. Télécharger le dépôt en ZIP (bouton Code → Download ZIP) ou depuis la page Releases.
2. Dans l'administration WordPress : Extensions → Ajouter une extension → Téléverser une extension.
3. Activer l'extension.

Depuis Git

cd wp-content/plugins
git clone https://github.com/thierrypigot/waw-list-view-expand-all.git

Puis activer l'extension depuis l'administration.

Il n'y a rien à compiler : index.js est du JavaScript natif, sans étape de build ni dépendance npm.

Utilisation

1. Ouvrir un contenu ou un modèle dans l'éditeur.
2. Sélectionner un bloc conteneur (groupe, colonnes, requête…).
3. Ouvrir son menu « … » (dans la barre d'outils du bloc ou dans la vue en liste).
4. Cliquer sur Tout déplier ou Tout replier.

L'intitulé s'adapte à l'état courant du bloc dans la vue en liste. Si la vue en liste est fermée, elle est ouverte automatiquement avant l'opération.

Prérequis

Compatible thèmes classiques et thèmes de blocs (FSE), éditeur de contenu et éditeur de site.

Fonctionnement technique

Point important pour toute personne qui reprend le code : l'état déplié/replié de la vue en liste n'est pas exposé dans un store wp.data. Il vit dans un reducer React local au composant ListView de @wordpress/block-editor. Il n'existe donc aucune API publique pour le piloter.

L'extension combine par conséquent deux sources :

• La topologie des blocs vient de core/block-editor (getBlockOrder, getBlockParents, getSelectedBlockClientId). C'est la partie fiable et documentée : elle donne la liste exacte des descendants d'un bloc.
• Le pilotage des chevrons passe par le DOM : on lit aria-expanded sur la ligne (ou sur le bouton interne, selon les versions) et on clique sur .block-editor-list-view__expander.

Deux subtilités traitées dans le code :

• Déplier procède par passes successives (MAX_PASSES, TICK), parce que les lignes enfants ne sont montées dans le DOM qu'une fois leur parent déplié. Chaque passe fait apparaître un niveau supplémentaire, jusqu'à ce qu'une passe ne change plus rien.
• Replier procède du niveau le plus profond vers le plus haut, sinon les descendants sont démontés avant d'avoir été traités et conservent leur état déplié au prochain dépliage. De plus, si le bloc sélectionné se trouve dans la branche, le hook useListViewExpandSelectedItem rouvre en boucle le chemin vers lui : la sélection est donc déplacée sur le bloc courant avant de replier.

L'interface est injectée via un Fill sur BlockSettingsMenuControls, enregistré avec wp.plugins.registerPlugin. L'entrée n'est rendue que si un seul bloc est sélectionné et qu'il possède des enfants.

Conséquence : fragilité assumée

Le pilotage par le DOM dépend de classes et d'attributs internes de Gutenberg (.block-editor-list-view-tree, .block-editor-list-view__expander, aria-expanded, aria-level). Ce sont des détails d'implémentation, non des API publiques : une refonte de la vue en liste peut casser l'extension. Les garde-fous en place (vérifications de présence, sortie silencieuse si le composant est absent) évitent une erreur JavaScript bloquante dans l'éditeur, mais l'entrée de menu peut alors ne plus rien faire.

Structure

waw-list-view-expand-all/
├── waw-list-view-expand-all.php   En-tête d'extension + enqueue de l'éditeur
├── index.js                       Toute la logique (JS natif, sans build)
├── languages/
│   ├── waw-list-view-expand-all.pot
│   ├── waw-list-view-expand-all-fr_FR.po
│   └── waw-list-view-expand-all-fr_FR-<md5>.json
├── README.md
├── CHANGELOG.md
├── readme.txt                     Format WordPress.org
└── LICENSE

Traductions

Les chaînes de l'interface sont traduites côté JavaScript, via wp_set_script_translations(). WordPress lit pour cela le fichier JSON dont le nom contient le hash MD5 du chemin du script (waw-list-view-expand-all-fr_FR-<md5 de "index.js">.json), pas le .po.

Pour régénérer les fichiers après modification des chaînes :

wp i18n make-pot . languages/waw-list-view-expand-all.pot
wp i18n make-json languages/ --no-purge

Le .po français reste la source éditable ; le .json est le fichier réellement chargé par l'éditeur.

Développement

Aucune chaîne d'outils n'est requise. Le fichier index.js est servi tel quel, avec un cache-buster basé sur filemtime().

Les dépendances déclarées à l'enqueue (wp-plugins, wp-block-editor, wp-components, wp-data, wp-element, wp-i18n) sont fournies par WordPress ; il n'y a rien à installer.

Licence

GPL-2.0-or-later. Voir LICENSE.

Auteur

WeAre[WP] - Thierry Pigot