Gutenberg: L'impact économique de la chronologie du déploiement de Gutenberg

Super article Bridget, merci d'avoir écrit ceci. Cela fait écho à mes inquiétudes.

J'avais l'habitude de travailler pour une entreprise qui, au moment où je suis parti, avait plus de 400 sites WordPress avec des thèmes personnalisés (construits avec un framework interne) et était dans un processus de plusieurs années de migration d'environ 200 autres à partir d'un ancien CMS dans en plus des nouvelles constructions. Alors que des entreprises comme celle-ci surveillent de près Gutenberg et se préparent, j'imagine qu'une bonne partie du temps des développeurs sera consacré à l'installation de quelque chose pour le désactiver, sans essayer de faire fonctionner plus de 400 sites avec Gutenberg.

Je m'occupe moi-même de 30 sites et c'est ce que je vais faire, puis je regarderai chaque site à une date ultérieure et je verrai lesquels peuvent être facilement mis à jour, puis j'essaierai de trouver quoi faire avec le reste.

En fonction de la complexité des sites, les développeurs ne peuvent tout simplement pas se permettre de passer beaucoup de temps là-dessus pour les sites existants, car nous ne pouvons pas les facturer à moins qu'un client ne demande spécifiquement que leur thème soit mis à niveau pour s'adapter à Gutenberg. Nous avons construit nos structures de tarification de maintenance autour de la rétrocompatibilité qui a toujours été une force de WordPress, alors que cela me rappelle les longues migrations de Drupal 6 à 7 sur lesquelles j'ai vu des collègues travailler dans un rôle précédent - la différence étant que c'est ainsi que Drupal a toujours été les contrats et les structures de prix reflétaient donc cela.

J'ai une clause dans mes contrats selon laquelle si un site cesse d'être compatible avec la dernière version de WordPress ou un plugin, il continuera à fonctionner sur la dernière version compatible jusqu'à ce qu'une solution soit trouvée. Je n'ai jamais pensé que j'aurais besoin d'utiliser cette clause pour WordPress lui-même.

Sur une autre note, il y a des utilisateurs qui ont bricolé leur propre site Web en utilisant des thèmes gratuits ou commerciaux basés sur des métaboxes et des codes courts dont les sites se briseront soudainement à un moment donné si Gutenberg n'est pas clairement facultatif. Ce sera sûrement terrible pour la rétention.

J'imagine qu'une bonne partie du temps des développeurs sera consacré à l'installation de quelque chose pour le désactiver

Exactement mes pensées.

J'ai jeté un œil au plugin Classic Editor, avec lequel l'utilisateur doit encore cocher une case pour supprimer complètement Gutenberg. Je le ferais donc soit en le forçant et en l'installant sur les sites de mes clients, soit en définissant simplement la version sur 499.x juste avant la version 5.0.

Et puis je peux à mon rythme migrer mes clients vers Grav, Kirby ou tout autre chose qui me plait, car nous savons tous que la plupart des clients ne se soucient vraiment pas du CMS que leurs sites utilisent !

@doubleedesign C'est une bonne chose que vous ayez cette clause. Je commencerais à éduquer votre clientèle le plus tôt possible afin que vous puissiez les habituer à l'idée.

@senlin Piet,

Êtes-vous en train de dire que vous pouvez quitter WordPress ?

@gidgey Bridget,

Je regarde sérieusement d'autres CMS et j'ai déjà créé quelques sites avec Grav CMS.

Donc, oui, vous pouvez en effet dire qu'il y a plus de 50% de chances que je laisse tomber WP lorsque Gutenberg tombe dans WP 5.0.

Et autre chose à considérer :

Si vous lancez maintenant un projet de taille moyenne que vous construirez certainement avec ACF si vous deviez choisir WP, choisiriez-vous alors WP ?

Je sais que je ne le ferais pas. Je préfère avoir la courbe d'apprentissage, que de dire au client en 4 mois que le site que j'ai développé ne peut plus être édité ou mis à jour.

C'est ce dont j'ai peur - à grande échelle.

J'apprécie votre honnêteté et ne vous blâme pas du tout. C'est une commercialisation
problème à coup sûr.

Le lundi 11 décembre 2017 à 14h41, Piet Bos [email protected] a écrit :

@gidgey https://github.com/gidgey Bridget,

Je regarde sérieusement d'autres CMS et j'ai déjà mis en place un
quelques sites avec Grav CMS.

Alors, oui, on peut effectivement dire qu'il y a plus de 50 % de chance que je
laissera tomber WP lorsque Gutenberg tombera dans WP 5.0.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/WordPress/gutenberg/issues/3926#issuecomment-350882640 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AV3JZs__wiuV2FslRNQMRkxvCoRKWnEJks5s_a-kgaJpZM4Q93ul
.

--
Cellulaire 949 370 4059
www.bridgetwillard.com

C'est précisément ce dont j'ai parlé à mes amis et clients.

Soupir. Merci pour votre retour Piet.

Le lundi 11 décembre 2017 à 15h01, Piet Bos [email protected] a écrit :

Et autre chose à considérer :

Si vous débarquez maintenant sur un projet de taille moyenne que vous allez certainement
construit avec ACF si vous deviez choisir WP, choisiriez-vous alors réellement WP ?

Je sais que je ne le ferais pas. Je préfère avoir la courbe d'apprentissage, que de dire au
client en 4 mois que le site que j'ai développé ne peut plus être édité ou
ne peut plus être mis à jour.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/WordPress/gutenberg/issues/3926#issuecomment-350887165 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AV3JZrxdz6HgF-9vGrhvZPC5Bi7prd2Nks5s_bQ7gaJpZM4Q93ul
.

--
Cellulaire 949 370 4059
www.bridgetwillard.com

Si vous lancez maintenant un projet de taille moyenne que vous construirez certainement avec ACF si vous deviez choisir WP, choisiriez-vous alors réellement WP ?

Un peu d'histoire : j'ai commencé ma carrière en tant que développeur Drupal junior et j'ai appris WP en parallèle pour mes propres clients. Mon prochain travail était 100% WordPress, donc même si je voulais rester dans les deux écosystèmes, bref, en réalité, il était plus logique de rester principalement avec WP.

La première chose qui m'a attiré vers ACF était essentiellement qu'il apportait quelque chose que j'aimais à propos de Drupal - la possibilité de spécifier facilement des champs pour les types de contenu dans le backend - dans WP. Il y a tellement d'utilisations pour cela. Il est facile pour les clients de remplir un formulaire avec leur contenu sans avoir à se soucier du formatage et de la mise en page, puis je contrôle l'affichage avec le modèle. C'est le fondement de la façon dont je crée des sites.

Donc si je ne peux plus construire comme ça et que Gutenberg ne fonctionne pas pour mes clients (je peux déjà penser à certains qui détesteraient ça parce qu'ils ne veulent pas penser au formatage ou à la mise en page, c'est mon travail) alors non, Je ne choisirais pas WP dans certains cas. Je retournerais probablement à Drupal. Pas pour tout le monde, et probablement même pas pour la plupart - je travaillerai toujours avec WP - mais certainement pour certains.

Merci de nous avoir renseigné, Leesa.

Ma présomption (et j'espère) est que le plugin ACF sera converti. Mais c'est sur
eux pour faire leurs blocs, pas sur WordPress Core. j'imagine qu'ils sont
attendre aussi la version "navire" de Gutenberg avant d'investir trop
ressources (temps et argent). C'est ce que je ferais.

Le lundi 11 décembre 2017 à 15h10, Leesa Ward [email protected]
a écrit:

Si vous débarquez maintenant sur un projet de taille moyenne que vous allez certainement
construit avec ACF si vous deviez choisir WP, choisiriez-vous alors réellement WP ?

Un peu d'histoire: j'ai commencé ma carrière en tant que développeur Drupal junior et j'ai appris WP
à côté de mes propres clients. Mon prochain travail était 100% WordPress, alors pendant que je
voulait rester dans les deux écosystèmes, pour faire court en réalité, cela a rendu plus
sens de rester principalement avec WP.

La première chose qui m'a attiré vers ACF, c'est essentiellement qu'elle m'a apporté
quelque chose que j'ai adoré à propos de Drupal - la possibilité de spécifier des champs pour le contenu
tape facilement dans le backend - dans WP. Il y a tellement d'utilisations pour
cette. Il est facile pour les clients de remplir un formulaire avec leur contenu sans
avoir à me soucier du formatage et de la mise en page, puis je contrôle l'affichage
avec le modèle. C'est le fondement de la façon dont je crée des sites.

Donc, si je ne peux plus construire comme ça et que Gutenberg ne fonctionne pas pour mon
clients (je peux déjà penser à certains qui détesteraient ça parce qu'ils ne
envie de penser au formatage ou à la mise en page, c'est mon travail) alors non, je
pas choisir WP dans certains cas. Je retournerais probablement à Drupal. Pas pour
tout le monde, et probablement même pas pour la plupart - je continuerai à travailler avec WP

• mais certainement pour certains.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/WordPress/gutenberg/issues/3926#issuecomment-350889174 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AV3JZmN-TRB-9rQgHSqACUhcz9CqdOl-ks5s_bZtgaJpZM4Q93ul
.

--
Cellulaire 949 370 4059
www.bridgetwillard.com

Ma présomption (et j'espère) est que le plugin ACF sera converti.

Oui, absolument, je crois que ce sera le cas, c'est pourquoi je ne retourne pas immédiatement à Drupal pour tout ;) Un peu comme WooCommerce vraiment, c'est devenu une telle épine dorsale de l'écosystème.

Mais cela reste un souci, car le développeur a besoin de temps pour rendre ACF compatible. Ce qui signifie que ceux qui utilisent beaucoup le plugin ne peuvent pas convertir les sites existants tant qu'ils ne le font pas. Ce qui pourrait rendre le délai déjà court encore plus court.

Je suis tout à fait d'accord avec la suggestion que Gutenberg soit facultatif pendant au moins un an. Cela donne aux développeurs de plugins l'opportunité de faire un travail minutieux pour rendre leurs plugins compatibles, ainsi que de donner aux développeurs le temps d'intégrer ces changements et d'éduquer les clients.

De plus, il devrait y avoir une option (par exemple via le plugin Classic Editor) pour garder Gutenberg éteint et garder l'éditeur classique encore plus de temps après cela, pour les sites qui ne seront tout simplement pas convertis du tout en raison de contraintes de coût / temps . La durée de conservation d'un site Web de petite à moyenne taille signifie que dans quelques années, ce client voudra peut-être une refonte de toute façon, puis il obtiendra Gutenberg à ce moment-là.

@doubleedesign Leesa fait un bon point ici :

ils [les clients] ne veulent pas penser au formatage ou à la mise en page, c'est mon travail

Et c'est aussi l'une des choses qui me met en colère/déçu ! Qu'il y ait des constructeurs de pages est une chose. Il y a évidemment un marché pour ça, mais ce n'est pas mon marché ni celui de mes clients.
Alors pourquoi tout le monde est-il maintenant poussé vers WP pour devenir un constructeur de pages ? Et utiliser l'expression _démocratiser l'édition_ pour cela ne rend PAS les choses correctes.

Lorsque je crée un site pour des clients, ils sont hautement personnalisés et répondent exactement aux souhaits du client. Mes clients ne font pas d'erreurs lorsqu'il s'agit d'éditer du contenu, car (avec ACF) je crée une expérience backend qui ne laisse aucune place à l'erreur.

Je regardais la présentation de @ mor10 où il a mentionné que les développeurs de thèmes peuvent guider les utilisateurs à travers le contenu.

Je le fais déjà depuis des années !!! Sans Gutenberg !

J'ai intégré WP en 2005 et je l'utilise avec beaucoup de plaisir depuis. J'ai développé un certain nombre de plugins, certains plus populaires que d'autres, et j'ai développé une spécialité qui m'a éloigné de la rue pour ainsi dire.

Comme je le dis souvent à mes clients, le monde du site web est constamment en mouvement et je suppose que le temps que j'ai passé intensément avec WP touche à sa fin et que de nouvelles frontières à découvrir se profilent à l'horizon pour moi.

Je n'aime pas la façon dont ça se termine, mais encore une fois, parfois une rupture est plus facile avec une poussée que de la laisser mourir lentement...

Qu'il y ait des constructeurs de pages est une chose. Evidemment il y a un marché pour ça, mais ce n'est pas mon marché ni celui de mes clients...

Mes clients ne font pas d'erreurs lorsqu'il s'agit d'éditer du contenu, car (avec ACF) je crée une expérience backend qui ne laisse aucune place à l'erreur.

@senlin , c'est comme si tu lisais dans mes pensées ! ;)

Qu'il y ait des constructeurs de pages est une chose. Evidemment il y a un marché pour ça, mais ce n'est pas mon marché ni celui de mes clients...

Mes clients ne font pas d'erreurs lorsqu'il s'agit d'éditer du contenu, car (avec ACF) je crée une expérience backend qui ne laisse aucune place à l'erreur.

@senlin , @doubleedesign , exactement la même ici.

Gutenberg est sûrement un projet intéressant et ambitieux, mais pas d'aucune utilité pour 99% de mes clients.

J'utilise WordPress depuis 10 ans et je suis impliqué dans la communauté francophone depuis le début mais cette fois, c'est la première version qui me fait peur pour toutes les raisons que tu as évoquées...

Je voulais faire un saut pour donner un peu de perspective sur le calendrier tel qu'il est actuellement prévu. Je dis planifié car à mesure que nous avançons vers la version 5.0, la communauté, la direction de la version 5.0 et l'équipe principale travailleront ensemble pour trouver la voie à suivre pour fusionner. Notez qu'il n'a pas été fusionné et qu'au moins 11 versions sont attendues - 1 vient de sortir.

Il convient de noter que toutes les versions ont une phase candidate, la 5.0 ne fera pas exception. Il convient également de dire que plusieurs personnes ont, il y aura pendant longtemps l'option du plugin d'éditeur classique et même de l'activer en réseau. Ce plugin ne va nulle part sur la version 5.0 et restera probablement pendant un bon moment, l'éditeur classique lui-même est toujours maintenu.

Les champs personnalisés ne sont pas manqués, il y a un plugin génial en cours d'élaboration et un article ici : https://riad.blog/2017/12/11/with-gutenberg-what-happens-to-my-custom- des champs/.

Les métaboîtes ont quelques chemins potentiels à mettre à niveau, en ce moment, c'est le meilleur d'entre eux. Comment le système sera par défaut et quelle sera l'expérience de l'utilisateur à ce sujet. Rien n'est figé, tout est travaillé pour la meilleure expérience utilisateur. Les utilisateurs sont tous types de personnes - ceux qui écrivent, les créateurs de thèmes, les créateurs de plugins et bien plus encore.

Je sais que le changement est difficile et effrayant, nous le ressentons tous. Je le fais, vous le faites et c'est encore pire quand nous ne pouvons pas tout à fait comprendre le changement. Je dirigerais les gens vers wordpress.org/gutenberg comme point de départ pour comprendre le projet. Je dis point de départ car à partir de là, vous pouvez aller au manuel : wordpress.org/gutenberg/handbook. Voici par exemple la section de compatibilité qu'il me semble important de partager :

Le projet Gutenberg s'attaque activement aux problèmes de compatibilité. Les blocs sont de facto le nouveau mécanisme de création de fonctionnalités de contenu, et nous recommandons aux développeurs de migrer toutes les fonctionnalités qu'ils proposent et qui sont bien encapsulées par des blocs. Cependant, la prise en charge des fonctionnalités WordPress existantes restera, et il y aura des chemins de transition pour les shortcodes, les méta-boîtes et les types de publication personnalisés :

Codes courts.

• Continuera à travailler sans changements.
• Il y a un nouveau "bloc de shortcode" pour aider à les insérer.
• Il y a un mécanisme prévu pour les prévisualiser en place.

Les méta-boîtes.

• Certains continueront de fonctionner sans aucun changement dans la nouvelle interface utilisateur.
• Certains auront besoin de mises à jour (en particulier ceux qui dépendent du DOM pour fonctionner).*
• Plusieurs peuvent être convertis en blocs natifs (en particulier ceux qui sont rendus sur le front-end).
• Certains peuvent passer à de nouveaux points d'extension natifs de Gutenberg en dehors de la zone de contenu.
• Il y aura un mécanisme pour les méta-boîtes en conflit pour charger l'éditeur classique à la place avec un avis.

Types de messages personnalisés.

• Sont pris en charge par Gutenberg.
• Besoin d'une déclaration API REST (show_in_rest).
• Peut se retirer en ne déclarant pas le support « éditeur ».
• Sera en mesure de déclarer les blocs pris en charge et par défaut.

• Certaines méta-boîtes qui reposent sur la structure spécifique de l'écran d'édition actuel ne sont pas garanties de fonctionner sous Gutenberg et peuvent nécessiter des modifications avant de pouvoir être chargées correctement.

Je vous encourage tous à considérer dans ce que j'ai dit quelle est la bonne voie pour votre configuration particulière. Chaque personne peut vouloir ou avoir besoin d'adopter une approche différente avec Gutenberg. La clé est que personne le jour 1 ne s'attend à ce que vous ayez fait des blocs. Ce serait incroyable si les gens l'avaient fait, mais la réalité est qu'il y aura des options pour vous mettre à niveau lentement. Il faut beaucoup de documentation, d'éducation et de discussion. C'est formidable parce que toute la communauté est impliquée dans cela et peut le faire.

Enfin, n'ayez pas peur. WordPress est une communauté et bien que des discussions comme celle-ci puissent sembler effrayantes, Gutenberg ne l'est pas et la dernière chose que toute personne impliquée dans le projet souhaite, c'est que vous ayez peur. Ceux qui s'occupent de Gutenberg, ceux qui s'occupent de la communauté. WordPress est un projet génial qui respecte vraiment les choses géniales que les gens font. Je vous encourage à trouver le chemin qui vous conviendra le mieux, puis à explorer, vous amuser et vous enthousiasmer pour les blocs. Ayez votre plan et regardez ensuite comment vous pouvez construire à partir de là.

Si vous avez des questions sur Gutenberg, quel que soit le contexte, le canal #core-editor sur chat.wordpress.org est toujours là pour vous. Vous pouvez également regarder sur cette chaîne le travail en cours et voir les réunions hebdomadaires à 18h00 UTC le mercredi et généralement le hangout. Travaillons tous ensemble sur la voie à suivre.

@karmatosed Tammie,

Les métabox ont quelques chemins potentiels à mettre à niveau

Le truc c'est qu'avant GB, mes métaboxes vont bien. Ils peuvent être actifs sur des sites que je ne gère plus. Qu'en est-il des clients de ces sites Web que j'ai développés il y a quelques années ? Tout à coup, le contenu de leur site n'est plus modifiable.

Je sais que le changement est difficile et effrayant, nous le ressentons tous.

Ce type de remarques est inutile car elles semblent vraiment condescendantes et condescendantes ! Diriger les gens vers la lecture de tas de documentation qui n'est même pas terminée et qui est toujours en cours est ridicule à mon avis.
une. Je n'ai pas le temps pour ça et b. cette discussion ne porte pas sur la compréhension de GB, mais sur l'impact économique de la chronologie du déploiement de Gutenberg

Concernant la liste de ce qu'il faut faire concernant les shortcodes, les métabox et les CPT, cela montre que c'est encore pire que je ne le pensais.

Les CPT ne fonctionneront plus sans déclarer show_in_rest ?!?!?! Je suis donc maintenant censée retourner sur les sites des clients et refaire 3 à 5 ans de travail ?

C'est exactement , Tammie, l'impact économique que @gidgey (Bridget) a

@karmatosed Merci pour votre réponse complète.

il y aura longtemps l'option du plugin éditeur classique et même de l'activer en réseau. Ce plugin ne va nulle part sur la version 5.0 et restera probablement pendant un bon moment, l'éditeur classique lui-même est toujours maintenu.

Pour les sites qui utiliseront l'éditeur classique dans un avenir prévisible, cela doit-il être installé avant le déploiement de la version 5.0 ? L'idéal pour moi dans ces cas, c'est que Gutenberg ne soit jamais allumé, pour ainsi dire - pas que je me connecte précipitamment à tous mes sites pour l'éteindre.

Je sais que le changement est difficile et effrayant, nous le ressentons tous.

Ce fil n'est pas tellement une voix de Stewie Griffin "Quelque chose ne va pas avec la maison! Je n'aime pas le changement!" chose. Il s'agit de la vitesse de celui-ci. Vous dites que vous ne vous attendez pas à ce que quelqu'un ait construit des blocs lorsque la version 5.0 sera livrée... mais sans intervention, les backends du site auront cette interface, les nouveaux sites en développement devront être modifiés ou une mise à niveau planifiée ; les nouveaux sites en cours de planification/étendue auront un tas de points d'interrogation sur leurs plans.

De plus, les clients avec des sites existants mais sans plans de maintenance ou développeurs actifs peuvent être désorientés, et si leur site tombe en panne, en colère. Les services informatiques recevront des demandes d'assistance pour quelque chose dont ils ne savent rien, et les développeurs répondront aux appels d'anciens clients en colère.

Tout cela va prendre beaucoup de temps à tout le monde. Je sais que Gutenberg est en version bêta depuis un certain temps, mais ce n'est pas la même chose que de pouvoir l'utiliser sur de vrais sites avec de vrais clients pour confirmer quels sont les vrais problèmes pour nos sites et pour nos clients.

il y aura des options pour vous de mettre à niveau lentement

Une transition lente doit être la valeur par défaut et l'attente. Cela a probablement déjà été suggéré, mais il pourrait sûrement y avoir une invite "Veuillez choisir votre éditeur" lors de la mise à niveau vers 5.0. Cela serait particulièrement utile pour les clients sans développeur/mainteneur actif qui s'inquiètent des changements.

@senlin

C'est, Tammie, *exactement l'impact économique que @gidgey (Bridget) a

La réponse par défaut aux préoccupations des développeurs semble être "Mais Gutenberg est génial !!!" Pour le moment, peu m'importe à quel point c'est génial, je le découvrirai en temps voulu en l'utilisant correctement après sa sortie. En ce moment, je me soucie de ce qui va arriver et de ce que je dois faire, des 30+ sites que je gère actuellement et de la poignée que j'ai actuellement en développement.

Les utilisateurs sont tous types de personnes - ceux qui écrivent, les créateurs de thèmes, les créateurs de plugins et bien plus encore.

@karmatosed Ceci est également un peu condescendant et n'aide pas à quel point certains développeurs se sentent actuellement aliénés. Nous savons que nous ne sommes pas les seuls utilisateurs. En fait, il y a eu des commentaires dans ce fil même exprimant nos inquiétudes quant à l'impact sur certains de ces utilisateurs qui écrivent réellement, parce qu'ils sont nos clients. Nous ne parlons pas seulement de la façon dont nous voulons coder (bien que ce soit un élément de celui-ci, mais pas pertinent pour ce sujet).

@senlin passons aux accusations d'intention, nous nous soucions tous de ce qui se passe ici et le respect est important.

J'ai partagé ce que j'ai fait avec l'intention d'informer, pas dans l'intention de condescendance. Il est important de noter que je vois la valeur de cette discussion, je me suis engagé et je m'engage ici. Je vois aussi l'intérêt du fil. Ce que j'ai ressenti, c'est que le partage des ressources dont nous disposons actuellement était important pour trouver un chemin.

Passons de ce point et plongeons dans une réponse à votre commentaire :

Qu'en est-il des clients de ces sites Web que j'ai développés il y a quelques années ?

C'est pourquoi j'ai ajouté les citations de la documentation, pour montrer les solutions de repli potentielles en cours d'élaboration. Cela dépendra de la métabox, mais ce repli est potentiellement ce qui se passe.

Une chose à noter pour ceux qui travaillent sur ce sujet à apprendre, il est important de partager les exemples auxquels vous pensez. Cela aide la conversation à deux sens.

@doubleedesign , merci aussi pour votre réponse.

Pour les sites qui utiliseront l'éditeur classique dans un avenir prévisible, cela doit-il être installé avant le déploiement de la version 5.0 ?

Le plugin d'éditeur classique doit être activé aujourd'hui. Cela signifierait l'avoir en direct le jour de 5.0.

J'encouragerais totalement, dans la mesure du possible, les gens à essayer Gutenberg aujourd'hui sur les sites. En essayant, des bogues, des problèmes et des commentaires peuvent être envoyés à ceux qui y travaillent. C'est crucial pour obtenir cette discussion à double sens.

_Cela dépendra_ de la métabox mais ce repli est _potentiellement_ ce qui se passe.

??

Cela dépendra de la métabox, mais ce repli est potentiellement ce qui se passe.

Certes, je n'ai pas été moi-même impliqué dans un projet logiciel de cette taille, donc je ne sais pas si c'est normal, mais je suis nerveux à propos de toutes les parties qui semblent encore incertaines à l'approche de la sortie.

@doubleedesign juste pour être clair, je ne

Nous savons que nous ne sommes pas les seuls utilisateurs. En fait, il y a eu des commentaires dans ce fil même exprimant nos inquiétudes quant à l'impact sur certains de ces utilisateurs qui écrivent réellement, parce qu'ils sont nos clients.

Je disais qu'il s'agit de l'expérience pour tout le monde, développeurs, concepteurs, utilisateurs. Je voulais m'assurer sur ce point car j'ai l'impression qu'il a été mal compris. Je disais que tout était important et ne rejetais pas du tout l'expérience des développeurs.

Pour résumer ce que je disais :

• Lorsque 5.0 est expédié, les choses ne se cassent pas. Il existe des options pour éviter cela. Plus d'options peuvent être ajoutées.
• Pour s'assurer que les choses ne se cassent pas, un retour d'information est nécessaire. Tester, dire à l'équipe où se trouvent les problèmes et quelles configurations ne fonctionnent pas, est essentiel. Cela ne veut pas dire que ceux qui y travaillent ne testent pas, c'est juste tous les cas de stress qui existent, personne ne le sait. La communication bidirectionnelle est la clé.
• Comment Gutenberg est expédié est un détail pour 5.0. L'équipe se concentre actuellement sur le produit, reçoit des commentaires, répond et itère. Cela n'écarte rien mais c'est là qu'intervient le lead de 5.0, la communauté ; déterminer comment Gutenberg est expédié.

@karmatose

Lorsque 5.0 est expédié, les choses ne se cassent pas.

Est-ce une garantie ou simplement un résumé de ce que vous disiez sans aucune valeur attachée à cela ?

@gidgey Je pense également qu'une solution potentielle à moyen terme est ce site de crowdsourcing pour obtenir et aider à faire la transition des produits vers Gutenberg : https://gettingreadyforgutenberg.com/

Je me rends compte que cela traite principalement d'un symptôme potentiel, plutôt que d'une préoccupation globale que vous avez. D'un point de vue purement philosophique, je me demande si nous ne sous-estimons pas la résilience du type de personne que cette communauté attire.

Je ne peux pas prédire l'avenir (bien que ce soit en haut de ma liste de souhaits pour les super pouvoirs) mais vous avez raison de dire qu'il y aura un gros impact économique. Je pense que nous devons aborder ce changement les yeux ouverts, et merci d'avoir exprimé ouvertement vos préoccupations ici pour en discuter. Ce sont des conversations comme celle-ci qui nous aident à nommer nos peurs afin que nous puissions y faire face du mieux que nous pouvons. ??

Exactement, Josépha. Mon intention n'est pas de faire peur mais de prendre conscience.

Merci Piet et Tammie pour vos commentaires également.

Cela a été une discussion importante et nécessaire.

Le mar. 12 déc. 2017 à 8h16, josephahaden [email protected]
a écrit:

@gidgey https://github.com/gidgey Je pense aussi à une solution potentielle dans
le moyen terme est ce site de crowdsourcing pour obtenir et donner de l'aide
transition des produits vers Gutenberg : https://gettingreadyforgutenberg.com/

Je me rends compte que cela s'attaque principalement à un symptôme potentiel, plutôt qu'à un
préoccupation primordiale que vous avez. D'un point de vue purement philosophique, je
se demande si nous sous-estimons la résilience du type de personne
la communauté attire.

Je ne peux pas prédire l'avenir (même si c'est en haut de ma liste de souhaits pour super
pouvoirs) mais vous avez raison de dire qu'il y aura un grand impact économique. je pense
nous devons aborder ce changement les yeux ouverts, et merci pour
verbaliser vos préoccupations ouvertement ici pour discussion. C'est des conversations
comme celui-ci qui nous aide à nommer nos peurs afin que nous puissions y faire face au mieux
pouvez. ??

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/WordPress/gutenberg/issues/3926#issuecomment-351101104 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AV3JZpL52P_idTCVbWhTT9qAnAnHjgfyks5s_qbegaJpZM4Q93ul
.

--
Cellulaire 949 370 4059
www.bridgetwillard.com

Les CPT ne fonctionneront plus sans déclarer show_in_rest ?!?!?! Je suis donc maintenant censée retourner sur les sites des clients et refaire 3 à 5 ans de travail ?

Je crois comprendre que c'est l'inverse; Les CPT qui ne déclarent pas explicitement show_in_rest n'utiliseront pas Gutenberg par défaut. Gutenberg utilise l'API REST pour obtenir et enregistrer les données de publication. Par conséquent, si le CPT ne prend pas en charge l'API REST, Gutenberg ne peut pas l'utiliser.

Ainsi, environ 95 % des CPT utiliseront l'éditeur classique par défaut, sans qu'aucune modification ne soit nécessaire.

https://github.com/WordPress/gutenberg/blob/9864a6092a965d2985307ed2456f83148a1dee78/lib/register.php#L303 -L338

Les CPT qui ne déclarent pas explicitement show_in_rest n'utiliseront pas Gutenberg par défaut.

Il s'agit en fait d'un "bug" dans l'API car tout CPT avec "show_ui" => true devrait pouvoir être modifié dans Gutenberg. Et je m'attends à ce que cela soit corrigé avant la fusion.

@iandunn C'est un énorme problème pour les progrès futurs de Gutenberg puisque Gutenberg n'est pas censé être simplement un remplaçant d'éditeur, mais une toute nouvelle façon de gérer les vues. Si les CPT bloquent Gutenberg, Gutenberg ne peut pas aller au-delà de l'éditeur.

Je suis tout à fait d'accord ici en ce que le problème pour moi n'est pas de changer. Si nous ne changions pas ou n'avancions pas, nous serions toujours coincés avec WordPress v1, ce qui était incroyable à l'époque mais est loin d'être aussi bon que nous l'avons maintenant.

Le souci est le moment du déploiement. On nous dit que Gutenberg sera déployé au début de 2018, ce qui est très inquiétant et à mon avis beaucoup trop tôt.

La plupart des projets dans WordPress (en pensant à l'API REST) ​​étaient des plugins pendant des mois voire des années avant d'être introduits dans le noyau, et ils n'étaient même pas des plugins que les utilisateurs remarqueraient réellement. C'est le premier grand développement dont je me souvienne qui affectera massivement chaque utilisateur de WordPress. Que vous soyez développeur, concepteur ou éditeur de contenu, cela vous affectera d'une manière ou d'une autre.

Pour atténuer cet effet et rendre la transition plus fluide, nous avons juste besoin de plus de temps. À l'heure actuelle, comme la plupart de ce fil et de nombreux développeurs de la communauté WordPress que je connais, nous utilisons des outils tels que ACF afin de créer des sites personnalisés selon les besoins des clients. Faire de même à l'avenir, dans un laps de temps aussi court, me demandera d'apprendre un tout nouveau langage en utilisant Javascript et React, ce qui est irréaliste dans ce qui pourrait prendre 4 à 6 mois.

De nombreux fils de discussion ici nous disent de lire la documentation et d'aller tout savoir sur Gutenberg. Ce n'est pas que je ne suis pas disposé à apprendre Javascript et React et Gutenberg - j'adorerais et il semblerait que si vous allez créer quelque chose de nouveau dans WordPress, c'est la voie à suivre. Cependant, comme beaucoup dans ce fil, j'ai une entreprise à gérer, des clients actuels à gérer et, de manière réaliste, je ne peux pas apprendre cela en si peu de temps. Je n'ai tout simplement pas le temps.

Je suis vraiment inquiet de ce qui arrivera aux sites clients lorsque WordPress version 5 débarquera et je m'attendrais à beaucoup de clients mécontents. Certes, nous n'en sommes pas encore là et j'espère que le chemin vers la version 5 de WordPress avec Gutenberg se fera en douceur. Je dois admettre cependant que peu de choses que j'entends me convainquent que ce sera le cas, avec des messages mitigés.

Jamais auparavant il n'y avait eu une telle question de division dans la communauté. On nous dit de ne pas s'inquiéter, mais sans aucune preuve solide pour étayer cela. J'espère juste que ça se passera mieux que je ne l'avais prévu.

Penser à voix haute, mais je me demande si les gens ont plusieurs moments en tête pour penser à la sortie de la 5.0.

Mes pensées de dos de la serviette sont:

Gutenberg continue avec des versions hebdomadaires régulières en tant que plugin (avec une pause de vacances bien méritée) jusqu'à environ début avril.

Ensuite, Gutenberg sera proposé pour fusion dans Core. Cela prendra probablement au moins une semaine de travail logistique, peut-être 2 semaines. Nous sommes alors à la mi-avril.

Dans les versions précédentes après la fusion du projet de fonctionnalité, il s'écoulait une semaine avant la sortie de la bêta 1. Je vais dire le 25 avril (encore une fois, ce sont mes pensées, pas un horaire ferme).

Une version de cette taille nécessitera probablement au moins 4 versions bêta, mais je pense que 5 pourraient être plus sûres ici. On va donc dire que c'est fin mai avant de passer au RC1.

Une période de RC de 3 semaines pour aplanir tous les bords place le lancement vers le 19 juin, soit environ 1 an après la première mondiale de Gutenberg au WCEU 2017 (en ignorant que le travail était en cours avant cela et que les messages avaient été publiés sur make.wordcamp.org/ quelques mois plus tôt décrivant certains des premiers travaux)

Quand je pense au fait que nous sommes essentiellement à un point où l'API est stable, cela donne plus de 6 mois pour se préparer. De toute évidence, il y a un besoin de plus de documentation à court terme pour aider les gens à construire plus facilement sur Gutenebrg, mais c'est essentiellement 2 trimestres pour se préparer aux types en cascade, ou 13 sprints de 2 semaines pour les gens plus agiles.

_Depuis le groupe Facebook AWP_

Je suis d'accord sur la nécessité d'éduquer. Cependant, cela ne nous prendra pas beaucoup de temps en tant que développeurs/créateurs de sites pour tester Gutenberg sur quelques sites existants. Si vous avez un site intermédiaire/local pour un site que vous avez déjà terminé, installez simplement Gutenberg dessus et testez. Il m'a fallu peut-être une demi-heure pour tester Gutenberg sur 3 sites (j'ai également mis à jour WordPress et tous les plugins sur ces sites). Celui qui utilisait Beaver Builder convenait parfaitement aux pages, tant que j'utilisais Beaver Builder (ce qui est parfaitement raisonnable) et que les messages (pas de constructeur) fonctionnaient bien dès le départ.
Les deux autres sites étaient alimentés par une utilisation intensive d'ACF et j'ai découvert que les méta-boîtes n'enregistraient actuellement pas. Je n'ai pas encore compris, et je ferai probablement un rapport sur GitHub (j'ai vu qu'il y avait déjà quelques problèmes sur le sujet) quand j'aurai un peu de temps.

Personnellement, j'ai confiance dans l'équipe de base et dans tous les contributeurs qui travaillent très dur sur Gutenberg, que lorsque 5.0 sortira, cela fonctionnera immédiatement pour un pourcentage très élevé de tous les sites. L'objectif, à mon avis, n'est pas de casser la plupart des sites fonctionnant sur WordPress.
Cependant, nous devons redonner à la communauté en signalant au moins toute incompatibilité que nous rencontrons en cours de route.

De plus, je ne suis pas entièrement d'accord avec le point de "ça coûtera cher". Ce qui sera? Installer le plugin de l'éditeur classique ? Si vous avez un contrat d'assistance avec vos clients, installez également le plug-in Classic Editor dans le cadre de la mise à jour 5.0 que vous effectuerez. Boom! Vous avez terminé :)
Si vous n'avez pas de contrat d'assistance, prenez un jour (ou le temps dont vous avez besoin - vous disposez de quelques mois) pour créer une liste des anciens clients pour lesquels vous avez créé des sites. Envoyez à vous-même et à Cci tout le monde et écrivez quelque chose du genre

Hé, je voulais juste vous informer qu'avec WordPress 5.0, dont la sortie est prévue le, une mise à jour majeure sera faite autour de l'expérience de publication/édition. Comme il s'agit d'une mise à jour vraiment importante, elle pourrait avoir des effets potentiellement négatifs sur la gestion du contenu de votre site.
Ne désespérez pas pour autant ! Il existe une solution vraiment simple, qui vous permettra toujours de mettre à jour en toute sécurité - il suffit d'installer et d'activer le plugin "Classic Editor". Cela garantira que vous continuez à utiliser la même interface que celle à laquelle vous êtes habitué.
Comme toujours, je vous recommande de faire ces mises à jour sur un site de staging, ou au moins de faire une sauvegarde de votre site avant de mettre à jour WordPress.
Si vous souhaitez en savoir plus sur la mise à jour à venir, n'hésitez pas à la lire ici

Si vous avez besoin d'aide, je serais heureux de vous aider.
Meilleures salutations,

Boom! Vous avez terminé. Oui, vous devrez peut-être répondre à un tas de demandes à ce stade, mais cela ne fera que renforcer la satisfaction de vos clients. Ils verront que vous vous souciez d'eux et du bien-être de leur site, même après l'avoir terminé. Si vous ne voulez pas prévenir vos clients, ne le faites pas, pour moi, cela en vaudrait la peine.

Quelques réflexions que je n'ai pas postées sur Facebook :

• Ce serait une bonne idée de créer un pointeur (c'est ainsi qu'ils s'appelaient, n'est-ce pas ?) Cela peut réduire considérablement le nombre de personnes frustrées qui se précipiteront vers Google/développeur/support/etc. pour aider.
• Quiconque prétend qu'il devra changer tout ce qu'il fait actuellement pour développer des sites WordPress personnalisés - veuillez comprendre que ce ne sera pas le cas. Au pire il vous suffit d'installer un seul plugin (ou d'ajouter le code équivalent à votre thème/plugin) et le tour est joué .
• Pour tous ceux qui disent qu'il n'y a pas assez de temps pour s'adapter (même les auteurs de plugins) - s'il vous plaît, il y a plus de 4 mois. Gutenberg n'est pas quelque chose sur lequel on travaille dans les coulisses et qui tombera sur la tête de tout le monde sans avertissement. Encore une fois, si vous testez maintenant, vous saurez si vous devez apporter des modifications. Si quelque chose ne fonctionne pas, contribuez en créant un problème.

Et enfin...

S'il vous plaît, s'il vous plaît, s'il vous plaît - soyez gentil avec tous les contributeurs. Je comprends que les grands changements soient frustrants, mais mettez-vous juste une minute dans la peau d'un contributeur travaillant sur Gutenberg ou derrière lui. Que ressentiriez-vous si des milliers de doigts vous pointaient du doigt et disaient « ce que vous faites est mal et vous devriez vous sentir mal. Nous ne voulons pas de votre innovation » ? Travaillez avec plutôt que contre les contributeurs. Aidez-les à trouver toutes les combinaisons de code/plugins/thèmes sur lesquelles ils ne pourraient pas tomber. Aidez à rendre la transition plus facile et meilleure pour tout le monde. Redonner à la communauté :coeur:

Paix dehors :v:

@senlin

Je regarde sérieusement d'autres CMS et j'ai déjà créé quelques sites avec Grav CMS.

Alors, vous êtes prêt à investir du temps pour apprendre un autre CMS, mais pas pour installer un plugin qui ne fait que garder l'expérience telle quelle ? Vous comprenez que tout ce dont vous n'êtes pas le seul développeur pourrait à un moment donné faire un choix que vous n'aimez pas/avec lequel vous n'êtes pas d'accord et vous mettre dans la même situation ? Vous êtes libre de faire ce que vous voulez bien sûr, cela me semble juste une décision illogique, étant donné la situation telle que je la comprends (peut-être que nous la comprenons simplement différemment?).

Les CPT ne fonctionneront plus sans déclarer show_in_rest ?!?!?! Je suis donc maintenant censée retourner sur les sites des clients et refaire 3 à 5 ans de travail ?

Comme c'est le cas actuellement, si votre CPT ne déclare pas show_in_rest , il sera par défaut l'éditeur standard (vous ne saurez même pas que Gutenberg est installé en éditant un message dans votre CPT). Cependant, comme @youknowriad mentionné ci-dessus, cela devrait être corrigé à l'avenir, de sorte que show_in_rest défaut la valeur de show_ui lorsqu'il est manquant.

Avez-vous eu l'occasion de tester Gutenberg avec l'un des sites que vous avez créés précédemment ? Sinon, je vous recommande fortement de l'installer sur un site de développement, afin que vous ayez une meilleure idée de ce qui fonctionne et ne fonctionne pas avec votre configuration.

@nikolov-tmw Nikola,

Donc, vous êtes prêt à investir du temps pour apprendre un autre CMS

Oui en effet!

mais ne pas installer un plugin qui ne fait que garder l'expérience telle quelle ?

Conserve l'expérience pendant combien de temps exactement ?

Vous êtes libre de faire comme vous le ferez bien sûr

Wow, merci, j'avais vraiment besoin de votre permission!

peut-être que nous le comprenons simplement différemment?

Probablement

Avez-vous eu l'occasion de tester Gutenberg avec l'un des sites que vous avez créés précédemment ?

En fait, je l'ai installé sur quelques sites

Sinon, je vous recommande fortement de l'installer sur un site de développement, afin que vous ayez une meilleure idée de ce qui fonctionne et ne fonctionne pas avec votre configuration.

Merci d'avoir supposé !

Je suppose qu'en fin de compte, l'impact économique dépend de la façon dont vous construisez des sites (pour les clients). Vous mentionnez Beaver Builder, j'ai déjà mentionné auparavant (faites défiler vers le haut) que les constructeurs de pages ne sont pas quelque chose que j'utilise ou que mes clients veulent. Donc, deux choses différentes que vous comparez ici vraiment.

L'impact économique que le passage à Gutenberg aura pour moi est si important que je préfère en effet passer à une autre manière de créer des sites Web. Merci de votre compréhension et de votre respect !

Tellement de bons points ici. Je suis d'accord avec à peu près tous. Je pense que la vraie solution est de faire en sorte que Wordpress implémente Gutenberg en tant qu'OPTION. Laissez-nous la possibilité de choisir d'utiliser l'éditeur Tiny MCE sans avoir à installer de plugin.

Je comprends les deux côtés. Les chances et les soucis. Je n'ai aucune idée si Gutenberg attirera de nouveaux utilisateurs de WordPress ou offensera ceux qui existent déjà. Mais en tant que développeur, je dois dire que tout ce que j'ai lu sur la façon dont Gutenberg fera partie du noyau WordPress semble faux.

@m me manque dans cette conversation. Où est le discours de rétrocompatibilité du passé ? Si vous voulez des transitions fluides, vous ne devez pas forcer les changements de rupture. Ne fournissez pas de plugin pour revenir à l'éditeur classique. Faites de l'éditeur classique la valeur par défaut pour toute mise à jour WordPress existante vers 5.0. Faites de Gutenberg une option pour ceux qui mettent à jour. Avez-vous déjà pensé aux milliers d'installations WordPress faisant une mise à jour automatique ? Vous n'atteindrez pas 90 % des utilisateurs pour leur dire comment ils peuvent « résoudre » le problème de Gutenberg. Ne l'activez tout simplement pas. Racontez votre histoire à ce sujet sur l'écran de mise à jour de WordPress. Dites aux gens pourquoi cela peut être intéressant. Si Gutenberg est l'avenir, vous pouvez l'activer à chaque nouvelle installation de WordPress, mais jamais par défaut sur Gutenberg après une mise à jour.

WooCommerce est passé à CRUD. Un changement radical. Et ce n'était pas aussi fluide que prévu. Cependant, il n'a pas rompu la compatibilité descendante. Les développeurs ont eu le temps de s'adapter après l'introduction de CRUD. Pourquoi ne pas faire de même avec Gutenberg ?

Vous parlez d'une meilleure documentation de Gutenberg. Amende. Mais en développant des plugins et des applications basées sur WordPress, j'ai appris la meilleure documentation c'est le code source. Par conséquent, vous devez simplement attendre que le Gutenberg final arrive car vous ne savez pas ce qui changera au cours du développement ultérieur de Gutenberg.

Si j'étais le chef de projet, je suivrais un plan simple :

1. Gutenberg n'obtiendrait pas l'éditeur actif pour les mises à jour WordPress. Uniquement pour les nouvelles installations WordPress
2. Le plugin pour passer à l'éditeur classique ferait partie du core. Ses paramètres seraient visibles sous les options de publication générales de WordPress.
3. Les CPT fonctionneraient comme avant. S'ils déclarent la prise en charge de l'éditeur, ils utiliseront par défaut l'éditeur classique. S'ils devaient utiliser Gutenberg, ils devraient le déclarer.
4. Les métaboîtes fonctionneraient comme avant. Peu importe qu'ils traitent de contenu, de taxonomies ou de trucs personnalisés. Il n'y a tout simplement aucune raison pour que l'éditeur ait un impact sur la logique métier.
5. Et enfin, pour moi, Gutenberg ne serait rien d'autre que n'importe quel autre constructeur de pages. Par conséquent, j'examinerais de près tout l'excellent travail de ces développeurs et comment ils l'ont réussi à NE PAS casser les fonctionnalités de base de WordPress ;-)

Juste mes 2 cents

parler d'impact économique :

quelques-uns prétendent que [GB] est un bogue que je devrais résoudre puisque j'ai suggéré WordPress en premier lieu.

https://deliciousbrains.com/wordpress-gutenberg/#comment -3700968927

Merci à tous ceux qui ont pris le temps de peser. Il s'agit d'un retour significatif auquel se référer au fur et à mesure que le projet progresse.

Clôturer ce problème car il n'y a rien d'actionnable dans l'immédiat.