 Bonjour tout le monde, je suis ravi d'être, de faire partie de ce World Camp avec vous aujourd'hui, à Lyon en plus, la ville où j'ai débuté ma carrière. C'est la première fois par contre que je passe de l'autre côté du micro, donc voilà, je voulais me dire qu'est-ce que c'est la fois ravi et honoré de participer et d'être partagé à cette expérience dorateur avec vous aujourd'hui. Donc merci à tous et merci à l'équipe d'organisation. Je me présente rapidement, je m'appelle Zéremis 35 ans, je suis co-insultant. J'interviens d'entreprise particulièrement sur deux types de missions, de la direction technique d'une part et d'autre part, je suis un développeur senior pour le Stack WordPress. C'est un outil que j'utilise quasiment en quotidien depuis plus de 12 ans maintenant. Donc c'est pour ça qu'on pourrait dire que je viens de l'écosystème classique. Et c'est pour ça qu'on va parler aujourd'hui de la courbe d'apprentissage dans la plupart de l'écosystème classique vers FSE, ou plus précisément, full site editing, voilà. Et vous pouvez me retrouver sur les réseaux pour toutes questions ou autres échangées après, sous le pseudo GDM. Juste avant de rentrer dans le concret, dans le vif du sujet de la courbe d'apprentissage, je voulais juste qu'on repart court ensemble 3 slides qui reposent le contexte de l'introduction et de l'évolution du projet Gutenberg. Parce que le projet Gutenberg, en fait, c'est un projet en 4 phases. C'est vrai qu'en 2018, on a eu l'introduction de l'éditeur de bloc qui a remplacé l'ancien vieil 100 A&E MCE par le nouvel éditeur. Voilà, donc ça c'était en 2018, ça fait 4 ans. En début d'année, nous avons eu la deuxième phase avec l'introduction du full site editing, donc c'est de ça qu'on va parler aujourd'hui. Suivrons 2 autres phases encore. Nous aurons une phase sur la collaboration, donc le multi-authoring. Donc en fait, ça, ce sera la possibilité pour plusieurs auteurs de contribuer en même temps sur le même document. Voilà. On ne sait pas pour quand c'est pour l'instant, mais en tout cas, ce sera pour la prochaine phase du projet Gutenberg. Et on aurait une autre phase encore à terme, qui est le multiland, parce qu'aujourd'hui on se repose sur des solutions terres pour faire ça. Mais à terme, votre presse aimerait bien qu'on le puisse le gérer nativement dans le cœur de votre presse. Voilà. Donc le projet Gutenberg, on voit qu'en fait c'est un projet qui est quand même assez important pour votre presse. Ce n'est pas juste lié à l'éditeur de bloc, mais ça tourne autour de cet éditeur-là. C'est un projet de transition, c'est un projet de mutation, même je dirais. Et aujourd'hui, on est à peu près à la flèche verticale, vous voyez, on a lancé full site editing. On est plutôt, voilà, début d'année, c'est assez récent. On n'a pas une pénétration marché du full site editing qui est aussi forte que ce qu'on pourrait avoir pour l'éditeur, pour l'écosystème classique. Mais vous voyez où va la tendance, vous voyez où va l'évolution. On va construire autour de Gutenberg. WordPress investit beaucoup sur le projet Gutenberg. Donc il ne faudrait pas rater cette évolution non plus. On ressent bien cet avancé dans la fréquence et la nature des releases de WordPress. Si vous regardez un petit peu là, en 4 ans, on a eu un nouvel éditeur de bloc. On a eu une nouvelle façon de construire des thèmes. Et on a aussi eu une nouvelle façon d'éditer ces thèmes. Voilà, tout ça, ça bouge. Et ce n'est pas la seule chose qui bouge. On a aussi énormément de nouveaux outils. Demgison, React, bloc, thème, template, template parts, bloc pattern, reasonable blocs, custom blocs, bloc variation, style variation. Ça fait beaucoup. Voilà, donc on est sur une vraie évolution. La question qu'on va pouvoir se poser, c'est comment appréhender un tel changement. Comment après, grosso modo, 10 ans de même, esprit de taming, de templateing. Comment appréhender ces nouveaux outils, ces nouvelles façons de procéder. Donc ça, c'est une question qui m'a beaucoup intéressé ces derniers temps. Et je me suis dit que la meilleure façon d'y répondre, c'était de prêter moi-même à l'exercice pour essayer d'en établir et d'en quantifier la roadmap d'apprentissage. Donc la roadmap, là, voici. On va bien sûr repasser sur tous les différentes parties ensemble en détail. On va parler de théories un peu. On va regarder comment déclarer un bloc thème. Comment est-ce que ça se passe pour les templates et les templates parts dans WordPress FSE. On va vous parler de thème.json. On va utiliser des patterns, des reusable blocs. Et on va aussi voir l'aspect code de bloc custom. Et du coup, je remercie mes deux collègues précédents qui vous ont déjà bien débroussé le terrain sur ces aspects-là. Moi, je n'irai pas aussi profondément, mais au moins vous aurez en tête tout ce qu'ils ont expliqué depuis ce matin. Voilà. Donc, un peu de théorie pour commencer. C'est vrai qu'en tant que développeur, on nous dit souvent qu'il faut essayer de réfléchir et de ne pas se jeter un corps perdu dans l'implémentation. Donc là, c'est ce qu'on va faire aussi. Avant de se lancer et d'essayer de faire du FSE, on va déjà essayer de se renseigner et de comprendre ce qu'il en est. Donc, tous les slides de la roadmap sont présentés comme ça. Je vous présente les objectifs et les étapes pour chaque partie. Après, je vous donne deux ou trois ressources et ensuite on fait une conclusion sur la difficulté et ce qu'il en coûte d'apprendre l'étape en question. Donc, à l'étape 1 sur 6, pour apprendre les capacités nouvelles de l'outil, ce qu'on cherche à faire, c'est maîtriser ce qu'on peut faire ou pas faire de base avec Gutenberg, avec le nouvel éditeur de bloc. Donc là, ce que je vous encourage à faire, c'est de ne pas couder et c'est de vous poser les questions, de regarder des tutos, des vidéos de l'équipe, notamment de WordPress qui est en charge de l'éducation pour essayer de comprendre ce qu'on peut faire vraiment de base, essayer de vous approprier le périmètre de ce qu'on peut faire ou pas faire avec l'éditeur natif. Voilà. Donc, on va faire des expériences. On va ajouter des blocs, on va triturer les options, on va essayer de monter des layouts et on va essayer de toucher un peu les limites pour savoir ce qu'on peut faire ou pas faire. Deux ressources que j'ai trouvées moi qui m'ont beaucoup aidé, en tout cas, quand je me suis confronté à cette partie. La première, c'est WordPress.tv, dans lequel vous avez surtout des ressources vidéos, donc des recap à la fois de WorldCamp, à la fois de conf, à la fois de Meetup, à la fois de personnes qui partagent leur expérience. Voilà. Donc la première, WordPress.tv. La deuxième, c'est Learned by WordPress.org, qui est gérée par l'équipe éducation de WordPress. Et eux, ils ont monté une équipe de mentor qui font des Meetups quasiment toutes les semaines sur plein d'aspects, que ce soit des aspects plutôt utilisateurs, comment utiliser Backoffice, des découvertes de nouvelles fonctionnalités, mais aussi des aspects devs avec des O2, des code with me, ce genre de choses pour pouvoir comprendre comment les experts font pour pouvoir essayer de refaire la même chose chez vous. Donc, les écueils qu'on va rencontrer sur cet état-là, c'est qu'il y a beaucoup de nouvelles fonctionnalités natives à appréhender. Vous l'avez vu sur le slide foncé tout à l'heure, il y a plein d'outils, plein de nouvelles façons de procéder. Et pour l'instant, il y a quand même assez peu de ressources communautaires, il faut se le dire, donc c'est pour ça que je vous ai montré deux ressources officielles d'apprentissage, ou à WordPress.tv et l'O2.org, parce qu'on manque encore de ressources de blogs, on manque encore un peu de ressources communautaires sur ça, et la doc, elle évolue, elle fait des programmes qui sont encore un peu difficiles. Je vous conseille d'investir entre 1 à 2 semaines sur cet état-là et la difficulté est de 2 sur 5. Une fois que la théorie vous avez compris et fait l'autour de cette histoire-là, on va s'intéresser après aux notions de taming et de templating. Parce que qu'est-ce qui est un petit rappel, ce qui compose un thème ? Un thème, déjà, il va falloir le déclarer pour qu'il soit valide, pour que WordPress le reconnaisse et qu'on puisse l'activer dans le bac-office. Ensuite, on va pouvoir monter des templates. Et ces templates ont composé généralement du footer et au milieu du contenu. Et en plus derrière, on va mener des attributs de style à cet template-là, donc des couleurs, les polices, plusieurs autres configurations graphiques. Ce qu'on aimerait faire, nous, c'est déclarer un thème, un nouveau, plus un classique, un thème FSE qui va être en capacité d'exploiter toutes les nouvelles ressources, toutes les nouvelles fonctionnalités. Comment faire ça ? Je vous propose de comparer les deux architectures. Comment est-ce qu'on déclaire un thème de ma façon classique et un nouveau ? De façon classique, au minimum de chez minimum, s'il devait y avoir deux fichiers pour que votre thème soit considéré valide, c'est index.php et style.css. Avec ces deux fichiers-là, quand vous allez dans votre bac-office, vous avez un thème qui est reconnu par votre reste et que vous pouvez activer. Voilà. Donc index.php, c'est plus là pour être responsable du rendu, du contenu de ce que vous administrez en bac-office. Et style.css, c'est à la fois bien sûr pour le style, mais aussi, vous savez, pour déclarer les métadonnées, donner le titre de votre thème, lui donner le nom de l'auteur, sa version, etc. Donc avec ces deux fichiers-là, vous déclarer un thème classique. Maintenant, si on regarde l'architecture block-thème, on voit qu'on a un fichier supplémentaire qui s'appelle index.php, pardon, lapsus index.html dans le dossier template. En fait, c'est ça la nouveauté. Ce fichier index.html, vous pouvez, vous permet de ne rien mettre dedans pour l'instant. Et si vous faites ces trois fichiers-là, que vous allez dans votre bac-office, vous aurez la possibilité de reconnaître votre thème, de l'activer. Et si vous le faites, vous aurez une différence fondamentale par rapport au thème classique, c'est que vous n'aurez plus apparence menu et plus apparence customisée, mais à la place, vous aurez le menu éditeur. Et si vous rentrez dans ces liens-là, vous aurez accès à l'éditeur FSE, Full Site Editing. Voilà. Qu'est-ce qu'on peut faire dans cet éditeur ? On peut modifier des éléments de son site, mais on peut aussi modifier ses templates, ses templates parts. On va revenir sur tout ça, bien sûr. Et vous voyez, pour déclarer un thème compatible FSE, je vous ai montré en deux secondes, ce n'est pas très compliqué. Tant investir, si vous voulez approfondir un peu le sujet, une journée, difficulté, très simple, un sur cinq, on a un thème FSE, qui ne fait rien de spécial, bien sûr, mais au moins qui active les nouvelles fonctionnalités du bac-office. Voilà. Déclaration du thème FSE, check. Maintenant, on va regarder comment on va pouvoir appréhender les templates et les templates parts. Donc les templates parts, c'est les morceaux de templates réutilisables. Bien sûr, l'exemple le plus évident, c'est le header, le footer qu'on ne recorde pas à chaque fois et qu'on inclut sur toutes nos pages. Voilà. Donc, l'objectif qu'on cherche à atteindre dans cette phase-là, c'est d'être autonome dans la création de thèmes et de templates. Comment on va faire ça ? On va essayer. On va essayer ensemble. On va comparer les architectures, pareil. Et on va essayer de s'inspirer aussi, je vous encourage, à vous inspirer d'exemples existants. Comme disait Sylvie Sméthain, c'est vrai qu'il y a des choses qui sont intéressantes à aller regarder chez les autres, notamment chez les thèmes 2022. Vous savez des exemples de choses qui marchent dedans à les récupérer. Alors, comment on déclare un template ? De manière classique, j'imagine que les développeurs ont déjà tous vu ça à gauche. C'est un template très simple. On lui donnait une annotation de commentaire pour lui déclarer son nom, pour pouvoir le choisir après dans la sidebar quand on édit une page. On inclut le header, on inclut le footer et au milieu, on avait la fameuse loop WordPress qui nous permet d'afficher le titre et le contenu de notre page ou de nos postes. J'imagine que vous êtes assez familiers avec cette syntaxe. Si vous regardez ici dans l'esprit, c'est le même esprit. Le concept, c'est le même. C'est la syntaxe qui change. Mais vous regardez, vous allez retrouver vos petits. On inclut ici la template part header en haut. On inclut la template part footer en bas. Ça, c'est l'équivalent de cette ligne et de cette ligne. Ok ? Ensuite, vous avez la boucle ici, WP query loop que vous retrouvez ici. Et vous avez l'affichage du titre et du contenu. Ce qui est équivalent à de title et de content. Donc dans l'esprit, quand vous êtes un développeur classique, qu'il faut passer à FSE, on passe sur un fichier html, c'est un peu perturbant au début, et on utilise des commentaires maintenant au lieu de fonction. Voilà, parce que c'est pas un langage dynamique. Mais dans l'esprit, on s'y retrouve. Donc ce qui concerne les templates part, c'est un peu comme les templates. Dans l'esprit, on s'y retrouve. On reconnaît nos petits et on change de syntaxe. Donc vous voyez, sur un thème classique 2020 qu'on a un dossier de template part avec nos morceaux de templates à l'intérieur qui sont en php. Dans un thème FSEur, enfin un blog thème, on a un dossier part maintenant, bon c'est plus template part, mais c'est part, j'imagine que vous y retrouverez. Et on a nos morceaux de templates à l'intérieur en html avec cette nouvelle syntaxe. Donc comment est-ce qu'on peut faire pour apprendre cette nouvelle syntaxe ? Ce slide est un peu compliqué mais après, de ce que j'ai pu voir, pour l'instant, la nouvelle syntaxe, on n'est pas obligé de l'apprendre par coeur dans sa tête. On peut avoir un workflow alternatif en se reposant sur l'éditeur FSEur que vous avez vu juste avant. Donc comment on va faire ça ? Je vous le dis en très rapide et après je vous montre. On va dans l'éditeur FSEur. On passe dans template. On clique sur ajouter un template. On monte notre template avec l'éditeur de blocs. C'est ça le full site editing en fait. C'est qu'on peut prendre l'éditeur de blocs et on peut s'en servir pour monter des éléments qui ne sont plus seulement cantonés au contenu du poste mais aussi au header, au footer, au menu, etc. Voilà. Donc on va faire ça. Éditeur FSEur, template, ajouter un template. On monte la structure. On passe en mode code. On copie ce que l'éditeur a généré pour nous et on le sort garde dans le fichier HTML que je vous ai montré juste avant. Ça donne ça. On va dans l'éditeur FSEur. On clique sur ajouter un nouveau template et on choisit parmi la liste. Par exemple, page pour faire simple. On monte notre template. On passe en mode code. On récupère ce qu'il y a dedans et on le sauvegarde dans le fichier template. Pareil pour l'étrône template part, c'est exactement la même chose. Donc là, si vous voulez créer un header, créer un footer avant de fosier peut-être à la main en PHP, vous pouvez le faire avec l'éditeur si vous voulez. C'est à l'intérêt. Pareil, add new. Est-ce que c'est un header ou un footer ou quelque chose de plus générique? Je manque ma structure. Je récupère son mode code, je récupère ce qu'il y a dedans et je sauvegarde ça dans mon dossier, dans mon fichier de template part. Voilà, donc c'est un peu différent. Et c'est une nouvelle façon de travailler, c'est aussi une nouvelle syntaxe. La compréhension, vous avez vu, elle est assez rapide parce que les concepts sont quand même équivalents par rapport à ce que vous avez l'habitude de voir. Donc en quelques heures on comprend l'histoire. Par contre, c'est pas en quelques heures qu'on est autonome. Donc je pense que pour encoder un thème ou deux avant de se sentir autonome sur cette nouvelle syntaxe c'est cette nouvelle façon de travailler. Après, pour ce qui est de la maîtrise du craft et de son art, ça dépend un peu plus de chacun, donc c'est libre à chacun d'investir le temps qu'il souhaite pour maîtriser cette partie-là. On est sur une difficulté de trois et demi sur cinq. Ok. Donc les templates et les templates part, on a vu. Maintenant, comment est-ce qu'on va pouvoir configurer l'esthétique de notre site? Avant, c'est vrai qu'on déclarait des polices, on déclarait des couleurs pendant des containers, tout ça dans un fichier de style CSS. Et bien on a un nouvel outil dans Full Site Editing qui s'appelle Thème.json. Il y avait une question sur ça d'ailleurs tout à l'heure sur une autre conférence. Et c'est un fichier qui a beaucoup de pouvoir. C'est un fichier qui est assez puissant et qu'il va falloir qu'on maîtrise aussi. Donc il va falloir qu'on passe du temps sur ce fichier-là pour le comprendre, pour comprendre comment on peut exploiter ce nouveau moteur de configuration. Et comment on va pouvoir faire ça? Il va falloir apprendre ce qu'on a vu sous la slide d'après. Et on va essayer de gérer des couleurs et on va essayer de gérer des palettes et on va essayer de gérer des fontes et on va essayer de comprendre comment WordPress à partir de ce fichier-là génère des variables CSS Dynamique. Voilà, donc on va être confronté à tout ça avec Thème.json. C'est vrai que le contraste n'est pas fou. Je ne sais pas si vous voyez bien au fond de la salle. Mais je n'ai pas mis grand chose pour l'instant. Après ce qui est intéressant dans ce fichier depuis un exemple même celui-là si vous voulez. Parce que ce schéma-là c'est ce qui va définir la structure de validité de votre fichier-json. Ça veut dire que grâce à ce fichier-là votre IDE il va pouvoir vous corriger si vous faites des bêtises il va pouvoir vous activer de l'autocompression parce qu'on ne connaît pas tout cela comme ça si on n'a jamais bossé avec qu'il faut une entrée settings color palette dedans. Si vous ne le savez pas de tête c'est le schéma qui va vous aider sur ça. Vraiment n'oubliez pas de mettre le schéma dans les settings on va pouvoir comme vous avez vu gérer des couleurs et dans les couleurs on va pouvoir générer des palettes de couleurs donc vous voyez en haut on peut définir une couleur en hexadecimal lui donner un slug pour la reconnaître et lui donner un ombre qui sera ensuite affiché dans l'éditeur. Si vous mettez ces lignes-là donc jusqu'à la ligne 8 vous allez activer dans votre éditeur FSC pour votre administrateur de contenu pour votre master vous allez lui débloquer lui activer des fonctionnalités qui sont basées sur ce que vous en tant que développeur vous avez spécifié donc là moi j'ai déclaré 2 couleurs après je pense que j'en avais déclaré 3 et que j'ai enlevé une ligne et ça génère bien moi mes 3 couleurs ici dans l'éditeur pour que mon administrateur de contenu puisse les utiliser pour les police c'est pareil on va venir déclarer des fonds de famille de police que moi en tant que intégrateur ou développeur j'ai envie de mettre à disposition même après dans les styles dans l'éditeur FSC pour pouvoir retrouver et sélectionner donc si il veut prendre un texte et le mettre dans cette police là il pourra le faire parce que moi je lui ai donné l'autorisation de le faire et ce qui est intéressant avec tout ça c'est que quand on regarde les slugs de mes couleurs donc j'ai un slug light et un slug dark il faut savoir que WordPress me génère des variables CSS dynamiquement dans l'esprit ça peut être un générateur de design tokens appliquer un design system qui est abstrait par WordPress vous le voyez pas forcément mais il faut savoir qu'il est là qu'il y a un moteur comme ça et que c'est puissant à utiliser et ensuite grâce à ces variables dynamiques par exemple je peux déclarer des styles globaux à tout mon site pour lui dire bah moi dans les couleurs j'ai envie que le fond de mon site le background color de mon site il soit basé sur ma couleur light donc là vous voyez WP preset color light c'est le slug de ma couleur light que j'ai déclaré là-haut pareil pour ma police j'ai envie que sur tout mon site ma police elle soit en couleur foncée donc je lui dis que dans style color text j'ai envie que mon style il soit basé sur la variable CSS généré dynamiquement par WordPress WP preset color dark ok et voilà pareil pour les typos j'ai envie que sur mon site ma font de famille elle soit basée sur la police que j'ai déclaré ici avec un slug ITC avant garde donc je peux lui dire typographie fond de famille WP preset fond de famille ITC avant garde et mon site il prend par défaut la police pardon que j'ai déclaré voilà donc theme json c'est un fichier puissant c'est un fichier nouveau mais qui va donner beaucoup de capacité à la fois développeur et à la fois administrateur donc ça pareil c'est tout nouveau ça il n'y avait pas de pendant dans les thèmes classiques c'est une nouvelle syntaxe il y a un gros schéma à prendre parce que ça m'a pris un moment à écrire parce qu'il faut savoir qu'il y a des entrées comme ça il faut savoir un peu comment écrire tout ça donc ça ça prend du temps à acquérir et la doc n'est pas toujours évidente parce que parfois ils vous disent que vous pouvez utiliser typographie fond de famille fond de face mais ils ne vous disent pas comment forcément ou pourquoi donc des fois il n'y a pas de commentaires pour l'instant donc voilà il faut bien une semaine pour rentrer dans ce fichier là et ce n'est pas forcément très évident donc c'est une difficulté donc pour la config on est bon ensuite on va passer au contenu je l'ai fait juste le temps pour le contenu il y a deux approches il y a l'approche l'ocode et l'approche code d'accord pour l'ocode on va parler de deux outils qui sont les patterns et les reusable blocks l'objectif c'est de savoir monter des briques en assemblant des blocs qui sont existants donc là on n'est pas dans l'esprit de nous créer de nouveaux blocks comme on a pu voir tout à l'heure avec Vincent notamment on est plutôt dans deux outils qui nous permettent d'assembler des blocs existants pour les mettre à disposition après de nos administrateurs voilà donc comment on va faire ça on va essayer les deux et je vais vous montrer un peu ce qu'il en dit donc patterns à gauche reusable blocks à droite pour les patterns ce qu'on va essayer de faire et fumer moi bien sur la nuance des deux parce que c'est important de le bien comprendre pour les patterns on va essayer de pré-monter une structure de template faite avec des blocs existants je vais monter une structure je vais la sauvegarder dans un fichier et je vais la mettre à disposition de mon utilisateur donc on est plutôt sur une utilisation faite par un développeur en amont il va préparer quelque chose avant il va la mettre à disposition d'un administrateur de contenu pour les reusable blocks la différence c'est qu'on est plutôt après pourquoi on est plutôt après c'est parce qu'on va aller dans l'éditeur dans l'éditeur on va construire un template on va construire une structure d'affichage de contenu et on va cliquer sur sauvegarder pour plus tard sauvegarder dans les blocs réutilisables donc là on est plutôt sur la valle vous voyez la différence patterns un développeur pré-partout en amont reusable blocks on a monté ça dans l'éditeur voilà les patterns ce qui est intéressant pour nous développeurs c'est que c'est un des nouveaux outils un des nouveaux éléments qui est possible de créer un PHP alors que jusqu'à présent vous avez vu template template part c'était surtout du HTML avec les patterns on va pouvoir les créer en PHP et on va pouvoir ensuite les déclarer soit par fonction soit par commentaire avec les métadonnées soit par thème.json pour les reusable blocks vous avez bien compris que c'était créé via l'éditeur et maintenant il faut qu'on parle d'un élément important qui est la synchronisation mais je pense que je vais vous montrer le slide d'après parce que ce sera plus facile à comprendre donc on a dit les patterns un développeur prépare un fichier avant une structure donc là j'ai mis un paragraph tout bête avec un copyright mais on voit dans l'exemple que j'ai mis ici car rien à voir avec le code que le développeur avait imaginé une structure où on pouvait faire deux sections avec une poire et un peu de contenu et un peu de fond ça il l'avait préparé avant ensuite quand un administrateur de contenu clique sur le bouton ajouter ça lui propose d'ajouter un bloc des patterns ou des blocs réutilisables la plupart du temps par défaut on est plutôt sur l'onglet bloc donc là si on passe sur l'onglet pattern on va avoir cette pattern à disposition que l'administrateur de contenu va pouvoir prendre et insérer dans son contenu et ça ça a été préparé avant reusable blocks j'étais dans mon éditeur j'ai fait ma vie j'ai cliqué sur des points verticaux que vous avez dans la toule bas ici et je l'ai ajouté aux reusable blocks via cette entrée là en résultat quand j'appuie sur mon bouton plus pour ajouter du contenu et que je vais dans le troisième onglet je retrouve ce que j'ai fait donc je peux passer par là et si je clique là ça va m'insérer ça dans mon contenu d'accord maintenant en termes de synchronisation et c'est là la nuance fondamentale et importante à comprendre en tout cas moi depuis que j'ai compris ça ça va beaucoup mieux pour les paternes il n'y a aucune synchronisation qu'est-ce que je veux dire par là j'ai fait ce fichier de code ça me met à disposition ça je peux insérer ça dans mon contenu j'ai créé une page je l'ai mis dans une page j'ai créé une deuxième page je l'ai repris je l'ai mis dans la deuxième page ok je modifie ce fichier là ça n'a aucun impact zéro sur le rendu que j'ai dans ma page 1 ou dans ma page 2 aucune synchronisation ni de contenu ni de structure ensuite dans ma page 1 j'ai modifié mon image j'ai mis une pomme à la place ça n'a aucun effet ni sur mon fichier de code original ni sur ce que j'ai pu insérer dans ma page 2 totalement désynchronisé voilà pour les reusable blocks c'est tout l'inverse 100% synchronisé donc j'ai créé ma structure ici elle est disponible je l'insère dans ma page 1 je l'insère dans ma page 2 je modifie la structure dans ma page 1 je vais dans ma page 2 la structure a été modifiée aussi je modifie le contenu sur ma page 2 je reviens sur ma page 1 le contenu a été modifié aussi 100% synchronisé donc ça c'est important de bien comprendre la différence de synchronisation entre les deux outils parce que ça influe sur la façon dont vous allez pouvoir ou l'utiliser ou le mettre à disposition de vos utilisateurs voilà donc les écrits qu'on va rencontrer sur cette partie c'est comment créer comment déclarer ces nouveaux éléments quelle est la différence de synchronisation donc là on l'a vu ensemble vous avez vu et quand est-ce qu'il faut utiliser l'un ou l'autre pour investir sur cette partie plutôt une semaine et plutôt sur les patterns parce que vous avez eu finalement les reusable blocks on les monte dans l'éditeur on te fait clic droit on les sauvegarde pour plus tard donc bon il n'y a pas vraiment une grosse difficulté sur ça c'est plutôt sur les patterns comment les déclarer comment utiliser les différences de syntaxe tout ça voilà mais la difficulté sur la déclaration des blocs patterns reste raisonnable on est plutôt sur du 2 sur 5 donc là jusqu'à présent on a discuté de comment on pouvait monter, modifier des éléments sans coder vous avez, vous en avez très peu vu de ligne de code et les lignes de code qu'on a vu côté FSN c'est même pas nous qui les avons écrits c'est l'éditeur dans cette partie-là et fort des 2 présentations que vous avez vues ce matin on va voir ce qui se passe avec plutôt quand la faculté de créer de nouvelles briques à pouvoir assembler dans l'éditeur donc notre objectif clairement c'est comment faire comment savoir créer de nouvelles briques comment on va faire on va s'intéresser aux tout-lignes donc à l'OTILA à l'OTIH Vincent vous a présenté NPX WordPress créé de blocs ce matin donc on va regarder ça et la différence entre les blocs statiques et les blocs dynamiques c'est ça qui va falloir qu'on appréhende donc différence côte à côte blocs statiques, blocs dynamiques pour les blocs statiques on utilise, vous avez vu NPX WordPress créé de blocs et vous avez vu ce matin on lui donne un nom pour les blocs dynamiques c'est la même chose la seule différence ici et vous ne trompez pas là c'est bien deux tirés c'est juste l'éditeur qui l'a mergé c'est deux tirés variant dynamique voilà donc ça c'est la différence de création si on fait ça on obtient ça qu'est-ce qu'on a là dedans ce qui nous intéresse comme vous avez bien compris ce matin c'est ce qu'il y a dans le dossier source pas dans le dossier build notre module on s'en occupe tout ça c'est géré on s'en occupe c'est ce qu'il y a dans le dossier source et dans le dossier source vous retrouvez comme à présenter ce matin le fichier index le fichier edit le fichier save pour les blocs statiques si on va de l'autre côté on a bien le fichier edit qui est responsable de l'expérience d'édition côté éditeur que vous allez mettre à disposition de vos utilisateurs on a index.php bien sûr mais on n'a pas save on n'a pas save.js à la place on a template.php donc la différence entre les deux c'est que quand vous êtes sur un bloc statique que vous éditez votre bloc ça va passer quand vous allez publier ou sauvegarder votre contenu c'est le fichier save.js qui est responsable de calculer le rendu qui y aura sur le front il le calcule de manière statique il le sauvegarde en base de données et il le rerans il le rerans sur le front donc ça c'est la partie statique et on appelle ça statique parce que save.js calcule une chaîne de caractère statique qui sauvegarde en base de données qui après est rendue tel quel pour les blocs dynamiques il n'y a pas de save il n'y a pas de save pourquoi ? parce qu'en fait l'éditeur il va sauvegarder des attributs directement en tant que meta dans le code HTML qui vont être ensuite passés à un callback php et cette fonction php va pouvoir récupérer ses attributs donc vous avez bien compris la notion d'attribut ce matin avec Vincent il va récupérer cet attribut il va faire le rendu dynamiquement en php fort de ces différences voilà ce qu'il faut vraiment comprendre sur les statiques versus dynamiques méthode édite, côté statique pour l'expérience dans l'éditeur pareil pour les blocs dynamiques méthode édite pour le rendre l'expérience d'édition dans l'éditeur une méthode save pour générer le rendu côté statique pas de méthode save côté dynamique le rendu et sauvegarder côté statique il est généré dynamiquement en php côté dynamique donc tout ça on a vu ensemble maintenant en termes de synchronisation encore parce que la synchronisation c'est vraiment des concepts qui nous intéressent auquel il faut faire attention si vous modifiez un bloc statique il faut obligatoirement recliquer sur le bouton sauvegarder de votre page pour que le bloc soit recalculé statiquement et re sauvegarder en base de données pour les blocs dynamiques c'est pas le cas c'est à dire que si vous modifiez le callback php partout dans toutes les pages où vous avez utilisé le bloc dynamique la modification sera effective tout de suite dès que vous réfléchissez la page si vous modifiez votre bloc statique que vous l'avez inséré sur 10 pages il faut passer sur les 10 pages pour appuyer sur save sur les 10 pages ça c'est un peu contraignant légèrement n'est-ce pas mais voilà il y a des avantages des secondes maintenant mais sur dans les deux types là pour la synchronisation la synchronisation c'est important et c'est différent entre les deux par contre un avantage du côté statique c'est que la méthode edit qui est responsable de vous faire l'édition côté éditeur et de vous faire le rendu aussi de cette édition la méthode save qui génère le rendu peuvent être mutualisées parce qu'on est un gs des deux côtés on peut faire du react on peut mutualiser un composant qui va servir des deux côtés ça c'est intéressant c'est quelque chose qu'on ne peut pas faire ici parce qu'on a du gs d'un côté du php de l'autre donc l'expérience d'édition il est en JavaScript le rendu front il est en php ça peut poser problème si vous cherchez à faire une expérience d'édition le plus whizzy week possible pour vos éditeurs de contenu je trouve moi-même pas trouver la solution à ce problème d'ailleurs donc si certains ont la solution dans la salle ça m'intéresse quand on en discute donc sur cette partie-là beaucoup décaillent parce que c'est la partie la plus difficile il va falloir comprendre comment on crée des blocs il va falloir qu'on comprenne les différences entre les blocs qu'on maîtrise l'architecture des blocs le tooling des blocs il faut qu'on comprenne les différences de mécanique d'édition de sauvegarde pour les deux côtés et l'assurer sur le gâteau c'est qu'il va falloir réact si on vient de l'écosystème classique il va falloir se taper du réact c'est sûr donc le temps à investir entre 1 et 3 semaines on est bien d'accord qu'on n'oublie pas la fin de la phrase c'est hors réact parce qu'à réact c'est un autre sujet un autre courbat d'apprentissage 2 ans voilà, par exemple 2 ans 2 ans à droite qui dit mieux et c'est bien sûr c'est l'étape la plus dur on est sur 5 sur 5 clairement la même chose la seule différence c'est que si vous commencez par les blocs statiques on va remettre 2 semaines pas en plus pour bien comprendre les notions et les subtilités du bloc dynamique mais on est toujours sur une difficulté de 5 sur 5 voilà je crois qu'on a tout déclaration du thème template, template part couleur contenu donc la roadmap présumée est agrémentée des différentes choses qu'on a pu voir au fur et à mesure des étapes je vous les remis en entier je vous les remis pour chaque la difficulté et le temps qu'il faut investir pour 6 mètres pour passer un développeur classique à un développeur FSE voilà m'a écouté j'ai fait le tour je peux vous laisser celle-là si vous voulez et je me rends disponible pour vos questions soit maintenant soit plus tard lors de l'événement si on se croise merci beaucoup merci Jérémy on a un peu de temps pour des questions est-ce qu'il y a des questions dans la salle ? oui priori c'était très clair merci beaucoup très bien merci beaucoup est-ce qu'il y a de liens pour les slides ? moi j'ai pas je les ai un pdf je les ai pas mis en ligne pour l'instant si tu veux je peux les envoyer directement mais aussi bien sûr le World Camp mettra à disposition les slides et je crois aussi qu'ils les replays seront disponibles sur World Press TV dans la section World Camp bon peut-être pas tout de suite peut-être dans un mois ou quoi mais sinon je te les envoie avec plaisir exactement mon speech c'est exactement ça merci bonjour et merci j'ai une petite question comment tu t'y prendrais toi pour ajouter des logiques conditionnelles dans des paternes par exemple afficher plusieurs blocs seulement pour des utilisateurs identifiés les paternes dans la chance c'est le seul élément qui peut inclure du PHP voilà donc tu pourras faire de la logique PHP dedans ça c'est cool parce que je me suis retrouvé avec un un casque figure tout bête c'est que quand j'ai commencé et que je voulais faire le footer je vois le copyright en bas avec la date dynamique en HTML je suis dit bah non je vais pas repasser tous les ans pour changer la date et c'est là que j'ai commencé à comprendre qu'effectivement on pouvait gérer du dynamique dedans voilà on a encore quelques minutes donc n'hésitez pas s'il y a d'autres questions oui j'en ai une je sais pas si elle est un peu stupide ou pas on va voir quand à un moment vous parlez dans les templates parce qu'il faut copier coller le code que vous avez pour après le remettre ça s'enregistre pas en fait tout seul si vous le mettez directement c'est une question qui est très intéressante ah ça va alors c'est vrai qu'il est pas bête du tout et je suis sûr qu'on enfin moi je me suis fait avoir plein de fois je vais remonter sur ça voilà toute la subtilité elle est dans le rond bleu que tu vois ici donc ça c'est un concept super intéressant du full site editing ça veut dire que moi en tant que développeur je vais préparer un template ce template toi en tant qu'administratise de contenu si tu veux si il te va pas ou si tu as envie de le changer tu pourras le modifier tu pourras le modifier directement dans l'éditeur donc tu vas faire ça tu vas cliquer sur le bouton save tout en haut là bas à partir du moment où toi tu as fait des modifs sur mon template à moi tes modifs à toi elles prennent le dessus sur ce que moi j'avais prévu et c'est matérialisé par le petit point bleu voilà donc si toi tu fais des choses ça sera sauvegarde direct et quand tu vas rafraîchir le front tu verras tes modifications par contre moi en tant qu'éditeur de thème c'est pas forcément ce qui m'intéresse parce que si je fais mon template ou alors si je le fais pas si tu veux en fait tu pourrais créer un site de zéro en partant d'un fichier vide tu peux tout faire avec l'éditeur full site editing tu peux le créer dans toute pièce ton template et le sauvegarder et ça va marcher mais ça va marcher que pour toi ou que pour ta machine tu comprends parce que c'est sauvegarder en base de données tes modifications donc ça va être sauvegarder sur la base de données de l'instance en cours donc soit ta machine de développement soit une pré-prod soit une prod sauf que nous enfin quand on édite des thèmes on a envie que de construire les thèmes et que toi quand tu les active tu es tout ce qu'on avait prévu ce qu'on avait prévu peu importe l'environnement d'ailleurs donc ça la notion et la différence entre les deux c'est que ce travail là à faire c'est un travail de développeur qui édite des thèmes voilà donc moi je dois faire ce travail pour que toi quand t'actives ce thème tu es en face de toi tout ce que moi j'avais prévu voilà si ça te plaît pas tu peux refaire et oubliez pas le petit rond bleu et le petit rond bleu surtout quand on est développeur au début on l'oublie tout le temps et on fait des modifs et on sauvegarde et quand on a et c'est super sur notre machine et puis après on installe le thème sur la machine en pré-prod et en fait ça n'a rien à voir donc c'est parce qu'on a oublié de récupérer les changements après je vous ai mis un petit truc ici qui est le plugin create block theme qui lui a un bouton sur lequel vous pouvez sauvegarder vous pouvez cliquer qui va récupérer tous les ronds bleus et tous les remettre dans vos fichiers de template voilà donc ça c'est c'est voilà ça fait plaisir on a une question au front merci t'as super bien répondu je voulais juste rajouter une précision en fait c'est qu'on peut exporter aussi tout le thème il y a un bouton je ne sais plus il y a les trois petits points qui sont sur le côté en haut il y a quelques parts cachés dans les trois petits points là et ça ça va créer l'archive à côté que vous pourrez récupérer dans votre téléchargement et que vous pourrez bien sûr recopier et recoller dans votre thème de base mais l'archive elle sera à côté voilà alors que create block theme quand vous cliquez il sauvegarde en lieu et place de vos templates alors on a une question juste devant du coup comme ça s'enregistre en base est-ce que t'as fait des tests de perf non j'ai pas fait de tests de perf parce qu'un gros thème en base ça implique beaucoup de requêtes alors full site editing c'est pour redonner le pouvoir aux administrateurs de contenu moi en tant que développeur j'ai pas vraiment d'intérêt à ce que les gens sauvegardent des choses en basie ça me fait un peu permanent d'ailleurs pour être honnête mais donc logiquement dans l'esprit le vrai moi je fais un template je le mets à disposition l'utilisateur s'il a envie il modifie les trucs sporadiques voilà si il commence à tout changer c'est qu'on s'est pas compris lui et moi sur ce qu'il attendait voilà c'est un autre problème après voilà quand tu récupères le plugin les modifications faits par le contributeur tu le réintègres dans ton code ça c'est un choix mais oui ça peut être ça la plupart du temps ce contributeur en vrai c'est le développeur du thème donc quand c'est ce cas là oui après quand tout est... voilà ça dépend parce que la notion elle est encore une fois elle est elle est là dedans dans ce petit point bleu est-ce qu'on a envie d'avoir le point bleu est-ce qu'on a envie de laisser une liberté à notre administrateur de contenu ou pas et ou est-ce qu'on est d'accord que ce que lui il a fait c'est mieux que ce que moi j'avais prévu à la base auquel cas je vais le récupérer le remettre par défaut ou est-ce que le... parce que moi je viens d'une agence en fait donc on est plutôt dans une notion d'édition pour répondre à un web design donné Full Site Editing je trouve qu'il a beaucoup de potentiel surtout pour les éditeurs de thèmes génériques qui proposent leurs thèmes voilà payants ou gratuits à la communauté et là ça donne beaucoup de pouvoir à la personne qui a récupéré le thème à partir de ce qu'avait fait le développeur avec le développeur avec qui tu ne seras même pas en contact d'ailleurs de pouvoir construire pas dessus voilà c'est surtout ça l'intérêt je trouve et deuxième partie de question du coup c'est en admettant que t'es pas inclus les modifications du webmaster du webmaster donc si tu déployais ton code t'écrase les modifs ou vu que les modifs sont toujours en base de données ça peut annuler tes dernières modifs enfin annuler ou pas prendre en compte en termes de priorité et de hiavarchie ce qu'a fait l'utilisateur sera toujours plus fort que ce que toi t'as fait dans le template donc oui donc si tu ne répercutes pas les modifs ni dans ton code ni en base de données en migration par exemple sur un environnement staging t'auras ton code à toi mais pas les modifs de l'utilisateur et si lui il fait de motifs ce sera plus fort que ton code de toi donc c'est obligatoire d'en récupérer les modifs enfin le point bleu en tout cas moi je ne l'envisage pas autrement dans un contexte agence annonceur quoi peut-être une dernière question pour Coucleur elle est courage il faut que tu passes au milieu là bonjour déjà merci beaucoup pour la présentation moi j'ai commencé à travailler avec du FSE mais avec un thème déjà existant j'ai pris le thème 2022 et puis j'ai regardé un peu comment ça fonctionnait tout ce que je pouvais faire avec l'éditeur et ensuite je suis allé faire un thème Json dans un thème enfant pour modifier ce que j'arrivais pas modifier sur l'éditeur et j'ai eu beaucoup de mal des fois à trouver dans ce thème point Json auquel je ne suis pas du tout habituée comment cibler ce que je voulais cibler pour appliquer un style dessus il y en a eu un notamment qui m'a pris un temps immémorial j'ai fini par trouver un ticket dans le github qui répond à la question est-ce qu'il y a un endroit où on peut retrouver en fait l'ensemble des possibilités de ciblage entre guillemets la manière de cibler chaque élément pour pouvoir appliquer le style qu'on veut dessus quelque chose que j'ai pas trouvé du coup oui alors vous avez vu dans les slides du début où je présentais les quatre phases du projet Gutenberg Fousat Editing ça a été lancé en début d'année c'est très récent ça s'en ressent en plein de choses dans l'état de la documentation ça s'en ressent dans les ressources communautaires ça s'en ressent dans le matériel éducatif qu'on a de notre disposition donc si vous vous y mettez je vous encourage à vous y mettre bien sûr sinon vous allez avoir beaucoup de retard à force mais vous allez être confrontés à ça et on est tous dans le même bateau de parfois c'est un peu la galère clairement mon approche par rapport à ça que ce soit un point d'histoire ou autre chose c'est de commencer par la documentation officielle parce que malgré tout même si on peut la critiquer même si on se dit qu'elle n'est pas au niveau c'est quand même par là que les contributeurs commencent donc s'il y a un début de réponse au moins c'est par là donc sur Theme.json j'ai vu qu'il y avait au moins trois pages de documentation différentes qui essayent d'expliquer la structure du fichier voilà donc il y a quand même beaucoup de réponses dedans ensuite le deuxième élément qui m'en met beaucoup c'est le schéma la fameuse deuxième ligne qui avait dans Theme.json ça c'est sûr qu'il faut l'avoir parce que si vous avez des idéaux vous aurez les auto-complexions et tout donc ça ça aide parce que quand aussi vous connaissez le schéma grâce au schéma vous aurez plus de facilité à vous lancer à essayer des trucs ça va vous donner les premiers chemins de propriété et après pour les valeurs on va plutôt aller dans la documentation voilà même avec ça ça évitera pas la galère de certaines situations c'est sûr merci beaucoup merci beaucoup Jérémy pour cette conférence et toutes ces réponses merci beaucoup