Explorer l'édition complète du site avec le thème Q WordPress

J'attendais avec impatience le moment où je pourrais installer un thème et vraiment tester la fonction d'édition complète du site de Gutenberg. Dans l'ensemble, chaque fois que je l'ai testé au cours des derniers mois, l'expérience s'est sentie complètement brisée. C'est pourquoi je suis resté sceptique de voir la fonctionnalité atterrir dans WordPress 5.6 en décembre.

Le thème Q d'Ari Stathopoulos est le premier thème qui semble être un exemple de travail décent. Que ce soit un coup de chance avec le timing ou que ce thème particulier soit simplement construit correctement est difficile à dire - Stathopoulos est un représentant de l'équipe des thèmes. Gutenberg 9.1 a été abandonné la semaine dernière avec la poursuite des travaux d'édition du site.

Q est aussi expérimental que possible. L'équipe des thèmes a lancé un appel ouvert pour des thèmes expérimentaux basés sur des blocs dès mars de cette année. Cependant, peu ont accepté l'équipe sur cette offre. S'il est approuvé, Q sera le premier thème basé sur des blocs à être mis en ligne dans le répertoire officiel de WordPress. Il doit encore se frayer un chemin à travers le processus d'examen standard, attendant son tour dans les semaines à venir.

Dans l'ensemble, l'édition complète du site reste une expérience frustrante et déroutante. Je reste toujours sceptique quant à sa capacité, même sous forme bêta, à se montrer au monde dans WordPress 5.6.

Cependant, Q est un thème intéressant à explorer à ce stade pour les utilisateurs finaux et les développeurs de thèmes. Les utilisateurs peuvent l'installer et commencer à bricoler l'écran d'édition du site via le plugin Gutenberg. Les développeurs peuvent apprendre comment les styles globaux, les modèles et les composants de modèle s'imbriquent à partir d'un thème de travail.

Utilisation de l'éditeur de sites

Le thème Q nécessite l'activation du plugin Gutenberg et de son mode d'édition complet du site. Généralement, l'exigence d'un plugin n'est pas autorisée pour les thèmes du répertoire. Cependant, les thèmes expérimentaux de Gutenberg sont autorisés à contourner cette directive.

Stathopoulos a souligné que le thème est hautement expérimental et ne devrait pas être utilisé sur un site de production. Cependant, il espère que cela attirera plus d'attention sur l'édition complète du site.

Il a mentionné que plusieurs éléments sont cassés, tels que les archives de catégorie n'affichant pas les bons messages. Il s'agit d'une limitation actuelle du bloc Query dans Gutenberg. Cependant, l'un des meilleurs moyens de trouver et de reconnaître ces types de problèmes est d'avoir un thème qui suit le rythme du développement.

Actuellement, l'éditeur du site a l'impression de mordre plus qu'il ne peut mâcher. Non seulement les utilisateurs peuvent modifier la mise en page et la conception de la page, mais ils peuvent également modifier directement le contenu des publications existantes - n'essayez pas cela à la maison, sauf si vous souhaitez que les titres de vos publications soient remplacés par le slug avec trait d'union. L'éditeur du site doit-il s'occuper de la double tâche de conception et d'édition du contenu ? Si tel est le cas, la conception et l'édition du contenu doivent-elles être gérées dans des emplacements distincts à long terme ou être fusionnées en une seule fonctionnalité ?

Il se sent brut. Il n'est pas orienté vers les utilisateurs à ce stade.

Le point positif avec l'éditeur de site est la progression actuelle des parties de modèle dans l'éditeur. Les parties de modèle sont essentiellement des "modules" qui gèrent une partie de la page. Par exemple, le thème typique aura une partie de modèle d'en-tête et de pied de page. Actuellement, les utilisateurs finaux peuvent insérer des composants de modèle personnalisés ou remplacer un composant de modèle par un autre. Cela ouvre un monde de possibilités, comme les utilisateurs qui choisissent entre plusieurs conceptions d'en-tête (parties de modèle) pour leurs sites.

L'inconvénient de l'ensemble du système de modèles est qu'il semble tellement séparé de l'éditeur du site qu'il est difficile de croire que l'utilisateur moyen comprendrait ce qui se passe. Les modèles et les parties de modèle résident dans le menu Apparence de l'administrateur. L'éditeur de site est un élément de menu distinct de niveau supérieur. Sans aucune connaissance préexistante de la façon dont ces pièces fonctionnent ensemble, cela peut être déroutant.

Les parties de modèle ont fonctionné pour moi dans l'éditeur de site dès le départ. Cependant, ils n'ont pas travaillé sur le front-end au début. J'ai continuellement reçu le message "partie de modèle introuvable" pendant des heures. Puis, à un moment donné - que ce soit par magie ou par une sauvegarde aléatoire qui a tout rassemblé - la fonctionnalité a commencé à produire les parties de modèle d'en-tête et de pied de page qui manquaient auparavant.

Aperçu de l'avenir du développement de thèmes

Le thème Q a peu de règles de style, qu'il charge directement dans la section <head> du site au lieu d'ajouter une feuille de style supplémentaire. Il s'appuie sur les styles de bloc Gutenberg d'origine à l'avant avec quelques dérogations mineures. La plupart des autres styles personnalisés sont gérés via le système de styles global, qui extrait du fichier de configuration experimental-theme.json du thème (sera theme.json à l'avenir).

Cela soulève la question de savoir si les thèmes auront nécessairement besoin de beaucoup de CSS lors de l'édition complète du site.

Si WordPress permet aux utilisateurs de configurer la plupart des styles via des options de bloc et des remplacements de styles globaux, les thèmes peuvent ne pas avoir besoin de beaucoup plus que leurs fichiers de configuration. Après cela, il s'agirait d'enregistrer des styles et des modèles de blocs personnalisés.

Si c'est l'avenir vers lequel nous nous dirigeons, n'importe qui pourrait essentiellement créer un thème WordPress. Et ces éléments, tels que les pièces de modèle et les modèles, peuvent tous être partagés entre n'importe quel site. Dans ce futur, les thèmes pourraient tout simplement ne plus avoir d'importance.

L'année dernière, Mike Schinkel a proposé de déprécier complètement le système de thème et de le remplacer par des composants Web.

"Plutôt que de rechercher un thème qui possède toutes les fonctionnalités dont on a besoin - ce qui limite toujours les choix à zéro - un propriétaire de site pourrait rechercher les composants et les modules dont il a besoin, puis assembler son site à partir de ces modules", a-t-il déclaré. . "Ils pouvaient choisir un en-tête, un pied de page, un héros de page d'accueil, un ensemble de fiches d'articles, un module de tarification, etc."

Plus je bricole avec l'édition complète du site, plus j'ai l'impression que c'est la voie dans laquelle il finira par fusionner. Imaginez un avenir où les utilisateurs finaux pourraient choisir les pièces qu'ils voulaient et les faire simplement apparaître sur le devant.

C'est excitant de penser à cette possibilité. Schinkel et moi avons plus d'expérience en programmation qu'en design. Il est logique, à partir de ce type d'état d'esprit analytique, de tout mettre dans des boîtes propres et réutilisables, car la réutilisation est la pierre angulaire de la programmation intelligente.

Cependant, je m'inquiète de l'état de la conception d'un tel système avec autant de pièces remplaçables. Les concepteurs pourront-ils adopter des approches holistiques pour le développement de thèmes, créant des œuvres d'art vraiment complexes ? Ce système créera-t-il essentiellement un réseau de sites à l'emporte-pièce ? Ou les concepteurs trouveront-ils simplement des moyens de sortir des sentiers battus tout en respectant les contraintes du système de blocs ?