7936 sujets

Développement web côté serveur, CMS

Bonjour,

La version 5 de WordPress arrive avec le nouvel éditeur Gutenberg...

Vous avez commencé à vous y préparer?

Après lui avoir craché dessus, un peu comme tout le monde au début, je commence à m'y pencher dessus, un peu obligé et finalement c'est pas si mal que ça..
Une chose est sure, beaucoup de nos habitudes vont devoir changer dans WordPress au niveau du développement des thèmes.

Quelles sont vos impressions?
Première constatation importante que j'ai pu faire, il semble que Gutenberg injecte son propre code CSS dans certains éléments affichés en front-end, les galeries d'images par exemple , qui semblent responsives en natif avec du CSS flexbox injecté par Gutenberg, ce qui semble une bonne nouvelle..
Salut !

Je ne m'y étais pas intéressé encore mais c'est chose faite merci Smiley smile
Effectivement c'est plus moderne, plus stylé etc.
Pour le grand publique ça va effectivement être un gros avantage de jouer sur le terrain des WIX etc. Ils seront beaucoup plus libre de tout faire eux-même (même si du coup ça bouffe également une partie des clients des créateurs de site j'imagine).

Moi qui suis un partisan du "tout maîtrisé" j’émets quand même un doute au niveau de la flexibilité d'un thème et du code généré (html ou CSS injecté comme tu dis).
A tester donc...
De toutes façons on aura pas le choix... je crois qu'il faudra bien briefer les utilisateurs aussi..

En tout cas en Aout je me jette corps et âme dans l'étude du développement de block custom pour Gutenberg afin de créer mon propre bloc de colonnes de contenus responsive, depuis le temps que j'attendais ça.. c'est ce qui manquait le plus dans wordPress..
Moi depuis longtemps je parsse le code produit par WordPress pour le rendre compatible avec ma propre charte html avec mes classes perso (tableaux, galeries, etc). Mais là je vais peut-être devoir m'adapter à ce nouveau venu qui risque de me compliquer la vie.
Alors, je suis allé voir des démos, et bien ça craint : l'utilisateur pourra casser la charte graphique du site, ce qu'il pouvait déjà faire, mais cette fois ci avec une facilité déconcertante. Et comme on peut tout définir bonjour le style inline, ça va ressembler a des copier-coller à partir de Word. Le système de menu par ascenseur est vraiment dégeulasse.

Ca fait longtemps que je souhaite me tourner vers un autre CMS, il va falloir que j'y songe sérieusement.

Pour moi, la vraie révolution dans l'édition serait une utilisation "côté front" - si vous me permettez l'expression -, avec éventuellement des classes que l'on pourrait mettre au diapason avec le theme, sans style inline.
Modifié par Olivier C (02 Aug 2018 - 08:41)
Pour info ce qui arrive aujourd'hui/demain avec la 4.9.8, c'est un appel à installer Gutenberg qui sera pour l'instant sous forme de plugin. Et wordpress 5 ce n'est pas pour tout de suite.

J'ai testé rapidement et je trouve que ça ne réagit pas super bien / c'est un peu compliqué à utiliser. Les éléments de l'interface clignotent dans tout les sens et ce n'est pas très clair. Bref ce n'est pas fonctionnel.

Cela demandera aussi beaucoup de boulot pour prendre en compte tout les éléments en front ou si on doit personnaliser des éléments. Mais ça correspond assurément à un besoin des utilisateurs.
Modifié par Depassage (02 Aug 2018 - 09:38)
Olivier C a écrit :
Alors, je suis allé voir des démos, et bien ça craint : l'utilisateur pourra casser la charte graphique du site, ce qu'il pouvait déjà faire, mais cette fois ci avec une facilité déconcertante.


Je pense qu'il sera possible, en plus de proposer ses propres blocs spécifiques, de modifier la liste des blocs qui sont proposés, afin d'éviter que l'utilisateur final ne se "sente plus".
De toutes façons il faudra surement discipliner ce dernier ( with great power comes great responsability ... comme disait l'oncle de Spiderman )
Depassage a écrit :
Pour info ce qui arrive aujourd'hui/demain avec la 4.9.8, c'est un appel à installer Gutenberg qui sera pour l'instant sous forme de plugin. Et wordpress 5 ce n'est pas pour tout de suite.

Ah, la 4.9.8 arrive et ils incitent à installe Gutenberg?
Moi sur les sites réels j'attendrai un peu... voir si tous les plugins fonctionnent bien, je vais laisser les autres essuyer les plâtres.


Depassage a écrit :
J'ai testé rapidement et je trouve que ça ne réagit pas super bien / c'est un peu compliqué à utiliser. Les éléments de l'interface clignotent dans tout les sens et ce n'est pas très clair. Bref ce n'est pas fonctionnel. utilisateurs.

C'est pas si mal que ça, il suffit d'y rentrer dedans..
Je pense que l'avenir est dans la création de ses propres modules/blocs..
Il y a un effort à faire puisque c'est orienté Js moderne mais la procédure est relativement blindée et de toutes façons c'est l'avenir...
lionel_css3 a écrit :

Ah, la 4.9.8 arrive et ils incitent à installe Gutenberg?
Moi sur les sites réels j'attendrai un peu... voir si tous les plugins fonctionnent bien, je vais laisser les autres essuyer les plâtres.
C'est pas si mal que ça, il suffit d'y rentrer dedans..
Je pense que l'avenir est dans la création de ses propres modules/blocs..
Il y a un effort à faire puisque c'est orienté Js moderne mais la procédure est relativement blindée et de toutes façons c'est l'avenir...

Après avoir parcouru plusieurs articles traitant de l'arrivée de Gutenberg et utilisé la page de démo Wordpress, je serais bien en peine de garantir la tête sur le billot que toute migration se passera sans dommage... collatéral ou non.
Certains blogueurs avancent l'idée d'une remise en question en profondeur pouvant les conduire à un changement pur et simple de CMS.
Grosso modo, c'est tout de même l'attentisme qui prédomine et pas mal de concepteurs de sites web sont plutôt dans une position type j'y vais / j'y vais pas... et attendent de voir si les autres se cassent les dents avant de décider.
Certains envisagent carrément de ne pas faire de montée en version, avec tous les problèmes de sécurité et autres que cela pose.
Après avoir joué un petit moment (pas en profondeur tout de même...) avec leur page de démo, deux ou trois trucs me laissent toutefois perplexe, notamment l'utilisation d'attributs @style dans les blocs. On sait tous ce que sont les préconisations à ce sujet...
De mémoire, mais à confirmer, il me semble avoir vu une DIV vide servant d'espacement vertical entre blocs. Si ce point est exact (encore un fois, j'ai parcouru le site en vitesse...), c'est une hérésie pure et simple.
Sur le fond, je rejoins l'avis exprimé par plusieurs auteurs qui auraient préféré que Gutenberg reste sous forme d'extension et que le choix soit laissé au concepteur du site. Il semble cependant que les intentions prêtées à la société gérant Wordpress sur le moyen / long terme soient plutôt une évolution vers un concepteur de type DIVI et consorts.
Apparemment tout le monde ne semble pas se réjouir cette orientation, réelle ou supposée...
Concernant le choix fait par Wordpress de raisonner en "blocs", je ne suis pas convaincu de sa pertinence tout simplement parce que j'ai rencontré la même problématique pour mon générateur de sites web et, bien que séduisante de prime abord, cette conception présente par nature quelques limites.
Je suis revenu à une notion de "composant", bloc ou non bloc, plus proche de ce qu'est le DOM.
sepecat a écrit :

Après avoir joué un petit moment (pas en profondeur tout de même...) avec leur page de démo, deux ou trois trucs me laissent toutefois perplexe, notamment l'utilisation d'attributs @style dans les blocs. On sait tous ce que sont les préconisations à ce sujet...
De mémoire, mais à confirmer, il me semble avoir vu une DIV vide servant d'espacement vertical entre blocs. Si ce point est exact (encore un fois, j'ai parcouru le site en vitesse...), c'est une hérésie pure et simple.


Alors là c'est sur, les puristes du Css et des recommandations W3C vont piquer des crises... moi j'aime même vu du style en ligne rajouté pour le centrage du texte par exemple..
C'est quasiment impossible de faire un wysiwyg comme cela sans css inline de toute façon car la css du site casserait inévitablement le code de l'éditeur.

Je pense aussi que ce genre d'éditeur est l'avenir. On va pas se cacher que ce que fait wordpress actuellement est très limité même si ça fonctionne bien. Le bond que veut faire gutenberg est peut être trop grand.

Ce qui est sûr c'est que j'éviterai de le mettre en production sur d'ancien site et sur les futurs je verrai à l'usage.
Modifié par Depassage (03 Aug 2018 - 09:28)
En explorant le bloc "galerie d'images" je vois un sérieux problème de performances..
Lorsque l'on choisi des images pour la galerie, on ne peut plus choisir la taille de l'image affichée dans l'article.
Avant, on choisissait en principe 'miniature' pour afficher les vignettes et on liait cette vignette à un format d'image ('large' bien souvent) pour l'affichage individuel (agrandi) de l'image.
Cela veut dire que maintenant dans un article , au lieu d'avoir 10 ou 15 vignettes avec des images 150x150 dans la page, on pourrait afficher 15 images full HD qui seraient représentées dans une 'size' réduite par le navigateur...

bizarre...
Modifié par lionel_css3 (04 Aug 2018 - 11:34)
De toute façon moi je parssais déjà la galerie actuelle pour l'optimiser et proposer des images dotés d'attributs srcset maîtrisés.

Exemple ici : Beatus de Silos ou encore ici Beatus de Facundus

Les images d'origine font facilement 4500X6500 et pas de problème de performance notable sur navigateurs modernes.

Pour info, le schéma de base du code html5 est ici : Picture tag, srcset and sizes attributes.
Et le parssage du html pour WordPress en php est ici : Github
Modifié par Olivier C (01 Dec 2018 - 09:32)
lionel_css3 a écrit :
Houla ça a l'air puissant tout ça et ça fait quoi exactement?

Au final ? ça génère chaque image d'une gallerie via la balise html5 <picture> (cf. ce tuto sur picture) comme il est montré dans le CodePen :
<figure>
  <picture>
    <source media="(min-width: 2000px)" srcset="https://scriptura.github.io/Images/LotusTest.jpg,  https://scriptura.github.io/Images/LotusTest.jpg  2x" sizes="100vw"/>
    <source media="(min-width: 1500px)" srcset="https://scriptura.github.io/Images/LotusTest2000.jpg,  https://scriptura.github.io/Images/LotusTest.jpg  2x" sizes="100vw"/>
    <source media="(min-width: 1000px)" srcset="https://scriptura.github.io/Images/LotusTest1500.jpg,  https://scriptura.github.io/Images/LotusTest2000.jpg  2x" sizes="100vw"/>
    <source media="(min-width: 800px)" srcset="https://scriptura.github.io/Images/LotusTest1000.jpg,  https://scriptura.github.io/Images/LotusTest2000.jpg  2x" sizes="100vw"/>
    <source media="(min-width: 600px)" srcset="https://scriptura.github.io/Images/LotusTest800.jpg,  https://scriptura.github.io/Images/LotusTest1500.jpg  2x" sizes="100vw"/>
    <source media="(min-width: 400px)" srcset="https://scriptura.github.io/Images/LotusTest600.jpg,  https://scriptura.github.io/Images/LotusTest1000.jpg  2x" sizes="100vw"/>
    <source media="(min-width: 300px)" srcset="https://scriptura.github.io/Images/LotusTest400.jpg,  https://scriptura.github.io/Images/LotusTest800.jpg  2x" sizes="100vw"/>
    <source srcset="https://scriptura.github.io/Images/LotusTest300.jpg" sizes="100vw"/>
    <img src="https://scriptura.github.io/Images/LotusTest.jpg" alt="Lotus"/>
  </picture>
</figure>

Note que WordPress est lui aussi capable de générer des attributs srcset à partir des différentes tailles d'images disponibles, mais il le fait à l'arrache.
Modifié par Olivier C (05 Aug 2018 - 03:05)