Gutenberg: Un moyen de désactiver l'éditeur Gutenberg dans le code?

Voir également:

• https://github.com/WordPress/gutenberg/blob/master/docs/faq.md#will -i-be-able-to-opt-out-of-gutenberg-for-my-site
• https://wordpress.org/plugins/classic-editor/

Salut @aduth a mis à jour le titre pour avoir plus de sens - à la recherche d'options de code :) merci

Je pense que ce serait une fonction très utile pour de nombreux développeurs. En fait, j'irais jusqu'à suggérer que je pense que Gutenberg ne devrait être actif que sur les nouvelles installations de WordPress qui sont la version 5.0 plutôt que d'être actif sur les sites qui mettent à niveau vers la version 5.0 de WordPress - lorsque la fusion avec le noyau se produit.

Si cela était combiné avec un moyen d'activer / désactiver dans le code, les développeurs pourraient l'activer lorsqu'ils sont prêts.

Pourriez-vous expliquer pourquoi vous devez y parvenir via le code?

S'il s'agit d'un problème de visibilité / contrôle client, vous pouvez toujours installer le plugin mentionné ci-dessus en tant que "Must Use Plugin": https://codex.wordpress.org/Must_Use_Plugins

Parce qu'un changement de code est rapide et facile - activer un plugin n'est pas 1) mon code et 2) pas aussi simple que d'ajouter du code - l'ajout à la liste des dépendances n'est pas une manière pratique ni sensée d'aborder ce problème.

La définition d'une constante peut être votre code, mais la logique qui opère sur ladite constante ne serait tout autant pas votre code que le plugin "Classic Editor" officiellement maintenu.

Je devrais préciser que je n'essaie pas d'être argumentatif, mais plutôt d'essayer de mieux comprendre pourquoi ces approches sont attrayantes, en m'assurant qu'il existe suffisamment d'options, sans en offrir aussi autant qu'elles soient excessives à maintenir.

Pourquoi la fonctionnalité du plugin ne peut-elle pas faire partie du noyau? Je demande juste comme je suis curieux :)

Je voudrais refléter la nécessité de pouvoir activer / désactiver l'éditeur Gutenberg. Ma situation particulière est qu'un de mes sites WordPress est construit sur un thème qui a un éditeur personnalisé (par exemple: Avia Editor dans le thème Enfold).

Lorsque Gutenberg est activé, le flux de travail de nos éditeurs change. Ils doivent aller dans Tous les articles> ou Pages> et cliquer sur «Éditeur classique», puis appuyer sur le bouton de l'Éditeur de mise en page avancé, qui invoque l'Éditeur intégré au thème au lieu de simplement cliquer sur «Modifier» sur la page qu'ils souhaitent modifier , ou depuis la page d'aperçu. Nous avons besoin de cet éditeur, car l'aspect et la convivialité de notre site sont normalisés autour des modèles que nous avons créés avec cet éditeur.

Bien que le processus semble trivial pour la plupart, le changement de flux de travail pour des dizaines d'éditeurs causerait des maux de tête au support.

Mes 2 cents.

Je pense que la différence n'est que «psychologique». L'avoir dans Core signifie que nous l'aurons indéfiniment, ce qui nuit à l'adoption de Gutenberg où l'avoir comme plugin signifie que nous le supporterons pendant un certain temps (je pense que Matt a dit plusieurs années) et à un moment donné, nous nous arrêterions.

Je ne sais pas si cela doit être transformé en un problème distinct ou non, mais j'aimerais exprimer mon soutien à l'idée de @wpmark de

Si vous voulez le lire, ma justification est donnée dans un article de blog que j'ai écrit et est une combinaison de l'énorme changement dans l'interface utilisateur pour mes clients, et des changements de code qui pourraient être nécessaires pour prendre en charge correctement Gutenberg (ce qui dans dans le cas de mes clients, il se peut qu'il n'y ait pas de budget pour).

On a l'impression que Gutenberg sera idéal pour les nouveaux utilisateurs de WordPress qui installent un nouveau blog et se lancent. Et ce sera génial pour les personnes qui mettent à jour et pensent "Yay - nouvel éditeur - je l'aurai s'il vous plaît". Mais pour d'autres, ce sera un énorme choc. Et dans certains cas d'utilisation, GB peut ne pas être une bonne interface pour éditer un type de publication personnalisé, ou les "blocs" peuvent ne pas être un bon modèle de données pour les informations éditées.

Il semble également que les voix des développeurs et des propriétaires de petites entreprises doivent être entendues sur ce sujet. Je connais beaucoup de petits magasins de développement WordPress et ce changement va être douloureux pour toutes les raisons exposées dans mon article de blog. Je n'ai entendu aucun développeur ou petite agence dire que l'activation automatique de GB pour les sites mis à jour est une bonne idée. J'ai entendu beaucoup de recul à l'idée.

Ce type d'utilisateur WordPress (et les magasins de développement comme le mien sont de grands partisans et partisans de WordPress, donc nous espérons vraiment que vous écouterez) comprend bien leurs utilisateurs, nous savons en profondeur ce que nous avons construit sur WordPress et si oui ou non. s'intègrera bien dans l'interface utilisateur GB sans modification, et nous avons BESOIN de la capacité de gérer ce changement au nom de nos clients.

Je sais que nous pouvons installer le plugin Classic Editor, et nous devrons peut-être le faire pour supprimer la possibilité que nos clients activent eux-mêmes GB. Et si la GB s'avère facultative pour les sites mis à niveau, cela impliquerait naturellement d'avoir un code pour le désactiver dans le noyau. Cela rendrait @ smp303 (et d'autres qui veulent un moyen de le désactiver dans le noyau) heureux aussi!

J'espère que les opinions des développeurs et des petites entreprises WordPress comme la mienne seront entendues au fur et à mesure que le plan de fusion dans le noyau est produit. Nos moyens de subsistance peuvent être affectés par ce changement et certaines personnes ont l'impression que ce changement leur est imposé trop rapidement. Veuillez nous donner plus d'options pour gérer la transition, et considérez que la GB ne sera pas la bonne chose pour tout le monde lorsqu'elle sera ajoutée pour la première fois au noyau.

Un filtre dans WP core ou une constante pour wp-config.php, semble être deux options solides à pouvoir avoir.

En écho à @rosswintle et à son excellent article de blog lié ci-dessus: nous sommes l'une des nombreuses agences à utiliser des champs personnalisés, des métaboxes (ACF en particulier) pour offrir une expérience d'édition vraiment riche. "WordPress en tant que plateforme" était la promesse, et c'est ce que nous faisons tous depuis quelques années.

Il doit y avoir un moyen d'activer Gutenberg pour ceux qui le souhaitent mais pas de l'appliquer pour ceux qui ne le souhaitent pas. Je suis raisonnablement facile de savoir si cela se produit dans le code ou via un plugin - en fait, en tant que personne qui gère plus de 50 sites WordPress à l'aide d'une console de gestion, une installation de plugin en masse pour désactiver Gutenberg aurait plus de sens pratique (si moins de sens geek), mais moi, tant que cela peut être fait. Même une option de paramètres dans le tableau de bord serait ok, IMO - un défaut de "Gutenberg: off" encore mieux ...

Le point de Ross sur les sites rétrocompatibles avec Gutenberg est également valable. Pratiquement tous ceux qui construisent pour des clients savent que la grande majorité dépense leur budget pour le lancement et n'a pas de budget par la suite. Moderniser Gutenberg, reformer les clients, une interface différente - penser que tout le monde paiera pour cela en dehors des développeurs et des propriétaires d'entreprise est une terre fantastique.

Juste pour faire écho aux sentiments de @ smp303 , @dmje et @rosswintle.

Pouvoir mettre une action simple dans functions.php pour désactiver Gutenberg semble être la chose la plus simple et la plus évidente à faire.

Je ne peux pas m'empêcher de penser que l'approche du plugin a été adoptée pour rendre un peu plus difficile qu'il ne le faut pour contourner Gutenberg.

Je sais que l'équipe de base a déployé beaucoup d'efforts pour Gutenberg, mais son succès devrait être déterminé par ses mérites, et non en réduisant sa capacité à l'éviter. De plus, pensez aux développeurs WP qui doivent développer pour un tout nouvel éditeur, apprendre à réagir et continuer à développer et maintenir des éléments hérités - la surcharge est ÉNORME.

Je voudrais également faire écho à cela - je voudrais également la possibilité de désactiver l'éditeur Gutenberg via le code et non via le plugin.

Voir aussi ce ticket Trac qui a été créé, et maintenant fermé comme wontfix : # WP43068

Par @ dd32 dans https://core.trac.wordpress.org/ticket/43068#comment : 6

Je ne pense pas que nous prendrons en charge une constante pour cela, mais que nous dirigerons simplement les gens vers le plugin et peut-être un wrapper mu-plugin pour cela, simplement parce que le plugin existant n'est pas qu'un interrupteur, il va pour impliquer du code qui n'est pas utilisé dans le noyau.

WordPress a essayé de s'éloigner des constantes, car elles sont très difficiles à changer plus tard sur la piste "Oh, je veux Gutenberg pourquoi est-il désactivé? Oh, mon plugin de référencement aléatoire (ou ancien développeur) pensait que je ne le ferais pas le veux et l'a désactivé de force, super .. maintenant qui puis-je résoudre ce problème pour moi "(utilisateur final)

Je peux voir pourquoi certaines personnes voudraient le désactiver, mais je ne vois aucun besoin de le faire de cette manière.

Je pense que nous pouvons fermer cela en toute sécurité en tant que wontfix , cela peut changer plus tard (et nous y reviendrons alors), mais je ne m'y attend pas.

Merci pour vos commentaires, tout le monde. Je comprends que la décision d'exiger le plugin Classic Editor pour désactiver complètement l'éditeur de blocs est controversée, alors j'aimerais discuter des différentes options.

Au cours des prochaines années, le concept de «bloc» de gestion des données de site deviendra la principale méthode de réflexion, de mise en page, d'interaction avec et de modification des données. L'éditeur de blocs à venir dans WordPress 5.0 est la première étape majeure dans cette direction, l'accent mis sur la personnalisation de Gutenberg cette année est la prochaine étape, avec le thème Gutenberg.

Bien sûr, tout le monde ne sera pas prêt à 100% pour l'éditeur de blocs lorsque WordPress 5.0 sera livré. C'est une réalité pratique dont tout le monde est conscient, et nous ne souhaitons pas laisser les gens sans moyen viable de passer à WordPress 5.0. Dans cet esprit, il existe plusieurs façons de désactiver Gutenberg, en fonction de votre cas d'utilisation particulier.

Si vous enregistrez des méta-boîtes qui ne fonctionnent pas avec l'éditeur de blocs, vous pouvez facilement marquer cette méta-boîte comme incompatible .

De même, il y a une discussion sur l'ajout d'un indicateur similaire pour les CPT (# 2457), de sorte que les CPT qui ne nécessitent pas la fonctionnalité d'éditeur de blocs puissent s'en désinscrire.

Ce sont les deux principaux cas d'utilisation à long terme pour la désactivation de l'éditeur de blocs - des situations où cela ne fonctionne pas ou il ne correspond pas aux modèles d'utilisation.

Avec ces choses à l'esprit, pensons aux prochaines années de la façon dont WordPress va potentiellement évoluer (notez que je regarde beaucoup dans une boule de cristal ici - les choses sur cette liste ne se produiront pas nécessairement dans cet ordre, cette période ou même pas du tout - c'est juste un scénario potentiel qui dépendra beaucoup de la façon dont la version WordPress 5.0 se terminera).

• Le Customiser utilise le concept de bloc pour tout. Pour 99% des nouveaux sites, les blocs sont la seule chose nécessaire pour créer des sites entiers. La manipulation de bloc est la façon dont les sites sont construits.
• De nouveaux thèmes évolueront autour de chantiers entièrement à partir de blocs. L'expérience utilisateur standard de WordPress est construite avec des blocs.
• Dans le même temps, wp-admin commencera à adopter l'interface JavaScript-app apportée par Gutenberg. Le passage à l'éditeur classique est toujours possible, bien sûr, mais il ne correspond pas au reste de l'interface WordPress.

Je répète que c'est au cours de plusieurs années, il y aura des plugins comme Classic Editor pour restaurer les anciennes interfaces, mais il ne sera pas nécessairement possible que ces interfaces soient maintenues dans Core. Bien que ce soit une option raisonnable de désactiver l'éditeur de blocs dans WordPress 5.0, vous rendriez un très mauvais service à vos clients si vous accédez à WordPress 5.5 ou 6.0 et que vous utilisiez toujours l'éditeur classique. Pour ne prendre qu'un exemple, tout comme les meilleures pratiques de mise en page de site ont évolué des mises en page de tableau, à plusieurs itérations de mises en page CSS, et maintenant les mises en page de grille, les meilleures pratiques de développement WordPress évoluent également.

Donc, pour revenir à la question initiale, une seule option basée sur un code pour désactiver l'éditeur de blocs n'est pas une solution viable à long terme, elle ne peut pas s'étendre pour donner des options appropriées pour le développement futur de WordPress Core, elle rend vraiment un mauvais service à tout le monde ici si nous devions créer cette option. Le plugin Classic Editor, cependant, peut continuer à évoluer pour s'adapter à tout paradigme que l'avenir apporte. Cela donne un environnement plus détendu où il peut être développé spécifiquement pour répondre aux besoins des personnes qui en ont besoin, plutôt que de devoir s'adapter aux besoins plus généraux de l'ensemble du monde WordPress.

Le problème avec l'éditeur Gutenberg n'est pas les blocs ou le concept de blocs - c'est que l'éditeur lui-même n'est pas un bon. Il est, actuellement, beaucoup plus déroutant que l'éditeur existant - qui, lui-même, est très loin d'être parfait. Et, à mesure que nous approchons du temps (prévu en avril, je suppose?) Et que les gens expriment de plus en plus de préoccupations, les commentaires ne sont jamais "vous avez raison, voici comment nous prévoyons d'y remédier", c'est comme vous l'avez fait ci-dessus "eh bien, cela se passe, alors mieux vaut monter à bord."

L'intérêt de désactiver Gutenberg, du moins mon intérêt, n'est pas l'avenir des blocs contre les widgets et la feuille de route à long terme du personnalisateur - c'est que l'éditeur actuel est vraiment nul. Je ne veux pas m'en servir. Mes clients ne veulent pas utiliser. Ce n'est pas une bonne chose à utiliser. Et, la raison pour laquelle ce n'est pas très bon, c'est le concept de base que chaque paragraphe et chaque morceau de texte est un "bloc" et nous détestons tous cela.

C'est la raison pour laquelle nous voulons désactiver cette option. Aller à Gutenberg est, pour beaucoup, une expérience très désagréable et profondément troublante pour les clients et le développement.

Je me fiche de la future feuille de route. Je me soucie de perdre mes clients et mon entreprise et jusqu'à présent, personne dans l'équipe de Gutenberg ne semble partager cette inquiétude. Que sommes-nous censés faire lorsque la plate-forme de base de nos revenus évolue à plein régime dans une direction que nous ne voulons pas aller? Et que sommes-nous censés faire lorsque nos préoccupations sont écartées au nom de «la future feuille de route»?

Je suis tout à fait pour remplacer les widgets, les insertions et les codes courts dans un système de blocs universel. Je pense que c'est une bonne idée - je suis derrière. J'aime essayer de donner aux utilisateurs plus de contrôle sur la mise en page de leur site - pourquoi pas?

Je suis inquiet parce que l'outil de création de contenu est, actuellement, un désordre brûlant que pas un seul de mes clients (plus de 300) ne veut utiliser. En fait, ils le regardent avec horreur, et toutes les belles petites démos et vidéos YouTube et les discussions WordPress enregistrées ne leur montrent qu'à quel point ils le détestent.

Ils ne veulent pas écrire en blocs! Ils ne veulent pas d'un éditeur basé sur des blocs! Ils détestent tous cela - ils veulent que cela fonctionne comme MS Word ou Google Docs, car c'est ce qu'ils utilisent normalement pour écrire des choses. C'est ce qu'ils veulent.

Comment puis-je leur donner cela alors que tout ce que WordPress veut faire est de leur pousser des blocs dans la gorge?

La seule alternative que j'ai est d'éteindre Gutenberg. Donc, je veux une méthode fiable pour le faire. À tout le moins jusqu'à ce que ce train de développement revienne à ses sens et crée quelque chose qui vaut vraiment la peine d'être utilisé - non pas comme un mécanisme de blocage mais comme un véritable éditeur.

J'ai besoin d'un éditeur fonctionnel où le texte n'est PAS basé sur des blocs. Quand Gutenberg fournira-t-il cela? Répondez-y et je vous dirai que nous n'avons plus besoin d'un moyen de désactiver Gutenberg. Jusque-là, ayez une réelle empathie et prenez soin des millions d'utilisateurs et d'entreprises WordPress et fournissez un moyen de désactiver Gutenberg auquel nous pouvons avoir confiance - cela signifie du code, pas un autre plugin.

Il doit y avoir un moyen de désactiver Gutenberg au niveau du code. Veuillez nous faire cette courtoisie. Ne donnez pas une autre réponse platitude - donnez-nous simplement un moyen de désactiver cette fichue chose si tout va de travers.

@pento , Pendant des années, il y avait une option facile par utilisateur pour désactiver tinymce, et alors que beaucoup de développement était spécifique à Tinymce, personne n'avait suggéré que l'option soit supprimée.

Je n'ai encore entendu personne suggérer de supprimer cette option dans le cadre de gutenberg, et cela n'a pas beaucoup de sens pour moi que vous puissiez passer de gutenberg à un éditeur basé sur du texte sans pouvoir continuer à utiliser l'actuel tinymce. En gardant à l'esprit que tinymce devra toujours être pris en charge dans le cadre du widget de texte et de l'API wp_editor, cela n'a aucun sens de développement ou d'interface utilisateur de forcer les gens à installer des plugins pour exposer des API de base activement maintenues.

Même si pour une raison quelconque vous ne souhaitez pas modifier cette option utilisateur pour inclure le paramètre lié à gutenberg, à partir d'un PDV de développement logiciel tant que vous allez prendre en charge la désactivation de gutenberg, il devrait s'agir d'une API qui fait partie de gutenberg et maintenue en tant que partie de son développement. Comme le montre le plugin de l'importateur, même les plugins "core" se désynchronisent et deviennent inutilisables principalement parce qu'ils ne font pas partie du développement réel du core.

Refuser de maintenir une telle API dans le cadre du noyau signifie qu'il n'y a aucun engagement à laisser les gens désactiver gutenberg même en 5.1, une version qui sera probablement en 2018. Vous ne pouvez pas vous attendre à ce que les gens puissent faire des plans à moyen terme avec de tels incertitude.

@pento Merci pour la réponse longue et détaillée. Je ne pense pas que ce soit juste un problème sur la façon de désactiver Gutenberg, mais aussi sur si et comment il sera activé par défaut. Je pense que votre réponse couvre les deux mais cela me trouble aussi.

Pour ma part, je suis très surpris que l'implication ici et ailleurs est que l'éditeur classique sera supprimé de WP et que le plugin "Classic Editor" le rajoutera. Est-ce une compréhension correcte? Cela me semble être une très mauvaise idée, mais je ne peux pas expliquer pourquoi pour le moment.

@markkap fait également un bon point sur le widget texte et l'API wp_editor - comment seront-ils conservés dans le noyau si TinyMCE est supprimé?

Et éditer du code meta_box / CPT pour empêcher le chargement de Gutenberg est bien, mais en fait, je suis un indépendant indépendant qui construit probablement environ 60 à 80 sites pour les clients. Je ne suis pas sur le point de modifier tout ce code et beaucoup de ces petits clients ne voudront pas me payer pour le faire. Je préférerais BEAUCOUP que ce soit opt-in plutôt que opt-out: Gutenberg devrait être activé lorsque je déclare son soutien. La valeur par défaut ici est, encore une fois, à l'envers. Vous obligez les gens à faire un changement pour éviter que les choses ne changent / se cassent (je suis heureux de soulever un problème distinct pour cela si nécessaire).

vous rendriez un très mauvais service à vos clients si vous accédez à WordPress 5.5 ou 6.0 et que vous utilisiez toujours l'éditeur classique

(En utilisant également ma boule de cristal) Je ne pense pas que je suis nécessairement d'accord avec cela. Je pense qu'il est impossible de dire que Gutenberg et les blocs seront une meilleure expérience d'édition pour tous les cas d'utilisation à l'avenir.

Je me trouve également un peu confus ici sur la nature des «blocs». C'est probablement une question de terminologie, mais cela implique qu'une ou plusieurs des conditions suivantes sont vraies:

• Il y a un changement de paradigme que j'ai du mal à faire ou j'ai mal compris quelque chose
• Le nouveau paradigme n'est pas très bien communiqué
• La manière dont WordPress est utilisé par des développeurs comme moi pour créer des outils de gestion de contenu pour les clients n'est pas bien comprise
• Les façons dont WordPress est utilisé par des développeurs comme moi pour créer des outils de gestion de contenu pour les clients sont bien comprises et sont ignorées

Tu as dit:

Au cours des prochaines années, le concept de «bloc» de gestion des données de site deviendra la principale méthode de réflexion, de mise en page, d'interaction avec et de modification des données.

Cela me fait un peu peur et j'y reviendrai.

La page Gutenberg à https://wordpress.org/gutenberg ne semble pas être d'accord avec cette description. Il appelle les blocs "blocs de contenu" et explique que:

[blocs] sont un moyen unifié de styliser le contenu

_Remarque: je suis un développeur back-end et je pense beaucoup en termes de données: quelles données existent dans un système, quelles sont les propriétés des éléments de données, comment les éléments de données sont liés et comment les données sont interrogées et manipulées._

Je crois comprendre que les «blocs» sont des sections de contenu qui peuvent être utilisées pour comprendre un article, une page, etc. Ils sont principalement stockés à l'intérieur du contenu des articles dans la base de données à l'aide de commentaires HTML pour une compatibilité ascendante, mais vous pouvez également configurer des blocs pour enregistrer des données à d'autres endroits comme post_meta. (Remarque: ce _feels_ comme un hack pour garder les gens comme moi heureux de mettre des métadonnées dans des blocs - cela ne ressemble pas à une décision de conception bien pensée sur la nature des blocs)

Votre implication dans ce que vous dites est que les blocs doivent conduire _tout_. C'est ainsi que les «données du site» seront gérées. Ceci, et d'autres choses que vous avez dites, impliquent que les blocs ne sont pas seulement des sections de contenu, mais une sorte de dispositif d'interface utilisateur qui peut être connecté à n'importe quoi: options du site, personnalisations, métadonnées sur les publications, widgets, menus, champs de profil utilisateur, tout.

Je pense donc que nous devons clarifier la nature d'un "blocage".

Si ce que vous sous-entendez est correct, je pense que cela représente une mauvaise compréhension fondamentale de la façon dont WordPress est utilisé par des gens comme moi. Et je pense que cette approche sera ce qui me poussera à descendre du train WordPress et à trouver un CMS alternatif pour certains projets. WordPress sera destiné aux blogs et aux magazines, mais la plupart des opportunités offertes par les types de publication personnalisés disparaîtront.

Les méta-données dans WordPress sont telles que décrites: des données sur les données. Ce sont des informations qui donnent des propriétés supplémentaires aux éléments de contenu. Les métadonnées ne sont PAS du contenu. Et, IMO, n'est pas adapté pour être placé dans des "blocs" tels que je les comprends. Certains des types de messages que je crée n'ont pas d'autre contenu qu'un titre: ils n'ont que des propriétés / champs / métadonnées.

Si ce que vous décrivez ici est vrai, je me demande pourquoi le statut de publication n'est pas un blocage? Pourquoi les catégories et les tags ne sont-ils pas des blocs? Pourquoi l'extrait n'est-il pas un bloc?

Personnellement, je ne pense pas que ce sont des "blocs" tels que je les comprends car ils ne sont pas contenus, ce sont des informations sur le contenu. Leur emplacement dans l'interface utilisateur est important. La manière dont l'utilisateur interagit avec ces informations est importante.

Certains des post_meta que je crée sont les mêmes.

Je (pense que je vais) aimer Gutenberg et les blocs pour créer des articles et des pages. Mais soit je comprends mal les «blocs», soit le projet a mal compris comment les gens utilisent des données qui ne seront pas adaptées aux «blocs».

Je suis heureux d'avoir clarifié cela et je suis prêt à être convaincu. Mais avoir des blocs comme "la principale méthode pour réfléchir, mettre en page, interagir avec et éditer des données" ne semble pas correspondre aux éléments que je construis dans WordPress.

Et, ramenant cela au problème principal ici, c'est pourquoi je ne pense pas que l'éditeur classique devrait être supprimé du noyau, et c'est pourquoi je ne veux pas que mes utilisateurs activent automatiquement Gutenberg lorsque je les mets à niveau vers la v5. .0.

@rosswintle vous avez parfaitement résumé cela à tous

Ajout de mon +1 pour faire de Gutenberg l'expérience d'édition par défaut pour les nouvelles installations uniquement.

Comme @rosswintle l' a dit, il y a des centaines de milliers de développeurs WP avec des clients qui ne seront pas intéressés à payer le temps de revenir à l'éditeur classique. Laisser les sites existants continuer tels quels (bien sûr, rendre le nouvel éditeur disponible mais aussi revenir en arrière si ce n'est pas comme prévu) et lancer Gutenberg avec de nouvelles installations.

Pensez à tous les propriétaires de petites entreprises avec des sites WP. Des sites qui ont été développés il y a des années et qui marchent bien sans nouveau développement. Soudainement, ces utilisateurs se voient imposer Gutenberg et non seulement ils ont besoin d'apprendre une nouvelle interface (ces utilisateurs peuvent ne pas être très férus de technologie en premier lieu et Gutenberg peut ou non être plus intuitif pour eux), mais cela pourrait empêcher de modifier le contenu de leur site.

Il y a aussi la réputation de WordPress à considérer, où nous essayons toujours de nous débarrasser de l'opinion selon laquelle WP regorge de vulnérabilités de sécurité. @wpmark et moi avons même eu une conversation aléatoire avec quelqu'un plus tôt dans la semaine où l'une des premières choses qu'ils ont mentionnée une fois qu'ils ont su que nous avons développé avec WordPress était "comment sécuriser vos sites".
Existe-t-il un risque que les utilisateurs trouvent leurs sites défectueux ou difficiles à utiliser? Comment cela affectera-t-il la réputation de WP dans les années à venir?

Je pense vraiment que les nouveaux sites devraient être compatibles avec Gutenberg, et cela peut être une fonctionnalité importante qui est criée depuis les toits pendant l'installation de 5 minutes, mais laissez les anciens sites continuer tels quels.

Je ne voulais pas que la question de l'activation de Gutenberg uniquement pour les nouvelles installations se perde dans cette préoccupation également valable concernant la facilité de désactivation. Voici un problème spécifique pour cela https://github.com/WordPress/gutenberg/issues/4423

Veuillez ajouter vos pensées, votes et commentaires à celui-ci. @joffff @wpmark @rosswintle @markkap @dmje

Spot sur @rosswintle.

Gutenberg doit être activé lorsque je déclare son support. La valeur par défaut ici est, encore une fois, à l'envers. Vous obligez les gens à faire un changement pour éviter que les choses ne changent / se cassent (je suis heureux de soulever un problème distinct pour cela si nécessaire).

Je ne pourrais pas être plus d'accord avec cela si j'essayais. Je ne pense pas que les gars et les filles qui poussent Gutenberg comprennent cela.

Juste pour ajouter à ce que Ross a dit du point de vue de l'entreprise (il a bien couvert le petit côté indépendant des choses): les sites que je gère pour une multinationale PLC sont comme des pétroliers. Des changements fondamentaux comme celui-ci prennent beaucoup de temps à être mis en œuvre. Des tests doivent être effectués et même dans ce cas, ils doivent être insérés dans un calendrier de publication hebdomadaire, qui fait partie d'un processus détaillé de révision et d'approbation du code.

Cela va causer un énorme mal de tête pour moi et mon équipe. En fait, il est probable que nous finirons probablement par rester sur 4.9.x jusqu'à ce que nous soyons en mesure de vérifier complètement l'impact de Gutenberg après la sortie du RC final pour 5.0.0. Cela pourrait prendre des semaines, voire des mois. Ce n'est pas une solution miracle.

Je me trouve également un peu confus ici sur la nature des «blocs». C'est probablement une question de terminologie, mais cela implique qu'une ou plusieurs des conditions suivantes sont vraies:

• Il y a un changement de paradigme que j'ai du mal à faire ou j'ai mal compris quelque chose.
• Le nouveau paradigme n'est pas très bien communiqué.
• La manière dont WordPress est utilisé par des développeurs comme moi pour créer des outils de gestion de contenu pour les clients n'est pas bien comprise.
• Les façons dont WordPress est utilisé par des développeurs comme moi pour créer des outils de gestion de contenu pour les clients sont bien comprises et sont ignorées.

Je sens absolument que c'est ce dernier. Je ne doute pas que les membres de l'équipe Gutenberg connaissent et comprennent comment la plupart des développeurs professionnels créent des sites à l'aide de WordPress.

Cependant, cette approche est totalement incompatible en faisant évoluer WordPress vers une approche de création de sites, ce dont Automattic en a besoin pour que WordPress.com continue de rivaliser avec Squarespace, Wix et al.

WordPress ne peut pas être à la fois un constructeur de site et un CMS professionnel. Cela ne peut tout simplement pas être fait. Il a parcouru une ligne fine entre les deux, permettant aux utilisateurs de le déplacer dans les deux sens via des plugins. (Vers une construction de site utilisant Beaver Builder, Divi et al et vers un CMS professionnel avec des plugins comme ACF et CMB). Cependant, il est maintenant clair que le CMS évolue fermement dans la direction des constructeurs de sites. Les sites qui utilisent des champs personnalisés soient damnés.

Enfin, votre point sur les blocs et la base de données est parfait.

Je pense que cela indique de nombreux problèmes que l'équipe WordPress devrait d'abord résoudre avant de regarder des choses comme Gutenberg:

• Mise à jour de la version min de PHP
• Implémentation de données sémantiques natives (via des champs personnalisés) et modification de la structure de la base de données pour en tenir compte.

Pour terminer, les gars de Statamic ont montré comment cela aurait dû être géré avec leur nouveau type de champ Bard. Une interface d'édition optionnelle qui résout les mêmes problèmes que Gutenberg, mais d'une manière beaucoup plus intelligente et moins perturbatrice.

Il ne sert à rien que je répète mes opinions, elles ont déjà été exprimées ci-dessus. Je suis d'accord avec le consensus général - cela devrait être une option envisagée pour permettre à Gutenberg de ne pas être obligatoire dans le passage de 4.x à 5.0.

Comme la plupart des développeurs ici, je dessert un certain nombre de clients, certains très experts en technologie, d'autres pas, mais les pousser dans cette direction, je suppose, ne fera que semer la confusion chez la majorité.

En termes de tout ce qui pourrait casser; du point de vue du client, ils ont déjà créé et dépensé un budget pour la solution fournie, ils n'apprécieront pas qu'ils peuvent avoir besoin d'un autre budget pour le soutien ou pour résoudre des problèmes causés par quelque chose qui n'est pas de leur fait ou de moi.

Entre le développeur / concepteur ou le fournisseur de la solution soigneusement étudiée qui leur a été donnée, le client et le fournisseur, devraient choisir quand activer un tel changement majeur ne pas devoir se conformer à quelque chose d'obligatoire.

Juste pour le jeter là-bas. Bien que WordPress ne suive pas strictement l'approche de gestion des versions sémantique, la version 5.0.0 est un changement radical.

Si Automattic ne veut pas changer sa stratégie concernant Gutenberg - et soyons honnêtes, ce serait la bonne chose à faire - alors la seule autre option est de faire de la 4.9 une version LTS.

De cette façon, les correctifs de sécurité pourraient être appliqués à 4.9 pour les 5 prochaines années, disons. C'est largement le temps pour les développeurs de sites Web de migrer leurs sites vers Gutenberg ou de s'éloigner entièrement de WordPress (ce qui, je suppose, sera l'option la plus populaire).

Eh bien, tout le monde aime bien écrire de longs commentaires ici. 😉 C'est le soir pour moi, donc je ne vais pas tout aborder, mais j'aimerais aborder quelques points.

Pour ma part, je suis très surpris que l'implication ici et ailleurs est que l'éditeur classique sera supprimé de WP et que le plugin "Classic Editor" le rajoutera. Est-ce une compréhension correcte?

Ce n'est pas correct. J'ai mentionné dans mon commentaire précédent que les méta-boîtes et les CPT peuvent revenir automatiquement à l'éditeur classique - ils ne pourraient pas le faire si le code de l'éditeur classique était supprimé. 🙂

TinyMCE est utilisé par Gutenberg pour alimenter les blocs de texte modifiables - cela ne va nulle part. Des fonctions telles que wp_editor() peuvent être relativement facilement maintenues dans Core sans avoir besoin d'être déplacées vers un plugin - je m'attendrais à ce qu'elles continuent à fonctionner indéfiniment.

Votre implication dans ce que vous dites est que les blocs doivent tout conduire. C'est ainsi que les «données du site» seront gérées. Ceci, et d'autres choses que vous avez dites, impliquent que les blocs ne sont pas seulement des sections de contenu, mais une sorte de dispositif d'interface utilisateur qui peut être connecté à n'importe quoi: options du site, personnalisations, métadonnées sur les publications, widgets, menus, champs de profil utilisateur, tout.

C'est exactement ce que je dis. Eh bien, les métadonnées ne sont pas un bloc, bien qu'elles puissent informer sur la façon dont un bloc est utilisé ou affiché.

Je pense donc que nous devons clarifier la nature d'un "blocage".

Sûr. Un bloc est un bloc de HTML qui s'emboîte avec d'autres blocs. Il existe un certain nombre d'API qui rendent le travail avec des blocs agréable et facile, mais c'est à cela qu'il revient.

Un bloc _ n'est pas_:

• Un morceau de HTML stocké dans post_content (bien que certains blocs utilisent cette méthode de stockage).
• Statique (bien que certains blocs le soient).
• Généré dynamiquement (bien que certains autres blocs le soient).

@rosswintle , vous avez mentionné les métadonnées à quelques reprises, et j'aimerais clarifier ce à quoi vous faites référence. Pourriez-vous me donner quelques exemples de ce que vous considérez comme des métadonnées?

Si ce que vous décrivez ici est vrai, je me demande pourquoi le statut de publication n'est pas un blocage? Pourquoi les catégories et les tags ne sont-ils pas des blocs? Pourquoi l'extrait n'est-il pas un bloc?

Juste une suggestion et je ne sais pas si c'est ou devrait être une option de thème, mais pourquoi pas sous add_theme_support () comme la plupart des fonctionnalités nouvellement développées l'ont été dans le passé?

De cette façon, les correctifs de sécurité pourraient être appliqués à 4.9 pour les 5 prochaines années, disons.

Étant donné que WordPress 3.7 a été publié il y a un peu plus de 3 ans et que sa dernière version de sécurité date d'il y a 6 semaines, je pense qu'il est raisonnable de supposer que WordPress 4.9 recevra des correctifs de sécurité pendant longtemps.

@eirichmond : add_theme_support() peut être nécessaire pour le focus de personnalisation de Gutenberg, mais la plupart des thèmes prendront en charge le contenu basé sur l'éditeur de blocs sans aucune modification.

add_theme_support () peut être nécessaire pour le focus de personnalisation de Gutenberg, mais la plupart des thèmes prendront en charge le contenu basé sur l'éditeur de blocs sans aucune modification

@pento Quel est exactement l'objectif de personnalisation de Gutenberg s'il vous plaît? Qu'est-ce que ça veut dire? Vous mentionnez que la plupart des thèmes prendront en charge le contenu basé sur des blocs, pouvez-vous indiquer pourquoi un thème ne le prendrait pas en charge?

Je vois des thèmes avec des barres latérales ne prenant pas en charge certains blocs parce que le bloc indique qu'il s'agit d'une image de couverture pleine largeur, par exemple.

Quel est exactement l'objectif de personnalisation de Gutenberg s'il vous plaît? Qu'est-ce que ça veut dire?

Matt en a parlé dans L'État de la Parole - les trois axes de cette année sont:

• Éditeur Gutenberg
• Personnalisation de Gutenberg
• Thème Gutenberg

L'éditeur Gutenberg est la chose à venir dans WordPress 5.0. La personnalisation de Gutenberg commence à peine à démarrer et examine la personnalisation du site et son fonctionnement dans le paradigme du bloc. Le thème Gutenberg sera le thème par défaut de cette année et sera probablement lancé plus tard dans l'année.

pouvez-vous donc indiquer pourquoi un thème ne le prendrait pas en charge?

Espérons que tous les thèmes fonctionneront. 🙂 Certains blocs sont associés à du CSS (les images de couverture en sont un bon exemple), il est donc possible que quelque chose ne soit pas exactement correct. Il n'y a cependant rien qui empêcherait un thème de fonctionner.

Puis-je rappeler aux gens que Gutenberg n'est pas un projet Automattic, ne dévalorisons pas les efforts et le travail des non-Automatticians qui contribuent

Je ne sais toujours pas pourquoi un plugin est insuffisant, les arguments que j'ai vus soutiennent tous que les gens n'aiment pas Gutenberg, ou qu'ils ont un flux de travail déjà configuré, tous les problèmes qui ont été mentionnés auparavant et tous corrigés en installant et en activant le plugin de l'éditeur classique.

Gardez à l'esprit qu'il existe également un précédent dans le plugin de liens.

Mais de toute façon, soyons constructifs:

J'ai mis à niveau vers WP 5.0 et Gutenberg a remplacé mon éditeur personnalisé / Je ne l'aime pas / J'ai besoin de plus de temps avec les clients

Que fais-je?

Installez le plugin de l'éditeur classique et activez-le, problème résolu. Maintenant, Gutenberg est remplacé par l'éditeur classique que nous avons dans la version 4.9

Des inconvénients?

Vous n'obtiendrez aucune des nouvelles fonctionnalités de Gutenberg, et les nouvelles fonctionnalités à l'avenir pourraient ne pas avoir de sens dans l'éditeur classique. Par exemple, si les blocs de lignes et de colonnes sont arrivés en 5.1, je ne vois pas en quoi cela a du sens dans l'éditeur classique

J'ai beaucoup de sites clients, je n'installe et n'active pas sur tous les sites, que faire si un client se désactive?

Utilisez-le comme un plugin MU:

• Mettez le dossier du plugin dans wp-content/mu-plugins
• Placez un fichier dans votre dossier mu-plugins contenant les éléments suivants:

<?php
require( 'classic-editor/classic-editor.php' );

Maintenant, le plugin est toujours chargé et ne peut pas être désactivé. Aucune étape supplémentaire autre que le placement des fichiers n'est requise. Vous pouvez ensuite télécharger le fichier et le dossier sur chaque site une fois sans avoir à vous en soucier à nouveau.

Leçons du plugin Classic Editor

Il y a beaucoup de fonctions utiles dans ce plugin pour des choses telles que la détection de l'activation de Gutenberg, et l'essentiel consiste à supprimer les hooks et à les remplacer.

Il ajoute même une zone de paramètres avec une option permettant d'activer les `` liens de l'éditeur classique '' afin qu'au lieu de remplacer Gutenberg, vous obteniez ce que vous voyez avec le plugin gutenberg activé du lien `` éditeur classique '' dans l'écran des articles, de sorte que vous donne 3 et non 2 options.

Je recommande fortement aux gens de jeter un œil au plugin, de le tester et de voir comment il est construit.

N'oubliez pas que nous sommes une communauté, pas les sujets d'une équipe produit Automattic. S'il se brise, nous avons tout un cycle de publication de WP pendant lequel le tester et le réparer. Je vois beaucoup de parties prenantes dans ce fil qui ont les compétences techniques pour réparer le plugin et plus encore. Si c'est vraiment un si gros problème, je suis sûr que quelqu'un interviendra, tout comme les personnes travaillant sur le noyau se sont intensifiées

@rosswintle , vous avez mentionné les métadonnées à quelques reprises, et j'aimerais clarifier ce à quoi vous faites référence. Pourriez-vous me donner quelques exemples de ce que vous considérez comme des métadonnées?

@pento Bien sûr:

Exemple de pays:

Un type de publication "Pays" qui a un nom (titre), une description (contenu), puis:

• population
• URL de l'image du drapeau
• classement (et autres facteurs, éventuellement codés d'une manière ou d'une autre)
• "communautés" associées (relations avec des articles d'un autre type)

Voir: http://peoplesunderthreat.org

Exemple immobilier:

Un type de "propriété" qui a:

• prix
• type
• nombre de pièces
• date de construction
  etc.

Exemple d'événement:

Un type "événement" qui a:

• Date
• temps
• détails de récurrence
• emplacement
  etc

Il y a beaucoup de.

Après avoir activé et joué un peu avec, j'ai quelques soucis majeurs ... Je vais me concentrer sur le principal pour l'instant:

WooCommerce casse complètement ... comme si ce n'était même pas là lors de l'édition d'un produit. Et j'imagine que de nombreux autres plugins seront également complètement cassés. Alors, quel est le plan pour aider la communauté à être compatible? Et combien de temps aurons-nous?

@tomjn

les arguments que j'ai vus soutiennent tous que les gens n'aiment pas Gutenberg, ou qu'ils ont déjà un flux de travail configuré

"n'aime pas" est peut-être le mauvais terme. Je pense que les gens avancent de bons arguments pour que Gutenberg ne soit pas adapté à de nombreux cas d'utilisation de WordPress. Ce n'est pas un cas de préférence ou de goût, c'est un cas d'aptitude.

Et les développeurs veulent juste des options pour ce faire. Je peux basculer d'autres fonctionnalités majeures comme le débogage, les éditeurs de code, le multisite, les mises à jour automatiques et les révisions de publication dans wp-config.php. Certaines fonctionnalités ne sont activées que par les thèmes qui les prennent en charge en utilisant add_theme_support . Pourquoi ne pouvons-nous pas avoir d'options dans le code pour basculer Gutenberg de la même manière afin que les développeurs puissent utiliser un flux de travail qui leur convient pour un changement aussi important?

L'un des problèmes ici est que les développeurs (pas nécessairement moi, mais d'autres) ne se sentent pas écoutés car ils expriment des inquiétudes à propos de Gutenberg. Ajouter cela comme un geste symbolique pour les aider vous aiderait à les rallier un peu plus. Même si pour une raison philosophique qui vous est propre, vous n'êtes pas d'accord que ce soit la bonne chose à faire, voyez-le comme une branche d'olivier qui peut être offerte aux développeurs qui ne sont pas heureux.

Gardez à l'esprit qu'il existe également un précédent dans le plugin de liens.

Le plugin links est un mauvais exemple ici. Il a conservé la fonctionnalité existante dans le noyau si vous l'utilisiez et ne supprimait la fonctionnalité que pour les nouvelles installations (ou si vous ne l'utilisiez pas).

J'AIME ce précédent.

C'est ce qui est argumenté dans # 4423

Ce qui me comprend vraiment, c'est que les développeurs principaux et Matt supposent que le monde entier va simplement adopter complètement le concept "Blocks" et l'éditeur Gutenberg sans aucun doute. Je suppose que tout va bien, mais cette approche "à notre façon ou à la haute" qu'ils utilisent avec Gutenberg n'est pas seulement facile à utiliser, mais elle peut sérieusement affecter l'état de WordPress dans son ensemble.

Il y a eu beaucoup de très bonnes idées à travers les âges qui ne sont tout simplement pas restées car elles n'ont tout simplement pas été adoptées par les masses. Betamax était un format bien supérieur, mais il a tout simplement tenu et VHS a gagné. Et si Gutenberg et les blocs ne collent pas? Qu'arrivera-t-il alors à WordPress?

Ensuite, il y a le facteur de confiance. La grande majorité des utilisateurs de WordPress ne comprennent même pas ce qu'est WordPress. Ils l'utilisent simplement parce que la marque WordPress est populaire, et peu importe comment vous le voyez, WordPress pour la plupart des gens n'est qu'une marque. Les marques vivent et meurent par la confiance des consommateurs.

Lorsque la mise à jour 5.0 sera enfin déployée et qu'un million de sites WordPress changeront soudainement la situation, comment vont réagir ces utilisateurs finaux, qui ne suivent rien du monde WordPress?

La plupart de mes clients sont, comme on dit, «à peine capables d'allumer un ordinateur» ou veulent simplement que ce pour quoi ils ont payé fonctionne comme promis. Ce sont ces personnes qui ont fait confiance à WordPress pour faire ce qu'il avait promis de livrer. Si un jour cette promesse est rompue à cause d'un tout nouveau format de gestion du contenu de leur site change soudainement. Ensuite, leur confiance en WordPress sera brisée et les gens vont simplement abandonner quelque chose s'ils ne lui font plus confiance.

C'est, je crois, de là que vient la plupart des préoccupations des développeurs. Nous construisons d'excellents sites WordPress personnalisés qui fonctionnent exactement pour qui nos clients le veulent et maintenant tout va "cassé" à cause de Gutenberg, et nous n'avons aucune option pour éviter ce qui pourrait être un énorme désastre.

Le seul but de Gutenberg est d'augmenter la part de WordPress Marke, mais il peut très facilement faire exactement le contraire. Cela peut en fait éloigner les gens de WordPress. Gutenberg pourrait devenir le nouveau coke pour WordPress, et WordPress n'est pas aussi gros que Coke qu'il pourrait simplement récupérer comme Coke l'a fait. Les gens passeront à autre chose et ne regarderont pas en arrière.

Vous continuez à dire "Cela aurait un impact sur l'avenir de l'adoption de Gutenberg, bla, bla, bla", mais c'est vraiment aussi simple. Soit tout le monde l'adorera et la nécessité de le supprimer soit via le code, soit via un plugin, soit tout ce qui deviendra inutile, soit Gutenberg deviendra simplement une fonctionnalité étrange que personne n'utilise vraiment comme Press This.

Dans l'état actuel des choses, la direction prise sera soit que Gutenberg sera un succès, soit WordPress dans son ensemble pourrait échouer. Nous, les développeurs avec des inquiétudes, essayons seulement de ne pas complètement gâcher un excellent outil de gestion de contenu. Nous savons mieux que quiconque comment nos clients abordent et utilisent WordPress. Les développeurs principaux et Matt ne regardent que les statistiques et les parts de marché, et vous savez ce que cela nous a apporté? Le redémarrage de Ghostbusters.

Nous voulons vraiment travailler avec vous pour que cela se produise, mais il serait préférable que nous puissions contrôler la façon dont cela est introduit dans le monde plutôt que de le forcer à des utilisateurs sans méfiance. Tout ce que nous demandons, c'est un moyen pour nous de faciliter l'intégration de nos clients dans le nouvel éditeur. Ce n'est vraiment pas grand-chose à demander.

Si Gutenberg va vraiment être l'innovation qu'il promettait d'être, alors tant mieux! Tout le monde monte dans le train Gutenberg. Sinon, nous demandons simplement la possibilité de ne pas en faire un énorme désastre.

C'est comme si vous saviez que cela ne sera pas bien reçu et que vous voulez tellement que cela se produise que vous sentez que le seul moyen de réussir est de le forcer à tout le monde. C'est comme la façon dont les politiciens vous disent un mensonge audacieux sur la façon dont une facture fiscale qui profitera à tout le monde pour la faire adopter alors qu'en réalité seuls les super riches en bénéficieront réellement.

C'est comme ce qu'a dit le grand Dr Cox.

Aide-moi à t'aider.Aide-moi à t'aider.Aide-moi à t'aider.Aide-moi à t'aider.

WooCommerce casse complètement ... comme si ce n'était même pas là lors de l'édition d'un produit. Et j'imagine que de nombreux autres plugins seront également complètement cassés. Alors, quel est le plan pour aider la communauté à être compatible?

@ smp303 Ce blog des développeurs

Peut-être une meilleure analogie que "New Coke" est Windows 8.

C'était une nouvelle vision audacieuse pour un état d'esprit informatique plus mobile qui s'est terriblement retourné contre lui parce qu'elle a changé trop d'hypothèses d'utilisation de base. Oui, au plus profond des paramètres, un utilisateur pouvait récupérer une grande partie de son expérience Windows précédente, mais à moins d'être au courant des journaux techniques, les utilisateurs ne savaient pas comment faire cela. Le résultat a été une catastrophe pour Windows.

Gutenberg s'engage très rapidement dans la même voie. Cela fait un changement monstrueux, complètement conduit par l'entreprise et non par la communauté, et il laisse (je suppose, quelques détails à ce sujet que je peux voir) un chemin assez obscur via un plugin externe pour revenir à l'éditeur traditionnel pour ceux-ci. qui n'aiment pas cette nouvelle méthodologie.

Je pense que si Automattic / WordPress ne fournit pas un moyen dans les paramètres de désactiver Gutenberg pour les millions d'utilisateurs occasionnels de WordPress, ils vont le regretter profondément. Gutenberg est un énorme changement. Il y aura BEAUCOUP de recul de la part des utilisateurs.

Dans ce fil, nous essayons de vous mettre en garde contre cela et de vous informer qu'un plugin externe ne sera PAS suffisant. Vous devez fournir aux utilisateurs un "out" à Gutenberg, ne serait-ce que pour leur permettre une période d'ajustement. Si nous pouvons l'activer dans nos thèmes existants via le code, nous pouvons éventuellement éviter une catastrophe.

Nous essayons désespérément d'aider ici. Un plugin externe ne suffira PAS. Une option pour revenir à l'éditeur classique doit être intégrée. Faites-le dans le cadre de la version ou fournissez-nous un moyen de le faire via du code que nous pouvons intégrer à nos thèmes.

D'un point de vue logique, j'essaie de comprendre la philosophie de permettre aux développeurs de déclarer une métabox, dans la fonction add_meta_box () pour NE PAS prendre en charge Gutenberg, ce qui provoque alors l'écran de l'éditeur, partout où cette métabox est utilisée, pour afficher la "version classique" de l'écran de l'éditeur. Pourquoi alors certains développeurs s'opposent-ils à une constante définie dans le fichier wp-config.php? Si je peux déclarer que le truc Gutenberg ne sera PAS utilisé dans une zone de code, pourquoi ne pouvons-nous pas le déclarer pour être utilisé dans d'autres domaines comme nous définissons actuellement des instructions define?

Gardez à l'esprit que pour une constante, le plugin d'éditeur classique devrait être fourni avec WordPress, avec un chargeur personnalisé, et y rester à perpétuité. Il pourrait encore être là dans 10, 15 ans, quand tout ce que Gutenberg est remplacé arrivera.

Même dans ce cas, pour ceux qui ont besoin ou veulent les deux éditeurs, le plugin est toujours nécessaire de toute façon.

N'oubliez pas que vous pouvez toujours installer et configurer le plugin dans la v4.9 en prévision de l'arrivée de Gutenberg.

Je pense que si Automattic / WordPress ne fournit pas

@robmcclel Automattic n'est pas WordPress, WordPress.org! = WordPress.com, l'un est une communauté open source, l'autre est un service tiers payant. Automattic ne publie pas de versions de WordPress, WordPress n'est pas un produit interne d'Automattic, et Gutenberg non plus. Il y a beaucoup de contributeurs non-Automattic, de responsables de publication, etc. qui font des choses en dehors d'Automattic.

«Même dans ce cas, pour ceux qui ont besoin ou veulent les deux éditeurs, le plugin est toujours nécessaire de toute façon.

En fait, d'après ce qui a été discuté ici et ailleurs, si un type de message personnalisé ou une metabox déclare qu'il ne supporte pas gutenberg, l'écran de l'éditeur revient automatiquement ... sans avoir besoin du plugin "Classic Editor". C'est l'un des problèmes que beaucoup ont avec l'état actuel du projet gutenberg, il existe de nombreuses opinions / déclarations sur ce qui se passe dans certaines situations et souvent ces déclarations / opinions diffèrent des autres.

Gardez à l'esprit que pour une constante, le plugin d'éditeur classique devrait être fourni avec WordPress, avec un chargeur personnalisé, et y rester à perpétuité.

@tomjn Attendez! Alors, dites-vous que tout le système de méta-boîtes est en train d'être dépouillé?

Non, je n'ai fait aucune mention des métaboxes. Mais gardez à l'esprit qu'il existe des métaboxes à Gutenberg, suggérer qu'elles sont supprimées implique que vous n'avez pas testé Gutenberg et ignore qu'une grande partie de l'écosystème en dépend. Ce serait un énorme problème pour wordcamp.org, wordpress.org etc.

Pour information, je ne suis pas membre de l'équipe Gutenberg, j'observe et applique simplement le bon sens. Ce n'est pas parce que je travaille chez Automattic que j'ai des pouvoirs spéciaux avec Gutenberg. J'ai autant à dire que tout le monde ici, et si je voulais changer cela, je le ferais en contribuant au code et en réglant les problèmes, comme n'importe qui d'autre.

@tomjn Donc, ce que vous avez dit n'a aucun sens pour moi. L '"éditeur classique" est essentiellement une page d'administration avec des méta-boîtes et des fonctionnalités pour la sauvegarde et autres. Cela signifie que pour pouvoir basculer entre Gutenberg et Classic, il doit y avoir du code intégré dans le noyau qui permettrait les deux options et tout le code de la fonctionnalité Classic resterait en place.

Cela signifierait donc que le plugin Classic ne serait rien d'autre qu'un moyen de déclencher le commutateur. Il semble qu'il serait beaucoup plus facile de simplement créer un élément de type constant ou de support de thème dans le noyau plutôt que d'avoir à créer et à maintenir un plugin.

Si tout pour Classic est toujours dans le noyau, pourquoi créer un plugin juste pour l'activer?

Et si cela devait rester en place. Il existe déjà une tonne de code ancien et obsolète dans le noyau de WordPress. Un déclencheur classique intégré ne ferait pas vraiment de différence dans le grand schéma des choses.

Ne soyons pas malhonnêtes ici Tom. Automattic est vraiment la force motrice derrière Gutenberg. Aucune quantité de «mais ce n'est pas» venant des employés d'Automattic ne changera le fait que c'est aussi évident que le soleil dans le ciel par temps clair.

Gutenberg est vraiment le bébé de Matt; tout comme Automattic. Il a conduit le projet. Il a été sa plus grande pom-pom girl.

Gutenberg présente de sérieux avantages opérationnels pour Automattic - à savoir en lui donnant un produit pour égaliser la sensation de jeu avec ses plus grands concurrents. On ne peut pas en dire autant du reste de la communauté.

Oui, de nombreux utilisateurs de WordPress utilisent des constructeurs de pages via des plugins. Cependant, une autre grande partie fait un usage intensif des champs personnalisés via des plugins comme ACF et CMB (et ses nombreuses fourches). Cette partie de la communauté réclame depuis des années que le projet WordPress implémente des champs personnalisés en tant que fonctionnalité native.

Cependant, cela n'a pas abouti parce que le financement n'a pas été là pour y arriver et chaque fois que cela est évoqué, il a souffert de ce problème si commun de l'open source de débat mort par comité.

De nombreux autres problèmes de presse ont également subi le même sort - comme le passage de la version min-PHP à quelque chose qui n'est pas en fin de vie depuis plus de 7 ans .

Ce ne sont là que quelques exemples de choses qui auraient dû être faites il y a des années et qui n'ont toujours pas été réalisées parce que le principal bailleur de fonds du projet ne l'a pas soutenu.

Automattic a jeté son poids derrière Gutenberg - en grande partie en raison directe du fait que Matt était aux commandes. Un grand nombre d'heures de travail ont été consacrées à en faire une réalité. Cela se traduit par un financement direct du principal bailleur de fonds du projet WordPress - Automattic.

Je ne vois pas en quoi cela est pertinent pour le ticket?

@rosswintle C'est très pertinent. De nombreux développeurs souhaitent un moyen simple de désactiver Gutenberg. Il est assez évident que les pouvoirs à ne veulent pas nous donner cela et rendre aussi gênant que possible la désactivation de Gutenberg.

L'élément moteur de cette décision est le programme de Matt et Automattic pour augmenter leur part de marché dans l'espace du site Web de bricolage. Il est clair que les préoccupations des communautés ne sont pas prises en compte en raison de l'influence de Matt et d'Automattic sur le projet. C'est de là que vient 100% de la frustration des communautés à propos de Gutenberg.

La direction du projet Gutenberg étant largement influencée par Matt et Automattic, elle est pertinente dans cette discussion comme dans toutes les discussions sur le projet.

@tomjn

À partir de Gutenberg et de cette prochaine version, WordPress est un produit d'Automattic. Croire autre chose est une folie. Peu importe .Com ou .Org - le programme WordPress est maintenant un produit d'Automattic. Les développeurs et ceux qui travaillent dessus ne sont plus que des stagiaires non rémunérés pour Automattic.

La communauté veut Gutenberg comme plugin. Matt ne le fait pas. Matt est à la tête d'Automattic. Matt est le responsable auto-désigné de cette version. Les personnes qui dirigent le développement de Gutenberg sont des employés d'Automattic. Matt force ça. Il n'y a pas d'autre décision ou débat - il a 51% des voix et il l'exerce.

Ne vous trompez pas en pensant que WordPress est en quelque sorte un produit démocratique ou communautaire. C'est le produit d'Automattic maintenant, mais il a été conçu ou commercialisé dans le passé, et ils dirigent maintenant l'orientation, le rythme et les décisions de développement.

@rosswintle , cela est pertinent pour le ticket dans la mesure où la communauté demande des méthodes pour désactiver Gutenberg, et l'équipe de Gutenberg répond que le plugin sera le seul moyen de le faire, indépendamment de ce que la communauté en tant que très grand ensemble demande.

Matt et Automattic font valoir leur autorité à ce sujet. Vous pourriez aussi bien fermer ce ticket et tous les autres l'aiment, car notre voix n'est plus pertinente que pour exprimer notre sympathie et nous donner un endroit où nous exprimer. Ce ticket pourrait aussi bien ne pas exister.

Automattic est responsable de cela, pas de la communauté. Nous devons faire face à cela et nous préparer à l'impact, car cela se produit et la seule rampe de sortie est le plugin Classic Editor, et même cela est un peu de charité. Il n'y aura rien d'autre.

Personnellement, je ne vois pas comment discuter de qui prend les décisions ici aide à faire avancer la question. Il est développé en tant que projet open source, ce qui signifie que vous pouvez avoir une voix, et j'encourage les gens à utiliser leur voix de manière constructive en aidant à développer des options et une justification pour la mise en œuvre de ces options.

Le dernier message sur le sujet de la demande était de @tomjn , suivi de quelques questions pertinentes de @wpstudio et @jawittdesigns

Gardez à l'esprit que pour une constante, le plugin d'éditeur classique devrait être fourni avec WordPress, avec un chargeur personnalisé, et y rester à perpétuité. Il pourrait encore être là dans 10, 15 ans, quand tout ce que Gutenberg est remplacé arrivera.

Une constante n'a-t-elle jamais été obsolète? (Véritable question) On dirait que WPLANG était peut-être dans la v4.0? Est-ce une chose philosophique sur la nature des constantes? Un filtre serait-il meilleur? Un filtre serait-il acceptable pour @ smp303 ?

Même dans ce cas, pour ceux qui ont besoin ou veulent les deux éditeurs, le plugin est toujours nécessaire de toute façon.

Pourquoi donc?

@jawittdesigns demande à juste titre:

Si tout pour Classic est toujours dans le noyau, pourquoi créer un plugin juste pour l'activer? Et si cela devait rester en place. Il existe déjà une tonne de code ancien et obsolète dans le noyau de WordPress. Un déclencheur classique intégré ne ferait pas vraiment de différence dans le grand schéma des choses.

et @pento a pratiquement exclu la suppression de la majeure partie de celui -

TinyMCE est utilisé par Gutenberg pour alimenter les blocs de texte modifiables - cela ne va nulle part. Des fonctions telles que wp_editor () peuvent être relativement facilement maintenues dans Core sans avoir besoin d'être déplacées vers un plugin - je m'attendrais à ce qu'elles continuent à fonctionner indéfiniment.

Finalement:

N'oubliez pas que vous pouvez toujours installer et configurer le plugin dans la v4.9 en prévision de l'arrivée de Gutenberg.

Nous en sommes tous conscients. Nous essayons de préconiser différentes méthodes qui offrent des options aux développeurs qui ont des flux de travail différents.

@rosswintle - Il est important d'en discuter, car en fin de compte, savoir qui prend les décisions permet de savoir dans quelle mesure nos demandes sont acceptées et comment les exprimer pour qu'elles soient aussi influentes que possible.

Cependant, oui, vous avez raison en ce que cette question particulière n'est pas le bon endroit pour en discuter. Le refus de bouger sur nos demandes est cependant révélateur du fait que nous sommes dans une position de faiblesse par rapport à ceux qui conduisent la décision.

En tous cas. Vous faites quelques bons points dans le dernier message. En fait, permettez-moi de reprendre votre devis:

Gardez à l'esprit que pour une constante, le plugin d'éditeur classique devrait être fourni avec WordPress, avec un chargeur personnalisé, et y rester à perpétuité. Il pourrait encore être là dans 10, 15 ans, quand tout ce que Gutenberg est remplacé arrivera.

Devons-nous supposer qu'une fois que ce qui remplacera Gutenberg arrivera, nous n'aurons plus la même discussion? Le grand USP de WordPress a toujours été son dévouement à la rétrocompatibilité par rapport à ses concurrents. Cela a bien fonctionné jusqu'à présent. Comme nous l'avons tous souligné, Gutenberg rompt cela. Il y a très peu de choix pour rester avec ce que nous avons maintenant, sauf ce qui est effectivement un piratage officiel sanctionné.

Le fait est que le code est toujours au cœur. C'est une approche beaucoup plus intelligente et plus éligible pour permettre l'utilisation d'une constante - une seule ligne de code - sur un plugin qui devra être maintenu séparément qui finira par être des centaines de lignes de code.

Le fait est que le code est toujours au cœur. C'est une approche beaucoup plus intelligente et plus éligible pour permettre l'utilisation d'une constante - une seule ligne de code - sur un plugin qui devra être maintenu séparément qui finira par être des centaines de lignes de code.

C'est tout à fait mon point ... Ce n'est pas seulement une niche de personnes qui en auront besoin. En raison du fait que Gutenberg actuellement à droite casse une énorme quantité de plugins et de thèmes etc etc ... Un autre plugin n'est pas un correctif, c'est un hack, une dépendance. Ce n'est pas la bonne façon de résoudre un problème qui pourrait finir par chasser un noyau de personnes qui créent les meilleurs sites WordPress.

L'autre option, qui me fait le plus peur, est que les gens s'en tiennent à 4.9 et ne mettent pas à jour les sites. Ceux-ci deviennent alors instables et ouverts au piratage, et font tomber le nom de WordPress.

Je ne pense tout simplement pas que cela ait été suffisamment réfléchi, et donc pourquoi un plugin est la solution finale.

Si TinyMCE va continuer à être "sous" Gutenberg pour certains blocs, alors pourquoi ne pas aborder la situation comme ceci:
La version antérieure à 5.0 (c'est-à-dire les sites actuels alimentés par WordPress) aurait désactivé Gutenberg par défaut avec un filtre / constante facilitant l'activation de Gutenberg.
5.0+ (aka les sites WordPress installés sur et après la version 5.0) aurait Gutenberg activé par défaut avec un filtre / constante facilitant la désactivation.

De cette façon, quiconque souhaite utiliser Gutenberg a plus de facilité à faire ce choix et quiconque n'est pas prêt ou ne veut pas utiliser Gutenberg (pour une raison quelconque) a également un moment facile à faire ce choix. Il apparaît juste parfois que certains veulent prendre position sur la colline de Gutenberg alors qu'il semble y avoir des solutions plus pratiques (à court terme).

@wpstudio C'est à peu près ce que # 4423 demande.

Comme @rosswintle , je pense qu'il est important de remettre ce problème sur les rails pour ceux qui l'ont fait et qui ont satisfait les derniers commentaires. Merci pour ceux qui discutent avec respect.

Il faut dire cependant, quoi que vous pensiez d'une entreprise et de ses motivations, de nombreuses personnes travaillent sur Gutenberg dans de nombreuses entreprises différentes. Tout comme avec WordPress, il s'agit de contributions de la communauté (pas seulement d'une entreprise). Faire des déclarations radicales n'est pas juste pour ceux qui y travaillent. Ce n'est pas non plus juste pour ceux qui ont lancé ce problème et qui veulent une solution.

J'espère que cette question se remettra sur les rails et continuera à débattre respectueusement de ce point.

@karmatosed , @ntwb , @tomjn et d'autres dans ce fil, si mon petit discours ci-dessus a offensé, je m'en excuse. C'est un sujet extrêmement important et qui mérite d'être débattu - si nous voulons effectivement en débattre.

D'après les discussions ci-dessus, je pense qu'il est assez évident que Gutenberg peut être désactivé dans Core, car les autres composants devront rester dans le Core, donc il suffit de désactiver Gutenberg. Ce qui est logique, car il existe actuellement en tant que plugin et de nombreux sites peuvent l'exécuter correctement. Donc, à moins d'une raison technique jusqu'ici non présentée, cela signifie que cette décision n'est pas technique, mais philosophique.

Et c'est le vrai cœur de celui-ci. Je ne pense pas que la communauté dans son ensemble soit du même avis à ce sujet. Pas même proche. C'est pourquoi la décision est placée (remarquez que j'ai dit «placé» et non «blâmé») avec Matt, car il semble être la force motrice derrière cela. Et, apparemment, derrière la décision inébranlable de faire de Gutenberg une partie de Core et de la version 5.0.

La question est "Pourquoi?"

Je peux certainement voir le raisonnement derrière le fait de forcer Gutenberg à être dans Core. Je pense que les "blocs" sont très importants pour la survie future et l'utilisation généralisée de WordPress, .org ou .com. Je fais. Je suis derrière "blocs" à 100%.

Cependant, je ne pense pas que Gutenberg lui-même, en tant que méthode de livraison de ces «blocs», soit un système bien pensé. Rien qu'à partir de ce fil, il existe 3 cas d'utilisation différents (moi, @ smp303 ) et Gutenberg ne semble satisfaire aucun d'entre nous. En effet, cela nous inquiète beaucoup - pour nous, notre entreprise et nos utilisateurs.

La décision de mettre Gutenberg dans Core a du sens pour Automattic car elle oblige chaque développeur de plugins à l'adopter et à réécrire leurs plugins pour travailler avec. C'est très bon pour WordPress.com et, peut-être, bon pour WordPress.org. Mais, encore une fois, certains cas d'utilisation ne bénéficieront pas des blocs, mais j'espère que l'existence de blocs ne leur fera pas de mal non plus.

Cependant, cela signifie qu'un très petit groupe de personnes prend des décisions économiques et commerciales assez puissantes pour un très grand nombre de personnes. Pour moi seul, le passage aux blocs coûtera des centaines d'heures et des milliers de dollars, plus le temps de développement perdu pour devoir retirer des ressources de mes objectifs planifiés (que la communauté que je dessert veut réellement) afin de réviser des sections importantes de mon système pour répondre aux demandes de ces décideurs inconnus (encore une fois, je suppose que Matt est une grande partie de ce groupe de prise de décision).

Je ne me sentirais pas si mal à ce sujet - ou si effrayé, pour être honnête - si Gutenberg résolvait des problèmes pour moi. Mais ce n'est pas le cas. Jusqu'à présent, cela rend ma vie bien pire. Les choses peuvent s'améliorer, mais je ne vois pas de changement radical dans la direction du développement. Il semble que 95% des décisions concernant l'utilisation, la mise en œuvre, l'interface utilisateur / UX, ainsi que les moyens et les méthodes, ont toutes été décidées par un petit groupe d'autres personnes sans trop de débat ni de contribution.

WordPress alimente plus de 25% de tout Internet. Cela se traduit par des millions de sites, des milliards de pages Web et, éventuellement, des centaines de milliards de dollars. Du New York Times à la poignée de blogueurs de livres sur mon réseau. Des sites de commerce électronique massifs aux livres individuels signés vendus par les auteurs que je dessert. C'est énorme - MASSIVE. C'est pratiquement un service public mondial.

Pourtant, la décision de réécrire une partie importante des fondements de tout cela - touchant plusieurs millions de personnes - a apparemment été prise sans débat. Tout, de l'interface à la dépendance à REACT (contrôlé par Facebook qui s'est avéré très prédateur, il suffit de demander à SnapChat). Toutes ces décisions ont été prises, en grande partie, unilatéralement.

S'il ne s'agissait que d'alimenter un module dans JetPack, personne ne s'en soucierait vraiment. C'est l'affaire de WordPress.com. Mais ce n'est pas le cas. Il transforme les fondements de tout Internet.

Ce qui m'amène ici et maintenant. La communauté, certainement les membres de la communauté dans ce fil, demande le contrôle du produit et de l'entreprise qu'ils ont construit en utilisant le code WordPress.org open source et accessible au public. Nous demandons la possibilité de nous protéger et de protéger nos utilisateurs, et la seule façon de le faire est de demander un moyen de désactiver Gutenberg. Nous demandons que cette capacité fasse partie de Core, tout comme l'ajout de Gutenberg signifie faire partie de Core.

La possibilité de désactiver Gutenberg peut-elle être ajoutée à Core? Qui prend cette décision et ordonne aux prospects de le faire? Quel est le mécanisme pour poser cette question? La réponse est-elle à débattre? Sera-t-il mis aux voix? Existe-t-il un processus de commentaires? Si oui, où?

Et, @karmatosed , vous avez raison à 100% en ce que la section "Problèmes" de Github n'est pas le meilleur endroit pour avoir ce débat. Je conviens que ce dépôt devrait être en grande partie laissé à son objectif, qui est d'identifier et de résoudre les problèmes techniques directement liés au plugin Gutenberg.

Malheureusement, il ne semble pas y avoir d'autre endroit pour avoir cette discussion. Je veux dire, il y a la section Avis du plugin Gutenberg, mais c'est un forum assez limité pour ce genre de conversation.

Y aura-t-il un site mis en place pour discuter de Gutenberg? Non seulement sa mise en œuvre, mais pour commenter et discuter de l'interface? Le calendrier de sortie? (Par exemple, quels critères régissent si Gutenberg et WP5.0 sont "terminés" et prêts à être publiés? Qui prend cette décision? ") Y aura-t-il un test utilisateur de l'interface Gutenberg? Existe-t-il un moyen de recueillir des données et des commentaires de @ " tomjn est très utile? Si oui, ces données seront-elles publiées?

Il y avait une vidéo intéressante sur YouTube demandant aux gens d'essayer d'utiliser Gutenberg et d'évaluer son intuitivité (lien ici: https://youtu.be/7iWRBLCP-l0) - y en a-t-il d'autres comme ça? Existe-t-il un effort à grande échelle pour tester Gutenberg? Si oui, où ces données sont-elles conservées? Comment ces données sont-elles partagées? La communauté peut-elle le voir? Est-il utilisé pour piloter la conception?

Le problème auquel nous sommes maintenant confrontés avec Gutenberg - et c'est en fait la force motrice derrière ce fil conducteur - est que la communauté se sent très isolée de ce processus. Nous avons l'impression que cela nous arrive. En effet, cela nous est imposé. Ouvrir le processus pour les commentaires et les débats, permettre de nouvelles voix et idées sur des choses comme l'interface, le partage de données et les idées des utilisateurs, contribuerait grandement à atténuer ces craintes et ces préoccupations.

Et faire des blocs une capacité de base, tout en conservant Gutenberg en tant que plugin, pourrait rendre tout beaucoup moins effrayant et beaucoup plus acceptable pour la communauté dans son ensemble. J'adorerais ça, personnellement. Donnez à la communauté le temps d'explorer et de développer des approches alternatives à Gutenberg - différentes interfaces et cas d'utilisation - tout en encourageant le développement et l'avenir des blocs.

Donc, c'était assez long, mais encore une fois, où en sommes-nous pour avoir ce débat en dehors d'ici? Et, ce débat est TRÈS important. C'est peut-être la discussion la plus importante sur Internet à l'heure actuelle, compte tenu du nombre de personnes et d'entreprises concernées.

Après avoir fait un peu de recherche à ce sujet, il semblerait que tout ce dont vous avez besoin, dans un fichier mu-plugin est le suivant pour désactiver Gutenberg avec du code, à moins que j'aie manqué quelque chose - ce qui est probable!

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

Pour le contexte, j'ai le plugin Gutenberg actif et le code ci-dessus dans un fichier dans le dossier mu-plugins . Désormais, tous les écrans de publication utilisent l'éditeur classique.

Quelques points à noter à ce sujet:

• gutenberg_can_edit_post_type n'est pas le nom final du filtre - gutenberg noms seront renommés avant d'être fusionnés dans Core.
• Ce filtre signifie simplement "ne pas charger l'éditeur de blocs", cela ne signifie pas "utiliser l'éditeur classique". Cela fonctionne pour le moment, mais il n'est pas garanti que cela fonctionnera à l'avenir. Lorsque le code spécifique à Classic (par exemple, edit-form-advanced.php ) est déplacé vers le plugin Classic Editor, il cessera de revenir à l'éditeur classique et attendra explicitement que vous chargiez votre propre éditeur.

@rosswintle : reprise du fil de la semaine dernière :

La façon la plus simple d'y penser est "si les données apparaissent entre <body> et </body> , c'est un contenu et finalement rentreront dans un bloc". Pour WordPress 5.0, c'est un peu plus limité - seul ce qui se situe entre <article> et </article> est des blocs. 😉

Donc, pour prendre un exemple, un type de publication Immobilier. Le prix est stocké dans postmeta, mais c'est contenu. Vous pourriez avoir un bloc appelé "Property Lede", il a quelques éléments à remplir - le prix, l'adresse, le type de bâtiment, le nombre de chambres / salles de bains / garages, ce genre de choses. Vous aurez probablement d' autres blocs, trop - Inspections Times, Caractéristiques, Photos, Plans d' étage, agent, etc. En utilisant des modèles de blocs , vous configurez l'éditeur de blocs de sorte que lorsque la property est en cours de modification de type poste, les blocs sont déjà localisés et ne peuvent pas être déplacés. Le flux de travail pour l'utilisateur final n'est pas différent de ce à quoi ressemble un flux de travail basé sur une métabox existante, mais il ressemble beaucoup plus à la sortie finale.

C'était un peu long, mais j'espère que cela définit la scène - tout ce qui ressemble à du contenu _est_ du contenu, quel que soit l'endroit où les données sont stockées, ou comment elles peuvent être manipulées ou formatées avant d'être affichées sur le frontend. Certains blocs peuvent stocker leurs données dans post_content , mais ce n'est pas la caractéristique déterminante de ce qui les rend contenu - l'affichage sur le frontend est ce qui les rend contenu.

Alors qu'en est-il des informations qui ne sont pas affichées sur le front-end? Le nom du propriétaire? Des relations avec la visualisation des rendez-vous? Est-ce «contenu»? Cela doit-il être inscrit dans un "bloc"?

Les catégories / étiquettes / taxonomies peuvent ou non être affichées sur le front-end. Sont-ils des "blocs"?

L'état de la publication peut être affiché sur le front-end, mais ce n'est certainement pas un blocage.

Vous avez dit précédemment:

Les métadonnées ne sont pas un bloc, bien qu'elles puissent informer sur la manière dont un bloc est utilisé ou affiché.

Ce qui est bien. Mais pourquoi, alors, dit-on aux développeurs qu'à l'avenir, les métadonnées devraient être modifiées à l'aide de l'interface de bloc?

C'est la vraie confusion pour moi. Je comprends pourquoi les blocs de Gutenberg sont bons pour éditer ce qui se trouve entre les balises body , mais je ne comprends pas pourquoi les blocs sont bons pour éditer d'autres données qui ne sont pas entre ces balises.

Il me semble que c'est cette confusion qui pousse les développeurs à vouloir désactiver Gutenberg. Certaines de nos utilisations de WordPress ont BEAUCOUP d'informations qui ne sont pas affichées dans le front-end et pourtant, on nous dit qu'à l'avenir, un éditeur front-end est ce que nous devrions utiliser comme interface pour ces données.

J'espère que cela communique la confusion.

Alors à propos de ces façons de le désactiver ...?

@pento le bloc doc pour cette fonction n'indique pas du tout que ce filtre est temporaire:

/**
 * Filter to allow plugins to enable/disable Gutenberg for particular post types.
 *
 * <strong i="7">@since</strong> 1.5.2
 *
 * <strong i="8">@param</strong> bool   $can_edit  Whether the post type can be edited or not.
 * <strong i="9">@param</strong> string $post_type The post type being checked.
 */

Quel est le but de ce filtre sinon de faire comme décrit?

De plus @pento à ce sujet:

Ce filtre signifie simplement "ne pas charger l'éditeur de blocs", cela ne signifie pas "utiliser l'éditeur classique". Cela fonctionne pour le moment, mais il n'est pas garanti que cela fonctionnera à l'avenir. Lorsque le code spécifique à Classic (par exemple, edit-form-advanced.php) est déplacé vers le plugin Classic Editor, il cessera de revenir à l'éditeur classique et s'attendra explicitement à ce que vous chargiez votre propre éditeur.

On nous a dit à plusieurs reprises que si les types de publication déclarent show_in_rest => false ou qu'une méta-boîte sur l'écran d'édition de publication déclare '__block_editor_compatible_meta_box' => false, , alors l'éditeur classique sera chargé. Il semble que vous disiez ci-dessus que cela ne fera pas partie du noyau et comment cela peut-il être le cas si vous n'avez pas activé le plugin de l'éditeur classique?

Pour revenir à l'éditeur Classic, est-ce que quelque chose est détecté qui ne prend pas en charge Gutenberg, alors l'éditeur Classic doit sûrement rester une partie du noyau - donc nous n'avons sûrement pas besoin du plugin pour invoquer cette fonctionnalité?

Alors qu'en est-il des informations qui ne sont pas affichées sur le front-end? Le nom du propriétaire? Des relations avec la visualisation des rendez-vous? Est-ce «contenu»? Cela doit-il être inscrit dans un "bloc"?

Bien sûr, il y a aussi de la place pour les méta-informations - c'est discuté dans # 3330. La principale chose que je voulais noter est qu'une grande partie de ce que l'on appelle «méta-données» est en fait du contenu.

Les catégories / étiquettes / taxonomies peuvent ou non être affichées sur le front-end. Sont-ils des "blocs"?

Eh bien, ils sont méta pour le message, mais peut-être du contenu sur le site. Le focus de personnalisation de Gutenberg inclura probablement un bloc qui utilise ces métadonnées pour produire du contenu. 🙂 Il est peu probable qu'un bloc dans l'éditeur de blocs les utilise comme contenu, c'est pourquoi les taxonomies sont dans la barre latérale, pas dans un bloc.

Ce qui est bien. Mais pourquoi, alors, dit-on aux développeurs qu'à l'avenir, les métadonnées devraient être modifiées à l'aide de l'interface de bloc?

Nous ne disons pas que toutes les métadonnées s'insèrent dans l'interface de bloc. Certains pourraient, mais ils ne sont pas obligés de le faire. Le fait est que la plupart des utilisations existantes des méta-boîtes s'intègrent dans l'interface de bloc, le moyen le plus simple de les distinguer est de se demander si elles sont affichées ou non sur le front-end. Le n ° 3330 aborde plus en détail les concepts d'édition des métadonnées.

Je peux catégoriquement vous dire que les métadonnées _ne pas_ n'ont pas besoin d'être modifiées dans l'interface de l'éditeur de blocs. Si ce n'est pas du contenu ou s'il ne se rapporte pas d'une manière ou d'une autre au contenu, il n'y appartient pas - il existe d'autres endroits pour insérer l'interface pour éditer ces métadonnées.

Alors à propos de ces façons de le désactiver ...?

Si vous créez des sites, utilisez le plugin Classic Editor. Si vous créez des plugins, utilisez les indicateurs de compatibilité CPT et meta box. 🙂

Si vous créez des sites, utilisez le plugin Classic Editor. Si vous créez des plugins, utilisez les indicateurs de compatibilité CPT et meta box. 🙂

C'est parfait pour les sites que nous construisons à l'avenir, ou pour les clients que nous avons "sur les livres" et que nous nous occupons de leurs sites. Cependant, qu'en est-il des clients dont les sites que nous avons construits dans le passé et qui fonctionnent correctement, la mise à jour automatique, etc. Ils cliqueront probablement sur la mise à jour vers WordPress v5.0.

Ces sites n'auront pas le plugin Classic Editor installé et ils n'auront aucun indicateur sur ces méta-boîtes / CPT car ils ont été codés lorsque Gutenberg n'était pas là. Ces sites vont avoir des problèmes et laisser leurs propriétaires confus et franchement assez ennuyés. Veuillez me corriger si je me trompe ici.

@wpmark l'a cloué.

J'utiliserai le plugin Classic Editor si j'en ai besoin à l'avenir. J'utiliserai les drapeaux CPT et meta box compat si j'en ai besoin à l'avenir. Mais j'ai des dizaines de particuliers, d'entreprises et d'organisations caritatives / à but non lucratif de toutes formes et tailles pour lesquelles j'ai déjà créé des sites. Certains d'entre eux avec lesquels j'ai encore des relations de travail. D'autres ont évolué et ne font qu'exécuter le site eux-mêmes, ou travaillent avec un autre développeur ou aucun développeur du tout.

Il n'est pas réaliste de s'attendre à des changements de code ou à une installation de plug-in sur chaque site qui en a besoin.

C'est vraiment le territoire # 4423.

Pour toutes les conversations importantes, ce billet n'a pas d'étiquette ni de propriétaire. Si cela ne se produit pas, est-il utile de le garder ouvert?

gutenberg_can_edit_post_type (ou quel que soit son nom dans Core) et '__block_editor_compatible_meta_box' => false reviendront à l'interface classique de WordPress 5.0. Cependant, les futures versions de WordPress pourraient changer ce comportement.

gutenberg_can_edit_post_type indique uniquement s'il faut charger l'éditeur de blocs ou non. Pour l'instant, le comportement par défaut lorsque vous ne chargez pas l'éditeur de blocs est de charger Classic, mais l'hypothèse de ce filtre est que, si vous ne chargez pas l'éditeur de blocs, vous fournissez votre propre interface. Cela pourrait être le plugin Classic Editor, cela pourrait être une interface personnalisée. Mais il est probable qu'une future version de WordPRess verra que le code classique sera déplacé vers l'éditeur classique.

Une situation similaire existe pour l'indicateur __block_editor_compatible_meta_box . Il revient à l'interface classique pour le moment, mais une future version de WordPress pourrait voir le comportement par défaut changé pour rester dans l'éditeur de blocs et afficher un avertissement à l'emplacement de la méta-boîte.

Bien sûr, aucun de ces changements ne se produira sans à la fois de recherche et de contact avec les propriétaires de sites - mon point est que ces paramètres existent principalement dans le but de passer à Gutenberg. Le plugin Classic Editor est l'option stable pour forcer l'utilisation de l'interface Classic.

Voir # 3902 pour plus de discussion sur ces questions.

Sur le thème de l'information des propriétaires de sites, WordPress 5.0 ne sortira pas dans le vide. Il existe de nombreux outils que nous pouvons utiliser pour informer les propriétaires de sites des changements à venir et pour leur faire savoir si leur site fonctionnera ou non. Les futures versions de WordPress 4.9.x incluront des informations sur l'éditeur de blocs , des plans sont en cours pour collecter des données sur la compatibilité des plugins (à la fois automatisés et collectés - # 4072), et nous sommes ouverts à d'autres options pour nous assurer que les propriétaires de sites sont au courant. ce qui s'en vient.

Pour toutes les conversations importantes, ce billet n'a pas d'étiquette ni de propriétaire. Si cela ne se produit pas, est-il utile de le garder ouvert?

Je n'ai eu aucun problème à le garder ouvert pendant que nous avions cette discussion, mais à ce stade, je ne vois pas la nécessité de le garder ouvert plus. Pour répondre à la question d'origine, une option basée sur le code pour revenir à l'éditeur classique n'est pas sur les cartes.

@pento Pourquoi avez-vous fermé ça? Le problème n'a pas encore été résolu.

Vous prouvez simplement que la communauté n'est pas écoutée en fermant ceci.

Je pense vraiment que vous devriez le rouvrir, afin que nous puissions parvenir à une résolution à ce sujet.

La résolution était non - ils ne permettront pas de désactiver Gutenberg dans le code. Vous devez vous fier à un plugin.

Complètement mécontent et insatisfait de cela, mais au moins j'ai essayé.

La résolution était non - ils ne permettront pas de désactiver Gutenberg dans le code. Vous devez vous fier à un plugin.

Où et quand est-ce arrivé? Il n'y a aucune mention d'une décision ici.

Ou est-ce juste la réaction typique de l'équipe de base en faisant semblant d'écouter puis en la fermant simplement?

Quel type de résolution voulez-vous à ce stade?

Si vous souhaitez désactiver Gutenberg à l'aide d'une constante, cela ne se produira pas. Nous avons été écoutés et l'idée a été rejetée.

Je n'ai eu aucun problème à le garder ouvert pendant que nous avions cette discussion, mais à ce stade, je ne vois pas la nécessité de le garder ouvert plus. Pour répondre à la question d'origine, une option basée sur le code pour revenir à l'éditeur classique n'est pas sur les cartes.

De @pento - c'est pourquoi il a fermé

Eh bien, j'espère qu'ils publient au moins le plugin avant la mise à jour afin que nous puissions l'installer et l'activer afin que l'expérience utilisateur ne soit pas perturbée.

Je veux dire que le support de la méta-box est toujours cassé en 2.0 et je ne suis pas vraiment convaincu que cela fonctionnera un jour.

Le plugin existe déjà: https://wordpress.org/plugins/classic-editor/

Pour répondre à la question initiale de @ smp303 .

1. Dans wp-config.php, ajoutez

define( 'ENABLE_GUTENBERG', false );

1. Dans un fichier appelé my-hacks.php dans le dossier mu-plugins , dans lequel vous devrez peut-être créer du code

<?php // (C) Bobbing Wide 2015-2018
if ( defined( "ENABLE_GUTENBERG" ) && !ENABLE_GUTENBERG ) {
    add_filter( 'gutenberg_can_edit_post_type', '__return_false' ); 
}   

accessoires @tomjn @wpmark

Vous pouvez le faire aujourd'hui sans avoir installé Gutenberg ou l'éditeur classique.
Mais soyez averti que le nom du filtre peut changer lorsque le code est fusionné dans core.
... à quel point quelqu'un rédigera des documents, puis vous pourrez ajouter une autre ligne.

Notes: Le fichier nommé my-hacks.php été introduit en 2003 et obsolète dans 200x.
Mais rien ne vous empêche de l'implémenter en tant que plugin incontournable dans mu-plugins .

Si vous voulez voir à quel point il est difficile de supprimer le code obsolète, y compris le champ d'option qui lui est associé
voir WordPress TRAC # 33741 - Supprimer les références à my-hacks.php et l'option hack_file

Encore plus facile ... dans wp-config.php

$_GET['classic-editor'] = true;

Je pense que le concept de bloc est faux. À mon avis, un bloc devrait être un poste. Donc, si nous avons besoin de plusieurs contenus dans un article, nous devons pouvoir avoir des articles enfants. Comme Twitter, où une page est composée de nombreux tweets indépendants.

À l'intérieur d'un article, nous avons juste besoin d'un éditeur de texte.

Nous n'avons pas de budget pour faire une mise à jour de toutes nos pages. Si wp n'offre pas de compatibilité à long terme, nous allons simplement changer à l'avenir pour une communauté plus stable car la porte serait ouverte à de nouvelles entreprises.

Maintenant, wordpress est cool à cause de la communauté. 5.0 signifie commencer à partir de 0. Donc, comme tout autre framework.

Deux axes de développement pourraient être une bonne idée au lieu de désactiver ou non. WP normal et WP Gutenberg. Au moins pour les 5 prochaines années. Ensuite, Gutenberg aurait le temps d'être stable et d'avoir une communauté aussi, tout comme WP.

Ce serait bien si beaucoup d'entre vous en tant que développeurs ont un problème, pourquoi ne pas simplement entrer et continuer
Github avec un ticket qui propose une méthode de travail pour résoudre votre problème plutôt que d'écrire sans fin pourquoi vous ne pouvez pas aider à construire une solution avec le projet Gutenberg actuel.

Apportez vos compétences en programmation pour aider à résoudre le problème.

Je suis un concepteur visuel et je planifie actuellement d'aider deux de mes clients à déplacer les processus d'édition vers Gutenberg et je suis actuellement en train de concevoir et de créer un nouveau site pour un client avec un site vieux de plus de vingt ans qu'il ne peut pas maintenir.

Participez et aidez à faire avancer WordPress.org en tant qu'outil de création de site.

@TomDesign avez-vous même essayé de lire la discussion? L'équipe GB ne veut pas que la fonctionnalité fasse partie du plugin, donc à moins que dans "Apportez vos compétences en programmation pour aider à résoudre le problème" vous voulez dire que quelqu'un devrait pirater ses comptes pour ajouter un code qu'il ne veut pas, je ne sais pas comment écrire du code est même à distance pertinent ici.

@tomdesign J'ai soulevé l'exigence d'avoir un plan de migration viable dans # 4981
J'ai souligné que ce sera beaucoup de travail. Et c'est quelque chose que j'estime nécessaire.

Je suis sûr que de nombreux développeurs aimeraient pouvoir utiliser nos compétences en programmation pour assurer une migration en douceur. Mais nous ne voulons pas perdre notre temps à développer quelque chose qui sera rejeté d'emblée. À mon avis, la migration mérite un projet à part entière, chaque exigence étant évaluée logiquement. C'est assez important pour avoir une proposition bien documentée qui nous y mènera à long terme.

La demande initiale de Simon était une solution à court terme à un problème à long terme.
Je pense que le processus de migration de contenu durera des années.

Salut les gars,
En lisant les commentaires, je pense que c'est le bon endroit pour partager un bon plugin sur Gutenberg.
Je voudrais vous présenter un plugin gratuit qui vous permet de gérer l'éditeur Gutenberg.
Il s'appelle Gutenberg Manager et vous permet d'activer / désactiver l'éditeur dans les différents types d'articles (pages et articles inclus). Il a plus de fonctionnalités mais je vous les laisse.

Nous avons lu des tonnes de messages de personnes se plaignant de la future implémentation de Gutenberg dans le noyau de WP 5.0 et cela nous a conduit à trouver une solution simple.

Gutenberg Manager résout ce problème et permet par exemple de continuer à utiliser Elementor, Visual Composer, Siteorigin Builder ou Cornerstone sans aucun problème même après WP 5.0.
Dès les premiers commentaires des utilisateurs sur WP.org, le plugin semble être apprécié :)

Pour cette raison, je voudrais vous présenter Gutenberg Manager -> https://wordpress.org/plugins/manager-for-gutenberg/

Le plugin peut être utilisé par les développeurs dans leurs propres thèmes et plugins grâce à quelques hooks utiles. Il y a un crochet pour HIDE le panneau d'options du plugin afin que l'utilisateur final ne le voie pas dans WP backend (excellente fonctionnalité pour les développeurs qui souhaitent inclure Gutenberg Manager dans leurs projets).

Nous prenons également des dispositions avec les équipes des constructeurs les plus connus pour activer des partenariats et des collaborations. De cette façon, nous espérons rendre la transition vers Gutenberg un peu moins traumatisante!

Merci à tous pour votre attention,
Bon travail.

@unCommonsTeam puis-je vous demander comment vous désactivez l'éditeur Gutenberg dans le plugin, lorsque par exemple ces options sont sélectionnées dans votre écran de paramètres?

Bien sûr @wpmark ,

jetez un œil sur la ligne 79 -> https://github.com/unCommonsTeam/gutenberg-manager/blob/master/inc/core.php

Meilleur

@unCommonsTeam merci d'être revenu vers moi. Je me trompe probablement ici, mais après avoir l'air, il semble que le plugin supprime simplement toutes les choses ajoutées par le plugin Gutenberg. C'est quelque chose que j'ai suggéré ci-dessus en utilisant:

add_filter( 'gutenberg_can_edit_post_type', '__return_false' );

Cependant, @pento a été informé que ce n'était pas une solution robuste car il remet un éditeur dans WordPress. Voir https://github.com/WordPress/gutenberg/issues/4409#issuecomment -357912790

@wpmark oui cette fonction supprime toutes les choses ajoutées par le plugin Gutenberg mais la fonction n'est appelée que dans des pages backend spécifiques pas pour tous les backend .. Par exemple si vous décidez de désactiver l'éditeur Gutenberg dans les pages mais que vous voulez l'utiliser dans les posts .. Donc je pense que c'est acceptable.

Meilleur

@unCommonsTeam cela ressemble à un excellent plugin, mais je pense qu'il souffrirait des mêmes problèmes que ma solution, en ce sens qu'il a vraiment besoin de rajouter un éditeur dans WordPress.

D'après ce que @pento disait, c'est que la suppression des ajouts de Gutenberg indique seulement que l'éditeur de blocs n'est pas souhaité, mais vous devez le remplacer par quelque chose - ce que fait le plugin d'éditeur classique.

Comme l'a dit @pento :

Ce filtre signifie simplement "ne pas charger l'éditeur de blocs", cela ne signifie pas "utiliser l'éditeur classique". Cela fonctionne pour le moment, mais il n'est pas garanti que cela fonctionnera à l'avenir.

Par conséquent, je pense (et je suis bien sûr corrigé) que votre plugin fait la même chose (mais bien sûr beaucoup mieux et avec beaucoup d'options intéressantes pour la flexibilité, etc.) que ma tentative ci-dessus.

Une autre chose à laquelle je pensais est le nom de Gutenberg qui traînera lorsque le projet sera fusionné dans le noyau, ou par exemple, ces fonctions (par exemple gutenberg_init ) vont-elles être renommées (par exemple) block_editor_init .

@wpmark vous avez raison. Nous espérons que dans WP 5, ils y laisseront l'éditeur classique. Cependant, nous pourrions essayer d'ajouter une option pour inclure l'éditeur classique via le plugin. Si l'équipe de développement de WP décide de supprimer l'éditeur classique, nous pensons que notre plugin deviendra vraiment populaire :)

À propos de la dénomination de gutenberg, vous avez raison, nous devrons probablement réparer notre plugin en remplaçant les noms des hooks.

De plus, notre plugin offrira d'autres fonctionnalités basées sur l'éditeur Gutenberg (activer / désactiver des blocs spécifiques, de nouveaux blocs, etc.). Nous pensons donc que cela sera également utile pour les personnes qui utilisent l'éditeur Gutenberg.

À votre santé

Cela peut être une bonne idée qui réglera presque toute la bousculade et le débat:

Si Gutenberg est désactivé par défaut dans le noyau, ainsi que l'éditeur classique toujours maintenu, cela pourrait économiser environ 1 milliard de dollars sur le marché des thèmes et des plugins WordPress et sur une vaste étendue d'Internet, beaucoup de problèmes, de pertes financières, d'incidents de support, ainsi que d'économiser beaucoup WP. de prestige et de perte de confiance en tant que plate-forme.

Gutenberg, bien qu'un éditeur plus moderne, semble être conçu pour les besoins de WordPress.com et des points de vente similaires qui fournissent des services de blogs / d'hébergement utilisant WordPress. Tout cela est bien et bien. Cependant, cela ne devrait pas conduire à un choc et un coup de pied dans les balles au reste de l'écosystème. Une vaste partie d'Internet, les sites Web des gens, leurs moyens de subsistance vont être affectés par la direction actuelle.

WordPress.com peut activer la valeur par défaut de Gutenberg, tandis que WP est désactivé par défaut, offrant ainsi le meilleur des mondes à tout l'écosystème.

Je suis d'accord avec codebard, que gutenberg soit désactivé par défaut et que l'éditeur classique continue d'être maintenu. Les mises à jour automatiques sont actuellement désactivées précisément pour cette raison - je ne veux pas que les blogueurs de mon réseau multisite se voient soudainement présenter ce type d'éditeur de type "constructeur de pages", et je ne veux certainement pas que l'éditeur classique soit complètement remplacé avec gutenberg.

À tout le moins, nous devrions pouvoir désactiver gutenberg avec une instruction de définition telle que define ('DISABLE_GUTENBERG', true); Un gros problème avec le fait d'avoir un plugin pour désactiver gutenberg est que nous serions alors dépendants du développeur pour maintenir et mettre à jour le plugin, si nécessaire. Que ferions-nous pendant les jours ou les semaines où le plugin cesse de fonctionner parce que le développeur est en vacances ou trop occupé pour mettre à jour le plugin. Il y a aussi le problème que les personnes utilisant le plugin devront mettre à jour le plugin de leur côté.

Il semble que nous forcer gutenberg et ensuite trouver des solutions de contournement pour le désactiver après coup est une façon vraiment rétrograde de faire les choses. Veuillez désactiver gutenberg par défaut. Beaucoup d'entre nous qui veulent juste un blog simple ont de plus en plus de mal à utiliser wordpress car il semble évoluer vers un constructeur de site Web.

Une autre note, dans le cas des réseaux multisites, l'administrateur du réseau devrait être en mesure de décider si gutenberg doit être mis à disposition sur le réseau.

@WebTrooper le plugin Classic Editor est maintenu par l'équipe de développeurs WordPress (les mêmes personnes qui maintiennent Core) et Gutenberg Ramp est maintenu par Automattic, donc les deux devraient être immunisés contre les facteurs «développeur en vacances» ou «trop occupé».

Notez que VIP a un engagement envers le plugin Gutenberg Ramp, qui est utilisé sur le site de nos clients et nos propres sites. Être en vacances ou trop occupé en cas de panne pourrait signifier des sites clients endommagés, ce qui est la dernière chose que souhaite VIP.

Je voudrais également noter que ces plugins peuvent être forkés, Automattic et les auteurs et du plugin d'édition classique ne possèdent aucune connaissance secrète qui leur a permis de construire ces plugins, ni ne sont techniquement volumineux ou complexes. Il existe des centaines d'agences à travers le monde avec des développeurs capables de gérer l'un ou l'autre des plugins.

En passant, beaucoup de gens plaident pour la désactivation de gutenberg par défaut, mais j'ai remarqué, quels que soient les mérites de ces arguments, ils échouent tous à dire quand exactement GB devrait être activé par défaut. La conclusion logique est une situation d'éditeur classique perpétuelle.

Il est 2934, l'empire galactique a sauté dans le système, 300 croiseurs de combat. Le réseau de nouvelles planétaires local a lancé l'éditeur classique pour rédiger un rapport pour les habitants locaux. Personne ne leur a parlé de Gutenberg avant de commencer à construire le site

J'ai toujours suggéré qu'il soit activé par défaut pour les NOUVELLES installations.

Mais pour les installations existantes, je suggérerais une approche dirigée par l'utilisateur, permettant aux gens d'accepter Gutenberg, de l'essayer, de le conserver s'ils l'aiment et de revenir à l'éditeur classique s'ils ne le font pas. WordPress pourrait alors collecter des statistiques et des commentaires si / quand les gens reviennent pour aider au développement et à la documentation du changement.

Lorsqu'une certaine masse critique de sites actifs avec elle est atteinte, vous pouvez l'activer par défaut. Et non, je ne vais pas choisir un numéro dans l'air. Mais nous pourrions mesurer l'utilisation et agir de manière appropriée.

Sinon, le 12 avril 2020 fera l'affaire. 😉

Cela se produit pour les anciennes versions de PHP, non? WordPress a été infatigable dans sa rétrocompatibilité de PHP 5.2 parce que les gens l'utilisent toujours, dans de nombreux cas probablement sans le savoir ou s'en soucier. WordPress analyse attentivement les statistiques; mettre beaucoup d'efforts dans la coordination avec les hôtes et ainsi de suite; et guider doucement les gens sur un chemin de mise à niveau. Et vraisemblablement, le projet agira, à un moment donné, sur les données d'utilisation dont il dispose pour prendre une décision.

Pourtant, avec une toute nouvelle interface utilisateur pour l'édition, quels utilisateurs connaissent et se soucient de l'approche, c'est leur imposer?

Même si je commence à défendre Gutenberg dans certains cas, j'espère vraiment que la proposition de fusion prend en compte les préoccupations de personnes comme moi qui gèrent de nombreux sites pour les utilisateurs finaux, dont beaucoup ont de faibles compétences informatiques pas confiant avec la technologie, et sera confus et désorienté par Gutenberg.

Je pense que Gutenberg devrait également être désactivé pour les NOUVELLES installations, pour les raisons importantes ci-dessous:

• Il existe une quantité presque infinie de tutoriels, de ressources, de procédures et de tout ce que vous pouvez imaginer, tous basés sur l'éditeur existant. Ceux-ci rendent l'entrée de personnes sur WordPress TRÈS facile.

• Cette facilité d'entrée est très importante, car comme ils commencent si facilement comme ça, les gens comprennent que `` WordPress est facile '', et ont facilement une perception chaleureuse de la plate-forme, une attitude plus acceptante et confiante pour l'apprendre davantage.

• Tout cela se combine dans la perception de `` WordPress fonctionne juste '', et ils le recommandent confortablement à leurs pairs. C'est ainsi que nous avons pu nous développer pour englober 30% d'Internet.

• La cohérence des informations est importante. Et il est impossible que chacune des ressources sur Internet soit mise à jour pour refléter Gutenberg, même à l'avenir. Cela créera beaucoup de confusion. Et le plus malheureusement, la réaction de l'utilisateur ordinaire sera «Je l'ai installé, mais ça NE FONCTIONNE PAS», simplement parce qu'il ne trouve pas comment faire les choses et que les choses ne ressemblent pas au didacticiel qu'il utilise. Ne vous y trompez pas, aucun effort de mise à jour ne dissipera cette confusion concernant les ressources, les didacticiels, etc.

Par conséquent, Gutenberg devrait être facultatif et pouvoir basculer pour conserver la `` compatibilité ascendante '' non seulement en termes de thèmes, de plugins de contenu existants créés par le constructeur de pages, etc., mais également en termes de ressources que nous avons en ligne. Une plate-forme n'est pas `` si facile '' et vous ne pouvez pas la recommander aux gens qui disent `` installez-la simplement et google ... '' alors que Google propose de nombreuses ressources obsolètes et à jour différentes. Et si vous avez une expérience de référencement, vous savez que ce sera ...

Avec Gutenberg, nous pouvons exploiter le marché prétendument en hausse du «constructeur de sites» (wix, squarespace, etc.) et le marché potentiel du «blog facile» (à la moyenne, etc.) Mais, si nous cassons ne serait-ce qu'une fraction de 30% d'Internet ou du marché des thèmes / plugins d'environ 1 milliard de dollars, ce sera un coup de pied massif et massif dont nous ne pourrons peut-être pas nous remettre dans une décennie.

Vous ne pouvez pas installer un plugin PHP classique, donc la comparaison avec PHP n'est pas pertinente, ce sont des millions de sites dont la rupture serait garantie, sans solution basée sur WP qui résoudrait cela, d'où une analyse minutieuse. Gardez également à l'esprit que la prochaine version a une invite qui installe le plugin classique, les utilisateurs ne sont pas seulement invités à installer le plugin Gutenberg.

Quoi qu'il en soit, cette question a été close, des décisions ont été prises. Un problème clos est un mauvais endroit pour essayer de changer une approche planifiée ailleurs.

Mais gardez à l'esprit que Gutenberg peut basculer, il existe des plugins pour l'activer et le désactiver. Cela fait des années que GB a été lancé, avec beaucoup de temps pour tester jusqu'à présent, du temps pour former les clients, du temps pour installer le plugin d'éditeur classique, etc. Ce n'est pas quelque chose de nouveau qui est imposé aux gens du jour au lendemain.

J'ai remarqué, quels que soient les mérites de ces arguments, ils échouent tous à dire quand exactement GB devrait être activé par défaut.

Et, semble-t-il, même si les personnes qui font ces arguments avaient fait des suggestions sur le moment où cela devrait se produire, cela serait de toute façon rejeté. Alors pourquoi en parler?

Je sais comment fonctionnent les tickets fermés. Vous avez fait un aparté assez sarcastique ici. J'ai donc essayé de proposer quelque chose de constructif en réponse.

@tomjn Je ferai écho à @rosswintle ici en disant oui, nous avons suggéré qu'il ne devrait être activé que pour les nouvelles installations par défaut - https://github.com/WordPress/gutenberg/issues/4423. C'est une autre question fermée, close sans réelle discussion sur le point.

Ils ne veulent pas écouter, il y a un plugin, bla bla bla, c'est fermé. Ne bougez rien à voir ici. Tout est au sujet du .com personne ne se soucie de .org il n'y a pas d'argent pour Automatic là-bas.

@ smp303 pouvez-vous identifier qui ils sont?

@rosswintle Aucun sarcasme n'était prévu, Gutenberg 0.1.0 est sorti il ​​y a 14 mois, et le seul moyen d'éviter que les sites fonctionnant sous 5.2 ne se cassent est de les soutenir et d'essayer de les mettre à niveau. Les sites dont l'écran d'édition de publication romprait avec Gutenberg peuvent installer le plugin d'éditeur classique sans nécessiter de changements au niveau du serveur, la comparaison n'est pas juste

Ils ne veulent pas écouter, il y a un plugin, bla bla bla, c'est fermé. Ne bougez rien à voir ici. Tout est au sujet du .com personne ne se soucie de .org il n'y a pas d'argent pour Automatic là-bas.

Je suis d'accord. Que ce soit ici ou dans le forum de support WordPress, il semble qu'ils ne s'en soucient pas du tout, même si de nombreuses personnes de la communauté sont contre cela. Puisque WordPress est une source ouverte, j'aimerais suggérer à quiconque de créer une pétition à ce sujet. Je pense personnellement et je suggère que GB devrait être un plugin comme Jetpack plutôt que de le fusionner dans le noyau.

Sur la note latérale: @karmatosed Puisque vous ne pouvez pas répondre et répondre à ma question à l'un des commentaires du forum WordPress concernant Gutenberg, je me demande pourquoi mon commentaire disparaît soudainement. Bon mouvement!

Ce fil de discussion a pris un tour de la discussion sur les raisons pour lesquelles il n'y a pas d'option basée sur le code pour désactiver Gutenberg, en attaques personnelles implicites ou directes à partir de comptes sockpuppet.

J'apprécie que certaines personnes se sentent assez passionnées par ce sujet, et il est regrettable que ce fil soit passé par là, mais la décision ne va pas changer.

Le plugin Classic Editor est la possibilité de revenir à l'éditeur classique sur l'ensemble d'un site. Il est annoncé en bonne place dans la prochaine version de WordPress 4.9.8 en tant qu'option à installer maintenant, en préparation de WordPress 5.0.

Si vous êtes un constructeur de site qui souhaite exclure vos clients de l'éditeur de blocs, l'installation du plugin Classic Editor (et la contribution avec des rapports de bogues ou des correctifs ) est la meilleure solution à long terme pour garantir que l'éditeur classique continuera d'être disponible.

Pour les métaboxes, il est déjà possible de désactiver l'éditeur de blocs , cette API sera fusionnée dans Core. Pour les CPT, le filtre gutenberg_can_edit_post_type sera renommé lors de sa fusion (probablement en block_editor_can_edit_post_type , ou quelque chose de ce genre), mais sera également disponible en tant qu'option basée sur le code.

Pour éviter que ce fil ne devienne plus important, je vais le verrouiller.

Toutes les personnes impliquées dans cette discussion sont absolument les bienvenues pour continuer à participer à la préparation de Gutenberg pour WordPress 5.0, mais n'oubliez pas que les attaques personnelles ne sont absolument pas les bienvenues et entraîneront le verrouillage de problèmes ou l'interdiction de comptes.