Sélectionner une page


Dès le début, l’éditeur de blocs doit toujours être plus qu’un simple éditeur pour la zone de contenu principale. Dans Gutenberg Phase 2, l’éditeur de blocs est déployé dans d’autres parties du site, y compris les widgets, les menus et d’autres aspects de la personnalisation du site. Matias Ventura, l’un des principaux ingénieurs du projet, a donné un aperçu de la vision de l’équipe sur la façon dont l’éditeur de blocs abordera l’édition de l’ensemble du site avec une nouveauté intrigante. prototype.

Ventura a partagé une démo vidéo présentant le concept de «zones de bloc», qui comprend des en-têtes, des pieds de page, des barres latérales et tout autre élément de modèle significatif en dehors du contenu de l’article contenant des blocs. Dans l’exemple suivant, chaque élément de la page est constitué de blocs et peut être édité directement par l’utilisateur.

Le prototype n’a pas nécessairement été créé pour dicter une implémentation spécifique, mais montre plutôt certaines des façons dont les zones de bloc peuvent être organisées dans la page. Chaque zone de bloc est enregistrée séparément et chacune des parties du modèle peut avoir son propre nom. Ventura a suggéré de les enregistrer en tant que publications individuelles dans un type de publication personnalisé interne qui peut être isolé et modifié individuellement ou dans le cadre de la page entière. Cela permettrait différents modes de vue et peut-être même un mode de conception avec une superposition de grille:

Le prototype montre la possibilité d’explorer les blocs individuels imbriqués dans des modèles de rubrique et du contenu de publication. Cela donne aux utilisateurs une meilleure compréhension de la structure de la page et leur permet de naviguer facilement dans les blocs imbriqués.

Le rapport de Ventura est un peu technique et les détails de mise en œuvre sont toujours activement discutés sur plusieurs tickets sur GitHub, mais les premières réactions de la communauté au prototype ont été globalement positives.

Un examen plus approfondi de la manière dont les zones de bloc pourraient remplacer le personnalisateur

Alors que WordPress approche essentiellement du premier anniversaire de l’éditeur de blocs, l’interface utilisateur présentée dans le prototype des zones de bloc semble immédiatement plus familière que le personnalisateur. L’édition complète des sites Web à l’ère Gutenberg changera fondamentalement la façon dont les utilisateurs abordent la conception de leur site Web. L’éditeur de blocs unifie la personnalisation et les interfaces de contenu qui ne pouvaient auparavant pas être entièrement traitées au niveau du front-end.

« Il est trop tôt pour le dire avec certitude, mais dans un monde où tout est un bloc, l’interface utilisateur actuelle de Customizer, où l’aperçu se trouve dans une fenêtre distincte des commandes, n’est pas très nécessaire », a déclaré Weston Ruter, gestionnaire de composants pour le personnalisateur. « Lorsque les modèles de thème sont entièrement constitués de blocs qui prennent en charge la manipulation directe, il s’agit essentiellement d’un paradigme d’édition frontale. »

Ruter, qui a joué un rôle déterminant dans le développement d’une grande partie du personnalisateur, a déclaré que l’interface utilisateur actuelle, qui divise la conception et les contrôles en fenêtres séparées, est nécessaire car de nombreux contrôles nécessitent le rechargement de pages entières. L’interface fractionnée garantit que les contrôles ne disparaissent pas à mesure que la page se recharge pour refléter les modifications.

«Les meilleures intégrations de personnalisation sont les contrôles de mise à jour en direct pour ‘postMessage’ qui ne nécessitent pas de rechargement (par exemple, un sélecteur de couleurs)», a déclaré Ruter. «Plus récemment, la fonction d’actualisation sélective a également permis aux thèmes et aux plugins de régénérer des modèles partiels sans avoir à recharger la page entière. En théorie, ces compétences ont permis Édition en ligne sans avoir à recharger la page. « 

Alors que le personnalisateur donnait aux utilisateurs plus de contrôle sur la conception de leur site Web, le composant avait toujours du mal à fournir des contrôles puissants et des mises à jour en direct sur la même interface avec un espace de page limité. Ruter a souligné certains des avantages de faire de l’éditeur de blocs le principal outil de personnalisation dans WordPress.

«Les blocs fournissent une interface utilisateur commune qui vous permet d’effectuer de telles modifications en ligne sur n’importe quelle partie de la page, et pas seulement sur des zones spécifiques de l’aperçu du personnalisateur qui ajoutent des extras supplémentaires», a-t-il déclaré. «Avec cette interface de bloc commune avec un paradigme de manipulation directe, il n’y a pas besoin d’un panneau de contrôle séparé, et aucune page complète n’a besoin d’être rechargée pour apporter des modifications à l’aperçu. L’interface de personnalisation actuelle ne serait donc pas requise. « 

Bien qu’une grande partie du personnalisateur soit probablement obsolète dans la nouvelle ère de l’édition de site complet basée sur Gutenberg, le Ensemble de modifications du personnalisateur est un concept clé qui, selon Ruter, pourrait être préservé. C’est le code qui permettra aux utilisateurs de faire cela Modifications de la conception de la scène sur scène et dans les délais.

« Ceci est indépendant de l’interface actuelle du Customizer et concerne le modèle de données sous-jacent de WordPress », a-t-il déclaré. «Si des modifications apportées aux blocs Gutenberg ont été incluses dans un tel ensemble de modifications avant la publication, les modifications peuvent être prévisualisées sur un site Web avant le lancement. La nécessité de cela n’a pas été aussi évidente car les changements se sont limités à la publication de contenu. Cependant, une fois que les données de bloc ont été modifiées dans différentes entités d’un site, il est important de disposer d’un emplacement pour effectuer ces modifications avant de les mettre en ligne. « 

Les développeurs de plugins et de thèmes veulent surveiller les conversations autour de la mise en œuvre des zones de bloc pour l’édition complète du site. Lorsque ce prototype deviendra réalité, il aura un impact significatif sur les thèmes et les plugins qui étendent actuellement le personnalisateur. De nombreux développeurs de produits doivent repenser leurs solutions pour mieux s’adapter à la personnalisation du site prise en charge par l’éditeur de blocs. Ventura répertorie tous les problèmes GitHub pertinents dans son article Introduction de zones de bloc de contenu.



Source link

Recent Posts