FWIW lorsque j'ai parlé aux développeurs Web, ils utilisent tous des métaboxes pour le contenu afin qu'ils aient un contrôle maximal. Je ne suis pas sûr que les métaboxes seront considérées comme un «héritage» pour beaucoup de gens mais plutôt comme faisant partie de l'avenir. Cela pourrait valoir la peine de contacter les personnalités VIP de WordPress pour obtenir leur avis.

Je ne suis pas sûr que les métaboxes seront considérées comme un «héritage» pour beaucoup de gens mais plutôt comme faisant partie de l'avenir. Cela pourrait valoir la peine de contacter les personnalités VIP de WordPress pour obtenir leur avis.

Mes excuses, cette formulation était mauvaise. Les métabox sont là pour rester. C'est pourquoi la barre latérale metabox reçoit une mise à jour sous la forme de la nouvelle barre latérale "Paramètres de publication".

Ce que je voulais dire, c'est que les nouvelles métaboxes devraient être écrites en JS et apparaîtront dans la barre latérale Paramètres de publication à côté de celles d'origine. Les métaboxes écrites en PHP devraient idéalement être mises à niveau pour être JS, mais devraient continuer à fonctionner également sous leur forme PHP. C'est à cela que sert le panneau "Paramètres étendus", et il se trouve au bas non pas parce que nous ne voulons pas qu'ils fassent partie de la barre latérale, mais plutôt qu'il est très difficile de mélanger les métaboxes PHP et JS dans une barre latérale.

La soumission de métabox gérées par PHP via JS et Ajax pose de gros défis, en particulier dans la gestion de la mise à jour du rendu de la métabox pour refléter l'état nouvellement enregistré: https://core.trac.wordpress.org/ticket/7756

Je me demande si l'intégration d'une métabox héritée via une iframe pourrait être une solution ici, où l'iframe src est quelque chose comme /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings et ne renvoie que cette métabox dans le document.

Ce que je voulais dire, c'est que les nouvelles métaboxes devraient être écrites en JS et apparaîtront dans la barre latérale Paramètres de publication à côté de celles d'origine.

Cela signifie-t-il que les métabox JavaScript ne peuvent aller que dans la barre latérale et ne peuvent pas faire partie de la section "Paramètres étendus"? Juste du haut de ma tête, je peux penser à de nombreux plugins où la barre latérale ne fournira pas vraiment assez d'espace et rendra la barre latérale potentiellement encombrée. Juste quelques plugins qui pourraient avoir des problèmes avec cette approche:

• Yoast SEO: fournit un grand nombre de champs, qui ne rentreront probablement pas dans la barre latérale - pourrait peut-être avoir une métabox de la barre latérale qui ouvrait un modal pour plus d'options, mais cela ressemble à contourner une limitation inutile

• Plugins de champ personnalisés / générateurs de pages par glisser-déposer - ceux-ci remplacent ou remplacent partiellement la zone de contenu principale et ont donc besoin de beaucoup d'espace d'écran. Le potentiel des constructeurs de pages complètes les justifie de créer leur propre interface totalement personnalisée en tant que vue séparée, mais dans certains cas, un certain nombre de champs supplémentaires structurés sont requis en plus de la zone de contenu principale (et j'apprécie que Guttenburg devrait réduire le besoin de ces types de plugin, mais il ne peut pas non plus couvrir tous les cas d'utilisation)

• WooCommerce - ajoute des métabox pour les données de commande et d'élément de campagne, tout en supprimant l'éditeur principal (Woo prévoit de créer éventuellement sa propre interface personnalisée, mais je soupçonne que c'est loin, et d'autres plugins seront dans une situation similaire)

(Je suppose que Guttenburg est prévu de remplacer à terme les vues post-new / post-edit.php actuelles, plutôt que d'être simplement une alternative?)

Ha merci @braders - Yoast UX-er

Notre metabox est en effet assez grande et large en ce moment, car elle fait beaucoup de choses. Cela ne nous dérangerait pas de travailler davantage ces fonctionnalités dans les différentes métaboxes de la barre latérale pour offrir une intégration plus étroite, mais je me demandais si cela serait possible? Par exemple, pouvons-nous ajouter des scores SEO à la boîte de publication comme nous le faisons actuellement? Et sinon, pouvons-nous toujours nous connecter à la boîte de paramètres étendus même si notre métabox est codée en JS?

Nous devons absolument chercher à rendre les nouveaux paramètres de publication enfichables, afin que vous puissiez ajouter des métabox javascript à la barre latérale. Il est peut-être temps d'ouvrir un ticket pour cela. Ce ticket est principalement destiné aux métaboxes écrites en PHP, qui doivent fonctionner de manière transitoire.

Dans le même esprit que les métaboxes de la section étendue, y a-t-il eu des discussions ou des maquettes sur la façon dont un type de publication qui ne prend pas en charge l'édition de contenu de publication serait présenté? Dans ces cas, les métaboxes dans la zone médiane sont utilisées pour l'expérience d'édition principale. Gutenberg devrait-il présenter un mode "Titre uniquement"? Ou le titre du message devrait-il être traité différemment en l'absence de l'éditeur.

Dans le même esprit que les métaboxes de la section étendue, y a-t-il eu des discussions ou des maquettes sur la façon dont un type de publication qui ne prend pas en charge l'édition de contenu de publication serait présenté? Dans ces cas, les métaboxes dans la zone médiane sont utilisées pour l'expérience d'édition principale. Gutenberg devrait-il présenter un mode "Titre uniquement"? Ou le titre du message devrait-il être traité différemment en l'absence de l'éditeur.

Ce serait bien de créer un ticket séparé pour! Avec des captures d'écran du type de publication existant, si vous l'avez! ✨

Je tiens également à souligner que de nombreux plugins utilisent des types de publication personnalisés qui reposent sur des méta-boîtes sans aucun éditeur de contenu. Si le type de publication est enregistré sans prise en charge de editor , il devrait y avoir un mode de titre uniquement qui ouvre le canevas complet pour une utilisation par les méta-boîtes.

+1 pour contacter WordPress VIP. C'est également un problème sur le fil Calypso: https://github.com/Automattic/wp-calypso/issues/587

Fonctionnalité vraiment importante pour le haut du marché!

Je me demande si l'intégration d'une métabox héritée via une iframe pourrait être une solution ici, où l'iframe src est quelque chose comme /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings et ne renvoie que cette métabox dans le document.

J'ai eu cette même idée aussi. C'est également une bonne idée pour des raisons de sandboxing et de gestion de session. Ensuite, nous pouvons identifier les cas d'utilisation courants de cette fonctionnalité et implémenter une API pour les gérer.

Je voulais devenir développeur de plugins et utiliser WordPress principalement comme outil de commerce électronique. Aussi parce que

J'ai fatigué Gutenberg aujourd'hui et je ne peux littéralement pas traiter cela comme étant WordPress sans voir comment les métaboxes et les boutons de l'éditeur (ajoutés via le crochet media_buttons) en font partie.

Je ne suis pas non plus un grand fan de l'état actuel de l'éditeur WordPress et de la metabox-palooza. Je viens de compter et dans le téléchargement (type de publication de produit de Easy Digital Download), je dispose de 14 méta-boîtes personnalisées ajoutées par Yoast, Easy Digital Downloads et mon propre code personnalisé à l'aide de CMB2. C'est beaucoup, mais j'en ai besoin. WordPress est assez inutile sans cette interface et ce qu'elle expose.

Je crains que cela n'ait pas été pris en compte depuis le début car j'ai travaillé sur tant de sites où l'interface des champs personnalisés ajoutée avec ACF, Pods, CMB2, etc. était toute l'expérience d'édition.

Voici mes préoccupations techniques:
1) Boutons ajoutés via les media_buttons. Dans mon plugin Caldera Forms (80K + installations actives), nous utilisons cette action pour ajouter un bouton d'insertion de formulaire qui fait apparaître un modal pour insérer le shortcode dans l'éditeur de publication. Peut-être que nous passerions à un bloc personnalisé à Gutenberg.
2) Comment l'action save_post reste-t-elle compatible avec les versions antérieures? Tant de plugins, de thèmes et de code personnalisé se connectent à save_action et accèdent à $ _POST super global. Ce n'est pas une bonne conception, mais c'est une dette technique qui affecte des millions de sites.
3) Il a été suggéré de rendre les métabox héritées dans un iFrame. Cela m'inquiète car accéder au contenu d'un iFrame via JavaScript n'est pas possible.

@ Shelob9 salut!

Il y avait une suggestion pour rendre les métabox héritées dans un iFrame. Cela m'inquiète car accéder au contenu d'un iFrame via JavaScript n'est pas possible.

Accéder au contenu d'une iframe via JavaScript _est_ possible, à condition qu'il se trouve sur le même domaine, comme ils le seraient dans ce cas.

Comment l'action save_post reste-t-elle compatible avec les versions antérieures? Tant de plugins, de thèmes et de code personnalisé se connectent à save_action et accèdent à $ _POST super global. Ce n'est pas une bonne conception, mais c'est une dette technique qui affecte des millions de sites.

Nous ne pouvons pas faire grand-chose pour faciliter la transition des anciennes métaboxes vers Gutenberg. Il y a une différence fondamentale dans la façon dont les données sont modélisées dans Gutenberg par rapport à l'écran d'édition actuel. C'est-à-dire que les données sont désormais modélisées pour la première fois. Avec la modélisation de données, nous pouvons enfin utiliser des interfaces JavaScript pour manipuler l'état des articles et postmeta de manière impossible en utilisant $_POST et l'action save_post , sans parler de la possibilité de _prévoir_ les modifications apportées à postmeta. En acheminant les modifications postmeta dans le modèle, cela permettra de prévisualiser postmeta pour la première fois. Ainsi, même si Gutenberg peut inclure des métabox héritées dans la mesure du possible, elles seront toujours intrinsèquement limitées dans la mesure où elles peuvent tirer parti de la nouvelle interface. Je pense que c'est autant une réalité que la réalité que nous avons une dette technique.

Je pense que c'est la décision intentionnelle et consciente de Matt que la dette technique doit être annulée si WordPress veut évoluer de manière à rester pertinent à l'avenir. Plus nous pouvons mettre à jour ACF, Pods et CMB2 pour utiliser le modèle de données introduit par Gutenberg, plus cette transition sera facile, je pense. Il y aura sans aucun doute beaucoup de défis et de travail acharné à venir!

@westonruter merci qui rend le but de la zone Paramètres étendus beaucoup plus clair.

Je soupçonne qu'une partie de la discussion ici porte également en partie sur l'immobilier d'écran disponible.

Il semble que les métaboxes Gutenberg JS peuvent accéder à la barre latérale à bascule (ce qui me convient) tandis que les métaboxes PHP héritées ont accès à la zone beaucoup plus large disponible en bas de l'écran (ce qui me convient également).

Malheureusement, je m'attends à ce que ce désir d'espace d'écran disponible puisse interférer avec la discussion prévue sur la façon de gérer efficacement les métaboxes PHP héritées.

Je conviens qu'au lieu de prendre en charge toutes les anciennes méthodes, les fabricants de plugins devraient reconsidérer leurs métaboxes et comment ils peuvent mieux s'intégrer à la nouvelle mise en page. Dans le même temps, je suis également d'accord pour que des possibilités d'intégration similaires soient également offertes dans le nouvel éditeur (et j'espère qu'elles le seront). Je crois que # 1352 est le principal endroit pour en discuter actuellement. Ce problème concerne la manière dont nous fournirons une compatibilité descendante pour les métaboxes PHP non mises à jour au lancement.

Je me demande si l'intégration d'une métabox héritée via une iframe pourrait être une solution ici

Accéder aux iframes n'est pas une expérience super excitante pour les utilisateurs de lecteurs d'écran. D'autres options?

Je voulais juste faire un carillon ici, la barre latérale n'est tout simplement pas assez grande pour la plupart des méta-boîtes que nous voyons dans les plugins et les thèmes. Nous forcer à entasser des choses dans ce petit espace est à mon avis un revers. Je pense que ce nouvel éditeur est génial, mais pas si cela signifie sacrifier la façon dont nous utilisons les méta-boîtes aujourd'hui.

Je suis tout à fait d'accord avec @kevinpmiller . Les métabox ont besoin de beaucoup de biens immobiliers et ne peuvent pas être cachés dans une barre latérale. L'état actuel des métaboxes est disjoint et de mauvaise conception, mais ils reflètent également ce qu'est WordPress - un CMS hautement extensible.

En réponse à @westonruter, merci d'avoir clarifié la compatibilité descendante. Je pense que cela doit être TRÈS clair que WordPress 5.0 ou ailleurs, n'est pas rétrocompatible puisque c'est ce que les utilisateurs attendent.

Je suis également préoccupé par la façon dont les métaboxes seront gérées, en particulier dans certains types de publication personnalisés où l'éditeur de contenu peut ne pas être le principal objectif du CPT. Je vais choisir WooCommerce ici car c'est un plugin bien connu, mais il y a beaucoup d'autres plugins et thèmes qui ont des problèmes similaires.

Par exemple, les commandes WooCommerce n'ont pas d'éditeur de contenu - ce n'est tout simplement pas nécessaire. Les détails sur la commande sont ce qui est important, pas l'édition du contenu, et devraient à juste titre être l'objectif principal de cette page.

Les CPT comme celui-ci auront-ils la possibilité de supprimer l'éditeur s'il n'est pas nécessaire? Le plugin ne semble pas être complètement intégré aux métabox personnalisées dans les CPT, il est donc difficile de dire si cela a été pris en compte ou non.

Les produits WooCommerce soulèvent également un autre problème où il y a deux zones de contenu - une pour la description du produit et une autre pour la brève description du produit. Faudra-t-il que l'un ait la priorité sur l'autre dans la zone d'édition "principale", tandis que l'autre reste bloqué dans la barre latérale? Cela semble être une expérience d'édition moins qu'optimale pour celui qui se trouve dans la barre latérale.

Peut-il y avoir une option pour enregistrer intentionnellement ces paramètres dans la zone ci-dessous (ou au-dessus?) De l'éditeur plutôt que de les entasser tous dans la barre latérale? Cela pourrait être similaire aux paramètres de contexte et de priorité actuels add_meta_box . Peut-être même basculer entre plusieurs éditeurs de contenu (ou d'autres métaboxes) appartenant à la section la plus large de la page.

Il me manque peut-être quelque chose ici (veuillez me corriger si je me trompe), mais il semble qu'une énorme poussée soit faite pour un meilleur éditeur alors qu'en réalité, toutes les utilisations de WordPress ne nécessitent pas quelque chose de différent de ce qui est utilisé aujourd'hui.

QUESTION comment définissons-nous un CPT pour ne pas utiliser Gutenberg (l'équivalent de l'absence d'éditeur), et afficher UNIQUEMENT les métaboxes pleine largeur sur lesquelles s'appuient nos entreprises.
Je compte sur les métaboxes. Le plus souvent, mes CPT ressemblent à ceci
'supports' => array( 'title' )
Et sont prolongés à partir de là. Veuillez considérer ceux d'entre nous qui ont construit des outils commerciaux pour les clients utilisant des CPT avec des métaboxes comme une saisie de données de formulaire contrainte et guidée, plutôt que pour la rédaction d'articles.
Mon travail consiste principalement en des extensions personnalisées de CMB2 qui s'interfacent avec les systèmes clients. Annonces immobilières EG qui font appel à des systèmes tiers.

Je ne veux pas paraître dramatique, mais je resterai sur WP4.9 jusqu'à ce que cela soit résolu et je suis très préoccupé par l'avenir. Je comprends que Gutenberg "annule la dette envers le passé"! Mais la dette incombe à des gens comme moi.

Le thème ici semble être que le problème n'est pas avec Guttenburg, mais plutôt avec le manque de compatibilité ascendante.

Il y a quelques problèmes réels de Guttenburg, pour lesquels des tickets séparés devraient éventuellement être soulevés (autorisez les métaboxes à utiliser une maquette de Guttenburg pleine largeur sans prise en charge de l'éditeur), mais Gutturnberg ne peut pas totalement reproduire les écrans actuels et ne devrait pas non plus essayer IMHO.

Cependant, je me demande s'il faut faire plus pour rendre Guttenburg opt-in / opt-out. Quelques idées:

• Je suppose que la plupart des CPT actuels utilisent beaucoup les métaboxes par rapport à l'éditeur principal. Alors peut-être que les auteurs de plugins devraient opter pour Gutturnberg avec 'supports' => array( 'gutenburg' ) ou similaire

• Pour les articles et les pages, Guttenburg devrait peut-être être facultatif en tant que paramètre de site. Il serait même possible de demander aux utilisateurs s'ils souhaitent utiliser Guttenburg après la mise à jour 5.0 et de stocker ce choix dans la base de données.

• Ou bien, les thèmes pourraient déclarer la prise en charge via post_type_supports (), mais cela pourrait sérieusement nuire à l'adoption - ou les thèmes pourraient être désactivés qui n'aideraient pas les utilisateurs de thèmes hérités et non maintenus qui ne sont plus mis à jour. (Peut-être qu'un plugin remove-guttenburn serait suffisant pour les utilisateurs de thèmes hérités?)

Mais, quelle que soit l'implémentation, je pense que la vue actuelle devrait rester, même si elle est de plus en plus cachée à la majorité des utilisateurs ...

J'aime l'idée théorique des CPT demandant explicitement 'supports' => array( 'gutenberg' ) pour maintenir les fonctionnalités existantes dans le cas où l'indicateur de support 'gutenberg' n'est pas défini. Cela me permettrait d'économiser beaucoup de travail pour réparer d'anciens sites pour les clients en colère qui ont mis à jour vers WP5.

Je note que les fonctionnalités existantes 'supports' => (titre, éditeur, auteur, ...) ont des noms très auto-descriptifs, Gutenberg se distingue comme un nom de _projet_ ici. Je me demande si un nom de fonction plus descriptif serait envisagé pour cette utilisation; peut-être "éditeur de blocs"? 'supports' => array( 'block-editor' )

Bien sûr, il faudrait une stratégie pour attraper des erreurs telles que 'supports' => array( 'title','editor',thumbnail', 'block-editor' ) . Je suppose que le drapeau «éditeur de blocs» remplacerait simplement l'ancien mode «éditeur».

Un autre développeur de plugin ici avec des préoccupations.

Si la méta de la barre latérale n'est accessible que via JS, qu'est-ce que cela signifie pour les métaboxes enregistrées en PHP avec un contexte de side ? Déplacer ceux-ci vers la section Paramètres étendus proposée révoque l'idée que ces métaboxes sont contextuelles.

Comme nous le savons tous, les barres latérales ne sont pas seulement une bonne décision de conception; ils détiennent souvent un contenu relationnel d'une manière qui aide l'utilisateur à comprendre la priorité de son contenu et la relation avec le contenu principal. Assigner à une métabox side un contexte différent en raison d'une barrière technique semble un peu malavisé.

Compte tenu de la JS-ification progressive de la zone d'administration, ces métaboxes "héritées" fournissent également aux développeurs de plugins et de thèmes un point de montage naturel pour les applications autonomes React / Vue / autres pour fournir des fonctionnalités supplémentaires à la page d'édition.

L'éditeur a fière allure, mais n'oubliez pas le reste de la page.

J'ai eu l'occasion d'y réfléchir un peu plus et avec un contexte partagé par d'autres ici, je pense qu'il y a encore un autre problème. Ce nouvel éditeur nous oblige à une mise en page et un flux de travail uniques; pourquoi supprimons-nous la personnalisation? La possibilité de sculpter la saisie de données par client est ce qui rend WordPress et la plupart des autres solutions vraiment géniales. Plus je joue avec cet éditeur, plus cela ressemble à une version gonflée du Customizer où la zone d'aperçu a été remplacée par un éditeur et la barre latérale vient de changer de côté.

Il a également été mentionné que nous pourrions l'utiliser pour écrire des articles, mais permettre aux CPT d'ajouter une prise en charge pour cela. Je ne pense pas que cela fonctionnera vraiment non plus. Les organisations de presse aimeraient ce type d'éditeur, mais ont également besoin de flux de travail personnalisés autour du contenu supplémentaire, de la planification, des intégrations, des infographies et d'autres données nécessaires.

Pourquoi ne pas faire en sorte que cet éditeur se comporte comme un éditeur plein écran / sans distraction? De cette façon, nous pourrions avoir le meilleur des deux mondes sans sacrifier la fonctionnalité et le code «hérité». (BTW - Je pense qu'il est ridicule que la façon dont nous construisons actuellement des méta-boîtes soit maintenant appelée "héritage ..." dans ce projet).

Merci pour votre temps les gars, c'est apprécié.

Pourquoi ne pas faire en sorte que cet éditeur se comporte comme un éditeur plein écran / sans distraction?

+1

Je vais réitérer ma principale préoccupation: les CPT ne nécessitent souvent pas `` l'éditeur '' car le message est construit à partir de métaboxes volumineuses et groupées dynamiquement dans un flux de travail utilisateur guidé (par exemple, les données de produit WooCommerce).

De telles métaboxes ne rentreront pas dans le tiroir "Paramètres étendus" proposé car elles forment des éléments d'entrée de contenu principal et doivent être visibles dans l'éditeur de publication, en pleine largeur et ouvertes. Dans cet esprit, # 952 semble une trop petite concession car il relègue la saisie de données importantes dans un tiroir fermé.

Si nous, les développeurs, devons _refactoriser_ toutes nos anciennes solutions de métabox en blocs, alors quelqu'un d'Automaticc doit le déclarer clairement et publiquement avant que le marteau ne tombe en 5.0. Je ne vois aucun signe que l'équipe ait pris en compte cette partie du marché et ses implications pour les entreprises.

Beaucoup de bonnes pensées ont déjà été ajoutées ici, alors je vais juste ajouter ces simples pensées:

Au lieu d'avoir un expanseur "Paramètres étendus" en bas pour tous les éléments hérités, pourquoi ne pas simplement créer un expanseur pour chaque métabox qui repose exactement comme ça en bas, lorsque la métabox est dans les contextes normal et avancé, puis utilisez les paramètres latéraux pour le contexte latéral?

Il ne semble pas que nous soyons si loin d'une solution. Et si le type de publication ne prend pas en charge l'éditeur, masquez simplement l'éditeur mais faites en sorte que tout le reste s'affiche de la même manière. C'est une mise en page raisonnable. Donnez simplement des options telles que la définition de la métabox étendue par défaut.

Cela ne me dérange certainement pas de considérer la méthode actuelle de restitution de l'héritage des métaboxes et de fournir une nouvelle méthode privilégiée et basée sur js pour créer les champs. On peut alors basculer progressivement sans avoir à paniquer à propos des ruptures immédiates en 5.0.

J'espère que ces pensées vous aideront. Si quelqu'un d'autre a déjà dit quelque chose à cet effet, prenez cela comme un accord. 😄

J'aimerais ajouter deux autres hooks précieux à la discussion: edit_form_after_title et edit_form_after_editor qui offrent actuellement un contrôle complet sur l'interface utilisateur post-édition. De toute évidence, Gutenberg n'est pas seulement un remplaçant pour "wp_editor", c'est une vision complètement différente de l'interface utilisateur (et comme elle le semble actuellement, sa future évolutivité modulaire).

Je vois que des problèmes comme celui-ci tentent de résoudre le problème, mais je pense qu'il ne s'agit pas de "ce qui arrive à nos métaboxes", mais plutôt de savoir où WordPress se dirige en tant que "produit".

Il est facile de repérer l'objectif à moyen terme d'établir une telle solution: il sera assez facile de la déplacer vers le frontend (et peut-être de se rapprocher de certains concurrents).

Du point de vue des développeurs / des affaires / de la planification, il serait utile de comprendre l'intention (future) de «Gutenberg», ou quelqu'un peut-il m'indiquer un tel énoncé de mission ou quelque chose de similaire?

Quelques autres opinions de ma part ...

Je note que les fonctionnalités existantes 'supports' => (titre, éditeur, auteur, ...) ont des noms très auto-descriptifs, Gutenberg se distingue ici comme un nom de projet. Je me demande si un nom de fonction plus descriptif serait envisagé pour cette utilisation; peut-être "éditeur de blocs"? 'supports' => array ('éditeur de blocs')

Je suis d'accord - cela ressemble à un détail qui peut être trié une fois l'approche approuvée 😄

Bien sûr, il faudrait une stratégie pour attraper les erreurs telles que «supports» => array («titre», «éditeur», vignette »,« éditeur de blocs »). Je suppose que le drapeau «éditeur de blocs» remplacerait simplement l'ancien mode «éditeur».

Je verrais Gutenberg étendre les supports de type de publication actuels - donc s'il n'y avait pas editor support

Au lieu d'avoir un expanseur "Paramètres étendus" en bas pour tous les éléments hérités, pourquoi ne pas simplement créer un expanseur pour chaque métabox qui repose exactement comme ça en bas, lorsque la métabox est dans les contextes normal et avancé, puis utilisez les paramètres latéraux pour le contexte latéral?

J'aime personnellement cette idée - Si ces panneaux pouvaient être réorganisés et cachés comme c'est possible pour le moment, cela pourrait être une solution d'idée ...

Eventuellement, il devrait également y avoir un moyen de définir un (ou plusieurs?) Ou ceux-ci comme étant ouverts au chargement de la page - surtout si le type de publication ne prend pas en charge l'éditeur principal.

Il a également été mentionné que nous pourrions l'utiliser pour écrire des articles, mais permettre aux CPT d'ajouter une prise en charge pour cela. Je ne pense pas que cela fonctionnera vraiment non plus. Les organisations de presse aimeraient ce type d'éditeur, mais ont également besoin de flux de travail personnalisés autour du contenu supplémentaire, de la planification, des intégrations, des infographies et d'autres données nécessaires.

Si le nouvel écran basé sur les réactions est aussi plugable que les anciens écrans d'édition, il n'y a aucune raison pour que ces flux de travail personnalisés ne puissent pas être ajoutés en haut de la page / barre latérale / sous l'éditeur ou ailleurs sur la page. (Avertissement: je n'ai pas une compréhension approfondie de React, il reste donc à voir à quel point les hooks seront plus complexes en dehors de PHP). Aussi # 1352

Je pense que la confusion ici est due au fait qu'il y a une différence fondamentale dans la façon dont Gutenberg réinvente l'éditeur pour qu'il soit le premier à bloquer . En d'autres termes, nous devrions cesser de penser à ajouter des métaboxes et plutôt penser à ajouter des blocs. Les champs que vous mettiez auparavant dans des métaboxes que vous allez maintenant avancer seront plutôt mis en blocs.

Lorsque vous définissez un type de publication personnalisé, cela inclut probablement les blocs requis et les blocs simplement autorisés. Pour un type de publication personnalisé qui n'a pas editor support save_post et $_POST global.

Je pense donc que le résultat final sera en grande partie le même. Les auteurs de plugins continueront à avoir une «boîte» pour y insérer des champs personnalisés. C'est juste qu'ils apparaîtront dans des blocs au lieu de métaboxes.

Je pense que la confusion ici est due au fait qu'il y a une différence fondamentale dans la façon dont Gutenberg réinvente l'éditeur pour qu'il soit le premier à bloquer. En d'autres termes, nous devrions cesser de penser à ajouter des métaboxes et plutôt penser à ajouter des blocs. Les champs que vous mettiez auparavant dans des métaboxes que vous allez maintenant avancer seront plutôt mis en blocs.

@westonruter Cela semble assez judicieux pour les métaboxes contenant du contenu, mais de nombreuses métaboxes sont spécifiques au service post meta qui n'aurait pas de sens dans le contenu de l'article.

Merci @westonruter pour la clarification, mais cela soulève quelques nouvelles questions pour moi.

Les blocs qui stockent leurs données comme post_meta semblent être un type de bloc fondamentalement différent de ce que j'ai vu jusqu'à présent dans la démo. Ces données seraient-elles également stockées de manière redondante dans le flux du contenu de l'article?

Y a-t-il quelque chose qui empêche un auteur d'ajouter plus qu'un nombre acceptable de blocs à un article? (Ajout de plusieurs champs post_meta quand un seul a du sens)

J'aurais tendance à être d'accord avec @westonruter sur l'exploration des blocs comme passerelle vers les métadonnées. Ce que je suggérerais, cependant, est de découpler l'idée d'un bloc du post_content. Un bloc sur un type de publication personnalisé ne doit pas nécessairement être membre de ce qui sort de post_content sur le front-end. Voici un exemple d'utilisation du plugin The Events Calendar (mon interprétation) par modern tribe.

Dans cette situation, le contenu principal sont les détails de l'événement, pas la zone de contenu de forme libre. Le plugin utilisera les métadonnées de son type de publication personnalisé pour assembler son propre balisage et le post_content est simplement le texte descriptif qui s'imprime au bas de la page. Pour cette raison, le bloc des détails de l'événement ne doit pas être déplaçable, supprimable ou vraiment faire partie de la sortie du contenu. Il doit cependant apparaître en premier, car il représente le contenu principal de ce type de publication.

WooCommerce serait un autre exemple où un ou plusieurs blocs d'informations sur le produit devraient avoir la priorité sur le texte descriptif d'un type de publication de produit, mais ils ne devraient pas être des blocs facultatifs que l'utilisateur est censé insérer lui-même.

Je pense que le concept fondamental des blocs devrait être d'assembler l'interface utilisateur appropriée pour le message et ne pas nécessairement impliquer où ces données seront stockées ou rendues sur le frontend.

... nous devrions cesser de penser à ajouter des métaboxes et plutôt penser à ajouter des blocs.

Cela a du sens pour le contenu, mais de nombreux plugins utilisent des types de publication personnalisés pour les non-contenus tels que les formulaires ou les paiements. Ces types d'articles ne ressemblent en aucun cas à un article de blog, et leurs champs méta abstraits ne bénéficieraient pas d'un éditeur de blocs. Forcer toute configuration à être effectuée par blocs supprime le canevas ouvert sur lequel les développeurs de plugins s'appuient, le même canevas ouvert qui a fait de l'écosystème des plugins ce qu'il est aujourd'hui.

L'approche actuelle semble être le bloc d'abord avec des méta-boîtes confinées à un rôle de soutien. Alors que les blocs bénéficieront à de nombreux plugins axés sur le contenu, la nécessité de définir des paramètres abstraits bénéficiera toujours des étiquettes évidentes et des entrées familières fournies par les méta-boîtes. Dans ces cas, les développeurs devraient avoir la liberté d'utiliser l'ensemble du canevas.

@westonruter Pouvez-vous préciser que ce que vous dites est que si mon type de message personnalisé nécessitait certains champs supplémentaires, j'aurais ces données entrées dans un bloc?

Si oui, j'ai quelques questions complémentaires:

1) Serais-je capable de faire de ce bloc un bloc par défaut? IE, il était toujours affiché sur ce type de message et ne pouvait pas être supprimé. Par exemple, si mon plugin a créé des événements et que chaque événement avait une date de début et de fin, le bloc pour les dates de début et de fin serait-il requis et dans le contenu de la publication lors de la modification du type de publication personnalisé de l'événement par défaut?

2) Comment les données seraient-elles enregistrées à partir de ce bloc? Si je comprends bien, pour le moment, les données des blocs sont stockées sous forme de commentaires HTML dans post_content. Comment pourrions-nous obtenir les données de ces blocs pour publier des méta? Par exemple, pour mon plugin d'événement hypothétique, comment pourrais-je obtenir la date de début et de fin dans la méta de publication afin de pouvoir les interroger?

3) Quelle est la justification de tout cela dans la direction de l'éditeur de contenu principal et de l'appliquer aux types de publication personnalisés? Existe-t-il des tests utilisateur qui soutiennent cette direction de conception, en particulier en ce qui concerne les types de publication personnalisés qui ne représentent pas un article de blog / article?

@kevinwhoffman Je ne vois toujours pas de conflit fondamental pour les blocs. Les paramètres abstraits peuvent toujours être considérés comme du contenu, mais d'un type différent: ce sont toutes des données. Chaque bloc n'a pas besoin d'avoir une représentation visuelle dans «le contenu». Je pense qu'il pourrait aussi bien y avoir des «métablocs», stockant des données dans postmeta au lieu de post_content . Les blocs en cours d'édition peuvent être stylisés pour avoir des en-têtes / étiquettes similaires à la présentation des métaboxes aujourd'hui.

@ Shelob9 oui, si votre type de message personnalisé nécessitait des champs supplémentaires, je pense qu'ils seraient présentés dans un bloc. Si vous avez un type de publication personnalisé «produit», il peut y avoir un bloc product-details singulier

1. Serais-je capable de faire de ce bloc un bloc par défaut? IE, il était toujours affiché sur ce type de message et ne pouvait pas être supprimé. Par exemple, si mon plugin a créé des événements et que chaque événement avait une date de début et de fin, le bloc pour les dates de début et de fin serait-il requis et dans le contenu de la publication lors de la modification du type de publication personnalisé de l'événement par défaut?

Oui, exactement. Les types de publication personnalisés, les formats de publication et les modèles de page pourraient tous impliquer simplement le concept de blocs requis qui sont «verrouillés», ne pouvant être supprimés ou réorganisés. Un exemple de ceci serait un bloc pour l'extrait de publication: https://github.com/WordPress/gutenberg/issues/1288#issuecomment -310544967

1. Comment les données seraient-elles enregistrées à partir de ce bloc? Si je comprends bien, pour le moment, les données des blocs sont stockées sous forme de commentaires HTML dans post_content. Comment pourrions-nous obtenir les données de ces blocs pour publier des méta? Par exemple, pour mon plugin d'événement hypothétique, comment pourrais-je obtenir la date de début et de fin dans la méta de publication afin de pouvoir les interroger?

La plupart des blocs aujourd'hui stockent leurs données en HTML à l'intérieur du post_content mais ils ne sont pas obligés de le faire. Par exemple, dans https://github.com/WordPress/gutenberg/issues/1288, vous pouvez voir la discussion sur un bloc Extrait stockant son contenu dans post_excerpt et un bloc Image en vedette stockant son contenu dans postmeta. Donc, vous devriez certainement pouvoir avoir un bloc event-details qui a une date de début et de fin qui est stockée dans postmeta.

1. Quelle est la justification de tout cela dans la direction de l'éditeur de contenu principal et de l'appliquer aux types de publication personnalisés? Existe-t-il des tests utilisateur qui soutiennent cette direction de conception, en particulier en ce qui concerne les types de publication personnalisés qui ne représentent pas un article de blog / article?

Comme ci-dessus, les données peuvent être extraites et enregistrées dans post_content , postmeta, termes ou tout autre endroit. L'idée d'être le «bloc d'abord» est d'avoir un bloc de construction commun que tout utilise et, ce faisant, les composants du bloc peuvent être réutilisés au maximum sur WordPress. C'est ma compréhension.

@westonruter - Merci pour la clarification. Ceci est très utile car il n'y a pas beaucoup d'informations sur la façon dont cet éditeur se rapporte aux types de publications qui ne sont pas des articles de blog / articles, etc.

J'espère que nous verrons bientôt de la documentation sur la façon d'écrire un "metablock".

Nous devons considérer ce que nous enseignons à l'utilisateur à travers l'expérience d'édition de publication et comment cela correspond aux types de publication personnalisés.

Lors de la modification d'une publication par défaut dans l'éditeur de blocs, l'utilisateur apprend que chaque bloc représente du contenu. Les paramètres associés au contenu sont disponibles dans un panneau / une méta-boîte qui se trouve en dehors de l'éditeur de blocs. Le contenu vit dans des blocs. Les paramètres vivent dans des panneaux. Il a été dit ailleurs que ce que l'utilisateur voit dans l'éditeur de blocs devrait être un aperçu de la page une fois publiée.

Combiner ensuite les paramètres et le contenu dans l'éditeur de blocs pour les types de publication personnalisés brise l'idée que l'éditeur de blocs est un aperçu. Je pense que nous devrions laisser l'éditeur de blocs faire ce qu'il fait de mieux, c'est-à-dire éditer le contenu, et permettre aux développeurs de créer des interfaces de paramètres qui ne partagent pas les mêmes exigences qu'un bloc de contenu.

J'ai travaillé sur un plugin étendu qui ajoute des méta-boîtes comme WooCommerce et EDD. La plupart du temps, j'ai supprimé l'éditeur de contenu de l'écran car il n'est pas nécessaire. Je crains un peu que ce ne soit pas quelque chose que nous devrions fusionner avec Gutenberg.
Sinon, où irait tout cela.

Je suis d'accord avec @kevinwhoffman pour

Cela ne résout pas tous les problèmes pour moi, mais je pense que c'est un moyen intéressant de donner un coup de jeune aux métabox et pourrait probablement être assez rétrocompatible avec les plugins existants, mais ce ne serait pas une expérience de première classe pour l'utilisateur.

Voici une tentative pour informer l'utilisateur lorsqu'un méta-bloc est le contenu principal, que le contenu de l'article est utilisé comme description et qu'il existe des méta-blocs supplémentaires.

@brentjett Merci pour les maquettes. Comme vous le faites remarquer, la nécessité de séparer les paramètres du contenu est importante, mais je ne vois pas l'avantage d'exiger qu'une boîte de paramètres comme Yoast soit un bloc en premier lieu.

• Il ne représente _pas_ le contenu de la page, brisant ainsi l'idée que l'éditeur de blocs est un aperçu du contenu de la page.
• Il ne nécessite _pas_ plusieurs instances.
• Il ne profite _pas_ d'être repositionné au milieu d'autres blocs de contenu.
• Il _doit_ être présent sur la page par défaut.

Chacun de ces traits va à l'encontre du comportement par défaut d'un bloc. Bien sûr, il existe diverses discussions pour créer des blocs à usage unique qui peuvent être verrouillés en position et présents par défaut. Mais pourquoi transformer un bloc en une méta-boîte alors que nous pourrions plutôt nous concentrer sur l'amélioration de l'implémentation de la méta-boîte qui sert déjà cet objectif?

Je ne vois pas l'intérêt d'exiger qu'une boîte de paramètres comme Yoast soit un bloc en premier lieu.

Revenons ici une minute. Deux choses. L'un est le support des anciennes métaboxes écrites en PHP, pour lesquelles nous avons le tiroir "paramètres étendus" simulé dans ce post.

L'autre chose est de répondre à la question: si nous voulions repenser cela à partir de zéro, à quoi cela ressemblerait-il aujourd'hui?

C'est là que nous proposons _blocks_, comme une nouvelle interface qui peut unifier de nombreuses interfaces disparates. Nous suggérons déjà que les blocs peuvent être supérieurs aux codes courts, au HTML personnalisé, aux widgets et à une offre pour les intégrations. En fonction de ce que fait la metabox, il n'y a aucune raison pour qu'elle ne puisse pas intégrer cette interface également.

D'accord. Et parlant au nom de Yoast pendant une seconde, nous prévoyons d'intégrer dans de nombreux endroits autour du nouvel éditeur, améliorant l'expérience que Gutenberg vise au lieu de construire un gros bloc pour imiter notre ancienne métabox, mais il y a eu d'autres exemples mentionnés ci-dessus qui seraient travailler comme un bloc aussi je pense. Oui, cela demande du travail, mais s'il s'avère que cet éditeur excitera les utilisateurs de wordpress une fois qu'il aura gagné un peu plus de force, c'est une opportunité excitante de repenser la façon dont nous nous intégrons avec lui, et je pense que nos produits deviendront meilleurs en conséquence.

Donc, nous avons deux cas fonctionnels _legacy_:
MetaBoxes qui géraient les méta-données (comme Yoast), et nous avons des MetaBoxes qui ont été utilisées pour fournir une interface structurée pour entrer du contenu (comme WooCommerce).

Développer pour le futur
Si nous partions d'une ardoise vierge («annuler notre dette envers le passé»), alors il est vrai que placer des méta-données dans le tiroir «avancé» proposé pourrait bien fonctionner. De plus, l'entrée de contenu structurée peut s'intégrer dans une interface de blocage bloquée dans Gutenberg. Ces deux éléments sont entièrement hypothétiques, mais ils pourraient potentiellement fonctionner comme des implémentations pour les futurs développements de WP CMS.

problèmes liés au CMS métier hérité
99% de mon travail consiste à fournir des solutions commerciales sur mesure directement à mes entreprises clientes. Je ne m'inquiète donc pas des grandes choses que je pourrais construire à l'avenir, mais de la dure réalité des fonctionnalités de mon site client et des relations commerciales. Quelles sont les propositions pour migrer les entreprises basées sur des solutions CMS existantes vers Gutenberg? Dans ma situation, chaque client dispose d'une solution CMS sur mesure différente basée sur le framework WP établi. Pour moi, l'expression "annuler la dette envers le passé" = "Jeter le bébé avec l'eau du bain".

Préoccupations
Si Gutenberg est livré en tant que noyau dans WP5.0, je prévois que mes clients auront des sites non fonctionnels. Ensuite, chaque site devra être refait et chaque client apaisé. Une quarantaine de clients voudront peut-être que je répare leur CMS cette semaine-là.

• Les anciens sites dépendants de la méta-boîte CMS et leur base d'utilisateurs semblent non essentiels pour l'équipe principale
• la proposition de tirage «avancé» n ° 952 n'a pas été priorisée, ce qui indique un manque d'intérêt pour l'ensemble de la zone.
• il n'y a pas de méthode proposée pour résoudre le problème de la «dette envers le passé» / CMS

C'est là que nous proposons des blocs, comme une nouvelle interface qui peut unifier de nombreuses interfaces disparates. Nous suggérons déjà que les blocs peuvent être supérieurs aux codes courts, au HTML personnalisé, aux widgets et à une offre pour les intégrations.

Les blocs ont du sens pour toutes ces choses - codes courts, HTML personnalisé, widgets, intégrations. Ce sont toutes des formes de contenu qui apparaissent sur la page. Je suis d'accord, bloquez-les tous.

Les paramètres ne sont rien de tout cela. Les paramètres ont des exigences distinctes qui ne chevauchent pas le comportement fondamental d'un bloc. Dans de nombreux cas, ces boîtes de paramètres stockent des méta de publication qui n'ont aucune incidence sur la présentation frontale d'une publication. Analyser le non-contenu à côté du contenu à chaque fois qu'un message est affiché semble inutile.

Une autre chose à considérer est ce qui se passe lorsque l'utilisateur passe en mode texte. Vont-ils voir un tas de commentaires HTML représentant des boîtes de paramètres à côté de leur contenu de publication? L'utilisateur supprimera-t-il ces éléments inconnus?

Tout cela pourrait être simplifié en traitant les blocs comme du contenu et les paramètres comme un composant d'interface utilisateur distinct. Même si nous n'avions pas à considérer les méta-boîtes héritées (ce qui est un énorme problème souligné par @steveangstrom ), l'expérience utilisateur bénéficierait toujours d'une séparation claire du contenu et des paramètres.

La section

C'est une excellente discussion sur ce qui sera possible à l'avenir et que tout sonne bien, WordPress en a vraiment besoin. Pour moi, en tant que développeur de plugins, ce n'est pas grave, je vais faire un bloc ou deux et être bon. Mais qu'arrive-t-il aux clients de Steve et aux millions de sites Web qui ont été vendus à des clients avec une attente de compatibilité ascendante?

Je comprends ces préoccupations car j'ai également de nombreux clients dont les sites Web vont probablement rompre avec la mise à jour. Quelques réflexions de ma part:

Nous utilisons largement ACF pour la gestion de contenu. Par exemple, nous pourrions avoir plusieurs éditeurs tinymce par article ou dans un répéteur. si le but est de remplacer tinymce, comment pourrions-nous utiliser plusieurs "conteneurs de blocs"? Je comprends bien pour le moment, il n'y a qu'un seul "conteneur de bloc", non?

Les pages d'options sont une autre fonctionnalité ACF qui ne correspond pas au flux de post-édition. Je ne vois vraiment pas comment cela fonctionnerait sur une page d'options.

Pour ceux qui veulent une compatibilité ascendante - quelqu'un va probablement créer un plugin pour restaurer l'expérience d'édition actuelle, s'il n'y a pas de temps / ressources pour mettre à jour vers gutenberg (c'est quelque chose que je prévois d'utiliser). De plus, 5.0 serait une modification majeure de la version, ce qui signifie que les changements de rupture sont OK (au moins selon les normes semver ).

WordPress ne suit pas semver.

@westonruter Je pense que cela a du sens:

Les champs que vous mettiez auparavant dans des métaboxes que vous allez maintenant avancer seront plutôt mis en blocs.

Mais, comment allons-nous de là (métaboxes) à ici (blocs)? À la fois en termes de rétro-compatibilité pour le code (plugins qui n'ont pas encore été mis à jour pour Gutenberg) et de rétro-compatibilité pour les données (comment afficher les données de métabox existantes dans un nouveau bloc de contenu, une fois qu'un plugin est mis à jour pour cela; est-ce un plugin- problème de portée?).

Mais, comment allons-nous de là (métaboxes) à ici (blocs)? À la fois en termes de rétro-compatibilité pour le code (plugins qui n'ont pas encore été mis à jour pour Gutenberg) et de rétro-compatibilité pour les données (comment afficher les données de métabox existantes dans un nouveau bloc de contenu, une fois qu'un plugin est mis à jour pour cela; est-ce un plugin- problème de portée?).

Ce sont de bonnes questions. Nous explorerons les réponses lors de la mise en œuvre de ces fonctionnalités.

Si je devais deviner où nous finirons ici: les métaboxes actuelles seront déplacées vers une zone "héritée" et nous fournirons des API, de la documentation et des exemples pour enregistrer des métabox-blocs-machins "nouveau style".

@nylen qu'en est-il du _rendering_ des métaboxes actuelles?

C'est une bonne nouvelle que les méta-boîtes soient priorisées, mais nous devons envisager une solution qui va au-delà de placer les anciennes méta-boîtes dans un tiroir ou de les confiner dans une zone «héritée».

Il existe aujourd'hui d'innombrables sites qui sont principalement construits avec des méta-boîtes via des plugins tels que Advanced Custom Fields. Nous parlons ici d'interfaces plein écran, pas seulement d'une ou deux boîtes en bas d'un article. Je suis sûr qu'ACF se mettra à jour pour fonctionner avec Gutenberg, mais ces sites ne seront pas reconstruits.

La question demeure donc, qu'arrive-t-il à une interface qui n'a pas d'éditeur et qui est entièrement composée de méta-boîtes?

La question demeure donc, qu'arrive-t-il à une interface qui n'a pas d'éditeur et qui est entièrement composée de méta-boîtes?

L'idée ici, et corrigez-moi si je me trompe @mtias , est que vous masquez simplement la zone de contenu avec votre plugin, et tout ce que vous voyez sont des métabox où se trouverait le contenu.

Pourquoi ne pas faire en sorte que cet éditeur se comporte comme un éditeur plein écran / sans distraction?

+1. C'est une bonne idée car cela n'affecte pas du tout l'éditeur actuel avec des méta-boîtes. Bien que l'éditeur sans distraction soit là depuis longtemps, il n'est pas beaucoup utilisé. L'éditeur Gutenberg peut prendre cela et s'améliorer au lieu de réécrire l'écran de l'éditeur.

De plus, il serait préférable d'enregistrer le support de l'éditeur Gutenberg avec le paramètre supports lorsque register_post_type .

Enfin, en tant que développeur de méta-boîtes, j'aimerais voir une nouvelle API pour faire fonctionner les méta-boîtes pour le nouvel éditeur. Comme vous le voyez ici, de nombreux développeurs utilisent des méta-boîtes comme moyen de fournir du contenu supplémentaire pour les articles. Ces contenus peuvent être catégorisés, recherchés plus tard. Ce ne sont pas que de simples blocs de contenu en tant que contenu de publication. Donc, s'il y a un nouveau remplacement pour la fonction add_meta_box() , je suis heureux de refactoriser mon plugin Meta Box pour travailler avec cela.

D'accord avec tout ce qui a été dit concernant: faire en sorte que les métabox standard fonctionnent encore / aient une place. En tant que développeur principal de CMB2, je peux garantir qu'il y aura un tollé assez important si CMB2 est en quelque sorte cassé lors de la sortie de WordPress 5.0. Je ne veux certainement pas dire cela comme une menace, mais simplement comme une réalité.

Plus nous pouvons mettre à jour ACF, Pods et CMB2 pour utiliser le modèle de données introduit par Gutenberg, plus cette transition sera facile, je pense.

Je chercherai certainement à le faire sur le long terme, mais je ne suis pas sûr que ce soit une attente raisonnable que les bibliothèques Metabox l'auront en place avant la sortie de gutenberg. (Certes, ce n'est peut-être pas l'attente)

I can guarantee there will be a pretty significant outcry if CMB2 is somehow broken when WordPress 5.0 is released

Et même si elle est mise à jour, les anciennes installations seraient cassées.

Veuillez également noter que les groupes de champs dans ACF n'ont pas besoin d'être dans des métaboxes, mais il y a aussi le style 'Seamless (pas de metabox)' avec les options 'Side', 'normal - after content' et 'high - entre le titre et l'éditeur (!!!) '. Le dernier est important pour créer un flux d'édition significatif.

Veuillez garder à l'esprit qu'il y a beaucoup de développements individuels critiques qui ne seront jamais mis à jour parce que personne ne paiera pour cela. Briser ces implémentations sera le tueur ultime pour WP dans les environnements d'entreprise.

@ wsydney76 Veuillez également noter que les groupes de champs dans ACF n'ont pas besoin d'être dans des métaboxes, mais il y a aussi le style 'Seamless (pas de metabox)' avec les options 'Side', 'normal - after content' et 'high - between title et éditeur (!!!) '. Le dernier est important pour créer un flux d'édition significatif.

Il convient de noter que ce n'est pas quelque chose qui "fonctionne simplement" dans WordPress, mais nécessite un code de plugin personnalisé pour supprimer l'interface utilisateur habituelle de la metabox - il est donc raisonnable de supposer que cela nécessitera un travail supplémentaire de la part d'ACF pour fonctionner avec Gutenburg.

Faites simple. Lorsque le type de publication personnalisé n'a pas de support pour l'éditeur (Gutenberg) déclaré, utilisez votre imagination, vos compétences CSS et vos concepteurs de base les plus talentueux pour convertir tout l'éditeur en autre chose. Faites-le apparaître comme quelque chose que le client / utilisateur ne voit pas dans l'écran d'édition (natif). C'est juste une question d'apparence. Les clients ne se soucient pas de savoir si Gutenberg fonctionne en arrière-plan ou non, ils s'en moquent même si les développeurs Web leur en parlent. Ce sont des personnes visuelles.

En ce qui concerne la rétrocompatibilité, j'ai proposé une version de support à long terme de WordPress en février, bien avant l'annonce de Gutenberg atteignant 5.0.

À ce stade, cela semblait être une tâche improbable, mais maintenant que cela se produit, il est encore plus important de discuter de la création d'une version 4.9 de LTS, de la suppression du support pré-4.9 et de se concentrer sur la 5.0.

Le message peut être trouvé ici:
https://khromov.se/wordpress-needs-another-long-term-support-version/

10 ans + développeur WordPress ici. Comme beaucoup l'ont souligné, ce développement est idéal pour le contenu. C'est une solution standard vraiment nécessaire pour les blocs de contenu dynamique avec un balisage personnalisé. Cela dit, cela limite l'utilisation des types de publication de manière à éloigner le contenu et à rapprocher WordPress d'un cadre.

A titre d'exemple: j'ai construit une suite de plugins qui permettent non seulement de créer des champs pour les types d'articles (comme beaucoup d'autres) mais aussi de créer des relations entre eux (c'est-à-dire un à un, un à plusieurs, etc.). Cela (avec plus de fonctionnalités) transforme les types de publications en quelque chose de très proche des modèles dans des frameworks comme Laravel ou Rails, et j'utilise ensuite un DSL pour travailler avec ces publications, leurs données et leurs relations.

Ce type d'utilisation est loin d'être rare et WordPress lui-même a encouragé les utilisations créatives des types de publication en permettant aux développeurs de déclarer les types de publication comme non publics. Les indicateurs tels que "public", "public_queryable" et "show_ui" sont tous destinés à permettre aux développeurs d'utiliser des types de publication à des fins autres qu'une simple relation miroir 1: 1 avec une page publique du site Web.

Comment Gutenberg s'inscrit-il dans cette vision?

Je ne vois pas d'autre solution que de garder cet éditeur facultatif, c'est-à-dire qu'il devrait toujours remplacer TinyMCE mais l'éditeur devrait rester facultatif tout comme TinyMCE est facultatif pour le moment.

Si nous pouvons continuer à créer des types de publication qui ne prennent pas en charge l'éditeur et que nous pouvons continuer à utiliser des métaboxes dans ces types de publication, je pense qu'un consensus pourrait être atteint beaucoup plus rapidement.

L'adoption du nouvel éditeur par les développeurs de thèmes et de plugins pourrait devenir plus lente avec ce type d'approche, mais honnêtement, je ne vois pas d'autre issue qui ne signifierait pas d'emprunter la route 4.9 LTS, ce qui permettrait de démarrer de nouveaux projets avec WP 5.0 et les projets hérités pour rester avec 4.9 LTS.

MISE À JOUR: lorsque j'ai écrit ce commentaire, le titre du fil de discussion était différent et la possibilité de déprécier les métaboxes était en cours de discussion (c'est-à-dire que l'équipe principale n'avait pas encore répondu clairement à cette question avec un «non» ferme comme elle l'a fait dans les commentaires ci-dessous). Dans un tel scénario, gutenberg aurait simplement pris en charge les blocs dynamiques et ignoré les nombreux autres cas d'utilisation des métaboxes, d'où mon commentaire ci-dessus.

Après avoir passé du temps à lire les commentaires de tout le monde, il me semble que le résultat probable de cette évolution de l'écran d'édition est de fournir une nouvelle API de métaboxes qui fonctionne dans cet écran d'édition basé sur js. C'est-à-dire que nous ne perdons pas réellement la possibilité d'utiliser les publications de manière créative comme je l'ai mentionné ci-dessus, mais nous obtenons simplement une nouvelle API pour le faire et l'interface utilisateur sera basée sur js.

Nous prévoyons d'utiliser Pods 2.7 pour créer une application alimentée par React à l'aide de l'API REST WordPress et de GatsbyJS .
Gutenberg sera-t-il compatible avec les pods?

Je vois que cette question vitale a été supprimée de toute étape importante. Il a de nouveau été dé-priorisé, tandis que les cloches et les sifflets pour l'édition de blogs demandent beaucoup de travail et sont ajoutés aux bêtas. C'est très inquiétant pour l'avenir de Wordpress en tant que CMS.

J'ai créé mes propres générateurs de code inspirés de GenerateWP. Pour mon usage personnel et privé sur localhost, pas public.
Quoi qu'il en soit, je me demande à quoi cela ressemblerait dans le Gutenberg une fois le changement effectué. Champs ACF, beaucoup de code PHP personnalisé pour l'aperçu.

Nous n'avons pas oublié ce problème. C'est plutôt une question extrêmement compliquée que nous commençons seulement à examiner, ainsi que de nombreuses autres priorités pour que l'éditeur fonctionne correctement.

Certaines des difficultés que nous rencontrerons lors du câblage des métaboxes peuvent devenir apparentes à la lecture de # 2251, qui contient également des informations sur les prochaines étapes d'un point de vue technique.

Le point principal que je veux insister sur cette question, ici, est que nous avons besoin de l'aide de la communauté pour planifier et tester cette mise en œuvre.

Voici un point de départ pour une liste de plugins à regarder:

Plugin                                      Active installs
======                                      ===============
advanced-custom-fields                           1,000,000+
custom-post-type-ui                                400,000+
meta-box                                           200,000+
types                                              200,000+
cmb2                                               100,000+
pods                                                50,000+
custom-field-suite                                  40,000+
wck-custom-fields-and-custom-post-types-creator     20,000+
piklist                                             10,000+
carbon-fields                                        2,000+

Plugins qui n'apparaissent pas ci-dessus, probablement parce qu'ils ne sont pas dans le répertoire des plugins WP.org:

• Fieldmanager

Si vous connaissez d'autres plugins largement utilisés qui accomplissent une tâche similaire, veuillez nous en informer ici dans ce numéro.

Si vous êtes le développeur de l'un de ces plugins et / ou pouvez fournir des détails sur les hooks WordPress que l' un de ces plugins utilise pour ajouter leurs métaboxes et mettre en file d'attente tous les scripts ou feuilles de style associés, veuillez nous le faire savoir ici dans ce numéro ou créer un nouveau problème pour chaque plugin spécifique de la liste ci-dessus. La collecte de ces informations prend du temps et il sera extrêmement utile pour les efforts de développement ultérieurs de tout avoir en un seul endroit. Par exemple:

Advanced Custom Fields ajoute ses métaboxes en enregistrant un hook contre admin_enqueue_scripts . Ce hook vérifie que le chargement actuel de la page est soit post.php ou post-new.php , et si tel est le cas, ajoute une action admin_head qui appelle add_meta_box . WP core effectue ses appels do_meta_boxes peu de temps après cette action, dans edit-form-advanced.php .

Enfin, si vous êtes un développeur familier avec la façon dont WordPress affiche et enregistre actuellement les métaboxes, votre contribution ici et / ou sur # 2251 est appréciée .

Salut les gars,
Elliot ici - Dev ACF.

ACF utilise l'action admin_enqueue_scripts pour effectuer une "logique de correspondance de groupe de champs", puis l'action admin_head pour ajouter des métaboxes (via add_meta_box() ). Il n'utilise pas l'action add_meta_boxes .

Puis-je poser une question évidente ici? Pourquoi discutons-nous des «difficultés» des métaboxes? Ceux-ci font partie intégrante de chaque site Web WP. La logique de la métabox peut sûrement rester telle quelle et coexister avec la nouvelle zone d'édition de Gutenberg.

Assurez-vous également de taguer @woocommerce . Il s'agit probablement du plus gros plugin de metabox.

Merci
E

Salut les gars-

Je suis encore en train de formuler quelques réflexions et idées, mais je voulais poser une question rapide car il semble que cette discussion devienne un peu trop ciblée.

Pourquoi ne parlons-nous que d'ajouter des champs aux méta-boîtes? Le système actuel nous permet d'ajouter n'importe quoi. Des données, du javascript pour accéder aux API tierces pour utiliser leurs outils, un affichage rapide des notes ou des informations d'aide, et même des photos de petits chatons mignons donnant aux gens un high five (ok, peut-être pas celui-ci, mais qui sait ?!).

Le point que j'essaie de faire valoir ici est que les méta-boîtes sont des conteneurs universels qui peuvent contenir une variété de choses qui incluent, mais ne sont pas limitées à, des champs. Pour le moment, c'est assez facile avec PHP de faire cela, mais demandons-nous actuellement aux gens de savoir comment écrire un composant React juste pour y ajouter du texte?

Comme je l'ai dit, j'essaie simplement d'ajouter au contexte de la conversation.

Merci,

Kevin - Développeur principal pour Piklist

Cette question a été évoquée dans de nombreux commentaires ci-dessus mais n'a pas reçu de réponse à ma connaissance:

Est-il possible de remplacer l'éditeur de publication TinyMCE existant par Gutenberg tout en laissant le reste de l'interface, y compris les méta-boîtes et les hooks existants, inchangés?

Cette portée restreinte permettrait à Gutenberg d'être inclus ou exclu des types de publication personnalisés en définissant la prise en charge de editor lors de l'enregistrement du type de publication.

• Si le support editor est enregistré, alors Gutenberg est présent sur l'écran d'édition avec des méta-boîtes existantes qui continuent de fonctionner comme elles le font aujourd'hui autour de l'éditeur actuel.
• Si le support editor n'est pas enregistré, alors Gutenberg n'est pas chargé et le canevas vierge est disponible pour les méta-boîtes comme c'est le cas aujourd'hui.

Cette approche semble éviter le défi massif de la rétrocompatibilité avec les implémentations de méta-box existantes tout en libérant des ressources pour créer le meilleur éditeur possible.

Puis-je poser une question évidente ici? Pourquoi discutons-nous des «difficultés» des métaboxes?

@elliotcondon - si un problème de développement est difficile à résoudre, la seule façon d'arriver à une solution est de

Merci de confirmer les informations que j'ai collectées sur la manière dont ACF enregistre ses métaboxes. Pour faire plus de progrès dans la mise en œuvre d'ACF en particulier, voici les prochaines choses qu'il serait utile de savoir:

• Quels scripts et feuilles de style sont mis en file d'attente pour contrôler la fonctionnalité des métaboxes ACF
• Quelles actions sont responsables de leur mise en file d'attente
• Toutes les conditions qui contrôlent si elles sont mises en file d'attente ou non.

Pourquoi ne parlons-nous que d'ajouter des champs aux méta-boîtes?

J'aimerais arriver à un endroit où le code Gutenberg n'a pas à se soucier beaucoup de ce que fait réellement une metabox.

Dans ce but, @kevinpmiller , voici les prochaines choses qu'il serait utile de savoir pour Piklist:

• Quelles actions sont responsables d'appeler add_meta_box pour enregistrer des métaboxes
• Toutes les conditions qui contrôlent si elles sont enregistrées ou non (par exemple, l'écran actuel est post.php ou post-new.php )

Dans ce numéro, gardons la conversation concentrée sur le fonctionnement des métaboxes PHP existantes aux côtés de l'interface Gutenberg.

Pour le moment, c'est assez facile avec PHP de faire cela, mais demandons-nous actuellement aux gens de savoir comment écrire un composant React juste pour y ajouter du texte?

Oui, nous devons élaborer un ensemble d'API pour créer des métaboxes de «nouveau style». Voici ce que nous avons aujourd'hui pour les blocs - je pense que ce sera assez similaire, avec des métaboxes enregistrées comme des "blocs" qui peuvent économiser ailleurs que post_content : http://gutenberg-devdoc.surge.sh/

La discussion sur les métaboxes de nouveau style devrait avoir lieu au # 1684 ou dans un autre problème pour proposer une API technique.

Si le support de editor n'est pas enregistré, alors Gutenberg n'est pas chargé et le canevas vierge est disponible pour les méta-boîtes comme c'est le cas aujourd'hui.

@kevinwhoffman - Gutenberg tel qu'il est écrit aujourd'hui est destiné à être un éditeur post_content . Il va donc de soi que si la prise en charge de editor n'est pas activée, du moins pour l'instant, nous la désactivons. C'est également une tâche assez facile du point de vue du code. Pouvez-vous créer un nouveau problème pour cela et je vais le taguer avec le libellé Good First Task ?

Gutenberg tel qu'il est écrit aujourd'hui est destiné à être un éditeur post_content .

@nylen Si Gutenberg est vraiment destiné à être un éditeur post_content , alors les méta-boîtes doivent être laissées seules car elles ne sont pas concernées par post_content .

De plus, la nécessité d'une API pour traduire les méta-boîtes PHP en méta-boîtes React est un problème fabriqué. Cela ne doit pas être un problème, mais c'est devenu un problème parce que quelque part le long de la ligne, il a été décidé que la réécriture de l'éditeur post_content devrait également changer complètement le fonctionnement des méta-boîtes.

Vous avez décrit l'énorme défi que représente l'écriture d'une telle API dans # 2251. Traduire des méta-boîtes PHP en React pour une solution de champs personnalisés populaire comme ACF est déjà assez difficile, sans parler d'essayer de le faire pour chaque implémentation de méta-boîtes qui existe aujourd'hui, populaire ou non. Il ne s'adapte pas.

@kevinwhoffman - Très bien dit. Cela reflète mes pensées exactes ainsi que de nombreux autres développeurs avec lesquels j'ai parlé.

Je ne souhaite pas retirer ce problème du sujet, mais je ne comprends pas pourquoi il doit y avoir des difficultés de «métabox» lors de l'introduction d'un nouveau générateur de page JS. C'est ce que je veux dire quand je dis:

Pourquoi discutons-nous des `` difficultés '' des métaboxes

Je suis heureux de lire ça:

Si le support de l'éditeur n'est pas enregistré, alors Gutenberg n'est pas chargé et le canevas vierge est disponible pour les méta-boîtes comme c'est le cas aujourd'hui.

Si ce qui précède est vrai, toute la logique wp-admin (actions, fonctions, etc.) devrait rester la même (ish) pour l'écran d'édition d'un article. Par conséquent, il ne devrait y avoir aucune raison pour laquelle le HTML de la métabox ne peut pas être rendu comme il le fait depuis des années.

@nylen
ACF met en file d'attente quelques fichiers JS et CSS pour styliser et interagir avec l'élément HTML métabox ACF.
ACF utilise les actions 'admin_enqueue_scripts' pour ajouter ces actifs
De nombreux autres plugins et thèmes mettent en file d'attente des styles / scripts - pourquoi cela poserait-il un problème?
ACF n'utilise pas JS pour enregistrer les métadonnées. Il utilise l'action save_post pour sauvegarder toutes les données $_POST - des choses assez normales.

De plus, la nécessité d'une API pour traduire les méta-boîtes PHP en méta-boîtes React est un problème fabriqué.

Ce n'est pas tout à fait ce que nous faisons. C'est plus comme: puisque nous n'utilisons plus le processus de chargement traditionnel post.php , nous devons en choisir les éléments dont nous avons besoin.

Si le support de l'éditeur n'est pas enregistré, alors Gutenberg n'est pas chargé et le canevas vierge est disponible pour les méta-boîtes comme c'est le cas aujourd'hui.

Pour clarifier: ce n'est pas le cas actuellement, mais ce serait une chose raisonnable à explorer dans un PR. Si vous souhaitez voir cela fonctionner aujourd'hui, aidez-nous, cela ira beaucoup plus rapidement.

@kevinwhoffman @elliotcondon @nylen Ou mieux encore, que diriez-vous:

• Si le support block-editor est enregistré, utilisez Gutenberg.
• Si le support editor est enregistré, utilisez TinyMCE.
• Si aucun support n'est enregistré, ni Gutenberg ni TinyMCE ne sont chargés.

Je ne suis pas en faveur d'une fracture de l'expérience WP Admin basée sur la présence ou l'absence de Gutenberg.

Si Gutenberg = New React Meta Boxes et No Gutenberg = Old PHP Meta Boxes, alors un administrateur fracturé est la direction dans laquelle nous nous dirigeons.

Les méta-boîtes devraient fonctionner de la même manière partout, qu'un éditeur soit présent ou non.

Exemple: disons que j'ai un plugin qui ajoute une méta-boîte pour évaluer les publications sur 5 étoiles. Le plugin est conçu pour que tout type de publication puisse être évalué. Pourquoi les éléments internes de cette méta-boîte devraient-ils changer selon que le type de publication utilise un éditeur ou non?

@kevinwhoffman

Je ne suis pas en faveur d'une fracture de l'expérience WP Admin basée sur la présence ou l'absence de Gutenberg.

Était-ce en réponse à ma suggestion concernant block-editor , ou autre chose?

BTW, je ne vois pas ma suggestion comme fracturant l'expérience, je la vois comme s'appuyant sur votre suggestion d'inclure des méta-boîtes existantes si elles existent dans la configuration WordPress.

@mikeschinkel La possibilité d'activer ou de désactiver Gutenberg est nécessaire, mais l'idée que Gutenberg détermine le comportement des méta-boîtes est ce à quoi je m'oppose. Ce sont des problèmes distincts.

@kevinwhoffman Je suis d'accord avec vous, au fait.

À partir des pods, nous faisons des choses normales, documentées et standard en utilisant les mêmes actions qu'ACF et CMB2. Nous le faisons tous à peu près comme il est recommandé de le faire actuellement.

+1 sur la possibilité de continuer à utiliser des méta-boîtes aux côtés de Gutenberg, les gens pourront finalement utiliser Gutenberg pour des choses qui appartiennent directement au contenu, et pour tout le reste, il y a toujours les méta-boîtes qu'ils aiment pour les attributs et les informations supplémentaires sur un "message "(de tout type).

-1 sur le fait de devoir tout réécrire dans React, au moins prendre en charge les deux pendant un long moment jusqu'à ce que tout le monde ait le temps de se familiariser avec la méthode React et qu'il en supporte plus / règle les problèmes pour les implémentations de méta-boîtes. Je ne pense pas qu'il y ait un moment où les méta-boîtes PHP devraient être progressivement supprimées, conservez-les pour une rétrocompatibilité et laissez les plugins migrer à mesure que la documentation de la méta-boîte React et les compétences des développeurs s'améliorent dans ce domaine.

À la suite de la discussion dans ce billet, ainsi que des conversations publiques et privées qui en découlent, je pense qu'il y a une question cruciale à laquelle il faut répondre ici:

WordPress a-t-il l'intention de désapprouver formellement l'API Metabox?

Si la réponse est non, alors le tout «déplaçons les choses et paralysons-les un peu» est un non-démarreur. Si l'API reste prise en charge selon les normes de compatibilité ascendante du cœur de WordPress, on s'attend à ce que toute implémentation de metabox existante fonctionne. Comme le font les choses dans WordPress.

Si la réponse est Oui, il s'agit d'un énorme changement de politique de compatibilité ascendante et de fin d'ère pour le développement WordPress dans son ensemble. Cela ne nécessite pas seulement de «résoudre» les métaboxes dans Gutenberg. Cela exigerait une rééducation et une clarification énormes que de nombreuses années de développement de base de WordPress effectuées d'une certaine manière et fournissant un certain niveau d'attentes de compatibilité descendante sont terminées.

Malheureusement, la réponse actuelle semble ne pas dire oui, mais avoir l'intention de casser des choses, tout en prétendant que c'est un non . Personnellement, je trouve l'approche extrêmement atypique pour une fonctionnalité principale majeure et il est très déconcertant que cela se fasse de cette manière.

L'écran Post Edit est _l'écran le plus personnalisé sur chaque projet qui va au-delà d'un blog barebones.

Ces personnalisations ne se limitent pas à l'enregistrement des métaboxes. Tout hook proposé par les écrans d'administration d'édition est utilisé dans le même projet. Et pour les cas pour lesquels il n'y a pas de hook, les développeurs utilisent jQuery pour injecter des éléments d'interface utilisateur dans la page.

Donc, pour ces personnalisations, il doit y avoir une voie à suivre.

Pour les métaboxes, Fieldmanager est l'outil de choix, car il est approuvé par VIP. Fieldmanager est puissant, mais concentré sur un ensemble limité de champs. Les bases de code héritées ne peuvent souvent pas être modernisées pour utiliser Fieldmanager ou une autre bibliothèque utilitaire.

Ainsi, de nombreuses métaboxes sont toujours créées à l'aide de code personnalisé. Le code personnalisé signifie une combinaison de PHP et de JavaScript, souvent avec des interactions basées sur Ajax.

La suggestion de bourrer toutes ces métaboxes soigneusement conçues de leur position prévue dans une zone sous l'éditeur est absurde.

Toute régression à partir des options de personnalisation de l'écran Post-modification disponible pour le moment sera inacceptable.

Si le code existant doit être mis à jour, vous pouvez compter 12 à 18 mois à partir du moment où toutes les nouvelles API sont finalisées pour que ces mises à niveau se produisent sur les projets clients. Ce qui signifie qu'il doit y avoir une période de double exécution, où les API héritées et les nouvelles API coexistent.

Je ne comprends pas pourquoi les Metabox ont quelque chose à faire avec Gutenberg? C'est juste une page backend, un écran. Peut être organisé de centaines de façons.
Vous avez dit que la mise en œuvre actuelle brise React.

Laissez les développeurs choisir s'ils lieront leur Metabox à Gutenberg ou s'ils les garderont à l'extérieur.
Tout ce problème est que vous supposez que tout le monde devra créer des blocs Gutenberg, d'une manière ou d'une autre. Et s'ils n'en veulent pas, n'en ont pas besoin.

Deuxième gros problème pour moi personnellement. J'ai toujours eu du mal avec javascript, je suis anti-talent pour ce langage.
Ok, tout ne tourne pas autour de moi, mais juste pour dire. Il ne sera pas plus facile d'ajouter des Metaboxes qu'auparavant.

Je pense que @Rarst a parfaitement résumé le problème. La communauté a besoin d'une réponse claire et il semble que l'équipe de développement semble encline à suivre la direction de la dépréciation, mais elle ne peut tout simplement pas l'expliquer clairement car elle essaie d'abord de trouver une solution, ce que je respecte complètement. Nous n'avons pas besoin d'une communauté qui passe en mode panique pendant des mois, mais en même temps, cette même communauté doit avoir suffisamment de visibilité et une route claire. C'est honnêtement un compromis difficile à trouver.

@ fklein-lu Je ne suis pas du tout d'accord Fieldmanager devrait être "l'outil de choix". Je ne le vois même pas dans la liste des 10 meilleurs plugins de champs.
https://github.com/WordPress/gutenberg/issues/952#issuecomment -320523428

Comme beaucoup d'autres l'ont dit, alors que je comprends le désir de faire des métaboxes et de Gutenberg une interface cohérente et connectée, changer le fonctionnement des métaboxes introduit des complexités incroyables qui peuvent finir par être un énorme dissuasif pour les gens. L'histoire nous a montré que l'introduction d'incompatibilités majeures entre les versions peut fortement fragmenter une communauté.

Comment ajouter des métaboxes à l'écran du backend du tableau de bord?
Cela n'a rien à voir avec Gutenberg.

@khromov Lisez ce que j'ai réellement écrit, au lieu de mal citer mes mots. De plus, si vous lisez le message auquel vous faites référence, vous sauriez pourquoi Fieldmanager ne figure pas dans la liste des dix premiers.

@ fklein-lu Je ne sais pas pourquoi vous pensez que je vous cite mal, voici le contexte complet: "Pour les métaboxes, Fieldmanager est l'outil de choix, car il est approuvé par VIP.". Je ne connais personne qui utilise Fieldmanager, j'ai donc du mal à comprendre cette citation.

Je sais que Fieldmanager n'est pas sur WPorg. Ce que je dis, c'est que nous n'avons pas de données d'utilisation. Je doute fortement qu'il rivalise avec certains des meilleurs plugins, et il a également très peu de soutien de la communauté, à part ceux qui l'utilisent pour VIP, qui est une petite minorité en voie de disparition du nombre total de développeurs.

Dans notre agence, nous pensons que quelque part dans 3.x WordPress est passé du système de blogs au système de gestion de contenu. À l'heure actuelle, nous sommes en mesure de façonner le contenu de la manière dont le projet a besoin et nous utilisons des types de publication personnalisés et des méta-boîtes pour créer une grande variété de contenus différents, pas seulement du texte.

Si l'éditeur de blocs devient obligatoire dans la version 5.0, nous croyons fermement que ce serait un recul idéologique du CMS au système de blogging. Il existe des tonnes d'applications d'entreprise, qui exécutent WordPress en tant que solution de réservation d'hôtel, plateforme d'emploi, CMS sans tête pour une application, services de localisation, etc., et beaucoup de ces cas d'utilisation n'ont même pas l'éditeur activé.

Une rétrocompatibilité totale avec l'implémentation actuelle de la metabox est un must absolu. Briser cela rompra la confiance avec les clients et les utilisateurs pour les années à venir. Ma solution préférée serait quelque chose sur les lignes du "theme_supports" et de la convivialité sans distraction.

TL; DR: Ne vous attendez pas à ce que les clients d'entreprise mettent à jour leur code dans les 12 prochains mois pour autre chose que la maintenance. Ajoutez une politique / un avertissement d'obsolescence avec un calendrier approprié. Attendez-vous à une énorme baisse de confiance dans WordPress, lorsque vous forcez un changement (même pour le meilleur) en termes de backend et de convivialité du code.

C'est devenu en quelque sorte la politique, ou le vote / les élections, pas le codage. Certains gens ont décidé que les anciennes métaboxes sont «anciennes», «arriérées», «limitantes», et il n'y a plus de place pour elles. Sans véritables arguments et raisons contre eux. Je ne les ai pas vus, sauf que React et d'autres scripts sont turbo-modernes.

Je vous aide toujours à trouver une solution pour abandonner les anciennes métaboxes et à le faire comme vous l'imaginiez à la manière de Gutenberg. Mais il semble que vous n'ayez aucune idée de comment le résoudre.

Difficile de discuter de tout ça alors que beaucoup reste pour moi un trou noir. Et je ne suis pas le seul.

Juste pour dire à quel point je suis objectif dans cette affaire, n'essayez pas de:

• Je pense toujours que TinyMce et l'ancien écran de publication (avec Metaboxes) sont quelque chose de plus beau que j'ai vu dans le monde CMS. Fonctions, filtres, extensions et beau design. Oui, pure beauté et plaisir.
• Malgré cela, j'ai accepté Gutenberg dès le premier jour. Oui, laissez tomber tout ce «vieux», changez et ne regardez jamais en arrière.

Ils savaient quelque chose que je ne sais pas. Ils possèdent du code. Mais je ne suis plus sûr.

Deuxième chose, je l'ai oublié, et c'est très important dans ce contexte. Il est déjà mentionné quelques fois ici.
Je fais les choses un peu différemment des autres. La raison pour laquelle j'ai accepté Gutenberg (l'un d'entre eux en tout cas) dès le premier jour est que personnellement, je n'aurai aucun problème pour convaincre les gens que j'ai créés de sites Web d'utiliser Gutenberg. C'est un gros choc lorsque vous leur forcez quelque chose d'aussi différent que TinyMce.
Je fais toutes les mises à jour du plugin et du noyau WP pour chacun d'eux gratuitement. Donc, dans ce dilemme, quand ils doivent choisir entre Gutenberg et arrêter toutes les mises à jour pour le reste du temps ,. Je pense que leur choix est évident,

De nombreux autres développeurs, entreprises, facturent les mises à jour. Donc, ce dilemme ne sera pas si facile alors.

@khromov Je travaille pour Alley, qui gère Fieldmanager. Nous surveillons activement le fil pendant que la direction du produit est déterminée. Il serait juste de dire que la base d'utilisateurs de WordPress.org n'utilise généralement pas Fieldmanager, mais que le plugin est largement adopté en tant que bibliothèque et cadre personnalisé / d'entreprise.

Je veux aussi +1 @Rarst et @kevinwhoffman. Le maintien de la prise en charge complète des métabox existantes pourrait encore permettre un avenir où nous remplacerions les métabox «héritées» par des équivalents TBD Gutenberg. Mais l'incertitude actuelle concernant la rétrocompatibilité doit être atténuée dès que possible.

Le nombre d'installations de plugins à partir de WordPress.org ne peut pas être la seule métrique pour l'inclusion ou l'exclusion d'un plugin ou d'une bibliothèque. Je connais un site unique qui utilise largement Fieldmanager et qui dessert près de 24 millions de visiteurs uniques par mois.

Ainsi, même si seul un petit nombre de développeurs peuvent utiliser un plug-in particulier, ils sont responsables du développement et de la maintenance de sites qui génèrent un trafic disproportionné et beaucoup de visibilité.

Ils ne peuvent donc pas être exclus de cette discussion. Je considère que l'équipe Gutenberg d'Automattic devrait collaborer avec l'équipe VIP pour avoir un aperçu de ces cas d'utilisation.

Ces projets d'entreprise évoluent à des vitesses plus lentes. Il y a beaucoup de travail à faire pour mettre à niveau les métaboxes et d'autres éléments de l'interface utilisateur qui ne sont pas un travail de codage réel. Il n'y a même pas assez de développeurs d'entreprise pour mettre à niveau tous ces sites dans la période 5.0.

Comme l'ont souligné d'autres personnes dans ce fil, il doit y avoir un chemin de mise à niveau qui prend en compte ce rythme. Ainsi, des changements peuvent se produire progressivement, dans le cadre d'un travail de maintenance proactif.

@ fklein-lu voir ci-dessus, nous sommes à votre écoute et vous pouvez toujours nous contacter si vous souhaitez collaborer sur du code!

En ce qui concerne VIP et le marché des entreprises, je pense qu'il y aura plus de quelques conversations sur ce sujet au WordCamp for Publishers la semaine prochaine à Denver . Cela dit, nous avons contacté les développeurs de Gutenberg et @m mais AFAIK aucun ne pourra y assister.

En ce qui concerne la chronologie "5.0", à ce stade, les ingénieurs d'entreprise que j'ai interviewés supposent qu'il y aurait un chemin de retrait assez facile pour utiliser l'éditeur TinyMCE et les métaboxes existants. Je pense que l'équipe de Gutenberg a également donné le 👍 à cette hypothèse.

Et j'ai un site Web qui utilise Jetpack et qui n'a que 2 visiteurs uniques par jour.
Arrêtez d'être si facilement offensé. C'est WordPress, pas une discussion sur la nouvelle version de Joomla. :)

@ fklein-lu Absolument d'accord avec vous. Mais si quelque chose devait être "l'outil de choix" pour les champs de métabox, je pense que ce serait l' API Fields proposée.

@davisshaver Je pense que c'est la

Merci à tous d'avoir sonné ici et d'avoir exprimé des préoccupations et des idées. Cela devient un long fil, mais je vais essayer de clarifier quelques points.

WordPress a-t-il l'intention de désapprouver formellement l'API Metabox?

Non.

La question qui n'a pas encore été entièrement répondue est _Comment fonctionnent les méta-boîtes dans le contexte de l'éditeur Gutenberg_. Devraient-ils rester les mêmes ou évoluer? Comment pouvons-nous progresser vers les objectifs de conception avec le moins de perturbations possible?

Ce problème persiste non pas par manque de désir, mais par manque de ressources. L'objectif principal de ce projet est d'offrir une interface d'édition de contenu riche qui optimise la manipulation directe du contenu utilisateur à travers la notion de blocs. (Ayant largement utilisé les méta-boîtes pour divers projets, je pense que les blocs peuvent offrir une meilleure avancée pour bon nombre de ces besoins tout en offrant une meilleure expérience utilisateur.)

Pourtant, il existe plusieurs façons de gérer les méta-boîtes et l'extensibilité:

• Si nous détectons qu'une méta-box est enregistrée, nous pouvons revenir à l'ancienne interface, rien ne change.
• Nous pourrions diviser l'édition du contenu et la modification des méta-informations en deux écrans ou étapes.
• Nous pouvons essayer de voir dans quelle mesure il est possible de les rendre tels quels (PHP) sous le contenu: # 2251.
• Un thème / plugin / CPT pourrait désinscrire la nouvelle interface si nécessaire.
• Divers éléments qui reposaient sur des méta-boîtes pourraient être convertis en blocs pour l'interface utilisateur (toujours en stockant les données séparément).
• Nous pourrions implémenter l'extensibilité des méta-boîtes basées sur l'API comme l'API Fields.

Ou toute combinaison de ceux-ci.

Nous apprécierions certainement l'aide de la communauté pour trouver la meilleure solution ici car, encore une fois, le manque de certitude n'est pas un manque de volonté; simplement que les solutions possibles doivent être explorées dans la pratique et les compromis - du point de vue de la conception et du développement - sont clairement définis.

Non.

Merci , je pense que beaucoup de gens ont juste expiré.

La question qui n'a pas encore été entièrement résolue est de savoir comment fonctionnent les méta-boîtes dans le contexte de l'éditeur gutenberg.

Pourquoi des méta-boîtes _are_ dans le contexte de l'éditeur Gutenberg?

La réponse semble être que Gutenberg vise à remplacer tout l'éditeur de publication _screen_ par une implémentation pilotée par JS. Je n'avais pas suivi le développement pour être conscient des raisons à cela.

Mais je pense toujours que c'était un point très valable soulevé - si la portée de Gutenberg est d'être un composant éditeur, alors le remplacement de la portée de _screen_ semble trop ambitieux. _Si_ la portée de Gutenberg est le remplacement (au moins partiel) de WordPress _admin_ dans son ensemble, elle est _ incroyablement_ plus large et plus exigeante. Non pas que le remplacement de l'éditeur «juste» soit simple.

Pourtant, il existe de multiples façons de gérer les méta-boîtes et l'extensibilité

Gutenberg est destiné à remplacer le composant principal _editor_ et l'interface utilisateur d'administration existante continue de fonctionner? Est-ce que cela est envisagé, sinon pourquoi?

Je ne peux parler que du plugin de gestion de terrain que j'ai construit et que nous utilisons actuellement dans plus de 60 projets différents pour le moment. Je mentionnerai brièvement ce que ce changement semble signifier pour lui dans l'espoir que cela puisse aider n'importe qui à réfléchir à son propre scénario.

Parce que j'ai eu la peine de construire une architecture hautement découplée avec des classes abstraites et des interfaces communes, il ne me restera plus qu'à ajouter un nouvel "emplacement". Voici les composants d'architecture qui sont pertinents à mon propos:

• Emplacement: où le groupe de champs est attaché (par exemple, article, page, terme de taxonomie, etc.), avec une variante pour chaque emplacement (par exemple, l'emplacement de l'article et des paramètres fonctionne avec des méta-boîtes). Cette classe instancie toutes les pièces mobiles mentionnées ci-dessous
• Magasin de données de localisation: la couche qui est responsable de la récupération et de la conservation des données, avec une variante pour chaque emplacement (par exemple, post DataStore fonctionne avec la méta de poste, Paramètres fonctionne avec des options, etc.)
• Vue d'emplacement: lorsque cela est nécessaire, comme c'est le cas pour la page des paramètres, c'est une classe View qui contient le modèle et toutes les fonctions d'assistance

Maintenant, dans le contexte de Gutenberg, si je veux supporter ce nouvel éditeur, tout ce que je devrai personnellement faire est d'ajouter un nouvel emplacement, appelé Gutenberg, et cet emplacement aura:

• Sa propre méthode d'initialisation qui le connectera à l'éditeur Gutenberg. J'imagine que ce sera principalement basé sur javascript, donc ma bibliothèque s'enregistrera et chargera les scripts communs nécessaires à cet effet.

• Sa propre vue / modèle: je devrai créer un composant de réaction pour chaque type de champ. Ce n'est pas un gros problème, la couche de vue est assez simple à créer lorsque toutes les autres pièces sont correctement configurées. Ces composants seront ensuite imbriqués dans le composant de réaction metabox. Tout cela est très similaire à ce que je fais déjà pour les métaboxes basées sur php html, c'est-à-dire les champs html> groupe de champs html> emplacement (page de paramètres html, metabox etc.)

• Sa propre classe de stockage de données. Je n'imagine pas que cette classe sera très différente du magasin de données de post-localisation, car ce sera basé sur la méta de publication (j'imagine que personne ne pense à désapprouver la méta de publication de si tôt).

• Nouvelle pièce: les extrémités. Ces nouveaux composants basés sur les réactions devront pouvoir communiquer avec le magasin de données pour récupérer et conserver les valeurs. Comme ceux-ci vivent complètement du côté client, ils auront besoin de points de terminaison comme pont pour parler avec le magasin de données de localisation, avec le méta-magasin pour récupérer les composants qui doivent être chargés dans n'importe quel contexte, etc.

Si je ne manque rien de majeur (j'avoue que je n'ai pas encore eu le temps de vérifier Gutenberg) c'est plus ou moins l'essentiel de ce que je pense que je devrais faire pour supporter nativement ce nouvel "emplacement". J'ai également des vérifications intégrées pour chaque emplacement et ses filtres pour m'assurer que ce que le développeur demande est possible, par exemple si j'essaie d'ajouter un groupe de champs à un type de message "projets" où le format si le type de message est "vidéo ", mais que CPT ne prend pas en charge les formats de publication, la bibliothèque lèvera une exception. J'espère que je serai en mesure de fournir les mêmes commentaires avec ce nouvel emplacement, par exemple si j'ajoute un groupe de champs à un emplacement Gutenberg où le type de publication est "avis", j'espère que je serai en mesure de savoir si ce type de message a été enregistré pour soutenir Gutenberg.

Cela a fini par être un peu plus long que ce que j'avais prévu, mon mal. J'adorerais avoir des nouvelles de toute personne impliquée dans le développement de Gutenberg ou de tout auteur de bibliothèques ayant des préoccupations similaires et qui ont des commentaires à partager.

Merci.

Gutenberg est destiné à remplacer le composant principal de l'éditeur et l'interface utilisateur d'administration existante continue de fonctionner? Est-ce envisagé, sinon pourquoi?

Gutenberg n'a commencé qu'avec la boîte de l'éditeur. L'objectif du coup d'envoi était d'unifier plusieurs interfaces disparates sous une seule interface de bloc unifiée. Il est rapidement devenu évident que pour que nous puissions créer une expérience convaincante autour de cette interface de bloc unifiée, nous devions considérer le flux d'écriture complet, y compris les paramètres et la publication.

Si la principale force de WordPress est de permettre à quiconque de créer facilement des articles riches, nous ne pouvons pas simplement concevoir pour ceux d'entre nous qui savent déjà comment utiliser l'éditeur. Nous devons prendre en compte les utilisateurs qui n'ont jamais utilisé WordPress auparavant et ce qu'ils attendent d'une interface de publication moderne. Sinon, nous ajouterions simplement une charge cognitive à une interface déjà lourde.

Nous n'avons pas encore terminé, et ce n'est pas facile, mais nous y travaillons tous les jours.

☝️ J'ai mis à jour le titre et la description du ticket pour corriger, espérons-le, certaines idées fausses.

Le nouvel éditeur Gutenberg et l'avenir de ButterBean

Comme demandé dans le commentaire ci -

Repo: https://github.com/justintadlock/butterbean/tree/dev

À des fins de test, le framework est inclus dans ce plugin: https://github.com/justintadlock/custom-content-portfolio

ButterBean est un framework intégré construit avec Backbone.js et Underscore.js. Il est largement modélisé à partir du personnalisateur du noyau WP.

C'est un jeune framework, mais c'est celui que j'ai prévu d'intégrer dans plusieurs plugins cette année. À l'heure actuelle, moi et d'autres hésitons à le faire à cause de la direction de Gutenberg. Et, je ne suis même pas sûr si je ne devrais pas simplement recommencer à zéro dans React ou quel que soit le framework JS qui sera finalement décidé pour être ajouté au noyau WP ensuite.

Crochets utilisés

Voici les principaux hooks WP utilisés (assez standard pour la plupart des frameworks de méta-boîtes, j'imagine):

load-post.php
load-post-new.php 
add_meta_boxes
save_post 
admin_enqueue_scripts
admin_footer 
admin_print_footer_scripts

Créé # 2265 pour documenter les hooks pertinents pour CMB2.

Ajout d'une étiquette de conception pour encourager les gens à ajouter des maquettes supplémentaires.

En général, je pense que les données qui ne font pas partie du contenu affiché ne devraient pas faire partie de la zone principale de l'éditeur. Tout n'est pas un bloc.

1) La majorité de mes méta-boîtes personnalisées sont faites avec Fieldmanager . À mes yeux, ceux-ci devraient "juste travailler" sans travail supplémentaire de ma part en plus de la mise à jour. cc / @mboynes et @bcampeau car ils peuvent être en mesure d'apporter de la valeur à cette discussion.

2) Certaines de nos méta-boîtes personnalisées sont un mélange de jQuery et de PHP. Par exemple, nous avons une méta-boîte "One or none" qui est une radio avec un bouton "clear". En supposant que cela se cassera, je m'attendrais à ce qu'il y ait des exemples de la façon dont je crée cela dans Gutenberg et qu'il me reste beaucoup de temps pour passer à une version de WordPress qui rend obligatoire Gutenberg avant que mon code ne casse.

3) J'ai une autre metabox qui combine du code jQuery et PHP qui désactive le bouton de publication jusqu'à ce qu'une sélection ait été faite. Similaire à mon deuxième exemple, en supposant que cela se cassera, je m'attendrais à ce qu'il y ait des exemples de la façon dont je crée cela dans Gutenberg et qu'il me reste beaucoup de temps pour passer à une version de WordPress qui oblige Gutenberg avant mon code se brise.

4) J'ai supprimé la méta-boîte de catégorie dans le passé et l'ai remplacée par: 1) une sélection radio 2) Une version sans possibilité d'ajouter de nouvelles catégories (c'était stupide).

5) J'ai utilisé post_submitbox_misc_actions pour ajouter des options à la métabox de publication qui n'ont pas besoin d'être dans leur propre métabox.

En ce qui concerne ce que je veux dire par un laps de temps significatif, je dirais ~ 2 ans à partir du moment où l'API Gutenberg est gelée.

Pendant que nous y sommes, j'aime rappeler à tout le monde ici que tout le monde n'utilise pas que des métaboxes pour étendre l'écran de publication. Certains d'entre nous utilisent également les crochets suivants:

• 'edit_form_top'
• 'edit_form_after_title'
• 'edit_form_before_permalink'
• 'edit_form_after_editor'
• 'edit_form_advanced'

Je veux juste revenir sur ce que edit_form_[POSITION] hooks. Piklist fait un usage intensif des méta-boîtes, des flux de travail et d'autres choses.

Merci encore pour votre temps les gars.

Il est important de répondre dès que possible à la question de savoir si Gutenberg est un remplacement d'éditeur ou un remplacement d'écran, non seulement pour ceux qui sont concernés par la rétrocompatibilité, mais aussi pour ceux qui développent Gutenberg. La réponse à cette question affecte de nombreuses décisions prises chaque jour concernant le fonctionnement de Gutenberg et l'emplacement des contrôles.

Il est clair depuis la première version bêta que nous sommes déjà bien sur la voie d'un remplacement d'écran, mais cette décision de refondre l'écran est également ce qui a créé les problèmes de prise en charge de la méta-boîte et des crochets manquants. Si la réponse à ces problèmes est «ne remplacez pas tout l'écran», je crains que tant de travail ait déjà été fait sous l'hypothèse du remplacement de l'écran qu'il serait difficile de revenir en arrière.

Tout d'abord, c'est formidable de voir de réels progrès à ce sujet.

Une observation est que les extensions d'écran d'édition fonctionnent rarement isolément. Par exemple, ACF modifie les champs visibles en fonction des événements de changement JS dans la boîte de sélection post-parent.

Étant donné que le DOM sera différent dans un contexte de Gutenburg, et que React est probablement moins adapté aux écouteurs d'événements externes, comment continuer à rendre ces données disponibles aux métaboxes et à d'autres codes de plugins. Une possibilité est que le magasin Redux soit mis à la disposition des métaboxes, mais je ne sais pas si cela est possible, souhaité ou donne suffisamment de flexibilité.

Cela devient encore plus problématique lorsque les métaboxes sont chargées dans une iframe ou ajaxées dans la page.

Il est clair depuis la première version bêta que nous sommes déjà bien sur la voie d'un remplacement d'écran, mais cette décision de refondre l'écran est également ce qui a créé les problèmes de prise en charge de la méta-boîte et des crochets manquants. Si la réponse à ces problèmes est «ne remplacez pas tout l'écran», je crains que tant de travail ait déjà été fait sous l'hypothèse du remplacement de l'écran qu'il serait difficile de revenir en arrière.

Je comprends tout à fait combien de travail a été fait pour l'approche de remplacement «écran». Mais un projet qui a démarré avec l'objectif d'un remplacement "post-éditeur de contenu" n'aurait pas dû revenir dans la communauté avant de décider unilatéralement qu'il remplacerait tout l'écran de l'éditeur?

Je ne veux pas rejeter l'énorme travail qui a été fait (l'éditeur a vraiment l'air incroyable), mais trop de WordPress repose sur des méta-champs qui ne sont pas strictement "contenu", et beaucoup d'entre eux ne rentreront pas du tout dans le même conteneur Gutenberg (à moins qu'il ne soit complètement forcé). Pour moi, cela ressemble plus à "nous avons une solution et devons créer un problème pour cela" que l'inverse, ce qui était la déclaration originale de Gutenberg (l'éditeur de contenu de publication est assez compliqué, les codes courts sont tout sauf faciles à utiliser - malgré des approches comme Shortcake -, etc.).

La maquette de

@rilwis Je pense que vous devriez passer et mentionner l'utilisation extensive des Metaboxes dans votre plugin. Puisque je l'utilise dans la plupart de mes produits, je trouve qu'il s'agit d'un cadre étendu. Comment cela s'intègre-t-il dans toute cette histoire de Gutenberg? - Les idées de quelqu'un dont l'activité est de vendre un plugin pour créer une metabox (qui sera le plus affecté) devraient être utiles ici.

Pour une inspiration de conception, vous pouvez consulter les thèmes d'administration backend gratuits et commerciaux (captures d'écran). Ou toute autre plateforme.

Tableau de bord, mais imaginez Gutenberg:

Peut-être que l' API Fields proposée résoudra certains des problèmes liés à la prise en charge des métaboxes dans le nouvel éditeur

Le scénario que nous devrions envisager est ce qui se passe lorsque WordPress est mis à jour avec Gutenberg et que les plugins qui ont implémenté les méta-boîtes ne le sont pas .

C'est le «pire des cas» qui représente la plus grande menace pour briser l'expérience d'administration, mais il ne sera pas rare étant donné le nombre de sites alimentés par des plugins de méta-boîte, y compris les grands joueurs et les solutions uniques personnalisées.

La mise à jour de ces plugins de méta-boîte ne devrait pas faire partie de l'équation à moins que nous ne soyons disposés à reconnaître les changements de rupture à grande échelle. L'API Fields est une excellente idée, mais nous ne devons pas supposer que l'amélioration de la gestion des champs personnalisés à l'avenir aura un impact sur le code qui a été écrit avant qu'une telle API n'existe.

Il est clair que:

• Nous n'allons pas rompre la rétrocompatibilité à grande échelle.
• Nous n'allons pas bifurquer la page de l'éditeur en utilisant un mécanisme de détection.
• Nous aurons un seul éditeur et une seule expérience d'édition.
• Il existe de nombreux cas d'utilisation ci-dessus que l'implémentation actuelle de Gutenberg ne peut pas accueillir.

Par conséquent:

La voie à suivre est de repenser l'écran de modification des publications d'une manière qui englobe le nouveau et l'ancien. Cela signifie très probablement revenir en arrière sur l'implémentation actuelle de Gutenberg d'une manière ou d'une autre. C'est un défi de conception, pas la fin du monde.

@dmccan Non, ces déclarations ne sont pas "claires" car toutes les solutions proposées jusqu'ici non plus:

• Divise l'expérience d'administration entre nouveau / ancien.
• S'appuie sur les mises à jour des plugins pour bloquer leurs méta-boîtes.
• S'appuie sur une API Fields inexistante.
• Nécessite la désinscription de la nouvelle interface pour éviter complètement le problème, ce qui diviserait à nouveau l'expérience d'administration.

Je n'ai pas insisté sur le fait que le pire des cas était mélodramatique; Je l'ai fait pour définir les contraintes dans lesquelles nous devrions aborder le problème.

Il semble donc que Gutenberg devrait probablement rester un plugin de fonctionnalités pendant longtemps, un plugin que les gens peuvent choisir de sélectionner s'ils le souhaitent ou de se retirer sinon, peut-être même d'être inclus en tant que plugin avec noyau.

Résoudre tous les problèmes qu'il doit résoudre pour avoir une seule expérience d'édition prendra beaucoup de temps. Regardez simplement ASP.NET original de Microsoft et à quel point il a résolu le problème Web général. Finalement, AJAX a émergé et le reste appartient à l'histoire.

Forcer un changement trop rapidement pourrait faire de WordPress une véritable plate-forme héritée uniquement.

PS L'exigence d'un "éditeur unique" semble irréaliste. Si les utilisateurs avaient la possibilité d'utiliser l'ancien ou le nouveau, le nouveau pourrait être autorisé à évoluer au fil du temps jusqu'à ce qu'il n'y ait plus aucun avantage à utiliser l'ancien. Mais tant qu'il y a des installations utilisant les hooks existants _ (je crois) _, il est irresponsable d'utiliser une solution d'éditeur unique. #jmtcw

@kevinwhoffman - Je pense que nous sommes d'accord, mais peut-être que je n'ai pas été assez bavard.

Je pense que mes puces sont claires et que la solution finale les adoptera. Par exemple, je ne pense pas que WordPress rompra la rétrocompatibilité à grande échelle, malgré ce que les personnes à la recherche de solutions pourraient proposer à ce stade.

Les solutions proposées jusqu'à présent font défaut, et c'est là que je conclus, que nous devons repenser la mise en œuvre actuelle de Gutenberg pour englober à la fois les nouveaux et les anciens. Je pense que cela est vraiment la seule voie à suivre.

@mikeschinkel - Je n'imagine pas que Gutenberg sera la seule option d'éditeur dans Core en 2017. Il se pourrait bien que cela commence comme un choix d'utilisateur et évolue au point qu'il couvre toutes les bases essentielles, ou il prend le il est temps de bien faire les choses.

Quoi qu'il en soit, ce que je suggère, c'est un retour en arrière pour incorporer Gutenberg dans une version améliorée de l'écran de l'éditeur actuel, plutôt que de tout jeter et de se demander comment nous pourrions gérer toutes les fonctions essentielles. Je pense que c'est faisable et peut-être pas un énorme retour en arrière, une fois que les gens ont accepté. Un tel cours serait probablement plus rapide et offrirait une meilleure expérience à l'utilisateur final.

Peut-être qu'ils (les codeurs principaux) devraient parler au Matt. Il a commencé tout cela et ils n'ont plus de réponses.

@dmccan Une chose qui, je crois, sera d'une importance cruciale est que tout ce qui est implémenté a un modèle d'extensibilité facile. WordPress est connu pour son modèle d'extensibilité facile avec une action de plugin et des crochets de filtre et sans cela, Gutenberg sera aussi mauvais pour WordPress que le système de gestion des médias actuel qui est très difficile à étendre.

En passant, même si je n'ai jamais utilisé React ou Vue _ (je suis un développeur PHP) _ la discussion sur React nécessitant un système de construction et le fait que de nombreuses personnes ont trouvé Vue beaucoup plus facile à utiliser que React m'a rendu très anxieux. si Gutenburg aura ou non un modèle d'extensibilité facile à apprendre et à utiliser, et si cela signifie ou non que nous pouvons continuer à utiliser WordPress pour les projets clients.

Juste mon retour pour noter mon inquiétude, pas besoin de répondre directement à cela.

Je pense que je sais de quoi il s'agit.
Il n'a jamais été question d'éditeur de contenu, jamais de "flux d'écriture", de "rupture avec l'ancien .... en arrière" etc ...

Il s'agit d'un éditeur de thème visuel frontal plein de sang.

Désolé pour l'envoi de courriels à vous tous. Mon dernier commentaire sur cette question particulière.

@Rarst @kevinwhoffman : Je suis totalement d' éditeur ou un remplacement d'

De plus, j'ai créé # 2308 pour lister les hooks pertinents du plugin Meta Box.

@ahmadawais Merci pour la mention.

@nylen Il vaudrait la peine d'ajouter Posts 2 Posts à la liste des plugins à considérer. Bien qu'il ne soit plus pris en charge, je pense qu'il est encore assez largement utilisé.

@nylen Je maintiens les champs personnalisés du développeur de mon plugin mais il n'est plus activement développé (j'utilise CMB2 ces jours-ci). Plus de 1000 installations actives, mais cela vaut peut-être la peine d'être ajouté à la liste.

Je suis d'accord avec les commentaires sur Gutenberg Editor étant juste cela, la partie d'édition de contenu. Je ne sais pas pourquoi ni comment il a été détourné pour devenir un remplacement d'écran complet. Tous les constructeurs de pages populaires le font correctement, il suffit de remplacer TinyMCE par quelque chose d'autre qui facilite la composition du contenu.

De plus, les méta-boîtes ne font généralement pas partie du contenu, et même si elles sont liées au contenu, elles n'ont généralement pas de sens pour être un bloc.

Prenons par exemple un annuaire du personnel. Pourquoi voudrais-je que les champs des informations sur les personnes soient un bloc? Ce n'est pas comme si vous vouliez qu'ils ajoutent d'autres blocs alors qu'ils sont simplement censés entrer le prénom, le nom, etc.

tldr; Gutenberg ne devrait remplacer l'éditeur TinyMCE que pour les types de publication nécessitant une composition de contenu.

Juste ajouter mes deux cents ici.

Pourquoi ne pas le laisser tel quel maintenant? Ce que je veux dire, c'est ceci.

• Conservez les deux options d'édition lorsque vous survolez le titre de l'article comme il est maintenant, mais changez-le pour que, par défaut, cliquez sur le titre pour vous amener à Gutenberg. Ensuite, demandez au lien Edit aller à Gutenberg et d'avoir un lien supplémentaire vers l'écran d'édition des classes. Peut-être l'appeler quelque chose comme Classic Edit .
• Ajoutez un type d'indicateur de support pour le type de publication de publication et de page, afin que Gutenberg puisse être désactivé si un développeur le souhaite. Si Gutenberg n'est pas activé, faites en sorte que le lien du titre accède à la page d'édition "classique", supprimez le lien Edit vers Gutenberg et le texte du lien Classic Edit deviendrait Edit
• Ensuite, avec les types de publication personnalisés, le support de Gutenberg, comme l'éditeur, l'image en vedette, etc.
• Mettez ensuite à jour le style des pages d'édition classiques. Mise à jour des méta-boîtes et des styles de la barre latérale pour correspondre au style de Gutenberg. Déplacez même les méta-boîtes d'extrait et de commentaires dans les barres latérales comme dans Gutenberg.

Je pense que cela rendrait tout le monde heureux. Gutenberg serait activé par défaut pour les types d'articles Post et Page. Si les développeurs ont besoin d'utiliser des méta-boîtes au lieu de Gutengerg, ils le peuvent. Cela donnerait aux plugins et aux développeurs de thèmes le temps de se convertir à Gutenberg et donnerait aux utilisateurs finaux la possibilité de s'adapter à Gutenberg sans interférer avec leur flux de travail par le changement d'éditeur.

Et cela donnera aux développeurs le temps de commencer à vendre l'idée d'utiliser Gutenberg aux utilisateurs finaux. Les gens ont tendance à ne pas aimer le changement. Les laisser s'habituer au nouvel éditeur serait bien mieux qu'un simple changement radical.

Cela séparerait également les deux, ce qui permettrait les deux méthodes de sauvegarde différentes. Gutenberg peut utiliser JS et Classic peut continuer à utiliser PHP.

J'ajouterais un type d'avertissement comme si un utilisateur enregistrait un message avec Gutenberg puis essayait de le modifier avec classique pour lui faire savoir que s'il enregistrait le message, il remplacera la sauvegarde précédente du message de l'autre éditeur. Il pourrait y avoir quelque chose comme une méta de publication pour indiquer quel éditeur a été utilisé en dernier.

C'est une idée. C'est peut-être une idée stupide, mais je pense que cela atténuerait toutes les inquiétudes que beaucoup de développeurs ont.

Je suis tout à fait d'accord avec les points soulevés par de nombreuses personnes au sujet de la portée de Gutenberg aujourd'hui. Ce projet a d'abord commencé comme une amélioration (indispensable) de l'éditeur de contenu. En lisant ce fil de discussion, je ne peux m'empêcher de penser que nous créons des problèmes qui n'ont pas besoin d'exister . Si nous nous en tenons au plan original d'ajouter Gutenberg à l'éditeur (sans remplacer le plein écran), cela résout tant de problèmes, pas seulement en ce qui concerne les Meta Boxes.

En réorganisant complètement l'écran, je crains que cela ne cause autant de problèmes aux éditeurs de contenu non technophiles. Le blogueur / auteur moyen va voir un écran complètement différent et paniquer. Si la mise à jour cible simplement l'éditeur, l'expérience d'intégration peut être beaucoup plus contrôlée.

Une autre façon d'aborder cela pourrait être d'utiliser le même flux de travail que Beaver Builder . C'est-à-dire conserver la page d'édition de publication normale (avec les sections habituelles de Meta Box, etc.), puis Gutenberg pourrait être lancé via un bouton. Cela peut alors vous amener à un nouvel écran. Tout comme les commentaires sur le ciblage du mode d'écriture sans distraction.

Je suis également d'accord avec les gens qui suggèrent de conserver l'interface utilisateur de la meta box existante et de ne changer que l'éditeur de contenu.

Je pense que la plupart d'entre nous reconnaissent que le principal facteur pour faire avancer une plateforme est d'innover. Il est évident que WordPress essaie lentement d'évoluer vers une approche basée sur JS pour des expériences plus riches qui peuvent correspondre (et surpasser!) À ce que tout le monde fait. Si nous sommes honnêtes, tout le système de métaboxes et l'interface utilisateur actuelle de l'écran d'édition peuvent sembler quelque peu datés, mais en tant que développeurs, nous y sommes tellement habitués que c'est une seconde nature pour nous et nous ne prenons pas en compte à quel point la courbe d'apprentissage est là. est à lui.

La lecture de tout ce fil clarifie deux choses pour moi:

• Il est évident que l'équipe principale veut faire pression pour un écran d'édition entièrement basé sur js, et ça va
• Peut-être que si nous pouvons tous accepter le point ci-dessus, nous pouvons faire évoluer la conversation vers le soutien hérité et les stratégies de migration à poursuivre

Dès que nous comprendrons comment la version js des métaboxes fonctionnera finalement (existe-t-il une API proposée?), Nous pourrons commencer à réfléchir à la manière de créer un pont qui rend notre technologie existante (plugins, gestionnaires de champs, etc.) travailler avec cette nouvelle approche.

Si une discussion axée sur l'API est déjà en cours, quelqu'un pourrait-il me diriger, moi et quelqu'un d'autre qui ne sait pas où cela se passe dans la bonne direction? Merci!

Y a-t-il une raison de ne pas diviser l'éditeur en deux écrans parcourus par des onglets?

Mon avis est que Gutenberg est,

• Une tentative pour ranger l'écran de l'éditeur
• Une tentative pour ajouter une fonctionnalité de création de page / mise en page au cœur
• Une tentative de minimiser le besoin de métaboxes en facilitant la création de nouveaux blocs de contenu pour les développeurs.

Le problème, comme souligné ci-dessus et comme la plupart d'entre nous, développeurs et utilisateurs finaux, pouvons le ressentir et le prévoir, c'est que Gutenberg,

• Supprime les choix de format de style d'éditeur des auteurs
• Oblige les auteurs à utiliser un flux de travail non intuitif qui nécessite de nombreux clics de souris pour ajouter des blocs
• Rupture de nombreux plugins plus anciens, dont certains sont maintenus et d'autres non.
• Convertit WordPress en ce qui ressemble à une plate-forme Tweet.

Utiliser Guttenberg pour créer du contenu présente la même maladresse que la conception d'un modèle d'e-mail dans Mautic ou MailChimp. L'interface utilisateur de Guttenberg fonctionnerait bien pour la conception de modèles, mais pas pour la création de post longs.

Nous devons nous concentrer sur l'augmentation de la fluidité du flux de travail, et non sur l'introduction d'une interface utilisateur de création de contenu stop-start.

L'interface utilisateur de Guttenberg a fière allure, mais il n'est pas réaliste de s'attendre à ce que les utilisateurs finaux en soient satisfaits alors qu'elle est proche de sa forme actuelle. Cela entrave la création de contenu.

Le bloc de texte est presque inutile. Un widget de texte ne doit pas limiter les auteurs à l'utilisation de quelques formats de police seulement. Cela ennuiera de nombreux auteurs.

Voici mes suggestions:

• Introduisez les écrans d'édition Tabify dans l'éditeur de page.
• Déplacez les métabox dans leur propre onglet de page dans l'écran de l'éditeur.
• Utilisez une page non basée sur React pour les métaboxes (page cachée derrière un onglet éditeur)
• Utilisez un canevas basé sur TinyMCE par défaut (ou un éditeur riche en fonctionnalités similaires) qui fonctionne bien pour les longues formes et qui n'insiste pas pour que les auteurs utilisent des blocs.
• Présentez Guttenberg Blocks en tant qu'addon à TinyMCE ou au sosie de TinyMCE.
• Présentez Shortcake à l'éditeur basé sur TinyMCE de sorte que les auteurs puissent voir visuellement le contenu des blocs et que les auteurs puissent modifier le contenu directement dans le flux de la page sans avoir besoin de cliquer sur un bouton d'édition pour chaque bloc.
• Aidez les développeurs à ajouter de nouveaux blocs à Guttenberg en associant add_shortcode () à la création de bloc, par exemple add_shortcode ('tag', 'function', 'guttenberg true / false'). Adaptez add_shortcode pour qu'il rende automatiquement le shortcode compatible avec Guttenberg; cela permettra aux développeurs de convertir facilement certains / plusieurs de leurs métaboxes en shortcodes fonctionnant dans Guttenberg.

Ce que je dis vraiment, c'est que Guttenberg doit être divisé en 3 tâches:

• Nettoyage de l'écran de l'éditeur
• Interface utilisateur améliorée de l'éditeur
• Amélioration du cadre d'extension de l'éditeur.

Je dirais que la plupart des gens utilisent WordPress pour créer du contenu de longue durée et ne souhaitent pas être forcés d'utiliser des blocs pour créer leur contenu. Les blocs sont parfaits pour la création de mise en page, mais ennuyeux lorsqu'ils sont utilisés à chaque fois qu'un article est écrit.

J'ai une cliente qui a 80 ans. Elle veut juste créer du contenu. Elle ne veut pas être obligée de réapprendre à utiliser l'écran de l'éditeur. Il lui a fallu plus d'un an pour s'habituer à Visual Composer et c'est un constructeur de pages facile à utiliser.

Je me suis éloigné du sujet du fil d'origine, mais cela doit être dit: Guttenberg va tuer WordPress.

Si Guttenberg est introduit dans sa forme actuelle, WordPress sera fourchu et la version Guttenberg mourra.

Peut-être que le nouvel éditeur a plus de sens si vous utilisez WordPress pour un site de blogage et créez un thème PHP pour celui-ci, mais de nos jours, beaucoup de gens utilisent WordPress comme CMS pour créer des applications Web à l'aide de React, PODS / ACF et l'API REST de WordPress. D'où la nécessité de prendre en charge les métaboxes et les champs Relation pour une liaison avancée entre les CPT.

Tout d'abord, je pense que Gutenberg va être génial.

Cela étant dit, je pense que nous pouvons tous convenir que la rupture des sites Web / fonctionnalités brise la confiance, et ce n'est pas cool. Nous voulons tous pouvoir nous faire confiance, et nos clients veulent / doivent nous faire confiance.

Je pense que la meilleure chose que nous puissions faire est d'inclure un filtre que les développeurs peuvent utiliser pour revenir à l'écran de l'éditeur "hérité".

De cette façon, nous pouvons appliquer notre propre logique pour déterminer si nous sommes prêts pour Gutenberg ou non. Si un utilisateur utilise une méta-boîte qui va se casser complètement dans Gutenberg, nous pouvons choisir de revenir au mode hérité.

Ensuite, nous pouvons travailler à notre rythme pour migrer nos méta-boîtes ou nos idées pour les adapter à Gutenberg, tout en conservant les anciens messages qui dépendent de nos méta-boîtes «héritées» fonctionnant comme il se doit.

Pourquoi les anciennes métaboxes ne peuvent-elles pas être rendues aux emplacements (contexte) pour lesquels elles sont enregistrées et continuer à fonctionner comme elles le font actuellement?

Donc, commencez par afficher la section (facultative) de l'éditeur Gutenberg, suivie de toute méta-boîte de contexte normale / avancée enregistrée (héritée) (avec son titre enregistré), puis de la barre latérale avec la nouvelle colonne Paramètres de publication et sous ce côté enregistré (hérité). context meta box (avec son titre enregistré).

Bien sûr, la méta-boîte héritée aurait le même style que la nouvelle boîte de paramètres de publication, tout aurait l'air bien intégré.

Peut-être que cela nécessiterait un script legacy-meta-box.php qui serait chargé en cas de besoin, par exemple lorsque add_meta_box est appelé.

Si nous ne considérons que les solutions de méta-box actuelles comme des «héritages» et que nous leur demandons d'utiliser l'ancien éditeur sans jamais réfléchir aux raisons de les utiliser en premier lieu, puis de travailler sur de meilleures façons de fournir cette fonctionnalité dans le nouvel éditeur, alors Les sites actuels resteront simplement hérités et ne seront jamais mis à niveau. Ce sera un énorme problème pour les utilisateurs qui gèrent les sites clients.

La raison pour laquelle nous utilisons les champs ACF dans presque tous nos projets est de contrôler les données afin qu'elles soient affichées de manière cohérente sur le site Web. Voici deux exemples sur lesquels nous travaillons actuellement; Un grand site d'événements et un festival avec des œuvres / installations qui doivent être liées aux artistes mais affichées séparément. Dans ces deux cas, le «contenu», la pièce que Gutenberg remplace ne représente qu'environ 10% du contenu de l'écran d'édition et est en fait la pièce la moins importante. Pour le site d'événements, les données importantes sont le type d'événement, la catégorie d'événement, la date, l'heure, le lieu, l'organisateur, etc. Vous pouvez publier une entrée d'événement significative sans entrer de contenu dans l'éditeur. Pour le site du festival, nous devons être en mesure de sélectionner un artiste et de le lier à une œuvre, de sélectionner l'emplacement des œuvres sur le site du festival et de télécharger une image en vedette, encore une fois, le contenu est un supplément et non une nécessité. Pour tout le contenu de page «normal» sur ces sites, Gutenberg n'est pas assez flexible (et il ne devrait pas non plus l'être par défaut, je ne crois pas) et nous continuerions à utiliser un générateur de page plus complet (Beaver Builder) pour mieux options de conception.

L'autre facteur clé dans tout cela est l'ordre du contenu sur l'écran d'édition. Pour un événement, vous devez définir un titre, mais dans un flux d'édition idéal, vous voulez certaines des informations clés comme la date, l'heure, etc. entrées AVANT de saisir un "contenu" dans "l'éditeur". Nous devons avoir la possibilité de contrôler où dans la page d'édition se trouve le contenu, avant ou après le «contenu».

L'idée de créer simplement un autre onglet avec toutes les méta-boîtes "héritées" serait horrible. Cela briserait complètement le flux d'édition pour de nombreuses utilisations des CPT, cachant le contenu aux utilisateurs d'une manière que je pense qu'ils trouveraient très difficile à découvrir.

Le projet doit être BEAUCOUP plus intelligent à ce sujet. Un processus à onglets pourrait fonctionner très bien si vous pouviez choisir (dans une sorte de modèle de page) quels bits se trouvaient sur quel onglet. Vous auriez également besoin d'un mécanisme pour guider l'utilisateur à travers chaque onglet. Cependant, je pense également que pour les articles CPT plus courts, vous DEVEZ avoir la possibilité de tout garder sur une seule page avec certains éléments clés au-dessus du contenu de l'éditeur (blocs requis si vous voulez).

Dans l'ensemble, la plupart des solutions dont les gens parlent ne semblent pas avoir la flexibilité de l'écran d'édition actuel.

C'est pourquoi j'ai peur de la chronologie de 5.0 pour cela, j'ai l'impression que cela pourrait être génial dans le temps, mais si elle est précipitée, la fragmentation détruira toute la bonne volonté des développeurs et des clients. WordPress échange sur sa flexibilité, sa compatibilité ascendante et sa convivialité générale. Nous ne pouvons pas sacrifier cela pour le nouveau jouet brillant. Regardez les exigences PHP pour WordPress, nous parlons littéralement des années avant que PHP 5.6 ou 7 ne soit une exigence. La communauté a reconnu que peu importe à quel point ce délai est frustrant, il est nécessaire de ne pas casser les sites Web. N'est-ce pas exactement le même genre de problème?

Des changements comme celui-ci, alors qu'en fin de compte, ils seront excellents pour que la plate-forme soit bien pensée et gérée, sinon ils risquent les fondations mêmes sur lesquelles WordPress est construit.

@avocadesign - Quelques bons points. Nous serons en mesure d'enregistrer les méta-boîtes JavaScript à l'avenir, bien qu'il semble que la pensée actuelle soit d'avoir deux emplacements ... ce qui n'est pas aussi flexible que vous l'avez mentionné.

@avocadesign - bien expliqué. Le post_content n'est pas toujours au centre d'un article et vos «événements et artistes» en sont un bon exemple. Ce serait formidable de voir des captures d'écran montrant le back-end et le front-end de ces types de publication afin que nous puissions aider les développeurs à visualiser comment WP est utilisé en tant que CMS et comment un client typique fonctionne via un écran de post-édition.

@avocadesign

Si nous ne considérons jamais que les solutions de méta-box actuelles comme «héritées» et que nous leur demandons d'utiliser l'ancien éditeur

Dans ce que j'ai suggéré (au-dessus de votre commentaire), les méta-boîtes `` héritées '' sont positionnées soit sous l'éditeur Gutenberg (si le type de publication en a besoin), soit sous le bloc Paramètres de publication (en fonction du contexte dans lequel elles sont enregistrées). Je ne vois aucune obligation de conserver l'ancien éditeur.

Je suis d'accord qu'une interface à onglets ne fonctionnerait pas. Que pensez-vous de ma suggestion. À mon avis, cela vous donnerait toute la flexibilité à laquelle vous êtes habitué et vous permettrait de passer au nouveau système lorsque vous êtes prêt.

Si Gutenberg faisait partie du noyau, vous seriez en mesure de créer une interface utilisateur encore meilleure pour les échantillons que vous mentionnez. Il se composerait en partie d'un bloc Festival personnalisé (sorte de formulaire WYSIWYG) et des paramètres associés dans une ou plusieurs sections de paramètres de publication (basées sur JS). L'utilisateur bénéficierait d'une interface plus rapide avec une rétroaction directe.

WordPress échange sur sa flexibilité, sa compatibilité ascendante et sa convivialité générale. Nous ne pouvons pas sacrifier cela pour le nouveau jouet brillant.

Je ne suis pas d'accord. Je pense que vous devriez donner un peu plus de crédit au Gutenberg. Ils travaillent dur sur une solution qui fonctionne pour tout le monde. Ils écoutent et recherchent des cas d'utilisation (comme celui que vous mentionnez). Rien n'est encore gravé dans la pierre, ni la version dont Gutenberg «pourrait» faire partie.
Si Gutenberg ne résout pas tous les problèmes actuellement en discussion, vous pouvez être sûr qu'il ne fera pas partie de la version 5.0. Nous avons vu cela se produire dans le passé à plusieurs reprises avec d'autres fonctionnalités également.

Voici un exemple d'interface que j'ai créée avec des champs personnalisés avancés pour un client qui gère des propriétés hôtelières.

• Le type de publication personnalisé Propriété utilise 18 champs personnalisés répartis sur 10 onglets.
• Les onglets conservent toutes les informations pertinentes sur un seul écran et accessibles à l'éditeur en un clic.
• Les types de champs incluent des champs de texte et de nombre simples en plus des galeries ACF et des champs de relation.
• La prise en charge de editor n'a pas été déclarée dans l'enregistrement du type de publication personnalisé, ce qui signifie que toute l'interface utilisateur repose sur des méta-boîtes personnalisées.

Ce type d'interface utilisateur est représentatif de nombreux sites WordPress personnalisés où une série de champs personnalisés contient un mélange de contenu sur la page et de métadonnées «invisibles» utilisées pour organiser les publications.

La communauté a besoin de savoir ce qu'il advient de ce type d'interface une fois que Gutenberg est introduit, et je ne pense pas que demander à @elliotcondon de tout migrer vers React à temps pour le lancement soit une attente réaliste.

@kevinwhoffman

La communauté a besoin de savoir ce qu'il advient de ce type d'interface une fois que Gutenberg est introduit

Vous avez raison, mais le but de ce numéro 952 est de _trouver_ cette réponse en discutant et en suggérant des alternatives. Qu'est-ce qui fonctionnerait ou non. À un moment donné dans le futur, quand tout le monde pense que nous sommes tous arrivés à quelque chose qui fonctionnerait dans tous les cas hérités et futurs, ce n'est qu'alors que cela peut être mis en œuvre et que la communauté (des utilisateurs) peut être expliquée comment cela fonctionnera. Actuellement, il est tout simplement trop tôt pour attendre une réponse de l'équipe à cette question à mon humble avis.

Je pense que le cas d'utilisation que vous fournissez et celui fourni par

En ce qui concerne votre exemple, ma suggestion (voir quelques réactions ci-dessus) montrerait simplement toutes les cases comme indiqué dans la capture d'écran (avec le nouveau style Gutenberg bien sûr).

@kevinwhoffman

Gutenberg optera probablement pour les CPT, tout comme votre CPT ne déclare pas la prise en charge de l'éditeur actuel. Je ne vois pas pourquoi il ne serait jamais opté pour les CPT car la plupart des éléments de WordPress sont extrêmement flexibles, Gutenberg ne sera pas différent. Il ne fonctionne actuellement que pour les messages.

Je doute fort que Gutenberg changerait quoi que ce soit pour une interface comme celle-ci, ni l'intention de le faire. Cela étant dit, il pourrait être intéressant d'explorer ce que propose Gutenberg et de voir si vous pouvez créer une expérience d'édition plus convaincante pour votre client en l'utilisant.

Par exemple, vous pouvez créer un bloc propriété / propriétés, qui pourrait être utilisé pour permettre à votre client d'intégrer rapidement et facilement les informations de propriété dans d'autres articles, etc. Ensuite, lors de l'édition dans Gutenberg, ils pourraient changer les mêmes informations que vous voyez dans ACF tout en regardant les informations de propriété affichées dans Gutenberg. Gutenberg ne dépasse pas l'interface d'administration de WordPress, il remplace la fonctionnalité de l'éditeur et conduira très probablement à des modèles de contenu basés sur des blocs.

De bonnes choses viennent de Gutenberg, pas des maux de tête!

Voici l'écran d'édition des événements pour le site mentionné ci-dessus avec les champs ACF au-dessus du post_content, puis la méta-boîte standard du calendrier des événements sous post_content.

Le site sera ouvert à de nombreux utilisateurs non techniques, nous ne parlons pas d'une équipe éditoriale formée, nous parlons de Joe moyen qui n'a jamais utilisé WordPress auparavant ou qui n'a jamais été formé autre que l'aide que nous fournissons dans le site.

Nous l'avons défini de cette manière pour nous assurer que les utilisateurs trouvent et saisissent le type et la catégorie d'événement, l'en-tête et les images en vedette pour chaque événement. Nous sommes également en mesure d'utiliser les positions de la méta-boîte existantes pour fournir une documentation d'aide pertinente à l'écran afin de les aider à modifier l'événement et de fournir une assistance aux nouveaux utilisateurs de manière non intrusive.

Veuillez également garder à l'esprit que nous sommes connectés en tant qu'administrateur, les utilisateurs non-administrateurs ont masqué diverses méta-boîtes de la barre latérale pour réduire davantage l'encombrement visuel qu'ils voient.

Le «contenu» n'est pas aussi pertinent que les différentes méta-boîtes pour réussir à entrer dans un événement. Un événement ne s'affichera pas sur le site si une date n'est pas correctement saisie ou une catégorie sélectionnée. Ce qui m'inquiète dans toute cette discussion, ce sont des maquettes comme dans le numéro 1352 où les méta-boîtes sont reléguées au bas de l'écran dans une section pliable. Je peux vous garantir, d'après notre expérience, que des utilisateurs non formés ne verront jamais les méta-boîtes, saisissant simplement la date et l'emplacement directement dans la zone de contenu sous forme de texte brut, puis se plaignant que leur événement n'apparaissait pas dans le système. Il n'est tout simplement pas assez découvrable pour les utilisateurs non formés dans les types de publication nécessitant des informations structurées.

Nous avons également des champs obligatoires dans cette interface et si la méta-boîte est réduite, un utilisateur recevra un avertissement mais ne pourra pas trouver facilement la cause du problème.

Les métabox ou la prochaine itération de leur type de fonctionnalité doivent être des citoyens de première classe et nous avons besoin de la capacité de les placer au-dessus du contenu, à côté du contenu ou en dessous du contenu afin de rendre les interfaces utilisables pour nos clients.

Gutenberg optera probablement pour les CPT, tout comme votre CPT ne déclare pas la prise en charge de l'éditeur actuel.

L'enregistrement du support de Gutenberg dans les CPT n'a pas été confirmé, et honnêtement, cela ressemble plus à éviter le problème des méta-boîtes plutôt qu'à le résoudre. Si le seul moyen pour les sites existants d'accéder à Gutenberg est d'enregistrer le support pour celui-ci par code, cela limiterait considérablement l'audience potentielle.

Nous ne devons pas non plus prétendre que les méta-boîtes personnalisées ne sont utilisées que dans les types de publication personnalisés. Ils sont tout aussi susceptibles d'exister sur des publications et des pages régulières.

Gutenberg ne dépasse pas l'interface d'administration de WordPress, il remplace la fonctionnalité de l'éditeur ...

Ceci est inexact. Tel qu'il existe aujourd'hui, Gutenberg _est_ un remplacement plein écran pour l'écran de post-édition.

@ BE-Webdesign et @kevinwhoffman

Aussi, pourquoi les CPT devraient-ils manquer les aspects de Gutenberg qui sont clairement meilleurs que l'écran d'édition actuel?

Les contrôles de publication déplacés vers le haut pour ne pas être confondus avec le contenu et une esthétique globale plus propre sont certainement des points forts de la direction de ce projet.

En n'ayant pas de plan décent pour créer des fonctionnalités équivalentes à ce qui existe actuellement pour les CPT ayant des besoins complexes (via des méta-boîtes), nous ignorons une grande partie de la base d'utilisateurs et les reléguons dans une deuxième classe, finalement une expérience non prise en charge.

IMHO qui suce tout simplement.

Je ne dis même pas que les métaboxes doivent fonctionner hors de la boîte telles qu'elles existent actuellement. Il pourrait y avoir une nouvelle et meilleure façon d'implémenter ce type de flexibilité d'interface.

Ce qui m'inquiète, c'est que l'équipe de développement ne semble pas vraiment saisir les problèmes pour beaucoup de développeurs avec l'application d'une première approche "post_content" ici. Nous utilisons Beaver Builder sur TOUS nos sites, à l'exception des CPT où nous avons besoin d'une sortie de données structurées. Un outil de création de page, qui est ce qu'est Gutenberg, est idéal pour les articles et les pages avec des besoins de contenu individuels. C'est terrible pour les données structurées. Pour les données structurées, la cohérence de l'interface, les champs obligatoires et les autres priorités de mise en page l'emportent à chaque fois sur le contenu du formulaire libre.

@kevinwhoffman

Nous ne devons pas non plus prétendre que les méta-boîtes personnalisées ne sont utilisées que dans les types de publication personnalisés. Ils sont tout aussi susceptibles d'exister sur des publications et des pages régulières. Ceci est inexact. Tel qu'il existe aujourd'hui, Gutenberg est un remplacement plein écran pour l'écran de post-édition.

Oui, mais cela ne remplace pas toute l'interface d'administration, ce à quoi je faisais référence. Vous comparez un projet incomplet à l'expérience actuelle. # 2251, une fois terminé, réintroduira les toutes puissantes méta-boîtes, donc ce ne sera pas si différent et ce sera beaucoup mieux. Certains auteurs de plugins devront probablement modifier certaines choses, mais pour la plupart, je suis convaincu que tout se passera bien.

@avocadesign

Aussi, pourquoi les CPT devraient-ils manquer les aspects de Gutenberg qui sont clairement meilleurs que l'écran d'édition actuel?

Personne n'a dit qu'ils le sont à ma connaissance? Il n'y a pas trop de différence entre l'ajout de la prise en charge de l'éditeur pour un CPT et l'ajout de la prise en charge de l'éditeur de blocs.

En n'ayant pas de plan décent pour créer des fonctionnalités équivalentes à ce qui existe actuellement pour les CPT ayant des besoins complexes (via des méta-boîtes), nous ignorons une grande partie de la base d'utilisateurs et les reléguons dans une deuxième classe, finalement une expérience non prise en charge.

Je pense qu'il y a un plan décent en place, peut-être que ce n'est pas clair, mais je suis très convaincu que Gutenberg répondra aux besoins de la grande majorité de tous les types d'utilisateurs, voire les dépassera, en fin de compte.

Personne n'a dit qu'ils le sont à ma connaissance? Il n'y a pas trop de différence entre l'ajout de la prise en charge de l'éditeur pour un CPT et l'ajout de la prise en charge de l'éditeur de blocs.

Je crains que l'étape dont beaucoup parlent dans ce fil de faire l'adhésion de Gutenberg aux CPT conduira à ignorer de nombreux cas d'utilisation complexes actuels dans Gutenberg à court et moyen terme et forcera efficacement des cas d'utilisation tels que les événements. celui illustré ci-dessus pour utiliser le système existant car Gutenberg n'est pas assez flexible. Cela oblige effectivement ces cas d'utilisation complexes actuels à manquer les autres avantages du projet.

On nous dit souvent "ne vous inquiétez pas, tout ira bien" mais vous avez raison @ BE-Webdesign lorsque vous suggérez que le plan n'est pas du tout clairement présenté pour certains d'entre nous, je ne vois tout simplement pas à tout comment cela va être résolu de manière satisfaisante à court terme - si c'est alors, n'hésitez pas à signaler la discussion ou le problème pour m'éclairer.

Éditer:
Ce que j'entends par «court terme», c'est par le lancement de 5.0 au public, début 2018 semble être l'objectif ici. À plus long terme dans 2 ou 3 ans, je peux voir que cela est résolu avec beaucoup plus de succès.

@BennyVL & @dmccan La flexibilité est le problème clé ici. Corrigez-moi si je me trompe, mais rien de ce que je vois suggéré par les développeurs qui y travaillent n'est aussi flexible que ce que nous avons actuellement.

Avec ACF et d'autres plugins, je peux facilement enregistrer des métaboxes au-dessus du contenu (sous le titre), sous le contenu et dans la barre latérale. La conception de l'interface dépend de moi. Cela n'impose pas que l'éditeur soit le premier, cela n'exige pas que l'éditeur soit même présent. Je peux enregistrer de nouvelles métabox, je peux en désinscrire ou en déplacer d'autres.

Ce que je veux, c'est une solution qui reste aussi flexible sur le long terme. Que les métaboxes doivent être mises à jour dans un nouveau format JS brillant, devenir des blocs appropriés ou que d'autres changements doivent se produire pour rendre cela possible ne me dérange pas vraiment. Je souhaite que la flexibilité dont nous bénéficions actuellement soit incluse dans Gutenberg, quelle que soit la méthode utilisée pour y arriver.

Ce que je veux, c'est une solution qui reste aussi flexible sur le long terme. Que les métaboxes doivent être mises à jour dans un nouveau format JS brillant, devenir des blocs appropriés ou que d'autres changements doivent se produire pour rendre cela possible ne me dérange pas vraiment. Je souhaite que la flexibilité dont nous bénéficions actuellement soit incluse dans Gutenberg, quelle que soit la méthode utilisée pour y arriver.

C'est l'objectif et ce que veulent la plupart des gens.

J'ai écouté beaucoup de discussions sur le problème des méta-boîtes et sur ce qui leur arrivera avec ce nouvel éditeur. Mon opinion personnelle est que Gutenberg devrait se concentrer uniquement sur l'éditeur et non sur l'écran d'édition de la page entière. Mais il semble que cette décision ait déjà été prise.

Salut les gars,

Je suis le développeur principal de Carbon Fields et je voulais ajouter la liste des actions / filtres que nous utilisons qui pourraient être affectés:

Filtres:

• postbox_classes_{$page}_{$id}

Actions:

• init
• admin_menu
• admin_init
• wp
• admin_enqueue_scripts
• in_admin_header
• admin_notices
• admin_print_footer_scripts
• save_post
• edit_comment
• media_buttons
• edit_form_after_title (positionnement du sucre - pas critique)

Mes questions:

• Si nous voulons conserver les anciennes méta-boîtes, comment interagiraient-elles avec les changements de données?
• Quel type d'événements (jQuery? Une implémentation exposée d'un émetteur?) Et à quels événements exactement pouvons-nous nous attendre de la part du nouvel éditeur (par exemple en cas de succès de soumission, d'échec, etc.)?
• Ces événements seront-ils disponibles pour les méta-boîtes héritées ou uniquement pour les implémentations React?

PS:
Je veux juste remercier l'équipe Gutenberg pour tout le travail acharné et les efforts et cela me rend excité que WordPress s'oriente vers des outils et des solutions modernes (même si le voyage semble effrayant)!

La prise en charge des méta-boîtes est très importante ...

... pour des milliers de développeurs et d'utilisateurs wordpress.

WordPress ne peut pas ignorer le gros lecteur de plugins ...

... comme Advacend Custom Fields Pro (https://github.com/elliotcondon/acf/issues/622), WooCommerce ou Yoast SEO.

Je suis responsable du projet Toolset , qui utilise fortement des types, des champs et une taxonomie personnalisés.

Nous voulons rendre nos plugins compatibles avec Gutenberg.

Voici ce que je comprends:

• Nous devrons utiliser une nouvelle API pour afficher les champs personnalisés et la taxonomie sur les pages et les articles, lorsqu'ils utilisent Gutenberg.
• Nous n'avons rien à faire à propos de Gutenberg pour les CPT, car ils utiliseront l'éditeur WordPress normal et non Gutenberg.

Est-ce correct? Si tel est le cas, pourriez-vous me référer à la documentation de l'API pour afficher les boîtes personnalisées sur Gutenberg?

Je pense que les documents évoluent encore. Il y a quelques documents sur https://github.com/WordPress/gutenberg/tree/master/docs - http://gutenberg-devdoc.surge.sh/

J'entends ce que @ BE-Webdesign et d'autres disent à propos de l'intention de minimiser les perturbations - merci, c'est rassurant - mais je voulais juste ajouter la valeur de mes 5p (ok, ok, la valeur de mes 105p habituels.)

Quiconque développe depuis un certain temps se souviendra de la douleur de créer manuellement des interfaces Web pour des bases de données sur mesure - ennuyeuses, longues, sujettes aux erreurs et très coûteuses en temps de développeur.

WordPress plus Advanced Custom Fields (Pro) est un excellent outil pour créer efficacement des sites Web sur mesure basés sur une base de données (et même des outils de gestion de données intranet) avec des frontaux attrayants, une vérification rigoureuse de la saisie de données, des interfaces utilisateur intuitives et cohérentes, etc. être évolutif pour d'énormes volumes de données relationnelles, mais dans de très nombreux cas, ils n'ont pas besoin de l'être; ce sont des systèmes simples qui peuvent être créés de manière rentable pour les clients. C'est ce qui fait de WordPress un CMS vraiment utile (et, en fait, un SGBDR léger), pas seulement une plateforme de blogs.

Je (et je suis sûr que beaucoup d'autres) petites entreprises utilisent WP + ACF (ou des plugins de données personnalisés similaires) pour créer des sites et des systèmes sur mesure pour les organisations clientes et les particuliers qui n'ont pas de gros budgets informatiques. Si l'introduction de Gutenberg se fait sans prendre en compte la prise en charge des flux d'édition / saisie de données existants, des métaboxes, etc., j'ai deux problèmes "non techniques" mais néanmoins importants:

1 / Mes utilisateurs finaux auront besoin d'une formation supplémentaire (il est facile pour nous, en tant que techniciens, d'oublier à quel point les utilisateurs non techniques sont extrêmement confus par les changements d'interface - j'ai écrit le plugin Clarify Password Reset parce que je perdais tellement de temps à trier les utilisateurs qui ont été totalement bloqués par le nouveau processus de réinitialisation de mot de passe introduit dans 4.3).

2 / En plus de mettre à jour mes propres plugins pour une approche métabox différente, je devrai passer du temps à mettre à niveau et à tester tous mes sites clients avec un niveau de diligence professionnel, en m'assurant que tous les plugins tiers que je suis en utilisant ont également réussi à mettre à jour correctement leur base de code. (Et cela dans une situation où je n'ai aucun contrôle sur la rapidité avec laquelle les plugins tiers sont mis à jour, soit avant, soit (pire encore) après la version 5.0 - la planification de la charge de travail devient donc vraiment difficile.)

Dans aucun des cas ci-dessus, je n'aurais le sentiment qu'il était juste de facturer à mes clients des frais supplémentaires pour ce travail supplémentaire; après tout, j'ai choisi la plate-forme sur laquelle construire leurs sites et leurs systèmes, et ce n'est pas comme s'ils avaient demandé des modifications ou des améliorations. Peut-être que je suis «trop gentil» ou naïf sur ce front, mais comme les gens l'ont mentionné ci-dessus, c'est une question de confiance; nous faisons confiance à WordPress pour ne pas nous laisser tomber dans le caca en cassant la rétrocompatibilité, afin que nos clients puissent nous faire confiance pour ne pas les piquer pour des frais supplémentaires inattendus. Le résultat net est que j'ai soudainement une énorme quantité de travail non rémunéré supplémentaire à intégrer - peut-être de toute urgence, si les sites sont immédiatement interrompus par la mise à niveau - tout en continuant à faire suffisamment de travail rémunéré pour rester à flot.

J'aime vraiment utiliser WordPress et j'ai investi beaucoup de temps à apprendre les ficelles du métier, à développer mes propres cadres de projet pratiques, etc. - au point où je gagne maintenant la majeure partie de ma vie (et nourris ma famille, etc.) via des projets de développement basés sur WordPress. J'ai également essayé de rendre quelque chose en prenant le temps de publier officiellement de petits plugins utiles que j'ai développés sur WordPress.com, parce que j'apprécie OSS, le développement basé sur la communauté, etc. Je suppose que c'est surtout un appel à prendre les problèmes mentionné dans ce numéro fil à cœur autant que possible; sinon, je suis d'accord qu'il y a un réel danger que la base de code soit fourchue. En tant que fan de WordPress et contributeur de plugins, je pense que c'est VRAIMENT mauvais résultat; cependant, en tant que développeur solo comptant sur WP pour gagner ma vie, je devrais peut-être utiliser la version fourchue (c'est-à-dire correctement rétrocompatible) par nécessité économique. Ne laissez pas cela arriver!

@konamac fait

Pour en tirer profit ,

1. Il n'y a pas de réponse directe au futur support des métabox existantes. Il s'agit d'un geste extrêmement frustrant et autoritaire contre les agences de développement et les auteurs de thèmes / plugins. "Gutenberg est open source, alors découvrez-le vous-même" est irresponsable.

2. Gutenberg est génial. J'adore l'interface, le design visuel et je pense que c'est la voie du futur en termes d'édition de contenu. Mais il est loin de là où il doit être pour pouvoir le considérer pour une version 4.9 ou 5.0.

3. Tout ce que je devrais pouvoir faire en héritage est tout ce que je devrais pouvoir faire à Gutenberg.

4. Options d'écran
5. Méta-boîtes (ACF, Yoast, etc.)
6. Permaliens?! Je ne peux même pas commencer à comprendre pourquoi ce n'est pas encore modifiable dans la version 1.0
7. Le bloc de contenu classique ne se charge PAS correctement dans les environnements localhost
8. La documentation DOIT être la clé pour créer différents blocs de style. Donnez plusieurs exemples, plusieurs cas d'utilisation. Tous les développeurs de thèmes ne sont pas en backend, alors ne présumez pas. Soyez limpide
9. Les paramètres de bloc ont besoin de travail. Il est très difficile de dire quels paramètres sont disponibles par bloc. Cela semble aléatoire. Quand dois-je modifier les paramètres de blocage et quand dois-je pas?
10. L'ensemble des balises de commentaires autour de l'éditeur de texte Gutenberg est ... triste à voir.

Certains d'entre nous sont extrêmement frustrés par ce processus. Ce devrait être une réponse très simple.

Gutenberg protégera-t-il l'utilisation actuelle des métaboxes / ACF, et existe-t-il des plans en place pour assurer un tel soutien indéfiniment?

Nous n'avons pas besoin de savoir quelle est la solution pour le moment - nous savons que vous la trouvez. Mais nous n'avons toujours pas de réponse claire à ce sujet. ACF en particulier doit fonctionner exactement de la même manière qu'il doit toujours prendre en charge les clients plus anciens qui n'accepteront PAS d'être facturés pour la mise à jour - en particulier lorsque vous discutez de la suppression de l'ancien éditeur à un moment donné (comment pouvez-vous même commencer à avoir cette conversation maintenant?! )

J'adore Gutenberg. Mais je dois rejoindre la chorale - cela devient ridicule. La manière dont l'équipe de projet a communiqué cette attente n'a pas été simple. Oui ou non, c'est tout ce que nous recherchons.

@ BE-Webdesign

quand il sera terminé, présentera les toutes puissantes méta-boîtes

Puis-je donc suggérer que vous écriviez un article entier sur cette question même, que vous avez en fait indiqué, que les méta-boîtes, telles qu'elles sont maintenant, vont rester s'il vous plaît. Cela éviterait que de nombreux développeurs inquiets de la communauté s'inquiètent pour leur entreprise.

De plus, j'encourage l'équipe à en faire une priorité pour les ajouter maintenant. Cela éviterait beaucoup de négativité autour du projet, j'en suis sûr.

Comme indiqué dans # 2308, j'ai copié les hooks que le plugin Meta Box utilise lors de la création / sauvegarde de champs personnalisés:

• Les scripts et les styles sont mis en file d'attente à l'aide de admin_enqueue_scripts . Nous vérifions l'écran actuel (via get_current_screen ) pour nous assurer que les scripts et les styles ne sont mis en file d'attente que pour ces pages. Pour le plugin principal, il vérifie par types de messages. Pour les extensions (terme méta, méta utilisateur, page de paramètres), il vérifie davantage les taxonomies, la page de profil utilisateur ou les pages de paramètres.
• Nous utilisons également print_media_templates pour imprimer des modèles Underscore.
• Les scripts que nous utilisons dans le plugin incluent: sélecteur de couleur, trait de soulignement, backbone, scripts multimédias, tinymce (pour le champ éditeur)
• Nous utilisons init pour initialiser tous les hooks du plugin.
• Les méta-boîtes sont enregistrées en utilisant des crochets add_meta_boxes .
• Les méta-boîtes cachées utilisent default_hidden_meta_boxes .
• Nous accrochons également à post_edit_form_tag pour permettre le téléchargement de fichiers.
• Nous utilisons save_post_{$post_type} et edit_attachment , add_attachment pour enregistrer des méta-valeurs pour les articles et les pièces jointes.

Quel est le problème avec la création de hooks pour afficher les métaboxes au-dessus / en dessous / dans la barre latérale de Gutenberg?

Je pensais que je pourrais aussi bien faire ce que les développeurs tiers font de mieux, et jeter une autre clé énorme dans les travaux.

Mattias nous dit que les métaboxes peuvent être réinventées sous forme de blocs stockés dans post_meta. Si tel est l'objectif de la fusion, il y a des problèmes à régler:

De nombreuses métaboxes enregistrent the_editor($custom_id); pour que cela soit pris en charge dans le contexte de Gutenberg, soit une interface et une API pour créer des blocs imbriqués sont nécessaires dès le premier jour, soit nous disons que les métaboxes ne peuvent avoir que l'interface d'édition de deuxième classe , sans aucun des avantages des blocs. Cela sera particulièrement problématique pour le grand nombre d'agences qui conçoivent actuellement à l'aide de mises en page flexibles ACF, car elles auront besoin d'un moyen de créer des blocs Gutenberg séparés pour différents contextes et domaines. Même "penser en blocs", je ne vois pas de bon moyen de résoudre le problème "zone de contenu suivie d'une partie de modèle suivie de zone de contenu" sans prendre en charge l'imbrication dans les "métablocs" dès le premier jour.

Il en découle le souci technique de l'imbrication par rapport aux blocs qui ne sont pas stockés dans post_content. Mattias dit que les blocs pourront être stockés dans postmeta, mais si un bloc peut définir où il est stocké, comment l'imbrication fonctionnera-t-elle, lorsqu'un bloc parent se stocke dans postmeta et que l'utilisateur ajoute un enfant qui stocke dans un post_meta différent ... (Ou dans le cas pathologique, un bloc imbriqué Tha stocké dans postmeta contient un bloc qui stocke dans le même champ postmeta.

Cela conduit à un troisième problème de métabox. Si Gutenberg est un remplacement complet de la page d'édition, plutôt qu'un remplacement de the_editor() , comment les gens pourront-ils mettre en file d'attente et utiliser des blocs sur d'autres pages et dans d'autres contextes, tels que des métaboxes ou des panneaux d'administration personnalisés qui utilisent the_editor() . Il semble à première vue que la réponse sera «ils ne peuvent pas». Ce qui conduit à de sérieuses inquiétudes quant à savoir si Gutenberg ajoute de la flexibilité aux implémentations CMS personnalisées ou la supprime.

Si les utilisateurs ont la possibilité de Gutenberg, et que c'est aussi révolutionnaire pour eux qu'on le prétend, ne pas pouvoir fournir cette nouvelle interface dans ces cas pourrait s'avérer désastreux pour les agences.

Il n'y a pas de réponse directe au futur support des métabox existantes.

J'ai dit à plusieurs reprises que nous allions rendre compte des méta-boîtes. La seule incertitude est ce qui est techniquement viable et comment il sera affiché dans la nouvelle interface utilisateur.

Nous n'essayons pas de casser quoi que ce soit - codes courts, champs personnalisés, etc. - tout devrait toujours fonctionner. L'interface utilisateur pour interagir avec eux peut changer (à moins que vous ne désactiviez complètement Gutenberg), et certains cas d'utilisation des méta-boîtes seront mieux adaptés aux blocs à venir.

Gutenberg est génial. J'adore l'interface, le design visuel et je pense que c'est la voie du futur en termes d'édition de contenu.

Je suis heureux d'entendre!

Permaliens?! Je ne peux même pas commencer à comprendre pourquoi ce n'est pas encore modifiable dans la version 1.0

Parce que l'API REST ne prend pas encore en charge cela. Toute aide est la bienvenue: https://github.com/WordPress/gutenberg/issues/1285

J'ai dit à plusieurs reprises que nous allions rendre compte des méta-boîtes.

@mtias Je pense que la confusion concernant le support des méta-boîtes résulte de @m suggérant qu'un plugin hérité sera disponible pour restaurer les fonctionnalités existantes. Il serait utile de clarifier quels aspects de l'interface existante (méta-boîtes, positions de méta-boîtes, crochets, etc.) continueront à fonctionner avec Gutenberg par rapport à quels aspects nécessitent le plugin hérité pour continuer à fonctionner.

J'ai dit à plusieurs reprises que nous allions rendre compte des méta-boîtes.

@mtias mes excuses, j'ai dû manquer votre clarification ailleurs. Heureux d'entendre! Rendez l'itération actuelle visuellement plus attrayante et plus ciblée et ce sera un énorme succès.

Je comprends ce que vous dites sur le support de l'API REST, je vais regarder le fil pour les mises à jour.

Merci d'avoir clarifié. Maintenant que j'ai cette idée, je suis à pleine vitesse pour Gutenberg - toutes mes craintes sont mises de côté.

@kevinwhoffman à droite, je pense que le cœur du problème est que la "fonctionnalité existante" inclut également la présentation - et comme Gutenberg modifie considérablement l'interface utilisateur, revenir à la précédente nécessiterait la désactivation du plugin. Comment les méta-boîtes s'intègrent dans la nouvelle interface utilisateur et comment les anciennes méta-boîtes peuvent être prises en charge sans l'intervention du développeur sont les choses sur lesquelles nous travaillons. Je ne sais pas exactement comment cela fonctionnera, donc je n'ai pas été en mesure de promettre un résultat précis. Je pense également que cela pourrait aboutir à une présentation plus claire des fonctionnalités des méta-boîtes.

@brograhamer aucune excuse nécessaire, c'est un gros fil! Nous ne voulons rien précipiter, et c'est un assez gros projet avec de nombreuses pièces mobiles. Parfois, certaines choses peuvent sembler négligées, mais cela ne signifie pas que nous ne prévoyons pas de les résoudre.

Je construis actuellement une application Web à l'aide d'ACF avec 10 types de publication personnalisés qui n'utilisent pas l'éditeur tinymce. J'utilise la fonction Titre et environ 15 champs ACF en moyenne pour chaque CPT.
Actuellement, vous pouvez déclarer les fonctionnalités (par exemple, éditeur, vignette, extrait, etc.) prises en charge par un CPT.
Sera-t-il possible de masquer / supprimer le bloc de paragraphe «Écrivez votre histoire» ainsi que l'icône «Insérer un bloc» de l'écran d'édition?

@ cr101 Je pense que si vous supprimez l '"éditeur" de vos supports CPT, nous devrions probablement supprimer l'inséreuse de blocs et les blocs de Gutenberg, cela me semble logique.

Par contre, avec la v1 des métaboxes, les volets des métaboxes peuvent être étendus par le bas, si nous gardons cela, nous devons nous assurer qu'il est toujours "ouvert" pour les CPT sans support "éditeur". Cela peut ne pas être nécessaire si les métaboxes sont toujours affichées sous l'éditeur (comme certaines des suggestions de conception ci-dessus)

Je ne sais pas si c'est le bon endroit pour cela, mais qu'en est-il des méta-champs personnalisés de base? On a beaucoup parlé de plugins tiers, mais qu'en est-il des méta-champs personnalisés de base. Je sais que ceux-ci ne sont pas vraiment populaires, mais je peux penser à quelques sites sur lesquels j'ai travaillé et qui les utilisent.

Existe-t-il un plan en place pour intégrer les méta-champs personnalisés de base dans Gutenberg?

Salut @jawittdesigns ,

Je suis presque sûr que les métaboxes de base (du moins la plupart d'entre elles) ont déjà été réimplémentées dans Gutenberg! Ils présentent des flux de travail plus agréables autour de la gestion des taxonomies, etc.

Tout le monde n'utilise pas WordPress pour bloguer. Beaucoup d'entre nous utilisent WordPress comme CMS. Nous construisons actuellement une application Web à l'aide de l'API REST de WordPress et d'ACF. Nous avons 10 types de publication personnalisés et chaque CPT a 20 champs personnalisés et tous les CPT sont liés les uns aux autres via des relations bidirectionnelles à l'aide des champs ACF Relationship et Post Object et du plugin ACF Post-2-Post.

Gutenberg ne nous est d'aucune utilité dans sa forme actuelle puisque nous n'utilisons même pas l'éditeur actuel. Nous n'utilisons que la zone de texte Titre pour nos CPT et le reste est des champs personnalisés qui sont stockés dans la table post_meta.

Je crois fermement que l'éditeur Gutenberg ne devrait pas faire partie du noyau dans son état actuel. Je reconnais que WordPress en tant que projet doit jouer un peu aux constructeurs de sites qui ne travaillent pas avec leurs propres thèmes personnalisés ... Cependant, l'éditeur Gutenberg semble être une attaque directe contre ceux d'entre nous qui utilisent des champs personnalisés avancés pour effectuer une saisie complexe de contenu assez «idiot proof» pour les propriétaires de sites en leur donnant une manière très spécifique de saisir leur contenu. L'éditeur Gutenberg dans son «état actuel» semble être une attaque directe contre ceux d'entre nous qui utilisent ACF.
Avec le plugin Gutenberg, le lien d'édition dans l'en-tête envoie l'utilisateur directement dans l'interface Gutenberg qui n'affiche AUCUNE des méta-boîtes ACF et n'a pas d'onglet d'options d'écran en haut de l'écran pour les activer. Oui, l'utilisateur peut revenir à la page / tableau d'articles et choisir l'option «éditeur classique», puis voir les méta-boîtes mais cela signifie qu'une étape supplémentaire doit être franchie par l'éditeur du site pour accéder aux champs ACF. Pas exactement optimal étant donné que l'objectif de l'utilisation d'ACF dans de nombreux cas était de rendre l'édition de mises en page complexes plus fluide et plus simple pour un éditeur non technique.

Quel problème de longue date!

Avec la fusion de # 3345 et # 3554, la prise en charge de la méta-boîte est à un état que nous sommes heureux d'appeler _feature complete_. Notez que c'est différent de _complete_, car il y a évidemment encore du travail à faire pour peaufiner l'expérience de la méta-boîte, en particulier en ce qui concerne le style, la gestion JavaScript plus complexe et la détermination des règles pour revenir à l'éditeur classique.

Merci à tous ceux qui ont participé de manière constructive à cette question, je comprends que cela a été un processus difficile et parfois controversé. Pour une documentation sur la façon dont Gutenberg gère les méta-boîtes et comment vous (si vous préférez) pouvez marquer les méta-boîtes comme étant incompatibles avec Gutenberg, veuillez consulter le manuel .

Si vous rencontrez des bogues associés à des plugins ou des méta-boîtes particuliers, veuillez ouvrir un nouveau problème afin qu'il puisse être correctement suivi et corrigé.

Avec égards, cela devrait être loin d'être complet.

@coffeeneed Si vous souhaitez être constructif, veuillez ouvrir un nouveau numéro avec suffisamment de détails pour que nous puissions vous aider. Merci