FWIW私がWeb開発者と話したとき、彼らはすべてコンテンツにメタボックスを使用しているので、最大限に制御できます。 メタボックスが多くの人にとって「レガシー」と見なされるかどうかはわかりませんが、将来の一部と見なされます。 WordPressのVIPの人々に連絡して、意見を聞く価値があるかもしれません。

メタボックスが多くの人にとって「レガシー」と見なされるかどうかはわかりませんが、将来の一部と見なされます。 WordPressのVIPの人々に連絡して、意見を聞く価値があるかもしれません。

申し訳ありませんが、その言い回しは悪かったです。 メタボックスはここにとどまります。 そのため、メタボックスサイドバーは新しい「投稿設定」サイドバーの形でアップグレードされています。

私が言いたかったのは、新しいメタボックスはJSで記述されるべきであり、ストックのものと一緒に投稿設定サイドバーに表示されるということでした。 PHPで記述されたメタボックスは、理想的にはJSにアップグレードする必要がありますが、PHP形式でも引き続き機能する必要があります。 それが「拡張設定」パネルの目的であり、サイドバーの一部にしたくないためではなく、サイドバーでPHPメタボックスとJSメタボックスを混在させることが非常に難しいために下部に配置されています。

JSとAjaxを介してPHP管理のメタボックスを送信することには、特に新しく保存された状態を反映するようにメタボックスレンダリングを更新する方法に、いくつかの大きな課題があります： https ：//core.trac.wordpress.org/ticket/7756

ここでは、iframeを介してレガシーメタボックスを埋め込むことが解決策になるのではないかと思います。iframesrcは/wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settingsようなもので、その1つのメタボックスのみをドキュメントに出力します。

私が言いたかったのは、新しいメタボックスはJSで記述されるべきであり、ストックのものと一緒に投稿設定サイドバーに表示されるということでした。

これは、JavaScriptメタボックスがサイドバーにのみ配置でき、「拡張設定」セクションの一部になることができないことを意味しますか？ 頭のてっぺんから、サイドバーが十分なスペースを提供せず、サイドバーが乱雑になる可能性のあるプラグインがたくさんあると思います。 このアプローチで問題が発生する可能性のあるプラグインはいくつかあります。

• Yoast SEO：サイドバーに収まらない可能性のある多数のフィールドを提供します-より多くのオプションのモーダルを開くサイドバーメタボックスがある可能性がありますが、これは不要な制限を回避しているように感じます

• カスタムフィールドプラグイン/ドラッグアンドドロップページビルダー-これらはメインコンテンツ領域を置き換えるか部分的に置き換えるため、十分な画面領域が必要です。 フルページビルダーは、独自の完全にカスタムのインターフェイスを個別のビューとして構築することを保証する可能性がありますが、場合によっては、メインコンテンツ領域に加えて、いくつかの追加の構造化フィールドが必要になります（Guttenburgはこれらのタイプの必要性を減らす必要があります）プラグインですが、すべてのユースケースをカバーできるわけではありません）

• WooCommerce-メインエディターを削除しながら、注文とラインアイテムデータのメタボックスを追加します（Wooは最終的に独自のカスタムインターフェイスを構築する予定ですが、これは遠い道のりであり、他のプラグインも同様の状況になると思います）

（Guttenburgは、単に代替手段ではなく、最終的に現在のpost-new / post-edit.phpビューを置き換える予定であると思いますか？）

@bradersに感謝します

私たちのメタボックスは、多くのことを行うので、実際にはかなり大きくて広いです。 サイドバーのさまざまなメタボックスにこれらの機能を追加して、より緊密な統合を提供してもかまいませんが、それが可能かどうか疑問に思いました。 たとえば、現在のようにSEOスコアを[公開]ボックスに追加できますか？ そうでない場合でも、メタボックスがJSでコーディングされている場合でも、拡張設定ボックスにフックできますか？

サイドバーにjavascriptメタボックスを追加できるように、新しい投稿設定をプラグ可能にすることを絶対に検討する必要があります。 おそらく、そのためのチケットを開く時が来たのでしょう。 このチケットは主にPHPで記述されたメタボックス用であり、移行的な方法で機能する必要があります。

拡張セクションのメタボックスと同じ行に沿って、投稿コンテンツの編集をサポートしない投稿タイプがどのように表示されるかについて、議論やモックアップが行われましたか？ そのような場合、中央の領域のメタボックスは、主要な編集エクスペリエンスに依存しています。 グーテンベルクは「タイトルのみ」モードを提示する必要がありますか？ または、編集者がいない場合は、投稿のタイトルを別の方法で処理する必要があります。

拡張セクションのメタボックスと同じ行に沿って、投稿コンテンツの編集をサポートしない投稿タイプがどのように表示されるかについて、議論やモックアップが行われましたか？ そのような場合、中央の領域のメタボックスは、主要な編集エクスペリエンスに依存しています。 グーテンベルクは「タイトルのみ」モードを提示する必要がありますか？ または、編集者がいない場合は、投稿のタイトルを別の方法で処理する必要があります。

これは、別のチケットを作成するのに適しています。 既存の投稿タイプのスクリーンショットがあれば、それを使用してください。 ✨

また、多くのプラグインは、コンテンツエディタをまったく使用せずにメタボックスに依存するカスタム投稿タイプを使用していることを強調したいと思います。 投稿タイプがeditorをサポートせずに登録されている場合は、メタボックスで使用するために完全なキャンバスを開くタイトルのみのモードが必要です。

WordPressVIPに連絡するための+1。 これはカリプソスレッドの問題でもあります： https ：

市場のトップにとって本当に重要な機能です！

ここでは、iframeを介してレガシーメタボックスを埋め込むことが解決策になるのではないかと思います。iframesrcは/wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settingsようなもので、その1つのメタボックスのみをドキュメントに出力します。

私も同じ考えを持っていました。 サンドボックス化とセッション管理の理由からも良い考えです。 次に、この機能の一般的なユースケースを特定し、それらを処理するAPIを実装できます。

私はプラグイン開発者として、そして主にeコマースツールとしてWordPressを使用する人として参加したかったのです。 また、 @ kevinwhoffmanが私に言ったので。

私は今日グーテンベルクを疲れさせました、そして私はメタボックスとエディターボタン（media_buttonsフックを介して追加された）がこれの一部である方法を見ずにこれをWordPressとして文字通り処理することはできません。

私はまた、WordPressエディターとmetabox-paloozaの現在の状態の大ファンではありません。 数えたところ、ダウンロード（Easy Digital Downloadの製品投稿タイプ）の単一投稿ビューに、Yoastによって追加された14個のカスタムメタボックス、Easy Digital Downloads、およびCMB2を使用した独自のカスタムコードがあります。 たくさんありますが、必要です。 WordPressは、そのインターフェイスとそれが公開するものがなければ、かなり無意味です。

ACF、ポッド、CMB2などで追加されたカスタムフィールドインターフェイスがすべての編集エクスペリエンスである非常に多くのサイトで作業してきたため、これが最初から考慮されていなかったのではないかと心配しています。

これが私の技術的な懸念です：
1）media_buttonsを介して追加されたボタン。 私のプラグインCalderaForms（80K以上のアクティブインストール）では、このアクションを使用して、ショートコードを投稿エディターに挿入するためのモーダルを表示するフォーム挿入ボタンを追加します。 グーテンベルクのカスタムブロックに移動するかもしれません。
2）save_postアクションはどのように下位互換性を維持しますか？ 非常に多くのプラグイン、テーマ、カスタムコードがsave_actionにフックし、$ _ POSTスーパーグローバルにアクセスします。 これは良い設計ではありませんが、何百万ものサイトに影響を与える技術的負債です。
3）iFrameでレガシーメタボックスをレンダリングする提案がありました。 JavaScript経由でiFrameのコンテンツにアクセスできないので心配です。

@ Shelob9こんにちは！

iFrameでレガシーメタボックスをレンダリングするという提案がありました。 JavaScript経由でiFrameのコンテンツにアクセスできないので心配です。

JavaScriptを介してiframeのコンテンツにアクセスすることは、この場合のように同じドメイン上にある限り可能です。

save_postアクションはどのように下位互換性を維持しますか？ 非常に多くのプラグイン、テーマ、カスタムコードがsave_actionにフックし、$ _ POSTスーパーグローバルにアクセスします。 これは良い設計ではありませんが、何百万ものサイトに影響を与える技術的負債です。

レガシーメタボックスからグーテンベルクへの移行を容易にするためにできることはたくさんあります。 グーテンベルクと現在の編集後の画面でのデータのモデル化方法には根本的な違いがあります。 つまり、データが実際に初めてモデル化されるようになりました。 データモデリングを使用すると、最終的にJavaScriptインターフェースを使用して、postmetaへの変更を_プレビュー_できることは言うまでもなく、 $_POSTとsave_postアクションでは不可能な方法で投稿とpostmetaの状態を操作できます。 ポストメタの変更をモデル全体に​​ルーティングすることで、ポストメタを初めてプレビューできるようになります。 そのため、グーテンベルクは可能な限りレガシーメタボックスを含めることができますが、新しいインターフェイスを利用できる量は常に本質的に制限されます。 それは私たちが技術的負債を抱えているという現実と同じくらい現実だと思います。

WordPressが今後も関連性を維持できるように進化するためには、技術的負債を取り消さなければならないというのは、マットの意図的かつ意識的な決定だと思います。 グーテンベルクによって導入されたデータモデルを使用するようにACF、ポッド、およびCMB2を更新できるほど、この移行は容易になると思います。 間違いなく多くの課題とハードワークが先にあります！

@westonruterに感謝します。これにより、拡張設定領域の目的がより明確になります。

ここでの議論の一部は、利用可能な画面の不動産についても部分的に行われていると思います。

Gutenberg JSメタボックスはトグル可能なサイドバーにアクセスできるようですが（私はこれで問題ありません）、レガシーPHPメタボックスは画面の下部にあるはるかに広い領域にアクセスできます（これも私は問題ありません）。

残念ながら、利用可能な画面領域に対するこの欲求は、レガシーPHPメタボックスを効果的に処理する方法に関する意図された議論を妨げる可能性があると思います。

プラグインメーカーは、古い方法をすべてサポートするのではなく、メタボックスと、新しいレイアウトとの統合を改善する方法を再検討する必要があることに同意します。 同時に、統合するための同様の可能性が新しいエディターでも提供されるべきであることに同意します（そしてそれらが提供されると信じています）。 現在、＃1352がそれについて議論する主な場所だと思います。 この問題は、起動時に更新されていないPHPメタボックスに下位互換性を提供する方法について説明するためのものです。

iframeを介してレガシーメタボックスを埋め込むことがここでの解決策になるのではないかと思います

iframeへのアクセスは、スクリーンリーダーユーザーにとって非常にエキサイティングな体験ではありません。 他のオプションはありますか？

ここでチャイムを鳴らしたかっただけですが、サイドバーは、プラグインやテーマに見られるほとんどのメタボックスには十分な大きさではありません。 この小さなスペースに物を詰め込むことを私たちに強いることは、私の意見では後退です。 この新しいエディターは素晴らしいと思いますが、今日のメタボックスの使用方法を犠牲にすることを意味する場合はそうではありません。

@kevinpmillerに強く同意します。 メタボックスには多くのスペースが必要であり、サイドバーに隠すことはできません。 メタボックスの現在の状態はばらばらでデザインが悪いですが、WordPressが何であるか（非常に拡張性の高いCMS）も反映しています。

@westonruterへの返信として、下位互換性について明確にしてございます。 それはユーザーの期待であったので、WordPress5.0またはこれがどこにでも下位互換性がないことを非常に明確にする必要があると思います。

また、特にコンテンツエディタがCPTの主な焦点ではない可能性がある特定のカスタム投稿タイプでは、メタボックスがどのように処理されるかについても懸念しています。 WooCommerceはよく知られているプラ​​グインなので、ここで取り上げますが、同様の問題を抱えているプラ​​グインやテーマは他にもたくさんあります。

たとえば、WooCommerceの注文にはコンテンツエディタがありません。単に必要ありません。 注文に関する詳細は、コンテンツの編集ではなく重要であり、当然のことながら、そのページの主な焦点となるはずです。

このようなCPTには、必要がない場合にエディターを削除する機能がありますか？ プラグインはCPTのカスタムメタボックスと完全に統合されていないようであるため、これが考慮されているかどうかを判断するのは困難です。

WooCommerce製品は、2つのコンテンツ領域がある別の問題も引き起こします。1つは製品の説明用で、もう1つは製品の簡単な説明用です。 「メイン」エディタ領域で一方を他方よりも優先する必要がありますが、もう一方はサイドバーでスタックしますか？ サイドバーにある編集エクスペリエンスは、最適とは言えないようです。

これらの設定をすべてサイドバーに詰め込むのではなく、エディターの下（または上）の領域に意図的に登録するオプションはありますか？ これは、現在のadd_meta_boxコンテキストおよび優先度パラメーターに類似している可能性が

ここで何かが足りないかもしれませんが（間違っている場合は修正してください）、実際には、WordPressのすべての使用に現在使用されているものとは異なるものが必要なわけではないのに、より優れたエディターを求めて大きな力が注がれているようです。

質問グーテンベルク（エディターなしに相当）を使用しないようにCPTを定義し、ビジネスが依存する全幅のメタボックスのみを表示するにはどうすればよいですか。
私はメタボックスに依存しています。 ほとんどの場合、私のCPTは次のようになります
'supports' => array( 'title' )
そしてそこから拡張されます。 記事の執筆ではなく、制約付きのガイド付きフォームデータ入力としてメタボックスを備えたCPTを使用するクライアント向けのビジネスツールを構築した私たちを考慮してください。
私の仕事は主に、クライアントシステムとインターフェイスするCMB2のカスタム拡張です。 サードパーティのシステムを必要とするEG不動産リスト。

ドラマチックに聞こえたくはありませんが、これが解決されるまでWP4.9を使い続け、将来について非常に心配しています。 グーテンベルクが「過去への借金を取り消す」ことを理解しています！ しかし、借金は私のような人々にかかっています。

ここでのテーマは、問題がグッテンバーグにあるのではなく、下位互換性の欠如にあるようです。

実際のGuttenburgの問題がいくつかあり、個別のチケットを発行する必要があります（メタボックスで全幅を使用できるようにし、エディターのサポートなしでGuttenburgをモックアップします）が、Gutturnbergは現在の画面を完全に複製することはできず、IMHOを試す必要もありません。

ただし、Guttenburgをオプトイン/オプトアウトするには、さらに多くのことを行う必要があるのではないかと思います。 いくつかのアイデア：

• 現在のほとんどのCPTは、メインエディターよりもメタボックスを多用していると思います。 したがって、プラグインの作成者は'supports' => array( 'gutenburg' )などでGutturnbergを選択する必要があります

• 投稿やページの場合、Guttenburgはサイト設定としてオプションである必要があります。 5.0のアップデート後にGuttenburgを使用するかどうかをユーザーに尋ねて、この選択をDBに保存することも可能です。

• または、テーマはpost_type_supports（）を介してサポートを宣言できますが、これは取り込みに深刻な悪影響を与える可能性があります。または、更新されなくなったレガシーのメンテナンスされていないテーマのユーザーを支援しないテーマをオプトアウトする可能性があります。 （たぶん、レガシーテーマのユーザーにはremove-guttenburnプラグインで十分でしょう？）

しかし、実装に関係なく、大多数のユーザーからますます隠されている場合でも、現在のビューはそのままにしておくべきだと思います...

'gutenberg'サポートフラグが定義されていない場合に既存の機能を維持するために'supports' => array( 'gutenberg' )を明示的に要求するCPTの理論的アイデアが好きです。 WP5にアップデートした怒っているクライアントのために古いサイトを修正することは私に多くの仕事を節約するでしょう。

既存の「サポート」=>機能（タイトル、エディター、作成者など）には非常にわかりやすい名前が付いていることに注意してください。ここでは、グーテンベルクが_プロジェクト_名として際立っています。 その用途には、よりわかりやすい機能名が検討されるのではないかと思います。 おそらく「ブロックエディタ」？ 'supports' => array( 'block-editor' )

もちろん、 'supports' => array( 'title','editor',thumbnail', 'block-editor' )などの間違いを見つけるための戦略が必要になります。 'block-editor'フラグは、古い 'editor'モードを単純にオーバーライドすると思います。

ここに懸念のある別のプラグイン開発者。

サイドバーメタにJS経由でのみアクセスできる場合、これはsideコンテキストを持つPHP登録メタボックスにとって何を意味しますか？ それらを提案された拡張設定セクションに移動すると、それらのメタボックスはコンテキストに依存するという考えが取り消されます。

ご存知のとおり、サイドバーは見栄えの良いデザイン上の決定だけではありません。 それらは、ユーザーがそのコンテンツの優先順位とメインコンテンツとの関係を理解するのに役立つ方法でリレーショナルコンテンツを保持することがよくあります。 技術的な障壁のためにsideメタボックスに別のコンテキストを割り当てることは、少し見当違いのようです。

管理領域のプログレッシブJS化を考慮すると、これらの「レガシー」メタボックスは、プラグインおよびテーマの開発者に、編集ページに追加機能を提供するための自己完結型のReact / Vue /その他のアプリの自然なマウントポイントも提供します。

エディターは見栄えがしますが、ページの残りの部分を忘れないでください。

私はこれについてもう少し考える機会がありました、そしてここで他の人と共有されているいくつかの文脈で、私はさらに別の問題があると思います。 この新しいエディターは、私たちを単一のレイアウトとワークフローに強制します。 なぜカスタマイズを削除するのですか？ クライアントごとにデータ入力をスカルプトする機能が、WordPressや他のほとんどのソリューションを本当に素晴らしいものにしているのです。 このエディターで遊ぶほど、プレビュー領域がエディターに置き換えられ、サイドバーの側面が切り替わった、肥大化したバージョンのカスタマイザーのように感じられます。

投稿を書くためにこれを使用できるが、CPTがこれのサポートを追加できるようにすることも言及されています。 それも実際にはうまくいかないと思います。 ニュース組織はこのタイプのエディターを気に入っていますが、追加のコンテンツ、スケジュール設定、埋め込み、インフォグラフィック、およびその他の必要なデータに関するカスタムワークフローも必要です。

このエディターをフルスクリーン/気晴らしのないエディターのように動作させるのはどうですか？ このようにして、機能と「レガシー」コードを犠牲にすることなく、両方の長所を活かすことができます。 （ところで、現在メタボックスを構築する方法がこのプロジェクトで「レガシー...」と呼ばれているのはばかげていると思います）。

お時間をいただきありがとうございます、それはありがたいです。

このエディターをフルスクリーン/気晴らしのないエディターのように動作させるのはどうですか？

+1

私の主な関心事を繰り返します。投稿はガイド付きユーザーワークフロー（WooCommerce製品データなど）で大きく動的にグループ化されたメタボックスから構築されるため、CPTは「エディター」を必要としないことがよくあります。

このようなメタボックスは、主要なコンテンツエントリ要素を形成し、投稿エディタで全幅で開いている必要があるため

開発者がすべての古いメタボックスソリューションをブロックに_リファクタリング_することが期待される場合、Automaticcの誰かが、ハンマーが5.0に落ちる前に、それを明確かつ公に述​​べる必要があります。 チームが市場のこの部分とビジネスへの影響を検討したという兆候は見られません。

ここにはすでに多くの良い考えが追加されているので、次の簡単な考えを紹介します。

すべてのレガシーコンテンツ用に下部に「拡張設定」エクスパンダを配置する代わりに、メタボックスが通常のコンテキストと高度なコンテキストにあるときに、そのように下部にある各メタボックスのエクスパンダを作成してから、サイドコンテキストのサイド設定？

解決策からそれほど遠くないようです。 また、投稿タイプがエディターをサポートしていない場合は、エディターを非表示にしますが、他のすべては同じように表示されます。 リーズナブルなレイアウトです。 デフォルトの拡張メタボックスの設定などのオプションを指定するだけです。

私は確かに、メタボックスをレガシーにレンダリングする現在の方法を検討し、フィールドを構築するための新しいjs駆動の好ましい方法を提供するという考えを気にしません。 その後、5.0ですぐに壊れることについて慌てる必要なしに、徐々に切り替えることができます。

これらの考えがお役に立てば幸いです。 他の誰かがすでにこの趣旨で何かを言っている場合は、これを同意として受け取ってください。 😄

ディスカッションに他に2つの価値のあるフックを追加したいと思います。 edit_form_after_titleとedit_form_after_editorで、現在、編集後のUIを完全に制御できます。 明らかに、グーテンベルクは「wp_editor」の単なる代替品ではなく、UIのまったく異なる見方です（そして現在のように、将来のモジュラー拡張性）。

このような問題が問題を解決しようとしているように見えますが、それは「メタボックスに何が起こるか」ではなく、WordPressが「製品」としてどこに向かっているのかという問題についてです。

このようなソリューションを確立するという中期的な目標を見つけるのは簡単です。これをフロントエンドに移動するのは非常に簡単です（そして、一部の競合他社に近づく可能性があります）。

開発者/ビジネス/計画の観点から、「グーテンベルク」の（将来の）意図を理解することは役に立ちますか、または誰かが私にそのようなミッションステートメントまたは同様のものを指摘できますか？

私からのいくつかのより多くの意見...

既存の「サポート」=>機能（タイトル、エディター、作成者など）には非常にわかりやすい名前が付いていることに注意してください。ここでは、グーテンベルクがプロジェクト名として際立っています。 その用途には、よりわかりやすい機能名が検討されるのではないかと思います。 おそらく「ブロックエディタ」？ 'supports' => array（ 'block-editor'）

私は同意します-これは、アプローチが合意されたら並べ替えることができる詳細のように聞こえます😄

もちろん、 'supports' => array（ 'title'、 'editor'、thumbnail '、' block-editor '）などの間違いをキャッチするための戦略が必要になります。 'block-editor'フラグは、古い 'editor'モードを単純にオーバーライドすると思います。

グーテンベルクは現在の投稿タイプのサポートを拡張していると思います-したがって、 editorサポートがなかった場合、グーテンベルクはタイトル/サイドバー/拡張オプションを表示するだけです。 では、Gutenburgのサポートは、supports配列の一部ではなく、個別のCPT登録引数として処理する方がよいのではないでしょうか。

すべてのレガシーコンテンツ用に下部に「拡張設定」エクスパンダを配置する代わりに、メタボックスが通常のコンテキストと高度なコンテキストにあるときに、そのように下部にある各メタボックスのエクスパンダを作成してから、サイドコンテキストのサイド設定？

私は個人的にこのアイデアが好きです-これらのパネルを並べ替えて、現時点で可能な限り非表示にすることができれば、それはアイデアの解決策になる可能性があります...

おそらく、1つ（または複数？）またはこれらをページの読み込み時に開くように設定する方法もあるはずです-特に投稿タイプがメインエディターをサポートしていない場合はそうです。

投稿を書くためにこれを使用できるが、CPTがこれのサポートを追加できるようにすることも言及されています。 それも実際にはうまくいかないと思います。 ニュース組織はこのタイプのエディターを気に入っていますが、追加のコンテンツ、スケジュール設定、埋め込み、インフォグラフィック、およびその他の必要なデータに関するカスタムワークフローも必要です。

新しいreactベースの画面が古い編集画面と同じようにプラグイン可能である場合、これらのカスタムワークフローをページの上部/サイドバー/エディターの下またはページの他の場所に追加できない理由はありません。 （免責事項：私はReactについて深く理解していないので、PHPの外部でどれほど複雑なフックが存在するかはまだわかりません）。 また＃1352

ここでの混乱は、グーテンベルクがエディターを最初に

カスタム投稿タイプを定義する場合、これには、必要なブロックと、単に許可されるブロックが含まれる可能性があります。 editorサポートしていないカスタム投稿タイプの場合、グーテンベルクに「エディター」が表示されますが、基本的に_inserter_が無効になる可能性があります。 エディターに表示されるブロックは、投稿の種類に応じて所定の位置にロックされます。 ブロックが設定されていない場合、それらは_placeholders_として表示されます。 これらのブロックは、メタボックスが現在行うのと同じようにプロパティをpostmetaに格納できますが、 save_postアクションと$_POSTグローバルを介してアドホックではなく、正規化された方法で格納することに注意してください。

したがって、ここでの最終結果はほぼ同じになると思います。 プラグインの作成者は、カスタムフィールドを配置するための「ボックス」を引き続き取得します。 メタボックスではなくブロックで表示されるだけです。

ここでの混乱は、グーテンベルクがエディターを最初にブロックするように再想像する方法に根本的な違いがあるためだと思います。 つまり、メタボックスの追加について考えるのではなく、ブロックの追加について考える必要があります。 以前はメタボックスに配置していたフィールドを、ブロックに配置する代わりに、現在は前進します。

@westonruterこれは、コンテンツを含むメタボックスには十分に

明確化してくれた@westonruterに感謝しますが、これは私にいくつかの新しい質問を提起します。

データをpost_metaとして保存するブロックは、これまでのデモで見たものとは根本的に異なるタイプのブロックのように見えます。 このデータも投稿コンテンツのフローに重複して保存されますか？

著者が許容可能な数を超えるブロックを投稿に追加することを妨げるものはありますか？ （1つだけが意味をなす場合に複数のpost_metaフィールドを追加する）

メタデータへのゲートウェイとしてブロックを探索することについて、 @ westonruterに同意する傾向があります。 ただし、私が提案するのは、ブロックの概念をpost_contentから切り離すことです。 カスタム投稿タイプのブロックは、必ずしもフロントエンドのpost_contentから出力されるもののメンバーである必要はありません。 これは、現代の部族によるイベントカレンダー（私の解釈）プラグインを使用した例です。

この状況では、主要なコンテンツはイベントの詳細であり、自由形式のコンテンツ領域ではありません。 プラグインは、カスタム投稿タイプのメタデータを使用して独自のマークアップをアセンブルします。 post_contentは、ページの下部に印刷される単なる説明テキストです。 このため、イベント詳細ブロックは、移動可能、削除可能、または実際にはコンテンツ出力の一部であってはなりません。 ただし、この投稿タイプの主要なコンテンツを表すため、最初に表示されるはずです。

WooCommerceは、1つ以上の製品情報ブロックが製品投稿タイプの説明テキストよりも優先される必要がある別の例ですが、ユーザーが自分で挿入することが期待されるオプションのブロックであってはなりません。

ブロックの基本的な概念は、投稿の適切なユーザーインターフェイスを組み立てることであり、必ずしもそのデータがフロントエンドのどこに保存またはレンダリングされるかを意味するものではないと思います。

...メタボックスの追加について考えるのではなく、ブロックの追加について考える必要があります。

これはコンテンツにとっては理にかなっていますが、多くのプラグインはフォームや支払いなどの非コンテンツにカスタム投稿タイプを使用します。 これらの投稿タイプは、ブログ投稿とはまったく似ていません。また、それらの抽象的なメタフィールドはブロックエディタの恩恵を受けません。 すべての構成をブロックで実行するように強制すると、プラグイン開発者が依存するようになったオープンキャンバスが削除されます。これは、プラグインエコシステムを現在の状態にしたのと同じオープンキャンバスです。

現在のアプローチは、メタボックスが脇役に限定されているブロックファーストのようです。 ブロックは多くのコンテンツに焦点を合わせたプラグインに利益をもたらしますが、抽象的な設定を定義する必要性は、メタボックスが提供する明白なラベルと使い慣れた入力から利益を得るでしょう。 そのような場合、開発者はキャンバス全体を自由に使用できる必要があります。

@westonruterカスタム投稿タイプに特定の追加フィールドが必要な場合、そのデータをブロックに入力するということを明確にしていただけますか？

もしそうなら、私はいくつかのフォローアップの質問があります：

1）そのブロックをデフォルトにすることはできますか？ IEは常にその投稿タイプに表示され、削除できませんでした。 たとえば、プラグインがイベントを作成し、各イベントに開始日と終了日がある場合、デフォルトでイベントのカスタム投稿タイプを編集するときに、開始日と終了日のブロックが必要であり、投稿コンテンツに含まれますか？

2）そのブロックからデータはどのように保存されますか？ 私が理解しているように、現在、ブロックからのデータはHTMLコメントとしてpost_contentに保存されています。 これらのブロックからデータを取得してメタを投稿するにはどうすればよいですか？ たとえば、架空のイベントプラグインの場合、開始日と終了日をポストメタに取得して、クエリを実行するにはどうすればよいですか？

3）これがすべてメインコンテンツエディタの方向に進み、カスタム投稿タイプに適用される理由は何ですか？ 特にブログ投稿/記事を表さないカスタム投稿タイプに関して、この設計の方向性を裏付けるユーザーテストはありますか？

@kevinwhoffmanまだブロックの根本的な競合は見られません。 抽象設定はコンテンツと見なすことができますが、種類は異なります。すべてデータです。 すべてのブロックは、「コンテンツ」に視覚的な表現を持つ必要はありません。 post_contentではなくpostmetaにデータを保存する「メタブロック」も非常に多いと思います。 編集中のブロックは、現在のメタボックスの表示方法と同様の見出し/ラベルを持つようにスタイルを設定できます。

@ Shelob9はい、カスタム投稿タイプに追加のフィールドが必要な場合は、ブロックで表示されると思います。 「商品」カスタム投稿タイプがある場合は、価格やバリエーションなどのフィールドを持つ単一のproduct-detailsブロックが存在する可能性があります。

1. そのブロックをデフォルトにすることはできますか？ IEは常にその投稿タイプに表示され、削除できませんでした。 たとえば、プラグインがイベントを作成し、各イベントに開始日と終了日がある場合、デフォルトでイベントのカスタム投稿タイプを編集するときに、開始日と終了日のブロックが必要であり、投稿コンテンツに含まれますか？

はい、正確に。 カスタム投稿タイプ、投稿フォーマット、およびページテンプレートはすべて、「ロック」され、削除または並べ替えることができない必要なブロックの概念を単純に含むことができます。 この一例は、投稿の抜粋のブロックです： https ：

1. そのブロックからデータをどのように保存しますか？ 私が理解しているように、現在、ブロックからのデータはHTMLコメントとしてpost_contentに保存されています。 これらのブロックからデータを取得してメタを投稿するにはどうすればよいですか？ たとえば、架空のイベントプラグインの場合、開始日と終了日をポストメタに取得して、クエリを実行するにはどうすればよいですか？

今日のほとんどのブロックは、データをHTMLでpost_content内に保存していますが、そうする必要はありません。 たとえば、 https：//github.com/WordPress/gutenberg/issues/1288で、コンテンツをpost_excerpt保存するExcerptブロックと、コンテンツをpostmetaに保存するFeaturedImageブロックの説明を見ることができます。 したがって、postmetaに格納される開始日と終了日を持つevent-detailsブロックを確実に作成できるはずです。

1. これがすべてメインコンテンツエディターの方向に進み、カスタム投稿タイプに適用される理由は何ですか？ 特にブログ投稿/記事を表さないカスタム投稿タイプに関して、この設計の方向性を裏付けるユーザーテストはありますか？

上記のとおり、データはpost_content 、postmeta、terms、またはその他の場所から取得して保存できます。 「ブロックファースト」であるという考えは、すべてが使用する共通の建物_block_を持つことであり、そうすることで、ブロックコンポーネントをWordPress全体で最大限に再利用できます。 それが私の理解です。

@ westonruter-説明ありがとうございます。 このエディタがブログ投稿/記事などではない投稿タイプにどのように関連しているかについての情報があまりないため、これは非常に便利です。

「メタブロック」の書き方に関するドキュメントがすぐに見られることを願っています。

投稿編集エクスペリエンスを通じてユーザーに何を教えているか、そしてそれがカスタム投稿タイプにどのようにマッピングされるかを検討する必要があります。

ブロックエディタでデフォルトの投稿を編集すると、ユーザーは各ブロックがコンテンツを表すことを学びます。 コンテンツに関連付けられている設定は、ブロックエディタの外部にあるパネル/メタボックスで利用できます。 コンテンツはブロックに存在します。 設定はパネルに表示されます。 ブロックエディタに表示されるのは、公開されたときのページのプレビューである必要があると他の場所で言われています。

次に、カスタム投稿タイプのブロックエディターで設定とコンテンツを組み合わせると、ブロックエディターがプレビューであるという考えが崩れます。 ブロックエディターにコンテンツの編集という最善の方法を実行させ、開発者がコンテンツブロックと同じ要件を共有しない設定インターフェイスを構築できるようにする必要があると思います。

私は、WooCommerceやEDDのようなメタボックスを追加する広範なプラグインに取り組んできました。 ほとんどの場合、コンテンツエディタは不要なので、画面から削除しました。 グーテンベルクと合併すべきものではないのではないかと少し心配です。
そうでなければ、これはすべてどこに行くのでしょうか。

私は@kevinwhoffmanに同意します。ブロックがメタを表す場合、これらは投稿コンテンツとは何らかの形で異なり、出力では予期されるべきではないという視覚的な合図がユーザーに必要です。 これに対処する1つの方法は、仕切りです。 これは基本的に、コンテンツがメタボックスから分離される方法を再解釈したものにすぎません。

これは私にとってすべての問題を解決するわけではありませんが、メタボックスを改良するための興味深い方法であり、おそらく既存のプラグインとかなり下位互換性があると思いますが、それはユーザーにとって一流のエクスペリエンスではありません。

これは、メタブロックがプライマリコンテンツであり、投稿コンテンツが説明として使用され、追加のメタブロックがある場合にユーザーに通知する1つの試みです。

@brentjettモックアップをありがとう。 ご指摘のとおり、設定をコンテンツから分離する必要性は重要ですが、そもそもYoastのような設定ボックスをブロックにする必要があるというメリットはわかりません。

• これはページ上のコンテンツを表すものではないため、ブロックエディタがページ上のコンテンツのプレビューであるという考えを破ります。
• 複数のインスタンスを必要としません。
• 他のコンテンツブロックの途中で再配置してもメリットはありません。
• デフォルトでページに表示されている必要があります。

これらの各特性は、ブロックのデフォルトの動作に反して実行されます。 確かに、所定の位置にロックしてデフォルトで表示できる1回限りの使用ブロックを作成するためのさまざまな議論があります。 しかし、すでにこの目的を果たしているメタボックスの実装の改善に集中できるのに、なぜブロックをメタボックスにねじるのですか？

そもそもYoastのような設定ボックスをブロックにする必要があるというメリットはわかりません。

ここに少し戻ってみましょう。 2つのこと。 1つは、PHPで記述された古いメタボックスのサポートです。この投稿では、「拡張設定」ドロワーをモックアップしています。

もう1つは、質問に答えることです。これをゼロから再設計したい場合、今日はどのようになりますか？

これは、多くの異なるインターフェースを統合できる新しいインターフェースとして、_blocks_を提案しているところです。 ブロックは、ショートコード、カスタムHTML、ウィジェット、および埋め込みのアフォーダンスよりも優れている可能性があることをすでに提案しています。 メタボックスの機能によっては、このインターフェイスも含めることができなかった理由はありません。

同意しました。 そして、Yoastについて少し話してみると、新しいエディターの周りの多くの場所に統合して、古いメタボックスをエミュレートするための1つの大きなブロックを構築する代わりに、グーテンベルクが目指しているエクスペリエンスを強化する予定ですが、上記の他の例があります。ブロックとしても機能すると思います。 少し手間がかかりますが、このエディターが少しトラクションを獲得するとワードプレスのユーザーを興奮させることがわかった場合、それは私たちがどのようにそれと統合するかを再考する刺激的な機会であり、結果として私たちの製品はより良くなると思います。

したがって、2つの_legacy_機能ケースがあります。
メタデータを処理するMetaBox（Yoastなど）と、コンテンツを入力するための構造化されたインターフェイスを提供するために使用されるMetaBox（WooCommerceなど）があります。

将来に向けた開発
白紙の状態から始めた場合（「過去の借金をキャンセルする」）、提案された「高度な」ドロワーにメタデータを配置することはうまくいく可能性があります。 また、構造化されたコンテンツエントリは、グーテンベルク内のロックされたブロック順序インターフェイスに収まる可能性があります。 これらは両方とも完全に架空のものですが、将来のWPCMS開発の実装として機能する可能性があります。

レガシービジネスCMSの問題
私の仕事の99％は、オーダーメイドのビジネスソリューションをクライアント企業に直接提供することです。 ですから、私の懸念は、将来構築する可能性のある素晴らしいものではなく、クライアントサイトの機能とビジネス関係の冷酷な事実です。 既存のCMSソリューションベースのビジネスをグーテンベルクに移行するための提案はありますか？ 私の状況では、各クライアントには、確立されたWPフレームワークに基づいて構築された異なる特注のCMSソリューションがあります。 私にとって、「過去への借金を取り消す」=「お風呂の水で赤ちゃんを捨てる」というフレーズ。

懸念事項
グーテンベルクがWP5.0のコアとして出荷された場合、クライアントには機能しないサイトがあると思います。 次に、各サイトを作り直し、各クライアントを軟化させる必要があります。 その週に約40人のクライアントがCMSの修理を希望するかもしれません。

• 従来のCMSメタボックスに依存するサイトとそのユーザーベースは、コアチームにとって不可欠ではないようです
• 「高度な」抽選提案＃952は優先順位が下げられており、地域全体に関心がないことを示しています。
• 「過去への借金」/ CMSの問題を解決するための提案された方法はありません

これは、多くの異なるブロックを統合できる新しいインターフェイスとして、ブロックを提案しているところです。 ブロックは、ショートコード、カスタムHTML、ウィジェット、および埋め込みのアフォーダンスよりも優れている可能性があることをすでに提案しています。

ブロックは、ショートコード、カスタムHTML、ウィジェット、埋め込みなど、これらすべてに意味があります。 これらはすべて、ページに表示されるコンテンツの形式です。 私は同意します、それらすべてをブロックします。

設定はそれらのどれでもありません。 設定には、ブロックの基本的な動作と重複しない明確な要件があります。 多くの場合、これらの設定ボックスには、投稿のフロントエンド表示とは関係のない投稿メタが保存されます。 投稿が表示されるたびにコンテンツと一緒に非コンテンツを解析する必要はないようです。

考慮すべきもう1つのことは、ユーザーがテキストモードに切り替えたときに何が起こるかです。 投稿コンテンツの横に設定ボックスを表すHTMLコメントがたくさん表示されますか？ ユーザーはこれらのなじみのないものを削除しますか？

ブロックをコンテンツとして扱い、設定を個別のUIコンポーネントとして扱うことで、これらすべてを簡素化できます。 従来のメタボックスを考慮する必要がなかったとしても（ @steveangstromが指摘した大きな問題

@steveangstromの懸念事項のセクションは、まだ回答されていない懸念事項のすばらしい要約です。

これは、将来何が可能になるかについての素晴らしい議論であり、すべてが素晴らしいように聞こえます。WordPressは本当にこれを必要としています。 私にとって、プラグイン開発者としては、大したことではありませんが、1つか2つのブロックを作成して上手くいきます。 しかし、下位互換性を期待してクライアントに販売されたSteveのクライアントとそこにある何百万ものWebサイトはどうなりますか？

ウェブサイトがアップデートで壊れてしまう可能性のあるクライアントもたくさんいるので、これらの懸念を理解しています。 私からのいくつかの考え：

コンテンツ管理にはACFを幅広く使用しています。 たとえば、投稿ごとに、またはリピーターに複数のTinymceエディターがあるとします。 目標がtinymceを置き換えることである場合、複数の「ブロックコンテナ」をどのように使用しますか？ 私は今正しく理解しています。「ブロックコンテナ」は1つだけですよね？

投稿編集フローに適合しないもう1つのACF機能は、オプションページです。 オプションページでこれがどのように機能するかは本当にわかりません。

下位互換性が必要な場合-gutenbergに更新する時間/リソースがない場合は、誰かが現在の編集エクスペリエンスを復元するためのプラグインを作成する可能性があります（これは私が使用する予定です）。 また、5.0はメジャーバージョンのバンプになります。つまり、重大な変更は問題ありません（少なくとも

WordPressはsemverに準拠していません。

@westonruterこれは理に

以前はメタボックスに配置していたフィールドを、ブロックに配置する代わりに、現在は前進します。

しかし、そこ（メタボックス）からここ（ブロック）にどのように到達するのでしょうか？ コードのバックコンパット（グーテンベルク用にまだ更新されていないプラグイン）とデータのバックコンパット（プラグインが更新された後、既存のメタボックスデータを新しいコンテンツブロックに表示するにはどうすればよいですか？それはプラグインです-スコープの問題？）。

しかし、そこ（メタボックス）からここ（ブロック）にどのように到達するのでしょうか？ コードのバックコンパット（グーテンベルク用にまだ更新されていないプラグイン）とデータのバックコンパット（プラグインが更新された後、既存のメタボックスデータを新しいコンテンツブロックに表示するにはどうすればよいですか？それはプラグインです-スコープの問題？）。

これらは良い質問です。 これらの機能を実装しながら、答えを探っていきます。

ここでどこに到達するかを推測する必要がある場合：現在のメタボックスは「レガシー」領域に移動され、「新しいスタイル」のmetabox-block-thingiesを登録するためのAPI、ドキュメント、および例が提供されます。

@nylen現在のメタボックスの_レンダリング_はどうですか？

メタボックスが優先されていることは朗報ですが、古いメタボックスを引き出しに配置したり、「レガシー」領域に限定したりする以上の解決策を検討する必要があります。

Advanced Custom Fieldsなどのプラグインを介して主にメタボックスで構築されたサイトは、現在無数に存在しています。 ここでは、投稿の下部にある1つまたは2つのボックスだけでなく、フルスクリーンのインターフェースについて説明しています。 ACFはGutenbergで動作するように更新されると確信していますが、これらのサイトは再構築されません。

それで、疑問が残ります。エディタがなく、完全にメタボックスで構成されているインターフェイスはどうなりますか？

それで、疑問が残ります。エディタがなく、完全にメタボックスで構成されているインターフェイスはどうなりますか？

ここでの考え方は、 @ mtiasが間違っている場合は訂正してください。プラグインでコンテンツ領域を非表示にするだけで、表示されるのはコンテンツが配置されるメタボックスだけです。

このエディターをフルスクリーン/気晴らしのないエディターのように動作させるのはどうですか？

+1。 これは、メタボックスを備えた現在のエディターにはまったく影響しないため、良い考えです。 気晴らしのないエディタは長い間存在していましたが、あまり使用されていません。 グーテンベルクの編集者は、編集者の画面を書き直す代わりに、これを取り入れて改善することができます。

また、 register_post_type場合、Gutenbergエディターのサポートをsupportsパラメーターで登録するとよいでしょう。

最後に、メタボックスの開発者として、新しいエディターでメタボックスを機能させるための新しいAPIを見てみたいと思います。 ここに表示されているように、多くの開発者は、投稿に追加のコンテンツを提供する方法としてメタボックスを使用しています。 これらのコンテンツは分類して、後で検索できます。 投稿コンテンツとしての単なるコンテンツのブロックではありません。 したがって、 add_meta_box()関数の新しい代替品がある場合は、メタボックスプラグインをリファクタリングしてそれを使用できるようにしています。

言われていることすべてに同意します：標準のメタボックスをまだ機能させる/場所を持たせる。 CMB2のリード開発者として、WordPress 5.0がリリースされたときにCMB2が何らかの理由で壊れた場合、かなり重大な抗議があることを保証できます。 私は確かにこれを脅威としてではなく、単に現実として意味します。

グーテンベルクによって導入されたデータモデルを使用するようにACF、ポッド、およびCMB2を更新できるほど、この移行は容易になると思います。

私は間違いなく長期的にこれを行うことを目指していますが、グーテンベルクがリリースされるまでにメタボックスライブラリがこれを実施することは公正な期待ではありません。 （確かに、それは期待ではないかもしれません）

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

そして、それが更新されたとしても、古いインストールは壊れてしまいます。

また、ACFのフィールドグループはメタボックス内にある必要はありませんが、タイトルとエディターの間に「サイド」、「通常-コンテンツの後」、「高」のオプションを持つ「シームレス（メタボックスなし）」スタイルもあります。 （!!!） '。 最後の1つは、意味のある編集フローを作成するために重要です。

世の中には重要な個々の開発がたくさんあることを覚えておいてください。誰もそれにお金を払わないので、それは決して更新されません。 これらの実装を破ることは、エンタープライズ環境におけるWPの究極のキラーになります。

@ wsydney76 ACFのフィールドグループはメタボックスにある必要はありませんが、タイトルの間に「サイド」、「通常-コンテンツの後」、「高」のオプションがある「シームレス（メタボックスなし）」スタイルもあることに注意してください。とエディター（!!!） '。 最後の1つは、意味のある編集フローを作成するために重要です。

これはWordPressで「正しく機能する」ものではありませんが、通常のメタボックスUIを削除するにはカスタムプラグインコードが必要です。したがって、Gutenburgを使用するには、ACFからの追加作業が必要になると想定するのが妥当です。

それを簡単に。 カスタム投稿タイプでエディター（グーテンベルク）のサポートが宣言されていない場合は、想像力、CSSスキル、および最も才能のあるコアデザイナーを使用して、エディター全体を別のものに変換します。 （ネイティブ）投稿編集画面でクライアント/ユーザーに表示されないように表示します。 見た目だけです。 クライアントは、グーテンベルクがバックグラウンドで動作するかどうかを気にしません。Web開発者から言われたとしても、それほど気にすることはできません。 彼らは視覚的なタイプの人々です。

下位互換性については、グーテンベルクが5.0に到達する発表のずっと前の、2月にWordPressの長期サポートバージョンを提案しました。

その時点ではありそうもない作業のように見えましたが、今ではそれが起こっているので、4.9をLTSバージョンにし、4.9より前のサポートを終了して5.0に焦点を当てることを議論することがさらに重要です。

投稿はここで見つけることができます：
https://khromov.se/wordpress-needs-another-long-term-support-version/

10年以上のWordPress開発者はこちら。 多くの人が指摘しているように、この開発はコンテンツに最適です。 これは、カスタムマークアップを使用した動的コンテンツブロックに本当に必要な標準ソリューションです。 そうは言っても、これはコンテンツから離れてWordPressをフレームワークに近づける方法で投稿タイプの使用を制限します。

例として：私は、投稿タイプ（他の多くのように）のフィールドを作成できるだけでなく、それらの間の関係（つまり、1対1、1対多など）を作成できるプラグインのスイートを構築しました。 これは（より多くの機能とともに）投稿タイプをLaravelやRailsなどのフレームワークのモデルに非常に近いものに変えます。次にDSLを使用して、それらの投稿、それらのデータ、およびそれらの関係を処理します。

このタイプの使用は珍しいことではなく、WordPress自体が、開発者が投稿タイプを非公開として宣言できるようにすることで、投稿タイプの創造的な使用を奨励しました。 「public」、「publicly_queryable」、「show_ui」などのフラグはすべて、開発者がWebサイトの公開ページとの単純な1：1ミラー関係以外の目的で投稿タイプを使用できるようにすることを目的としています。

グーテンベルクはそのビジョンにどのように適合しますか？

このエディターをオプションのままにする以外の解決策はありません。つまり、TinyMCEを置き換える必要がありますが、TinyMCEが現在オプションであるように、エディターはオプションのままにする必要があります。

エディターをサポートしない投稿タイプを作成し続けることができ、それらの投稿タイプでメタボックスを使用し続けることができれば、コンセンサスにはるかに早く到達できると思います。

テーマとプラグインの開発者からの新しいエディターの採用は、このタイプのアプローチでは遅くなる可能性がありますが、正直なところ、新しいプロジェクトを開始できる4.9LTSの道を進むことを意味しない別の方法は見当たりません。 WP5.0とレガシープロジェクトで4.9LTSを維持します。

更新：このコメントを書いたとき、スレッドのタイトルが異なり、メタボックスを非推奨にする可能性が議論されていました（つまり、コアチームは、以下のコメントのように、この質問に「いいえ」で明確に回答していませんでした）。 このようなシナリオでは、グーテンベルクは単に動的ブロックをサポートし、メタボックスの他の多くのユースケースを無視していたため、上記のコメントがあります。

みんなのコメントを読んでしばらく過ごしたので、編集画面のこの進化の可能性のある結果は、このjsベースの編集画面内で機能する新しいメタボックスAPIを提供することであるように思われます。 つまり、上記のようにクリエイティブな方法で投稿を使用する機能が実際に失われることはありませんが、それを行うための新しいAPIを取得するだけで、UIはjsベースになります。

WordPress REST APIとGatsbyJSを使用してReactを利用したアプリを構築するために、ポッド2.7を使用することを計画しています。
グーテンベルクはポッドと互換性がありますか？

この重大な問題は、マイルストーンから削除されたようです。 ブログ編集用のベルやホイッスルが多くの作業を行い、ベータ版に追加されている間、それは_再び_優先順位が下げられました。 これは、CMSとしてのWordpressの将来にとって非常に心配です。

GenerateWPに触発された独自のコードジェネレーターを作成しました。 パブリックではなく、ローカルホストでの私自身およびプライベートな使用のため。
とにかく、切り替えが行われたとき、グーテンベルクではどのように見えるのだろうか。 ACFフィールド、プレビュー用の多くのカスタムPHPコード。

私たちはこの問題を忘れていません。 むしろ、エディターをうまく機能させるための他の多くの優先事項とともに、私たちが調査し始めたばかりの非常に複雑な問題です。

メタボックスを配線するときに遭遇する問題のいくつかは、＃2251を読むと明らかになる可能性があります。これには、技術的な観点からの次のステップに関する情報も含まれています。

ここで、この問題について強調したい主なポイントは、この実装を計画およびテストするには、コミュニティからの支援が必要であるという

確認するプラグインのリストの開始点は次のとおりです。

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+

上に表示されないプラグイン。おそらくWP.orgプラグインディレクトリにないためです。

• フィールドマネージャー

同様のタスクを実行する他の広く使用されているプラ​​グインをご存知の場合は、この号でお知らせください。

これらのプラグインのいずれかの開発者である場合、および/またはこれらのプラグインのいずれかがメタボックスを追加し、関連するスクリプトまたはスタイルシートをキューに入れるために使用するWordPressフックの詳細を提供できる場合は、この号でお知らせいただくか、新しいプラグインを作成してください上記のリストにある特定のプラグインごとに発行します。 この情報の収集には時間がかかり、すべてを1か所にまとめることはさらなる開発努力に非常に役立ちます。 例えば：

Advanced Custom Fieldsは、 admin_enqueue_scriptsに対してフックを登録することにより、メタボックスを追加します。 このフックは、現在のページの読み込みがpost.phpまたはpost-new.phpいずれかであることを確認し、そうである場合は、 admin_headを呼び出すadd_meta_box admin_headアクションを追加します。 WPコアは、そのアクションの直後にedit-form-advanced.php do_meta_boxes呼び出しを実行します。

最後に、WordPressが現在メタボックスをレンダリングおよび保存する方法に精通している開発者の場合は、ここおよび/または＃2251での入力を歓迎します。

こんにちは、みんな、
ここのエリオット-ACF開発者

ACFは、 admin_enqueue_scriptsアクションを使用して「フィールドグループマッチングロジック」を実行し、次にadmin_headアクションを使用してメタボックスを追加します（ add_meta_box()介して）。 add_meta_boxesアクションは使用しません。

ここで明白な質問をすることはできますか？ なぜメタボックスの「難しさ」について話し合っているのですか？ これらは、すべてのWPWebサイトの不可欠な部分です。 確かに、メタボックスロジックはそのままにして、新しいグーテンベルクエディターエリアと一緒に使用できます。

必ず@woocommerceにもタグを付けてください。 それらはおそらく最大のメタボックスプラグインです。

ありがとう
E

こんにちは、みんな-

私はまだいくつかの考えやアイデアを策定していますが、この議論は少し集中しすぎているように思われるので、簡単な質問に立ち寄りたいと思いました。

メタボックスにフィールドを追加することだけを話しているのはなぜですか？ 現在のシステムでは、何でも追加できます。 データ、サードパーティのAPIを使用してツールを使用するためのJavaScript、メモやヘルプ情報のクイック表示、そしてハイタッチをするかわいい子猫の写真もあります（これではないかもしれませんが、誰が正しいのかわかりますか？！）。

ここで私が言いたいのは、メタボックスは、フィールドを含むがこれに限定されないさまざまなものを保持できるユニバーサルコンテナであるということです。 今のところ、PHPを使用するとこれを行うのは非常に簡単ですが、現在、たとえばテキストを投入するためだけにReactコンポーネントを作成する方法を知っているように人々に求めていますか？

私が言ったように、会話のコンテキストに追加しようとしているだけです。

ありがとう、

Kevin-Piklistの主任開発者

この質問は上記の多くのコメントでほのめかされていますが、私の知識には答えられていません。

メタボックスや既存のフックを含むインターフェイスの残りの部分を変更せずに、既存のTinyMCEポストエディターをGutenbergに置き換えることは可能ですか？

この狭い範囲では、投稿タイプの登録時にeditorサポートを定義することで、グーテンベルクをカスタム投稿タイプに含めたり除外したりできます。

• editorサポートが登録されている場合、グーテンベルクは編集画面に表示され、既存のメタボックスは現在のエディターの周りで現在と同じように機能し続けます。
• editorサポートが登録されていない場合、グーテンベルクはロードされず、現在のように空白のキャンバスをメタボックスで使用できます。

このアプローチは、リソースを解放して最高のエディターを可能にする一方で、既存のメタボックス実装との下位互換性という大きな課題を回避しているようです。

ここで明白な質問をすることはできますか？ なぜメタボックスの「難しさ」について話し合っているのですか？

@ elliotcondon-開発の問題を解決するのが難しい場合、解決策にたどり着く唯一の方法は、問題を解決することです。 私はこれを＃2251から始めましたが、そこで説明されているように、簡単な作業や簡単な修正にはなりません。

ACFがメタボックスを登録する方法について収集した情報を確認していただきありがとうございます。 特にACFに関する実装をさらに進めるために、知っておくと役立つ次のことを次に示します。

• ACFメタボックスの機能を制御するためにどのスクリプトとスタイルシートがキューに入れられるか
• それらをキューイングする責任があるアクション
• キューに入れられるかどうかを制御する条件。

メタボックスにフィールドを追加することだけを話しているのはなぜですか？

グーテンベルクのコードがメタボックスが実際に何をしているのかをあまり気にする必要がない場所に行きたいです。

その目的に向けて、 @ kevinpmiller 、Piklistについて知っておくと役立つ次のことを次に示します。

• メタボックスを登録するためにadd_meta_boxを呼び出す責任があるアクション
• 登録されているかどうかを制御する条件（たとえば、現在の画面はpost.phpまたはpost-new.php ）

この号では、既存のPHPメタボックスをGutenbergインターフェースと一緒に機能させることに焦点を当てた会話を続けましょう。

今のところ、PHPを使用するとこれを行うのは非常に簡単ですが、現在、たとえばテキストを投入するためだけにReactコンポーネントを作成する方法を知っているように人々に求めていますか？

はい、「新しいスタイル」のメタボックスを作成するための一連のAPIを作成する必要があります。 これが今日のブロックの内容です-メタボックスがpost_content以外の場所に保存できる「ブロック」として登録されているので、かなり似ていると思います： //gutenberg-devdoc.surge.sh/

新しいスタイルのメタボックスについての議論は、＃1684または別の問題で行われ、技術的なAPIを提案する必要があります。

editorサポートが登録されていない場合、グーテンベルクはロードされず、現在のように空白のキャンバスをメタボックスで使用できます。

@ kevinwhoffman-今日書かれているグーテンベルクはpost_content編集者になることを目的としています。 したがって、 editorサポートが有効になっていない場合、少なくとも今のところは無効にするのは当然のことです。 これは、コードの観点からも非常に簡単な作業です。 このための新しい問題を作成できますか？ Good First Taskラベルでタグ付けしますか？

今日書かれているグーテンベルクは、 post_content編集者になることを目的としています。

@nylenGutenbergが本当にpost_contentエディターになることを意図している場合、メタボックスはpost_content関係しないため、そのままにしておく必要があります。

さらに、PHPメタボックスをReactメタボックスに変換するためのAPIの必要性は、製造上の問題です。 問題になる必要はありませんが、 post_contentエディターを書き直すことでメタボックスの動作も完全に変更する必要があると判断されたため、問題になっています。

＃2251で、このようなAPIを作成する際の大きな課題について概説しました。 PHPメタボックスをACFのような人気のあるカスタムフィールドソリューションのReactに変換することは、人気があるかどうかにかかわらず、今日存在するすべてのメタボックス実装に対してそうしようとすることは言うまでもなく、十分に困難です。 スケーリングしません。

@ kevinwhoffman-非常によく言われています。 これは、私の正確な考えと、私が話をした他の多くの開発者を反映しています。

この問題を話題から外したくはありませんが、新しいJSページビルダーを導入するときに「メタボックス」の問題が必要な理由がわかりません。 これは私が言うとき私が意味することです：

メタボックスの「難しさ」について話し合うのはなぜですか

私はそれを読んでうれしいです：

エディターサポートが登録されていない場合、グーテンベルクはロードされず、現在のように空白のキャンバスをメタボックスで使用できます。

上記が当てはまる場合、すべてのwp-adminロジック（アクション、関数など）は、投稿の編集画面で同じ（ish）のままである必要があります。 したがって、メタボックスHTMLを何年にもわたってレンダリングできない理由はありません。

@nylen
ACFは、いくつかのJSファイルとCSSファイルをキューに入れて、ACFメタボックスHTML要素のスタイルを設定して操作します。
ACFは、「admin_enqueue_scripts」アクションを使用してこれらのアセットを追加します
他の多くのプラグインとテーマがスタイル/スクリプトをキューに入れます-なぜこれが問題になるのでしょうか？
ACFはメタデータの保存にJSを使用しません。 save_postアクションを使用して、 $_POSTデータを保存します。これはごく普通のことです。

さらに、PHPメタボックスをReactメタボックスに変換するためのAPIの必要性は、製造上の問題です。

これは私たちがしていることではありません。 これは、従来のpost.phpロードプロセスを使用しなくなったため、必要なものを選択する必要があります。

エディターサポートが登録されていない場合、グーテンベルクはロードされず、現在のように空白のキャンバスをメタボックスで使用できます。

明確にするために：これは現在のところそうではありませんが、PRで調査することは合理的なことです。 これが今日機能するのを見ることに興味があるなら、助けてください、それははるかに速く進みます。

@kevinwhoffman @elliotcondon @nylenまたはさらに良いことに、どうですか？

• block-editorサポートが登録されている場合は、グーテンベルクを使用してください。
• editorサポートが登録されている場合は、TinyMCEを使用してください。
• どちらのサポートも登録されていない場合、GutenbergもTinyMCEもロードされません。

グーテンベルクの有無に基づいてWP管理者の経験を壊すことには賛成しません。

グーテンベルク=新しいReactメタボックスとグーテンベルクなし=古いPHPメタボックスの場合、骨折した管理者が私たちの目指す方向です。

メタボックスは、エディターが存在するかどうかに関係なく、どこでも同じように機能するはずです。

例：5つ星から投稿を評価するためのメタボックスを追加するプラグインがあるとします。 プラグインは、あらゆる投稿タイプを評価できるように構築されています。 投稿タイプがエディターを使用しているかどうかに基づいて、そのメタボックスの内部を変更する必要があるのはなぜですか？

@kevinwhoffman

グーテンベルクの有無に基づいてWP管理者の経験を壊すことには賛成しません。

それはblock-editorに関する私の提案、または何か他のものへの応答

ところで、私は私の提案が経験を壊しているとは思いません。WordPress構成に存在する場合は既存のメタボックスを含めるというあなたの提案に基づいていると思います。

@mikeschinkelグーテンベルクを有効または無効にする機能は必要ですが、グーテンベルクがメタボックスの動作を決定するという考えは私が反対しているものです。 それらは別の問題です。

@kevinwhoffmanところで、私はあなたに同意します。

ポッドからは、ACFおよびCMB2と同じアクションを使用して、通常の文書化された標準的な処理を実行しています。 私たちは皆、今のところ推奨されている方法でそれを行っています。

グーテンベルクと一緒にメタボックスを使い続ける能力に+1すると、最終的にはコンテンツに直接属するものにグーテンベルクを使用できるようになります。それ以外のすべての場合、属性や「投稿」に関する追加情報に必要なメタボックスがまだあります。 "（任意のタイプ）。

-1 Reactですべてを書き直す必要がある場合は、少なくとも、全員がReactメソッドに慣れるまでの長い間、両方をサポートし、メタボックスの実装でより多くの問題を解決します。 PHPメタボックスを段階的に廃止し、バックコンパットのために保持し、Reactメタボックスのドキュメントと開発者のスキルがその分野で向上するにつれてプラグインを移行させる必要がある時期はないと思います。

このチケットでの議論と、そこから始まる公的および私的な会話に続いて、ここで答えなければならない重要な質問が1つあると思います。

WordPressはMetaboxAPIを正式に非推奨にするつもりですか？

答えが「いいえ」の場合、「物事を動かして少し不自由にしましょう」全体は初心者では

答えが「はい」の場合、これは後方互換性ポリシーの大幅な変更であり、WordPress開発全体の時代の終わりです。 グーテンベルクでメタボックスを「解決」するだけではありません。 WordPressコア開発の何年にもわたるスパンが特定の方法で行われ、特定のレベルの下位互換性の期待が終わったことを、膨大な再教育と明確化が必要になります。

残念ながら、現在の答えは「はい」とは言えないようですが、「いいえ」のふりをしながら、物事を壊そうとしています。 個人的には、主要なコア機能に対して非常に非定型的なアプローチであると感じており、そのような方法で行われていることは非常に不安です。

投稿編集画面は、必要最低限​​のブログを超えたすべてのプロジェクトで最もカスタマイズされた画面です。

これらのカスタマイズは、メタボックスの登録に限定されません。 編集管理画面が提供するフックは、同じプロジェクトで使用されています。 また、フックがない場合、開発者はjQueryを使用してUI要素をページに挿入します。

したがって、これらのカスタマイズには、前進する方法が必要です。

メタボックスの場合、VIP承認済みであるため、Fieldmanagerが最適なツールです。 Fieldmanagerは強力ですが、限られたフィールドのセットに焦点を合わせています。 多くの場合、レガシーコードベースは、Fieldmanagerまたは別のユーティリティライブラリを使用するように改造することはできません。

したがって、多くのメタボックスは依然としてカスタムコードを使用して構築されています。 カスタムコードとは、PHPとJavaScriptの組み合わせを意味し、多くの場合、Ajax主導の相互作用を伴います。

これらすべての注意深く作成されたメタボックスを意図した位置からエディターの下の領域に詰め込むという提案はばかげています。

現在利用可能な[編集後]画面のカスタマイズオプションからの回帰は受け入れられません。

既存のコードを更新する必要がある場合は、これらのアップグレードがクライアントプロジェクトで行われるように、すべての新しいAPIが完成した瞬間から12〜18か月を数えることができます。 つまり、レガシーAPIと新しいAPIの両方が共存するデュアルラン期間が必要です。

メタボックスがグーテンベルクと何もしなければならない理由がわかりませんか？ これは、1つのバックエンドページである画面です。 何百もの方法で配置することができます。
あなたは現在の実装がReactを壊すと言いました。

開発者に、メタボックスをグーテンベルクに結び付けるか、外部に保持するかを選択させます。
このすべての問題は、誰もが何らかの方法でグーテンベルクブロックを作成する必要があると想定しているためです。 彼らがそれを望まないのなら、それを必要としないのです。

個人的には2番目に大きな問題です。 私はいつもjavascriptに苦労していました、私はこの言語に対して反才能があります。
わかりました、すべてが私の周りを回転するわけではありませんが、言うだけです。 以前よりもメタボックスを追加するのは簡単ではありません。

@Rarstはこの問題を素晴らしく要約したと思います。 コミュニティには明確な答えが必要であり、開発チームは非推奨の方向性に従う傾向があるように見えますが、最初に解決策を見つけようとしているため、明確に説明することはできません。これは私が完全に尊重しています。 コミュニティが何ヶ月もパニックモードに入る必要はありませんが、同時に、同じコミュニティには十分な注意と明確な道が必要です。 これは正直なところ、見つけるのが難しい妥協案です。

@ fklein-lu私はFieldmanagerが「選択のツール」であるべきだということに強く反対します。 トップ10フィールドプラグインのリストにも表示されません。
https://github.com/WordPress/gutenberg/issues/952#issuecomment -320523428

他の多くの人が言っているように、メタボックスとグーテンベルクを一貫性のある接続されたインターフェースにしたいという願望は理解していますが、メタボックスの動作方法を変更すると、信じられないほど複雑になり、最終的には人々にとって大きな抑止力になる可能性があります。 歴史は、バージョン間に大きな非互換性を導入すると、コミュニティを大幅に断片化する可能性があることを示しています。

ダッシュボードのバックエンド画面にメタボックスを追加するにはどうすればよいですか？
それはグーテンベルクとは何の関係もありません。

@khromov私の言葉を誤って引用するのではなく、私が実際に書いたものを読んでください。 また、参照している投稿を読むと

@ fklein-luなぜ私があなたを誤って引用していると思うのかわからないので、完全なコンテキストは次のとおりです。「メタボックスの場合、VIP承認されているため、Fieldmanagerが最適なツールです。」 Fieldmanagerを使用している人は誰も知らないので、その引用を理解するのに苦労しています。

FieldmanagerがWPorgにないことを知っています。 私が言っているのは、そこからの使用状況データがないということです。 いくつかのトッププラグインに匹敵するかどうかは非常に疑わしいです。また、VIPに使用するプラグインを除いて、コミュニティのサポートはほとんどありません。VIPは、開発者の総数のごく少数です。

私たちのエージェンシーでは、3.xのどこかでWordPressがブログシステムからコンテンツ管理システムへの一歩を踏み出したと信じています。 現在、プロジェクトに必要なコンテンツを形作ることができ、カスタム投稿タイプとメタボックスを使用して、テキストだけでなくさまざまなコンテンツを作成しています。

5.0でブロックエディタが必須になった場合、これはCMSからブログシステムへのイデオロギー的な後退になると強く信じています。 WordPressをホテル予約ソリューション、ジョブプラットフォーム、アプリ用ヘッドレスCMS、位置情報サービスなどとして実行するエンタープライズアプリケーションは数多くあり、その多くのユースケースではエディターがアクティブ化されていません。

現在のメタボックス実装との完全な下位互換性は絶対に必要です。 それを破ると、今後数年間、クライアントやユーザーとの信頼が失われます。 私のお気に入りの解決策は、「theme_supports」のライン上の何かと気を散らすことのないユーザビリティです。

TL; DR：エンタープライズクライアントがメンテナンス以外の目的で今後12か月以内にコードを更新することを期待しないでください。 適切なタイムラインで非推奨ポリシー/警告を追加します。 バックエンドとコードの使いやすさの観点から変更を強制する場合は、WordPressへの信頼が大幅に低下することを期待してください。

それはどういうわけか、コーディングではなく、政治、または投票/選挙としてなりました。 一部の人々は、古いメタボックスが「古い」、「後方」、「制限されている」と判断し、それらのための場所はもうありません。 それらに対する実際の議論や理由はありません。 Reactやその他のスクリプトがターボモダンであることを除いて、私はそれらを見たことがありません。

私はまだ古いメタボックスを捨てる解決策を見つけることであなたをサポートし、あなたがグーテンベルクの方法を想像したようにそれをします。 しかし、あなたはそれを解決する方法がわからないようです。

多くがまだ私にとってブラックホールであるとき、これらすべてを議論するのは難しいです。 そして、私だけではありません。

この問題で私がどれだけ客観的であるかを述べるために、次のことを試みてください。

• TinyMceと古い投稿画面（メタボックス付き）は、CMSの世界で見た中で最も美しいものだと思います。 機能、フィルター、拡張、そして美しいデザイン。 はい、純粋な美しさと喜び。
• それにもかかわらず、私は初日からグーテンベルクを受け入れました。 はい、この「古い」ものをすべて捨て、切り替えて、決して振り返らないでください。

彼らは私が知らないことを知っていました。 彼らはコードを所有しています。 しかし、私はもうわかりません。

第二に、それを忘れており、この文脈では非常に重要です。 ここではすでに数回言及されています。
私は他の人とは少し違うことをします。 私が最初からグーテンベルク（とにかくそのうちの1つ）を受け入れた理由は、私がウェブサイトを作った人々にグーテンベルクを使うように説得するのに個人的には何の問題もありません。 TinyMceとはまったく異なる何かを彼らに強制するとき、それは大きなショックです。
私はすべてのプラグインとWPコアの更新をそれらすべてに対して無料で行います。 したがって、このジレンマでは、グーテンベルクと残りの時間の更新の停止のどちらかを選択する必要があります。 彼らの選択は明らかだと思います、

他の多くの開発者、企業は、更新に対して料金を請求します。 したがって、このジレンマはそれほど簡単ではありません。

@khromov私はFieldmanagerを管理しているAlleyで働いています。 製品の方向性を決定する間、スレッドを積極的に監視しています。 WordPress.orgのユーザーベースは通常Fieldmanagerを使用しないと言っても過言ではありませんが、プラグインはライブラリおよびカスタム/エンタープライズフレームワークとして広く採用されています。

また、@ Rarstと@kevinwhoffmanを+1したいと思います。 既存のメタボックスの完全なサポートを維持することで、「レガシー」メタボックスをTBDグーテンベルクの同等のものに置き換える将来を可能にする可能性があります。 ただし、下位互換性を取り巻く現在の不確実性は、できるだけ早く軽減する必要があります。

WordPress.orgからのプラグインのインストール数は、プラグインまたはライブラリを含めるか除外するかを示す唯一の指標にはなりません。 Fieldmanagerを広範囲に使用する_single_サイトを知っており、月に2400万人近くのユニークビジターにサービスを提供しています。

そのため、特定のプラグインを使用する開発者はごく少数ですが、不均衡な量のトラフィックと多くの可視性を得るサイトの開発と保守を担当しています。

したがって、彼らはこの議論から除外することはできません。 AutomatticのGutenbergチームはVIPチームと協力して、これらのユースケースについての洞察を得る必要があると思います。

これらのエンタープライズプロジェクトは、より遅い速度で移動します。 実際のコーディング作業ではないメタボックスやその他のUI要素のアップグレードには多くの作業が必要です。 5.0の時間枠でこれらすべてのサイトをアップグレードするのに十分なエンタープライズ開発者さえいません。

このスレッドの他の人々が指摘しているように、このペースを考慮に入れたアップグレードパスが必要です。 このように、積極的なメンテナンス作業の一環として、変更が徐々に発生する可能性があります。

@ fklein-lu上記を参照してください。私たちは耳を傾けており、コードで共同作業したい場合はいつでも連絡できます。

VIPとエンタープライズ市場に関しては、来週デンバーで@mに連絡を取りましたが、AFAIKは誰も参加できません。

「5.0」のタイムラインに関して、この時点で、私がインタビューしたエンタープライズエンジニアは、既存のTinyMCEエディターとメタボックスを使用するのに十分簡単なオプトアウトパスがあると想定しています。 グーテンベルクチームもこの仮定に👍を与えたと信じてください。

また、Jetpackを使用するWebサイトが1つあり、1日あたりのユニークビジター数は2つだけです。
簡単に気分を害するのをやめなさい。 これはWordPressであり、新しいJoomlaバージョンについての議論ではありません。 :)

@ fklein-lu絶対にあなたに同意します。 しかし、メタボックスフィールドの「選択ツール」となるものがあるとすれば、それは提案されたFieldsAPIだと思います。

@davisshaverそれが賢明なことだと思います。 WordPressが下位互換性のない非推奨アプローチを強力に強化しようとすると、誰かがコードの古いチャンクを「並列」のレガシーベースの代替投稿およびメタボックスシステムに移植し、プラグインなどとしてパッケージ化するのを簡単に見ることができます。 個人的には、それが絶対に最後に起こることを望んでいます。 繰り返しになりますが、これを実現するのは間違いなく大変な作業です。WordPressコミュニティをこの新しい未踏の土地に運ぶことに携わっているすべての人に幸運を祈ります。

ここでチャイムを鳴らし、懸念やアイデアを表明してくれた皆さんに感謝します。 これは長いスレッドになりつつありますが、いくつかの点を明確にしようと思います。

WordPressはMetaboxAPIを正式に非推奨にするつもりですか？

番号。

まだ完全には答えられていない質問は、_グーテンベルクエディターのコンテキストでメタボックスがどのように機能するか_です。 それらは同じままであるか、進化する必要がありますか？ 混乱を最小限に抑えながら、どうすれば設計目標に向かって進むことができるでしょうか。

この問題は、欲求の欠如ではなく、リソースの不足のために長引いています。 このプロジェクトの主な焦点は、ブロックの概念を通じてユーザーコンテンツの直接操作を最適化するリッチコンテンツ編集インターフェイスを提供することです。 （さまざまなプロジェクトでメタボックスを幅広く使用してきたため、ブロックは、より優れたユーザーエクスペリエンスを提供しながら、これらのニーズの多くに対してより優れた前進を提供できると思います。）

それでも、メタボックスと拡張性を処理する方法は複数あります。

• メタボックスが登録されていることを検出すると、古いインターフェイスにフォールバックできます。何も変更されません。
• コンテンツの編集とメタ情報の変更を2つの画面またはステージに分割することができます。
• これらをコンテンツの下に（PHP）そのままレンダリングすることがどれほど実現可能かを確認することができます：＃2251。
• テーマ/プラグイン/ CPTは、必要に応じて新しいインターフェースの登録を解除できます。
• メタボックスに依存するさまざまなアイテムは、UI用のブロックに変換できます（データは個別に保存されます）。
• FieldsAPIのようなAPIベースのメタボックス拡張性を実装できます。

またはこれらの任意の組み合わせ。

繰り返しになりますが、確実性の欠如は意志の欠如ではないので、ここで最良のソリューションを構築する上でコミュニティからの助けに間違いなく感謝します。 考えられる解決策を実際に検討する必要があり、トレードオフ（設計と開発の観点から）を明確に書き出す必要があるということだけです。

番号。

ありがとう、たくさんの人が息を吐いたと思います。

まだ完全には答えられていない質問は、グーテンベルクエディターのコンテキストでメタボックスがどのように機能するかです。

グーテンベルクエディターのコンテキストでメタボックスが「ある」のはなぜですか？

答えは、グーテンベルクがポストエディター全体をJS主導の実装に置き換えることを目指しているようです。 私はその理由を認識するために開発を追跡していませんでした。

しかし、それでも非常に有効な指摘だったと思います。グーテンベルクのスコープをエディターコンポーネントにする場合、_screen_スコープを置き換えることは非常に野心的です。 グーテンベルクの範囲が（少なくとも部分的に）WordPress _admin_全体の置き換えである場合、それは_信じられないほど_より広く、要求の厳しい範囲です。 「ただの」エディタを置き換えるのは簡単ではありません。

それでも、メタボックスと拡張性を処理する方法は複数あります

グーテンベルクはメインの_editor_コンポーネントを置き換えるスコープであり、既存の管理UIは引き続き機能しますか？ _this_が検討されていますか、そうでない場合はなぜですか？

私が作成したフィールドマネージャープラグインについてのみ話すことができ、現在60を超えるさまざまなプロジェクトで使用しています。 これが誰もが自分のシナリオについて考えるのに役立つことを期待して、この変更がそれにとって何を意味するように見えるかについて簡単に述べます。

共通の抽象クラスとインターフェイスを使用して高度に分離されたアーキテクチャを構築するという問題を経験したため、私がしなければならないのは、新しい「場所」を追加することだけです。 これが私のポイントに関連するアーキテクチャコンポーネントです：

• 場所：フィールドグループが添付されている場所（投稿、ページ、分類用語など）と、場所ごとのバリエーション（投稿と設定の場所はメタボックスで機能します）。 このクラスは、以下で説明するすべての可動部分をインスタンス化します
• ロケーションデータストア：データの取得と永続化を担当するレイヤーで、ロケーションごとにバリアントがあります（たとえば、ポストデータストアはポストメタで機能し、設定はオプションで機能します）。
• ロケーションビュー：必要に応じて、設定ページの場合と同様に、テンプレートとヘルパー関数を保持するViewクラスです。

さて、グーテンベルクの文脈で、この新しいエディターをサポートする場合、私が個人的にしなければならないのは、グーテンベルクと呼ばれる新しい場所を追加することだけです。この場所には次のようになります。

• グーテンベルクエディターにフックする独自の初期化メソッド。 これはほとんどjavascriptベースになると思いますので、私のライブラリはこの目的に必要な一般的なスクリプトを登録してロードします。

• 独自のビュー/テンプレート：フィールドタイプごとにreactコンポーネントを作成する必要があります。 これは大したことではありません。他のすべての部分が適切に設定されている場合、ビューレイヤーは非常に簡単に作成できます。 これらのコンポーネントは、メタボックスの反応コンポーネントにネストされます。 これはすべて、phpベースのメタボックスhtmlに対してすでに行っていることと非常によく似ています。つまり、フィールドhtml>フィールドグループhtml>場所（設定ページhtml、メタボックスなど）です。

• 独自のデータストアクラス。 このクラスはポストメタベースになるため、ポストロケーションデータストアと大きく異なるとは思いません（ポストメタをすぐに非推奨にすることを誰も考えていないことを想像します）。

• 新しい部分：エンドポイント。 これらの新しい反応ベースのコンポーネントは、値を取得して永続化するためにデータストアと通信できる必要があります。 これらは完全にクライアント側に存在するため、ロケーションデータストアと通信するためのブリッジとしてエンドポイントが必要になります。メタストアは、どのようなコンテキストなどで読み込まれるコンポーネントを取得するためにも必要です。

主要なものを見逃していない場合（グーテンベルクをチェックする時間がまだないことを認めます）、これは多かれ少なかれ、この新しい「場所」をネイティブにサポートするために私がしなければならないと思うことの要点です。 また、各場所とそのフィルターの組み込みチェックを使用して、開発者が求めていることが可能であることを確認します。たとえば、投稿タイプが「ビデオ」の場合の形式である「プロジェクト」投稿タイプにフィールドグループを追加しようとした場合などです。 "ただし、CPTは投稿形式をサポートしていないため、ライブラリは例外をスローします。 この新しい場所で同じフィードバックを提供できることを願っています。たとえば、投稿タイプが「レビュー」であるグーテンベルクの場所にフィールドグループを追加した場合、その投稿タイプがどこにあるかを知ることができるといいのですが。グーテンベルクをサポートするために登録されました。

これは、私が予想していたよりも少し長くなってしまいました。 グーテンベルクの開発に関わっている人や、同様の懸念を持ってフィードバックを共有できる図書館の著者からの返信をお待ちしています。

ありがとう。

グーテンベルクはメインエディターコンポーネントを置き換えるスコープであり、既存の管理UIは引き続き機能しますか？ これは考慮されていますか、そうでない場合はなぜですか？

グーテンベルクは、エディターボックスから始めました。 キックオフの目標は、単一の統合ブロックインターフェイスの下で複数の異なるインターフェイスを統合することでした。 この統合されたブロックインターフェイスを中心に展開する魅力的なエクスペリエンスを作成するには、設定と公開を含む完全な書き込みフローを考慮する必要があることがすぐに明らかになりました。

WordPressの主な強みが、誰でも簡単にリッチな投稿を作成できるようにすることである場合、エディターの使用方法をすでに知っている私たちのためだけにデザインすることはできません。 これまでWordPressを使用したことがないユーザーと、最新のパブリッシングインターフェイスに期待することを考慮する必要があります。 そうでなければ、すでに重いインターフェースに認知的負荷を追加するだけです。

まだ終わっておらず、簡単ではありませんが、日々取り組んでいます。

☝️いくつかの誤解にうまく対処するために、チケットのタイトルと説明を更新しました。

新しいグーテンベルクエディターとButterBeanの未来

上記のように、私はButterBeanメタボックスフレームワークをリストしています。 必要に応じて新しいチケットを作成できます。

リポジトリ： https ：

テストの目的で、フレームワークはこのプラグインに含まれています： https ：

ButterBeanは、Backbone.jsとUnderscore.jsで構築されたドロップインフレームワークです。 これは、コアWPのカスタマイザーから大きくモデル化されています。

これは若いフレームワークですが、今年はいくつかのプラグインに組み込むことを計画しています。 現在、グーテンベルクの指示により、私や他の人はこれを行うのをためらっています。 そして、Reactで最初からやり直す必要があるのか​​、それともJSフレームワークが最終的にコアWPに追加されることになったのかさえわかりません。

使用したフック

以下は、使用される主要なコアWPフックです（ほとんどのメタボックスフレームワークではかなり標準的だと思います）。

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

CMB2に関連するフックを文書化するために＃2265を作成しました。

モックアップを追加するように促すデザインラベルを追加しました。

一般的に、表示されているコンテンツの一部ではないデータは、メインのエディター領域の一部であってはならないと感じています。 すべてがブロックであるわけではありません。

1）私のカスタムメタボックスの大部分はFieldmanager作られています。 私の目には、これらは「Just Work」であり、更新以外に追加の作業は必要ありません。 cc / @mboynesと@bcampeauは、この議論に価値を提供できる可能性があるためです。

2）カスタムメタボックスのいくつかは、jQueryとPHPを組み合わせたものです。 たとえば、「クリア」ボタンのあるラジオである「Oneornone」メタボックスがあります。 これが壊れると仮定すると、グーテンベルクでこれを作成する方法の例があり、コードが壊れる前にグーテンベルクを義務付けるバージョンのWordPressにアップグレードするのにかなりの時間がかかると思います。

3）選択が行われるまで公開ボタンを無効にするjQueryとPHPコードを組み合わせた別のメタボックスがあります。 私の2番目の例と同様に、これが壊れると仮定すると、グーテンベルクでこれを作成する方法の例があり、以前にグーテンベルクを義務付けているバージョンのWordPressにアップグレードするのにかなりの時間がかかると思いますコードが壊れます。

4）過去にカテゴリメタボックスを削除し、次のように置き換えました：1）ラジオ選択2）新しいカテゴリを追加する機能のないバージョン（これはばかげていました）。

5） post_submitbox_misc_actionsを使用して、独自のメタボックスにある必要のないオプションを公開メタボックスに追加しました。

私がかなりの時間を意味する限り、グーテンベルクAPIが凍結された時点から約2年と言えます。

その間、ここにいるすべての人に、投稿画面を拡張するためにメタボックスだけを使用しているわけではないことを思い出させたいと思います。 私たちの中には、次のフックを使用する人もいます。

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

@mikeschinkelがedit_form_[POSITION]フックについて言ったことを2番目にしたいと思います。 Piklistは、メタボックスやワークフローなどに多用します。

お時間をいただき、ありがとうございました。

グーテンベルクがエディターの置き換えなのか画面の置き換えなのかという質問は、下位互換性に関心のある人だけでなく、グーテンベルクを開発している人にとってもできるだけ早く答えることが重要です。 その質問への答えは、グーテンベルクがどのように機能し、コントロールがどこにあるかに関して毎日行われる決定の多くに影響を与えます。

最初のベータ版以来、画面の置き換えへの道はすでに順調に進んでいることは明らかですが、画面をオーバーホールするという決定は、メタボックスのサポートとフックの欠落の問題を引き起こした原因でもあります。 これらの問題に対する答えが「画面全体を交換しないでください」である場合、画面交換を想定してすでに多くの作業が行われているため、元に戻すのが難しいのではないかと心配しています。

まず、これに関する実際の進歩を見るのは素晴らしいことです。

1つの観察結果は、編集画面の拡張機能が単独で機能することはめったにないということです。 たとえば、ACFは、親の投稿選択ボックスのJS変更イベントに基づいて表示フィールドを変更します。

DOMはグーテンブルクのコンテキストでは異なり、Reactは外部のイベントリスナーにはあまり適していない可能性が高いため、このデータをメタボックスやその他のプラグインコードで引き続き利用できるようにするにはどうすればよいですか。 1つの可能性は、Reduxストアがメタボックスで利用できるようになっていることですが、これが可能か、望ましいか、または十分な柔軟性を提供するかどうかはわかりません。

これは、メタボックスがiframeに読み込まれたり、ページに追加されたりすると、さらに問題になります。

最初のベータ版以来、画面の置き換えへの道はすでに順調に進んでいることは明らかですが、画面をオーバーホールするという決定は、メタボックスのサポートとフックの欠落の問題を引き起こした原因でもあります。 これらの問題に対する答えが「画面全体を交換しないでください」である場合、画面交換を想定してすでに多くの作業が行われているため、元に戻すのが難しいのではないかと心配しています。

「画面」置換アプローチに向けてどれだけの作業が行われたかを完全に理解しています。 しかし、「ポストコンテンツエディター」の置き換えを目的として開始されたプロジェクトは、エディター画面全体を置き換えることを一方的に決定する前に、コミュニティに戻るべきではありませんでしたか？

行われた膨大な作業を却下するつもりはありませんが（エディターは本当に素晴らしく見えます）、WordPressが多すぎると、厳密には「コンテンツ」ではないメタフィールドに依存し、その多くは内部にまったく収まりません。同じグーテンベルクコンテナ（完全に強制されていない限り）。 私には、グーテンベルクの元の声明であった逆よりも「解決策があり、問題を作成する必要がある」ように思えます（投稿コンテンツエディターは非常に厄介で、ショートコードは使い勝手が悪いです-ショートケーキのようなアプローチにもかかわらず-など）。

7月4日の@brentjettモックアップは、コンテンツに収まらない「改良されたメタボックス」（「設定領域」）と、グーテンベルクブロックに簡単に変換できるメタボックス（イベント情報）の両方で機能するようです。

@rilwisプラグインでのメタボックスの広範な使用について、立ち寄って言及する必要があると思います。 ほとんどの製品で使用しているので、広範なフレームワークであることがわかります。 このグーテンベルク全体にどのように適合しますか？ —メタボックスを構築するためのプラグインを販売することをビジネスとしている人からの洞察（最も影響を受ける）は、ここで役立つはずです。

デザインのインスピレーションについては、無料および商用（スクリーンショット）のバックエンド管理テーマを確認できます。 または他のプラットフォーム。

ダッシュボードですが、グーテンベルクを想像してみてください。

おそらく、提案されたFields APIは、新しいエディターでのメタボックスのサポートに関する問題のいくつかを解決するでしょう。

考慮すべきシナリオは、WordPressがGutenbergで更新さ

これは、管理エクスペリエンスを損なう最大の脅威となる「最悪のシナリオ」ですが、有名なプレーヤーやカスタムの1回限りのソリューションなど、メタボックスプラグインを利用したサイトの数を考えると珍しいことではありません。

更新されるこれらのメタボックスプラグインに依存することは、大規模な重大な変更を認める意思がない限り、方程式の一部であってはなりません。 Fields APIは素晴らしいアイデアですが、カスタムフィールドの処理方法を将来改善することが、そのようなAPIが存在する前に記述されたコードに影響を与えると想定するべきではありません。

は明らかです：

• 大規模な下位互換性を壊すことはありません。
• 何らかの検出メカニズムを使用してエディターページを分割することはしません。
• 単一のエディターと編集経験があります。
• 上記の多くのユースケースでは、現在のグーテンベルクの実装では対応できません。

したがって：

今後の道は、新旧を取り入れた方法で投稿編集画面を再考することです。 これは、現在のグーテンベルクの実装を何らかの方法でバックトラックすることを意味する可能性が非常に高いです。 これは設計上の課題であり、世界の終わりではありません。

@dmccanいいえ、これまでに提案されたすべてのソリューションのように、これらのステートメントは「明確」ではありません。

• 管理エクスペリエンスを新旧に分割します。
• プラグインの更新に依存して、メタボックスをブロックします。
• 存在しないFieldsAPIに依存しています。
• 問題を完全に回避するには、新しいインターフェイスの登録を解除する必要があります。これにより、管理エクスペリエンスが再び分割されます。

最悪のシナリオがメロディアスであることを強調しませんでした。 問題に取り組むべき制約を定義するためにそれを行いました。

したがって、グーテンベルクは機能プラグインを長期間維持する必要があるようです。ユーザーは、好きな場合は選択するか、そうでない場合はオプトアウトするかを選択でき、コア付きのプラグインとして含めることもできます。

単一のエディターエクスペリエンスを実現するために解決する必要のあるすべての問題を解決するには、多くのカレンダー時間がかかります。 Microsoftの元のASP.NETと、それが一般的なWebの問題をどれほどひどく解決したかを見てください。 最終的にAJAXが登場し、残りは歴史です。

変更の強制が速すぎると、WordPressが真のレガシーのみのプラットフォームになる可能性があります。

PS「単一のエディター」の要件は非現実的なようです。 ユーザーが古いものまたは新しいものを使用するオプションを持っていた場合、古いものを使用するメリットがなくなるまで、新しいものを時間の経過とともに進化させることができます。 しかし、既存のフックを使用したインストールがある限り、_（私は信じています）_単一のエディターソリューションを使用することは無責任です。 #jmtcw

@ kevinwhoffman-同意すると思いますが、冗長ではなかったのかもしれません。

私の箇条書きは明確であり、最終的な解決策はそれらを受け入れると思います。 たとえば、現時点で解決策を探している人々が提案するかもしれないものにもかかわらず、WordPressが大規模に下位互換性を壊すとは思わない。

これまでに提案された解決策が欠けているので、新しいものと古いものの両方を受け入れるために現在のグーテンベルクの実装を再考する必要があるという私の結論が出てきます。そうすることが本当に前進する唯一の方法だと思います。

@ mikeschinkel- 2017年にGutenbergがCoreの唯一のエディターオプションになるとは思いません。ユーザーの選択として始まり、すべての重要な基盤をカバーするまで進化する可能性があります。それを正しくする時間。

いずれにせよ、私が提案しているのは、すべてを捨てて、すべての重要な機能をどのように処理するのか疑問に思うのではなく、現在のエディター画面のアップグレードされたバージョンにグーテンベルクを組み込むためのバックトラックです。 人々がそれに同意すれば、それは実行可能であり、おそらくそれほど大きなバックトラックではないと思います。 このようなコースはおそらくより速く、より良いエンドユーザーエクスペリエンスを提供します。

多分彼ら（コアコーダー）はマットと話すべきです。 彼はこれらすべてを始めました、そして、彼らは今答えを持っていません。

@dmccan非常に重要だと私が信じていることの1つは、実装されているものはすべて簡単な拡張性モデルを持っているということです。 WordPressは、プラグインアクションとフィルターフックを備えた簡単な拡張モデルで知られています。それがないと、Gutenbergは、拡張が非常に難しい現在のメディア管理システムと同じくらいWordPressに悪影響を及ぼします。

ちなみに、私はReactやVueを使用したことがありませんが_（私はPHP開発者です）_ビルドシステムを必要とするReactに関する議論と、ReactよりもVueの方がはるかに使いやすいと多くの人が感じたため、私は非常に不安になりました。 Gutenburgが拡張性モデルを簡単に習得して使用できるかどうか、そしてそれがクライアントプロジェクトにWordPressを引き続き使用できることを意味するかどうか。

私の懸念に注意するための私のフィードバックだけで、これに直接返信する必要はありません。

私はそれが何であるかを知っていると思います。
それは決してコンテンツエディタについてではなく、「書き込みフロー」、「古いものとの決別....後方」などについてではありませんでした...

それは、本格的なフロントエンドのビジュアルテーマエディタについてです。

みなさんにメールを送ってすみません。 この特定の問題についての私の最後のコメント。

@Rarst @kevinwhoffman ：グーテンベルクがエディターの代替品なのか画面の代替品なのかについて私は完全にあなたと一緒です。 それはよく考えられたポイントです。 そして、開発チームがスタート地点とグーテンベルクの性質（編集者）に戻って、他のすべてを現在のままにしておくことができることを願っています。 これらは2つの異なるパーツであり、相互に使用することも使用しないこともできます。 したがって、それらを別々のものとして保持することをお勧めします。

さらに、メタボックスプラグインから関連するフックを一覧表示するために＃2308を作成しました。

@ahmadawais言及してくれてありがとう。

それは価値が追加されるだろう@nylen投稿2件の投稿を検討するプラグインのリストに。 現在はサポートされていませんが、まだかなり広く使用されていると思います。

@nylenプラグインの開発者用カスタムフィールドを管理していますが、現在は積極的に開発されていません（最近はCMB2を使用しています）。 1000以上のアクティブなインストールのみですが、リストに追加する価値があるかもしれません。

グーテンベルク編集者がまさにそれ、コンテンツ編集部分であるというコメントに同意します。 なぜ、またはどのようにして完全な画面の置き換えになるのかわからない。 そこにある人気のあるページビルダーはすべてそれを正しく行います。TinyMCEを他のものに置き換えるだけで、コンテンツの作成が簡単になります。

また、メタボックスは通常、コンテンツの一部ではなく、コンテンツに関連している場合でも、通常はブロックとして意味がありません。

スタッフディレクトリを例にとってみましょう。 個人情報のフィールドをブロックにしたいのはなぜですか？ 名、姓などを入力することになっているときに、他のブロックを追加してほしくないのです...

tldr; Gutenbergは、コンテンツ構成が必要な投稿タイプのTinyMCEエディターのみを置き換える必要があります。

ここに私の2セントを追加するだけです。

今のままにしてみませんか？ 私が言いたいのはこれです。

• 現在のように投稿タイトルにカーソルを合わせるときは、2つの編集オプションを保持しますが、デフォルトでタイトルをクリックするとグーテンベルクに移動するように変更します。 次に、 Editリンクをグーテンベルクに移動させ、追加のリンクをクラス編集画面に移動させます。 たぶんそれをClassic Editようなものと呼んでください。
• 投稿タイプとページ投稿タイプに何らかのタイプのサポートフラグを追加して、開発者が必要に応じてグーテンベルクを無効にできるようにします。 グーテンベルクが有効になっていない場合は、タイトルリンクを「クラシック」編集ページに移動し、グーテンベルクへのEditリンクを削除すると、 Classic EditリンクのテキストがEdit変更されます。
• 次に、カスタム投稿タイプを使用すると、エディターや注目画像などのようにグーテンベルクがサポートされます。これにより、CPTはグーテンベルクをサポートする必要がなくなります。
• 次に、クラシック編集ページのスタイルを更新します。 グーテンベルクのスタイルに一致するようにメタボックスとサイドバーのスタイルを更新しました。 グーテンベルクのように、抜粋とコメントのメタボックスをサイドバーに移動することもできます。

これでみんなが幸せになると思います。 グーテンベルクは、投稿タイプとページ投稿タイプでデフォルトでオンになっています。 開発者がGutengergの代わりにメタボックスを使用する必要がある場合は、使用できます。 プラグインとテーマ開発者がグーテンベルクに変換する時間を与え、エンドユーザーがエディターの変更によってワークフローに干渉することなくグーテンベルクに適応できるようにします。

また、開発者はグーテンベルクを使用するというアイデアをエンドユーザーに販売し始めることができます。 人々は変化を好まない傾向があります。 彼らに新しいエディターに慣れさせることは、単なるハードな変更よりもはるかに良いでしょう。

これにより、2つが分離され、2つの異なる保存方法が可能になります。 グーテンベルクはJSを使用でき、クラシックはPHPを引き続き使用できます。

ユーザーがグーテンベルクで投稿を保存した後、クラシックで編集しようとした場合など、ある種の警告を追加して、投稿を保存すると、他のエディターからの投稿の以前の保存が上書きされることを知らせます。 どのエディタが最後に使用されたかを示す投稿メタのようなものがある可能性があります。

それはアイデアです。 それはばかげた考えかもしれませんが、それは多くの開発者が抱えているすべての懸念を軽減すると思います。

今日のグーテンベルクの範囲について多くの人が提起した点に完全に同意します。 このプロジェクトは、コンテンツエディタの（非常に必要な）改善として最初に開始されました。 このスレッドを読んでいると、存在する必要のない問題が発生しません。 グーテンベルクをエディターに追加するという当初の計画に固執する場合（全画面を置き換えるのではなく）、これにより、メタボックスだけでなく、非常に多くの問題が解決されます。

画面を完全に刷新することで、技術者以外のコンテンツ編集者にとって非常に多くの問題が発生するのではないかと心配しています。 平均的なブロガー/作者は、まったく異なる画面とパニックを目にするでしょう。 更新が単にエディターを対象としている場合、オンボーディングエクスペリエンスをはるかに制御できます。

これにアプローチする別の方法は、同じワークフローを使用することであるかもしれませんビーバービルダー。 つまり、通常の投稿編集ページ（通常のメタボックスセクションなどを含む）を維持すると、ボタンを使用してグーテンベルクを起動できます。 これにより、新しい画面に移動できます。 気晴らしのない書き込みモードをターゲットにすることについてのコメントとよく似ています。

また、既存のメタボックスUIを維持し、コンテンツエディターのみを変更することを提案する人々にも同意します。

私たちのほとんどは、プラットフォームを前進させる主な要因はイノベーションであることを認識していると思います。 WordPressが、他の誰もがしていることに匹敵する（そしてそれを超える）ことができるより豊かな体験のために、JSベースのアプローチにゆっくりと移行しようとしていることは明らかです。 正直なところ、メタボックスシステム全体と現在の編集画面のUIはやや時代遅れに感じるかもしれませんが、開発者としてはそれに慣れているため、それは私たちにとって第二の性質であり、そこでの学習曲線の量を考慮に入れていません。それにあります。

このスレッド全体を読むと、私にとって2つのことが明らかになります。

• コアチームが完全にjsベースの編集画面をプッシュしたいのは明らかです、そしてそれは大丈夫です
• おそらく、私たち全員が上記の点を受け入れることができれば、会話をレガシーサポートおよび移行戦略に向けて進めることができます

メタボックスのjsバージョンが最終的にどのように機能するかを理解するとすぐに（提案されたAPIはありますか？）、既存のテクノロジー（プラグイン、フィールドマネージャーなど）を作成するブリッジを作成する方法について考え始めることができます。この新しいアプローチで作業します。

APIに焦点を当てた議論がすでに行われている場合、誰かが私とそれが正しい方向でどこで起こっているのかわからない他の誰かを指すことができますか？ ありがとう！

エディターをタブ間を移動する2つの画面に分割しない理由はありますか？

私の見解では、グーテンベルクは、

• エディター画面を整理する試み
• ページビルダー/レイアウト機能をコアに追加する試み
• 開発者が新しいコンテンツブロックを簡単に作成できるようにすることで、メタボックスの必要性を最小限に抑える試み。

上で強調したように、そして私たちのほとんどの開発者とエンドユーザーが感じ、予見できる問題は、グーテンベルク、

• 作成者からエディタースタイルの形式の選択肢を削除します
• ブロックを追加するために多くのマウスクリックを必要とする直感的でないワークフローを使用するように作成者に強制します
• 多くの古いプラグインを壊します。その中には維持されているものとそうでないものがあります。
• WordPressをツイートプラットフォームのように感じられるものに変換します。

Guttenbergを使用してコンテンツを作成することは、MauticまたはMailChimpで電子メールテンプレートを設計するのと同じように厄介です。 GuttenbergのUIは、テンプレートのデザインには適していますが、長い形式の投稿の作成には適していません。

ストップスタートコンテンツ作成UIの導入ではなく、ワークフローの流動性の向上に集中する必要があります。

GuttenbergのUIは見栄えがしますが、現在のフォームに近い場所にあるときにエンドユーザーが満足することを期待するのは非現実的です。 コンテンツ作成の邪魔になります。

テキストブロックはほとんど役に立たない。 テキストウィジェットは、作成者が少数のフォント形式の使用のみに制限されるべきではありません。 これは多くの作者を悩ませます。

これが私の提案です：

• Tabify EditScreensをページエディタに導入します。
• メタボックスをエディター画面内の独自のページタブに移動します。
• メタボックスにはReactベースではないページを使用します（エディタータブの後ろに隠されたページ）
• デフォルトのTinyMCE（または同様の機能が豊富なエディター）ベースのキャンバスを使用します。これは、長い形式で適切に機能し、作成者がブロックを使用することを要求しません。
• TinyMCEまたはTinyMCEそっくりさんへのアドオンとしてGuttenbergブロックを導入します。
• TinyMCEベースのエディターにShortcakeを導入して、作成者がブロックのコンテンツを視覚的に確認できるようにし、作成者が各ブロックの編集ボタンをクリックすることなくページフローでコンテンツを直接編集できるようにします。
• add_shortcode（）をブロック作成に結び付けることにより、開発者が新しいブロックをGuttenbergに簡単に追加できるようにします（例：add_shortcode（ 'tag'、 'function'、 'guttenberg true / false'））。 add_shortcodeを適応させて、ショートコードを自動的にGuttenbergと互換性のあるものにします。 これにより、開発者はメタボックスの一部/多くをGuttenberg内で機能するショートコードに簡単に変換できます。

私が本当に言っているのは、グッテンベルクは3つのタスクに分割する必要があるということです。

• エディタ画面のクリーンアップ
• 改善されたエディターUI
• 改善されたエディター拡張フレームワーク。

ほとんどの人はWordPressを使用して長い形式のコンテンツを作成しており、ブロックを使用してコンテンツを作成することを強制されたくないと思います。 ブロックはページレイアウトの作成には最適ですが、投稿が書き込まれるたびに使用すると煩わしくなります。

私には80代の顧客がいます。 彼女はただコンテンツを作りたいだけです。 彼女は、エディター画面の使用方法を再学習することを余儀なくされたくありません。 彼女がVisualComposerに慣れるまでに、1年以上かかりました。これは、使いやすいページビルダーです。

私は元のスレッドのトピックから逸​​脱しましたが、これは言う必要があります：GuttenbergはWordPressを殺します。

Guttenbergが現在の形式で導入された場合、WordPressはフォークされ、Guttenbergバージョンは停止します。

ブログサイトにWordPressを使用してPHPテーマを作成する場合、新しいエディターの方が理にかなっているかもしれませんが、最近では、React、PODS / ACF、およびWordPress RESTAPIを使用してWebアプリケーションを構築するためのCMSとしてWordPressを使用する人がたくさんいます。 したがって、CPT間の高度なリンクのためにメタボックスとリレーションシップフィールドをサポートする必要があります。

まず、グーテンベルクは素晴らしいものになると思います。

そうは言っても、ウェブサイトや機能を壊すことは信頼を壊すことに同意できると思いますが、それはクールではありません。 私たちは皆、お互いを信頼できることを望んでおり、クライアント/顧客は私たちを信頼したいと思っています。

私たちにできる最善のことは、開発者が「レガシー」エディター画面に戻るために使用できるフィルターを含めることだと思います。

このようにして、独自のロジックを適用して、グーテンベルクの準備ができているかどうかを判断できます。 グーテンベルクで完全に壊れそうなメタボックスをユーザーが使用している場合は、レガシーモードに戻すことを選択できます。

次に、「レガシー」メタボックスに依存する古い投稿を正常に機能させながら、自分のペースでメタボックスやアイデアをグーテンベルクに合わせて移行できます。

レガシーメタボックスが登録されている場所（コンテキスト）でレンダリングできず、現在のように機能し続けることができないのはなぜですか？

したがって、最初に（オプションの）Gutenbergエディターセクションをレンダリングし、次に登録済み（レガシー）の通常/詳細コンテキストメタボックス（登録済みのタイトル付き）、次に新しい[投稿設定]列のあるサイドバーをレンダリングし、その下に登録済み（レガシー）側をレンダリングしますコンテキストメタボックス（登録されたタイトル付き）。

もちろん、従来のメタボックスは、新しい投稿設定ボックスと同じようにスタイル設定され、すべてがうまく統合されているように見えます。

たぶん、add_meta_boxが呼び出されたときなど、必要なときにロードされるlegacy-meta-box.phpスクリプトが必要になるでしょう。

現在のメタボックスソリューションを「レガシー」としか考えておらず、そもそもそれらを使用する理由を考えずに古いエディターを使用するように要求し、新しいエディターでその機能を提供するためのより良い方法に取り組んでいる場合現在のサイトはレガシーのままであり、アップグレードすることはありません。 これは、クライアントサイトを管理するユーザーにとって大きな問題になります。

ほとんどすべてのプロジェクトでACFフィールドを使用する理由は、データがWebサイトに一貫して表示されるようにデータを制御するためです。 現在取り組んでいる2つの例を次に示します。 大規模なイベントサイトと、アーティストにリンクする必要があるが個別に表示される作品/インスタレーションのあるフェスティバル。 どちらの場合も「コンテンツ」であり、グーテンベルクが置き換えている部分は、編集画面のコンテンツの約10％にすぎず、実際には最も重要性の低い部分です。 イベントサイトの場合、重要なデータはイベントタイプ、イベントカテゴリ、日付、時刻、場所、主催者などです。エディタにコンテンツをまったく入力せずに、意味のあるイベントエントリを公開できます。 フェスティバルサイトでは、アーティストを選択して作品にリンクし、フェスティバルサイトで作品の場所を選択し、注目の画像をアップロードできる必要があります。この場合も、コンテンツは必須ではありません。 これらのサイトのすべての「通常の」ページコンテンツについて、グーテンベルクは十分な柔軟性がありません（また、デフォルトではそうではないと思います）。より完全な機能を備えたページビルダー（ビーバービルダー）を引き続き使用します。デザインオプション。

これらすべてのもう1つの重要な要素は、編集画面でのコンテンツの順序です。 イベントの場合、タイトルを設定する必要がありますが、理想的な編集フローでは、「エディター」に「コンテンツ」を入力する前に、日付、時刻などの重要な情報を入力する必要があります。 「コンテンツ」の前後で、編集ページのどこにコンテンツがあるかを制御する機能が必要です。

すべての「レガシー」メタボックスを含む別のタブを作成するというアイデアは恐ろしいものです。 これは、CPTの多くの用途で編集フローを完全に中断し、ユーザーが見つけにくいと思う方法でコンテンツをユーザーから隠します。

プロジェクトはそれについてはるかに賢くする必要があります。 （ある種のページテンプレートで）どのビットがどのタブにあるかを選択できれば、タブ付きプロセスはうまく機能する可能性があります。 また、ユーザーが各タブをステップスルーするためのメカニズムも必要です。 ただし、CPTアイテムが短い場合は、エディターコンテンツの上に特定の重要な要素（必要に応じてブロック）を使用して、すべてを1ページに保持する機能が必要だと思います。

全体として、人々が話しているほとんどのソリューションには、現在の編集画面の柔軟性がまったくないようです。

そのため、5.0のタイムラインが怖いので、時間内に素晴らしいと思いますが、急いで断片化すると、開発者とクライアントの両方の善意がすべて破壊されます。 WordPressは、その柔軟性、下位互換性、および一般的な使いやすさで取引されています。 新しい光沢のあるおもちゃのためにそれを犠牲にすることはできません。 WordPressのPHP要件を見てください。PHP5.6または7が要件になる何年も前に、文字通り話し合っています。 コミュニティは、その長い時間枠がどれほど苛立たしいものであっても、ウェブサイトを壊さないことが必要であることを認識しています。 これはまったく同じ種類の問題ではありませんか？

このような変更は、最終的にはプラットフォームに最適ですが、よく考えて管理する必要があります。そうしないと、WordPressの基盤そのものが危険にさらされます。

@ avocadesign-いくつかの良い点。 今後、JavaScriptメタボックスを登録できるようになりますが、現在の考えでは2つの場所があるようですが、これはおっしゃったほど柔軟ではありません。

@ avocadesign-よく説明されています。 post_contentは常に投稿の焦点であるとは限らず、「イベントとアーティスト」が良い例です。 これらの投稿タイプのバックエンドとフロントエンドを示すスクリーンショットをいくつか見て、開発者がWPがCMSとしてどのように使用されているか、および一般的なクライアントが投稿編集画面でどのように機能するかを視覚化できるようにすると便利です。

@avocadesign

現在のメタボックスソリューションを「レガシー」としか考えておらず、古いエディターを使用する必要がある場合

私が提案したこと（コメントの上）では、「レガシー」メタボックスはグーテンベルクエディターの下（投稿タイプに必要な場合）または投稿設定ブロックの下（登録されているコンテキストに応じて）に配置されます。 古いエディターを維持する必要はありません。

タブ付きのインターフェイスが機能しないことに同意します。 私の提案についてどう思いますか。 私が見ているように、それはあなたが慣れているすべての柔軟性をあなたに与え、準備ができたら新しいシステムに移行することを可能にするでしょう。

グーテンベルクがコアの一部になると、言及したサンプルに対してさらに優れたUIを構築できるようになります。 これは、カスタムのフェスティバルブロック（WYSIWYGフォームの一種）と、1つ以上の（JSベースの）投稿設定セクションの関連設定で部分的に構成されます。 ユーザーは、直接フィードバックを備えたより高速なインターフェースの恩恵を受けるでしょう。

WordPressは、その柔軟性、下位互換性、および一般的な使いやすさで取引されています。 新しい光沢のあるおもちゃのためにそれを犠牲にすることはできません。

同意しません。 グーテンベルクにもう少し信用を与えるべきだと思います。 彼らは皆のために働く解決策に一生懸命取り組んでいます。 彼らは（あなたが言及したのと同じように）ユースケースを聞いて探しています。まだ何も決まっておらず、グーテンベルクのリリースもその一部ではないかもしれません。
グーテンベルクが現在議論されているすべての問題に対処していない場合は、5.0リリースの一部ではないと信じることができます。 私たちは過去に他の機能でも何度もそれが起こるのを見てきました。

これは、ホテルのプロパティを管理するクライアント用にAdvanced CustomFieldsを使用して構築したインターフェイスの例です。

• プロパティカスタム投稿タイプは、10個のタブにわたって18個のカスタムフィールドを使用します。
• タブはすべての関連情報を1つの画面に保持し、ボタンをクリックするだけでエディターがアクセスできます。
• フィールドタイプには、ACFギャラリーと関係フィールドに加えて、単純なテキストフィールドと数値フィールドが含まれます。
• editorサポートは、カスタム投稿タイプ登録で宣言されていません。つまり、UI全体がカスタムメタボックスに依存しています。

このタイプのUIは、一連のカスタムフィールドが、投稿の整理に使用されるページ上のコンテンツと「非表示」のメタデータの組み合わせを保持する多くのカスタムWordPressサイトを表しています。

コミュニティは、グーテンベルクが導入された後、このタイプのインターフェースがどうなるかを知る必要があります。 @ elliotcondonに、

@kevinwhoffman

グーテンベルクが導入されると、コミュニティはこのタイプのインターフェースがどうなるかを知る必要があります

あなたは正しいですが、この問題＃952の目標は、代替案について話し合い、提案することによって、その答えを_見つける_ことです。 何がうまくいかないのか。 将来のある時点で、私たち全員がすべてのレガシーおよび将来のケースで機能する何かに到達したと誰もが考えるとき、それは実装でき、（ユーザー）コミュニティはそれがどのように機能するかを説明できます。 現在、私見の質問に対するチームからの回答を期待するのは時期尚早です。

あなたが提供するユースケースと@avocadesignが提供する思います。

あなたの例に関して、私の提案（上記のいくつかの反応を参照）は、スクリーンショットに示されているようにすべてのボックスを表示するだけです（もちろん新しいグーテンベルクスタイルを使用）。

@kevinwhoffman

グーテンベルクは、CPTが現在のエディターのサポートを宣言していないのと同じように、CPTをオプトインする可能性が最も高いでしょう。 WordPressのほとんどのものは非常に柔軟であるため、CPTをオプトインしない理由がわかりません。グーテンベルクも例外ではありません。 現在、投稿に対してのみ機能します。

グーテンベルクがこのようなインターフェースのために何かを変えることはまったくないだろうし、そうするつもりもない。 そうは言っても、グーテンベルクが提供するものを探求し、それを使用してクライアントにとってより魅力的な編集体験を作成できるかどうかを確認することは興味深いかもしれません。

たとえば、プロパティ/プロパティブロックを作成して、クライアントがプロパティ情報を他の投稿などにすばやく簡単に埋め込むことができるようにすることができます。 次に、グーテンベルクで編集しているときに、グーテンベルク内に表示されているプロパティ情報を見ながら、ACFに表示されるのと同じ情報を変更できます。 グーテンベルクはWordPressの管理インターフェースを追い抜いておらず、エディターの機能を置き換えており、ブロックベースのコンテンツテンプレートにつながる可能性があります。

頭痛ではなく、グーテンベルクから良いことが起こっています！

これは、post_contentの上にACFフィールドがあり、post_contentの下にイベントカレンダーの標準メタボックスがある、上記のサイトのイベント編集画面です。

このサイトは多くの非技術ユーザーに公開されます。私たちは訓練を受けた編集チームについて話しているのではなく、サイトで提供するヘルプ以外にWordPressを使用したことがない、または訓練を受けたことのないJoe平均について話します。

ユーザーがイベントの種類、カテゴリ、ヘッダー、各イベントの注目の画像を見つけて入力できるように、このように設定しました。 また、既存のメタボックスの位置を使用して、画面上に関連するヘルプドキュメントを提供し、イベントの編集を支援し、邪魔にならない方法で新しいユーザーにサポートを提供することもできます。

また、私たちは管理者としてログインしていることを覚えておいてください。管理者以外のユーザーは、視覚的な混乱をさらに減らすために、さまざまなサイドバーのメタボックスを非表示にしています。

「コンテンツ」は、イベントに正常に参加するためのさまざまなメタボックスほど関連性がありません。 日付が正しく入力されていないか、カテゴリが選択されていない場合、イベントはサイトに表示されません。 この議論全体について私が心配しているのは、問題＃1352のように、メタボックスが折りたたみ可能なセクションで画面の下部に追いやられているモックアップです。 私たちの経験から、訓練を受けていないユーザーにはメタボックスが表示されず、日付と場所をプレーンテキストとしてコンテンツ領域に直接入力し、イベントがシステムに表示されないと文句を言うだけであることが保証されます。 構造化された情報を必要とする投稿タイプのトレーニングを受けていないユーザーにとっては、十分に発見できません。

また、このインターフェイスには必須フィールドがあり、メタボックスが折りたたまれている場合、ユーザーは警告を受け取りますが、問題の原因を簡単に見つけることはできません。

メタボックスまたはそのタイプの機能の次のイテレーションは第一級市民である必要があり、クライアントが使用できるインターフェイスを作成するには、メタボックスをコンテンツの上、コンテンツの横、またはコンテンツの下に配置する機能が必要です。

グーテンベルクは、CPTが現在のエディターのサポートを宣言していないのと同じように、CPTをオプトインする可能性が最も高いでしょう。

グーテンベルクのサポートをCPTに登録することは確認されておらず、正直なところ、メタボックスの問題を解決するのではなく回避するように感じています。 既存のサイトがグーテンベルクにアクセスする唯一の方法がコードでそのサポートを登録することである場合、それは潜在的な聴衆を厳しく制限するでしょう。

また、カスタムメタボックスがカスタム投稿タイプでのみ使用されていると偽ってはなりません。 それらは通常の投稿やページに存在する可能性があります。

グーテンベルクはWordPressの管理インターフェースを追い越しているのではなく、エディターの機能を置き換えています...

これは不正確です。 今日存在するように、グーテンベルクは編集後の画面のフルスクリーンの代替品です。

@ BE-Webdesign＆@ kevinwhoffman

また、なぜCPTは、現在の編集画面よりも明らかに優れているグーテンベルクの側面を見逃さなければならないのでしょうか。

コンテンツと混同されないように公開コントロールが一番上に移動され、全体的な美学がよりクリーンになることは、このプロジェクトが向かっていることの確かな強みです。

（メタボックスを介して）複雑なニーズを持つCPTに現在あるものと同等の機能を作成する方法について適切な計画を立てていないため、ユーザーベースの大部分を無視し、最終的にはサポートされていないエクスペリエンスを2番目のクラスに委ねています。

ただひどい私見。

私は、メタボックスが現在存在しているので、箱から出してすぐに機能する必要があるとさえ主張していません。 この種のインターフェースの柔軟性を実装するための新しくてより良い方法があるかもしれません。

私が懸念しているのは、開発チームがここで「post_content」の最初のアプローチを実施することで、多くの開発者の問題を実際に把握していないように見えることです。 構造化されたデータ出力が必要なCPTを除いて、すべてのサイトでBeaverBuilderを使用しています。 グーテンベルクが何であるかであるページ構築ツールは、個々のコンテンツのニーズを持つ投稿やページに最適です。 構造化データにとってはひどいものです。 構造化データの場合、インターフェイスの一貫性、必須フィールド、およびその他のレイアウトの優先順位は、毎回自由形式のコンテンツよりも優先されます。

@kevinwhoffman

また、カスタムメタボックスがカスタム投稿タイプでのみ使用されていると偽ってはなりません。 それらは通常の投稿やページに存在する可能性があります。 これは不正確です。 今日存在するように、グーテンベルクは編集後の画面のフルスクリーンの代替品です。

はい、しかしそれは私が言及していた管理インターフェース全体を置き換えるものではありません。 不完全なプロジェクトを現在の経験と比較しています。 ＃2251が完了すると、全能のメタボックスが再び導入されるので、それほど違いはなく、はるかに優れています。 特定のプラグイン作成者が微調整しなければならないことがいくつかあるかもしれませんが、ほとんどの場合、物事はスムーズに進むと確信しています。

@avocadesign

また、なぜCPTは、現在の編集画面よりも明らかに優れているグーテンベルクの側面を見逃さなければならないのでしょうか。

誰も彼らが私の知る限りだとは言いませんでしたか？ CPTのエディターサポートを追加することと、ブロックエディターのサポートを追加することの間に大きな違いはありません。

（メタボックスを介して）複雑なニーズを持つCPTに現在あるものと同等の機能を作成する方法について適切な計画を立てていないため、ユーザーベースの大部分を無視し、最終的にはサポートされていないエクスペリエンスを2番目のクラスに委ねています。

まともな計画があると思いますが、はっきりしないかもしれませんが、グーテンベルクは、すべてのことを言い終えれば、すべてのタイプのユーザーの大多数のニーズを満たし、それを超えることさえできると確信しています。

誰も彼らが私の知る限りだとは言いませんでしたか？ CPTのエディターサポートを追加することと、ブロックエディターのサポートを追加することの間に大きな違いはありません。

グーテンベルクをCPTにオプトインさせるというこのスレッドで多くの人が話しているステップにより、現在の複雑なユースケースの多くが短中期的にグーテンベルクで無視され、イベントなどのユースケースが効果的に強制されるのではないかと心配しています。グーテンベルクは十分な柔軟性がないため、既存のシステムを使用するために上に示したもの。 これにより、現在の複雑なユースケースは、プロジェクトの他の利点を見逃すことになります。

「心配しないで、大丈夫だ」とよく言われますが、私たちの中には計画がまったく明確に提示されていないことを示唆するとき、あなたは正しい@ BE-Webdesignです、私はただ見ることができませんこれが短期的に満足のいくように解決されるすべての方法-それなら、私を啓発するために議論や問題を自由に指摘してください。

編集：
私が「短期的」とは、5.0を一般に公開することを意味します。ここでは、2018年初頭が目標のようです。 2、3年後の長期的には、これがはるかにうまく解決されていることがわかります。

@ BennyVL ＆ @ dmccan柔軟性はここでの重要な問題です。 私が間違っている場合は訂正してください。しかし、これに取り組んでいる開発者によって提案されているものはどれも、現在の柔軟性ほど柔軟ではありません。

ACFやその他のプラグインを使用すると、コンテンツの上（タイトルの下）、コンテンツの下、サイドバーにメタボックスを簡単に登録できます。 インターフェイスのデザインは私次第です。 編集者が最初であることを強制するものではなく、編集者が存在することさえ義務付けていません。 新しいメタボックスを登録したり、登録を解除したり、他のメタボックスを移動したりできます。

私が望んでいるのは、長期的にこの柔軟性を維持するソリューションです。 メタボックスを光沢のある新しいJS形式に更新する必要があるか、適切なブロックになる必要があるか、またはこれを可能にするために他の変更を行う必要があるかどうかは、実際には気になりません。 グーテンベルクに到達するために使用された方法に関係なく、現在私たちが楽しんでいる柔軟性がグーテンベルクに含まれることを望んでいます。

私が望んでいるのは、長期的にこの柔軟性を維持するソリューションです。 メタボックスを光沢のある新しいJS形式に更新する必要があるか、適切なブロックになる必要があるか、またはこれを可能にするために他の変更を行う必要があるかどうかは、実際には気になりません。 グーテンベルクに到達するために使用された方法に関係なく、現在私たちが楽しんでいる柔軟性がグーテンベルクに含まれることを望んでいます。

それが目標であり、ほとんどの人が望んでいることです。

私はメタボックスの問題とこの新しいエディターで彼らに何が起こるかについてたくさんのおしゃべりを聞いてきました。 私の個人的な見解では、グーテンベルクはページ編集画面全体ではなく、エディターだけに焦点を当てるべきだということです。 しかし、すでに決定が下されているようです。

こんにちは、みんな、

私はCarbonFieldsの主任開発者であり、影響を受ける可能性のある使用するアクション/フィルターのリストを追加したいと考えています。

フィルタ：

• postbox_classes_{$page}_{$id}

行動：

• 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 （砂糖の配置-重要ではありません）

私の質問：

• 従来のメタボックスを保持する場合、データの変更とどのように相互作用しますか？
• どのタイプのイベント（jQuery？エミッターのいくつかの公開された実装？）と、新しいエディターから正確にどのようなイベントを期待できますか（たとえば、送信の成功、失敗など）？
• これらのイベントは、レガシーメタボックスで利用できますか、それともReact実装でのみ利用できますか？

PS：
グーテンベルクチームのすべての努力と努力に感謝したいと思います。WordPressが最新のツールとソリューションに移行していることに興奮しています（旅が怖いように見えても）。

メタボックスをサポートすることは非常に重要です...

...何千ものワードプレス開発者とユーザーのために。

WordPressは大きなプラグインプレーヤーを無視することはできません...

... Advacend Custom Fields Pro（https://github.com/elliotcondon/acf/issues/622）、WooCommerce、YoastSEOなど。

私は、カスタムタイプ、フィールド、分類法を多用するツールセットプロジェクトを担当しています。

プラグインをグーテンベルクと互換性のあるものにしたいと考えています。

これは私が理解していることです：

• Gutenbergを使用する場合は、新しいAPIを使用して、ページと投稿にカスタムフィールドと分類法を表示する必要があります。
• Gutenberg for CPTは、Gutenbergではなく通常のWordPressエディターを使用するため、何もする必要はありません。

これは正しいです？ もしそうなら、グーテンベルクでカスタムボックスを表示するためのAPIのドキュメントを参照してください。

ドキュメントはまだ進化していると思います。 https://github.com/WordPress/gutenberg/tree/master/docsにいくつかのドキュメントがあります-http //gutenberg-devdoc.surge.sh/

@ BE-Webdesignや他の人たちが、混乱を最小限に抑える意図について言っていることを聞いています-ありがとう、それは安心です-しかし、私の5pの価値を追加したかっただけです（わかりました、わかりました、私の通常の105pの価値）。

しばらくの間開発を続けている人なら誰でも、特注のデータベース用のWebインターフェースを手動で作成することの苦痛を覚えているでしょう-退屈で、時間がかかり、エラーが発生しやすく、開発者の時間の点で非常に高価です。

WordPressとAdvancedCustom Fields（Pro）は、魅力的なフロントエンド、厳密なデータ入力チェック、直感的で一貫性のあるユーザーインターフェイスなどを備えた、特注のデータベース駆動型Webサイト（およびイントラネットデータ管理ツール）を効率的に作成するための優れたツールです。膨大な量のリレーショナルデータに対してスケーラブルである必要がありますが、多くの場合、スケーラブルである必要はありません。 これらは、クライアントにとって費用効果の高い方法で作成できる単純なシステムです。 これが、WordPressを単なるブログプラットフォームではなく、本当に便利なCMS（そして事実上軽量のRDBMS）にしている理由です。

私（および他の多くの人）の中小企業は、WP + ACF（または同様のカスタムデータプラグイン）を使用して、大きなIT予算を持たないクライアント組織や個人向けに特注のサイトやシステムを作成しています。 グーテンベルクの導入が、既存の編集/データ入力フロー、メタボックスなどのサポートを十分に考慮せずに行われた場合、2つの「非技術的」ですが、それでも重大な問題があります。

1 /エンドユーザーは再トレーニングが必要になります（技術者として、技術者以外のユーザーがインターフェイスの変更によってどれほど混乱する可能性があるかを忘れるのは簡単です-整理に多くの時間を費やしていたため、Clarify PasswordResetプラグインを作成しました4.3で導入された新しいパスワードリセットプロセスに完全に悩まされていたユーザー。

2 /別のメタボックスアプローチ用に独自のプラグインをアップグレードするだけでなく、すべてのクライアントサイトを専門的なレベルの注意を払ってアップグレードおよびテストし、すべてのサードパーティプラグインが自分のものであることを確認する必要があります。を使用して、コードベースを正しく更新することもできました。 （これは、サードパーティのプラグインが5.0リリースの前または（さらに悪いことに）いつか更新される速度を制御できない状況であるため、ワークロードの計画が非常に困難になります。）

上記のいずれの場合も、その追加作業に対してクライアントに追加料金を請求するのは正しいとは思いません。 結局のところ、私は彼らのサイトとシステムを構築するためのプラットフォームを選択しました、そしてそれは彼らが変更や改善を要求したようではありません。 たぶん私はその面で「良すぎる」または素朴ですが、人々が上で述べたように、それは信頼の問題です。 私たちは、WordPressが下位互換性を壊して私たちをうんちに落とさないことを信頼しているので、クライアントは予期しない追加料金で彼らを刺さないことを信頼できます。 最終的な結果として、私は突然、大量の追加の無給の仕事を何とかして収まるようになりました-アップグレードによってサイトがすぐに積極的に破壊された場合は、おそらく緊急に-浮かんでいるのに十分な有給の仕事を続けています。

私はWordPressを使うのが本当に好きで、ロープを学び、自分の便利なプロジェクトフレームワークを開発するなど、WordPressベースの開発プロジェクトを通じて生計を立てる（そして家族を養う）までに多くの時間を費やしてきました。 私はOSSやコミュニティベースの開発などを大切にしているので、時間をかけてWordPress.comに開発した便利な小さなプラグインを正式にリリースすることで、何かを還元しようとしました。これは主に問題を解決するための嘆願だと思います。この号のスレッドで可能な限り心に留めておいてください。 そうでなければ、コードベースがフォークされる可能性があるという本当の危険があることに同意します。 WordPressのファンでありプラグインの貢献者である私は、これは本当に悪い結果だと思います。 ただし、生計を立てるためにWPに依存しているソロ開発者として、経済的な必要性から、フォークされた（つまり、適切に下位互換性のある）バージョンを使用する必要があるかもしれません。 これを起こさせないでください！

@konamacはいくつかの素晴らしい点を指摘しており、そのいくつかは別のスレッドで投稿しています。

これに便乗するために、メタボックスの将来について安心できる答えを私たちに与えないことはまったく受け入れられません。

1. 既存のメタボックスの将来のサポートに対する直接的な答えはありません。 これは、開発機関やテーマ/プラグインの作成者に対する非常に苛立たしくて手間のかかる動きです。 「グーテンベルクはオープンソースなので、自分で理解してください」は無責任です。

2. グーテンベルクは素晴らしいです。 私はインターフェースとビジュアルデザインが大好きで、これがコンテンツの編集という点で将来の道だと思います。 しかし、4.9または5.0リリースで検討するために必要な場所よりもはるかに遅れています。

3. レガシーでできるはずのことはすべて、グーテンベルクでできるはずのことです。

4. 画面オプション
5. メタボックス（ACF、Yoastなど）
6. パーマリンク？！ これが1.0で編集できない理由を理解し始めることすらできません
7. クラシックコンテンツブロックがローカルホスト環境で正しく読み込まれない
8. さまざまなスタイルのブロックを作成するには、ドキュメントが重要である必要があります。 いくつかの例、いくつかのユースケースを挙げてください。 すべてのテーマ開発者がバックエンドであるとは限らないので、想定しないでください。 クリスタルクリアであること
9. ブロック設定には作業が必要です。 ブロックごとにどの設定が利用可能かを判断するのは非常に困難です。 ランダムのようです。 ブロック設定を編集する必要があるのはいつですか？編集しないのはいつですか？
10. グーテンベルクのテキストエディタの周りのコメントタグ全体は...見るのが悲しいです。

私たちの何人かは、このプロセスに非常に不満を感じています。 それは完全に単純な答えでなければなりません。

グーテンベルクはメタボックス/ ACFの現在の使用を保護しますか？また、そのようなサポートを無期限に保証する計画はありますか？

現在、ソリューションが何であるかを知る必要はありません。あなたがそれを理解していることはわかっています。 しかし、これについてはまだ明確な答えがありません。 特にACFは、更新の課金に同意しない古いクライアントを常にサポートする必要があるのとまったく同じように機能する必要があります。特に、ある時点でレガシーエディターの削除について話し合う場合は、どうすればその会話を今すぐ始めることができますか？！ ）

グーテンベルクが大好きです。 しかし、私は合唱団に参加する必要があります-これはばかげています。 プロジェクトチームがこの期待を伝える方法は単純ではありませんでした。 はいまたはいいえは私たちが探しているすべてです。

@ BE-Webdesign

完了すると、全能のメタボックスが再び導入されます

したがって、この問題に関する投稿全体を書くことをお勧めします。実際には、メタボックスは現在のようにそのままにしておくことを示しています。 これにより、コミュニティ内でビジネスを心配している多くの心配している開発者を防ぐことができます。

さらに、チームがこれを優先してこれらを今すぐ追加することをお勧めします。 これは私が確信しているプロジェクトの周りの多くの否定性を防ぐでしょう。

＃2308で述べたように、カスタムフィールドを作成/保存するときにMetaBoxプラグインが使用するフックをコピーしました。

• スクリプト、スタイルはadmin_enqueue_scriptsを使用してキューに入れられます。 現在の画面を（ get_current_screenを介して）チェックして、スクリプトとスタイルがそのページに対してのみキューに入れられていることを確認します。 コアプラグインの場合、投稿タイプごとにチェックします。 拡張機能（用語メタ、ユーザーメタ、設定ページ）の場合、分類法、ユーザープロファイルページ、または設定ページをさらにチェックします。
• また、 print_media_templatesを使用してアンダースコアテンプレートを印刷します。
• プラグインで使用するスクリプトには、カラーピッカー、アンダースコア、バックボーン、メディアスクリプト、tinymce（エディターフィールド用）が含まれます。
• initを使用して、プラグインのすべてのフックを初期化します。
• メタボックスはadd_meta_boxesフックを使用して登録されます。
• 非表示のメタボックスはdefault_hidden_meta_boxesます。
• また、ファイルのアップロードを許可するためにpost_edit_form_tagにフックします。
• save_post_{$post_type}とedit_attachment 、 add_attachmentを使用して、投稿と添付ファイルのメタ値を保存します。

グーテンベルクの上/下/サイドバーにメタボックスを表示するフックを構築することの何が問題になっていますか？

サードパーティの開発者が最も得意とすることを実行し、別の大規模なレンチを作業に投入することもできます。

Mattiasは、メタボックスはpost_metaに格納するブロックとして再考できると語っています。 それがマージの目標である場合、解決すべきいくつかの問題があります。

多くのメタボックスthe_editor($custom_id); 、これがグーテンベルクのコンテキストでサポートされるために

それから生じるのは、post_contentに格納されていないブロックに関するネストの技術的な懸念です。 Mattiasは、ブロックはpostmetaに保存できると言いますが、ブロックが保存場所を定義できる場合、親ブロックがpostmetaに保存され、ユーザーが別のpost_metaに保存する子を追加すると、ネストはどのように機能しますか... （または、病理学的なケースでは、Thaがpostmetaに格納するネストされたブロックには、同じpostmetaフィールドに格納するブロックが含まれます。

これは、3番目のメタボックスの懸念につながります。 グーテンベルクがthe_editor()代わりではなく、完全な編集ページの置き換えである場合、他のページや、メタボックスやthe_editor()を使用するカスタム管理パネルなどの他のコンテキストでブロックをキューに入れて使用するにはどうすればよいでしょうか。

ユーザーにグーテンベルクのオプションが与えられ、それが主張されているように彼らにとって革命的である場合、これらのインスタンスでその新しいインターフェースを提供できないことは、政府機関にとって悲惨なことになる可能性があります。

既存のメタボックスの将来のサポートに対する直接的な答えはありません。

メタボックスを説明するつもりだと繰り返し言いました。 唯一の不確実性は、技術的に実行可能なものと、それが新しいUIでどのように表示されるかです。

ショートコード、カスタムフィールドなど、何も壊そうとはしていませんが、すべて機能するはずです。 それらと対話するためのUIは変更される可能性があり（Gutenbergを完全に無効にしない限り）、メタボックスの特定のユースケースは今後のブロックにより適したものになるでしょう。

グーテンベルクは素晴らしいです。 私はインターフェースとビジュアルデザインが大好きで、これがコンテンツの編集という点で将来の道だと思います。

聞いてうれしいです！

パーマリンク？！ これが1.0で編集できない理由を理解し始めることすらできません

RESTAPIはまだこれをサポートしていないためです。 どんな助けでも大歓迎です： https ：

メタボックスを説明するつもりだと繰り返し言いました。

@mtiasメタボックスのサポートに関する混乱は、既存の機能を復元するためにレガシープラグインが利用可能になることを示唆している@mに起因すると思います。 既存のインターフェースのどの側面（メタボックス、メタボックスの位置、フックなど）が引き続きグーテンベルクで機能するのか、どの側面でレガシープラグインが機能し続ける必要があるのか​​を明確にすることは役に立ちます。

メタボックスを説明するつもりだと繰り返し言いました。

@mtias申し訳ありませんが、他の場所での説明を見逃したに違いありません。 聞いてうれしい！ 現在のイテレーションを視覚的により魅力的で目的のあるものにしてください。そうすれば大成功になります。

REST APIサポートについてあなたが言っていることを理解しました、私は更新のためにスレッドを監視します。

明確にしていただきありがとうございます。 この洞察を得た今、私はグーテンベルクに向けて全速力で前進しています-私の恐れはすべて脇に置かれています。

@kevinwhoffmanそうですね、問題の核心は「既存の機能」にもプレゼンテーションが含まれていることだと思います。グーテンベルクはUIを大幅に変更するため、以前のUIに戻すには、プラグインを無効にする必要があります。 メタボックスが新しいUIにどのように適合するか、および開発者の介入なしに古いメタボックスをどのようにサポートできるかが取り組んでいます。 それがどのように機能するか正確にはわからないので、具体的な結果を約束することはできませんでした。 また、これにより、メタボックス機能がより明確に表示される可能性があると思います。

@brograhamer謝罪は必要ありません、それは大きなスレッドです！ 私たちは何も急いでやりたくありません、そしてこれは多くの可動部分があるかなり大きなプロジェクトです。 無視されているように見えることもありますが、それは私たちがそれらを解決することを計画していないという意味ではありません。

私は現在、Tinymceエディターを使用しない10のカスタム投稿タイプでACFを使用してWebアプリを構築しています。 タイトル機能と、CPTごとに平均して約15のACFフィールドを使用しています。
現在、CPTがサポートする機能（エディター、サムネイル、抜粋など）を宣言できます。
「ストーリーを書く」段落ブロックと「ブロックを挿入」アイコンを編集画面から非表示/削除することはできますか？

@ cr101 CPTサポートから「エディター」を削除する場合は、おそらくブロック

一方、メタボックスのv1では、メタボックスペインを下から展開できます。これを維持する場合は、「エディター」サポートのないCPTに対して常に「オープン」であることを確認する必要があります。 メタボックスが常にエディターの下に表示される場合は必要ない場合があります（上記のいくつかの設計提案のように）

これが適切な場所かどうかはわかりませんが、コアカスタムメタフィールドについてはどうでしょうか。 サードパーティのプラグインについては多くの話がありましたが、コアのカスタムメタフィールドについてはどうでしょうか。 それらはそれほど人気が​​ないことは知っていますが、私が取り組んできたいくつかのサイトでそれらを使用していると思います。

コアカスタムメタフィールドをグーテンベルクに統合するための計画はありますか？

こんにちは@jawittdesigns 、

コアメタボックス（少なくともそれらのほとんど）はすでにグーテンベルクで再実装されていると確信しています！ それらは、分類法などの処理に関するいくつかのより良いワークフローを特徴としています。

誰もがブログにWordPressを使用しているわけではありません。 私たちの多くはWordPressをCMSとして使用しています。 現在、WordPress RESTAPIとACFを使用してWebアプリを構築しています。 10のカスタム投稿タイプがあり、各CPTには20のカスタムフィールドがあり、すべてのCPTは、ACFリレーションシップフィールドとポストオブジェクトフィールド、およびACFPost -2-Postプラグインを使用して双方向の関係を介して相互にリンクされてい

グーテンベルクは、現在のエディターを使用していないため、現在の形式では役に立ちません。 CPTにはTitleテキストボックスのみを使用しており、残りはpost_metaテーブルに格納されるカスタムフィールドです。

グーテンベルクの編集者は、現在の状態ではコアの一部になるべきではないと強く信じています。 プロジェクトとしてのWordPressは、独自のカスタムテーマを使用しないサイトビルダーに対してある程度機能する必要があることを認識しています…しかし、Gutenbergエディターは、高度なカスタムフィールドを使用してコンテンツを複雑に入力する私たちを直接攻撃しているようです。コンテンツを入力するための非常に具体的な方法をサイト所有者に提供することにより、サイト所有者にとってかなり「ばかげた証拠」になります。 現在の状態のグーテンベルク編集者は、ACFを使用している私たちを直接攻撃しているようです。
Gutenbergプラグインを使用すると、ヘッダーの編集リンクがユーザーをGutenbergインターフェースに直接送信します。このインターフェースには、ACFメタボックスは表示されず、画面上部にアクティブ化するための画面オプションタブがありません。 はい、ユーザーはページ/投稿配列に戻って「クラシックエディター」オプションを選択し、メタボックスを表示できますが、これは、ACFフィールドにアクセスするためにサイトエディターが追加の手順を実行する必要があることを意味します。 多くの場合、ACFを使用する目的が、技術者以外の編集者にとって複雑なレイアウトの編集をより流動的かつ簡単にすることであったことを考えると、正確には最適ではありません。

これは何と長期にわたる問題でした！

＃3345と＃3554の統合により、メタボックスのサポートは_featurecomplete_と呼べる状態になりました。 これは_complete_とは異なることに注意してください。これは、メタボックスエクスペリエンスの洗練、特にスタイリング、より複雑なJavaScript処理、およびクラシックエディターにフォールバックするためのルールの決定に関して行うべき作業がまだ残っているためです。

この問題に建設的に参加してくれたすべての人に感謝します。それは困難で、時には物議を醸すプロセスであったことを私は理解しています。 グーテンベルクがメタボックスを処理する方法、および（必要に応じて）メタボックスをグーテンベルクと互換性がないものとしてマークする方法に関するドキュメントについては、ハンドブックを参照してください。

特定のプラグインまたはメタボックスに関連するバグに遭遇した場合は、新しい問題を開いてください。正しく追跡して修正できます。

ちなみに、これは完全な機能にはほど遠いはずです。

@coffeeneed建設的になりたい場合は、私たちが支援できるように十分な詳細を記載した新しい号を開いてください。 ありがとう