Demandez au barman : qu'arrive-t-il au personnalisateur lorsqu'un thème de bloc est actif ?

Quelque chose sur mon radar en ce moment est des plugins tiers qui ont des paramètres dans le Customizer. Ce que je comprends d'amis qui sont les développeurs travaillant sur Customizer et des éléments frontaux au sein de quelques sociétés de plugins, les styles globaux et les styles de blocs ne sont pas encore sur leur radar. Que se passe-t-il si quelqu'un installe Twenty Twenty-Two ou un autre thème basé sur des blocs ? Le menu d'administration de gauche pour Customizer n'est pas là. Le moyen le plus simple d'y arriver est via Apparence> Thèmes> Personnalisateur. Mais on s'attend à ce que les plugins et thèmes tiers doivent déplacer les paramètres. En fait, cela semble plus qu'ils doivent dupliquer les paramètres aux deux endroits pendant un certain temps.

Anonyme

Pour ceux qui ne sont pas au courant, permettez-moi de fournir un rappel rapide sur ce sujet. Lorsque WordPress 5.9 débarquera, nous nous attendons à ce qu'il soit livré avec le nouvel éditeur de site et l'interface des styles globaux. Cependant, la plupart des utilisateurs ne verront pas cet écran à moins qu'ils n'exécutent un thème de bloc.

Étant donné que le prochain Twenty Twenty-Two est également livré avec WordPress 5.9 et à en juger par la popularité des thèmes par défaut passés, nous pouvons nous attendre à ce que plusieurs milliers d'utilisateurs soient transportés dans ce tout nouveau monde. Pour certains, cela pourrait être aussi choquant que le lancement de l'éditeur de blocs dans la version 5.0.

Lorsqu'un thème de bloc est actif, les liens permettant d'accéder à l'ancien et familier personnalisateur disparaissent de l'interface utilisateur. Les widgets et les écrans de menu de navigation ne seront pas là non plus. Cependant, ils seront toujours accessibles si vous connaissez l'URL des écrans.

Nous avons appris pour la première fois que ce serait le cas l'année dernière dans le cadre de la sortie de Gutenberg 9.3. Il existe également un problème ouvert pour s'assurer que l'éditeur de site a la parité des fonctionnalités avec certains paramètres de base de WordPress.

Il est normal que ces fonctionnalités soient progressivement supprimées pour les utilisateurs de thèmes de blocs. Ce sont toutes des tentatives précoces et disparates de créer des éléments individuels de ce que l'éditeur du site autorisera. WordPress rassemble tous ces concepts dans une expérience utilisateur plus cohérente. C'est une norme sur laquelle les contributeurs peuvent continuellement itérer. Ce ne sera pas parfait dès le départ, mais cette première version de la plate-forme principale devrait alimenter les commentaires nécessaires pour l'améliorer à mesure que de plus en plus d'utilisateurs commencent à installer des thèmes de blocs.

Le problème présenté ici a plus à voir avec le marché des plugins. Le personnalisateur a été initialement conçu comme un outil de paramétrage de thème et a principalement été utilisé à cette fin. Mais, de nombreux plugins lui ont lié divers paramètres au cours de ses neuf ans d'histoire. Une recherche de wp_customize dans le répertoire du plugin affiche plus de 1 400 résultats. Le hook customize_register en affiche plus de 1 900. Ce ne sont pas nécessairement des correspondances exactes pour le nombre de plugins qui ajoutent réellement des panneaux, des sections, des paramètres ou des contrôles. Cependant, c'est un indicateur que beaucoup s'y fient pour présenter des options aux utilisateurs finaux.

Nous revenons donc à la question posée. Que se passe-t-il lorsqu'un utilisateur installe un thème de bloc, tel que le prochain Twenty Twenty-Two, tout en utilisant un plugin qui s'appuie sur le personnalisateur ?

Ça dépend.

Certains plugins comme WooCommerce ont déjà placé un lien direct vers leur panneau/section de personnalisation dans le menu d'administration. Ce ne sera pas un problème pour leurs utilisateurs. Cependant, pour tout le monde, le personnalisateur semblera disparaître complètement.

Dans quelques semaines après la version 5.9, en fonction de la rapidité avec laquelle l'adoption de Twenty Twenty-Two se produit en particulier, nous pourrions être confrontés à des milliers d'utilisateurs confus. Bien sûr, tout cela pourrait changer dans le temps précédant la sortie. Cependant, c'est une conversation qui doit avoir lieu maintenant.

"La préoccupation ici concerne les utilisateurs finaux", a déclaré le questionneur anonyme. "Ils consulteront les articles de la base de connaissances, les instructions dans les paramètres du plug-in, etc. indiquant où rechercher les paramètres."

Au moins pour le moment, il incombe aux auteurs de plugins de résoudre ce problème pour leurs propres utilisateurs. Cependant, il existe plusieurs voies qu'ils voudront peut-être emprunter.

La méthode la plus simple consiste à suivre l'exemple de WooCommerce. Le plugin vérifie le conditionnel gutenberg_is_fse_theme() (notez que ce nom de fonction peut changer). S'il renvoie true , le plugin ajoute un lien directement vers son panneau de personnalisation.

La liaison à un panneau, une section ou un contrôle de personnalisation est simple. Les auteurs de plugins peuvent trouver les URL dans le manuel du développeur. Ils peuvent également simplement copier la technique utilisée par l'équipe WooCommerce.

Il s'agit d'une méthode rapide pour garantir que les utilisateurs ne perdent pas l'accès à leurs options si les auteurs de plugins ne peuvent pas apporter de modifications avant l'arrivée de WordPress 5.9.

A long terme, ce n'est pas la solution idéale. Le personnalisateur sera là pendant longtemps, mais les auteurs de plugins devront gérer deux groupes d'utilisateurs : ceux qui exécutent à la fois des thèmes de blocs et des thèmes classiques.

Parce que chaque plugin est différent, les solutions devront être différentes. Beaucoup peuvent simplement utiliser l'API Paramètres pour créer un écran d'options personnalisé. S'il s'agit d'une solution viable, peu importe le thème exécuté par l'utilisateur.

Cependant, la réalité pourrait être de maintenir deux systèmes pour les deux groupes d'utilisateurs. Un qui s'intègre au personnalisateur et un autre qui extrait des options dans l'éditeur de site. Si le plugin a des fonctionnalités liées à la conception, les utilisateurs du thème de bloc s'attendront à voir les paramètres dans la nouvelle interface.

Du côté des thèmes, il devrait y avoir moins de problèmes. De toute façon, un thème de bloc ne fait rien avec le personnalisateur. Un problème en suspens serait la conversion du contenu de démarrage, et il existe un ticket ouvert pour l'apporter à l'édition complète du site.

Plus que tout, garder des lignes de communication ouvertes avec les utilisateurs aidera à faciliter la transition. Une partie de cela devrait provenir du cœur de WordPress. Cependant, de nombreux utilisateurs auront besoin de l'entendre de leurs développeurs de plugins et de thèmes. Il peut s'agir d'articles de blog, de mises à jour de la base de connaissances ou de didacticiels et du suivi de l'assistance.

Ensuite, il y a la solution finale, celle que WordPress lui-même pourrait implémenter. C'est aussi le chemin de moindre résistance.

WordPress devrait détecter automatiquement les filtres ou les actions sur les crochets liés au personnalisateur. Cela devrait déclencher un indicateur "personnaliser les supports" et maintenir le menu d'administration et les liens de la barre d'outils vers l'écran de personnalisation. Cela donnerait aux développeurs un peu de temps pour rattraper leur retard sans dérouter les utilisateurs dans le processus. Il peut y avoir quelques faux drapeaux ou intégrations manquées, mais il devrait être capable de détecter efficacement la majorité des cas d'utilisation.