Gutenberg: iframeはメタボックスの実行可能な長期ソリューションですか？

1. ...グーテンベルクは現在、メインコラムとサイドバーに2つの別々のiframeを使用しています。 タイトルの後に表示されるメタボックスをサポートする場合、理論的には3番目のiframeになります。 これにより、プラグインがすべてのiframeメタボックスに影響を与える必要のあるアセットをキューに入れる方法に関する問題が発生しますか？

今夜、いくつかのパフォーマンステストを行いましたが、[ネットワーク]タブでこの発見に遭遇しました。 親ウィンドウにキューに入れられているすべてのCSSおよびJSアセットは、メイン列のiframeとサイドバーのiframeにもキューに入れられているようです。つまり、各アセットは合計3回リクエストされ、使用時にアセットリクエストの数が実質的に3倍になります。グーテンベルク。

ブラウザのキャッシュを有効にすると、ページの重みによる損傷は軽減されますが、アセットリクエストの数は3倍になります。 これは、各iframeにメタボックスを機能させるために必要なアセットが含まれるように行われていると思いますが、これは今後アセットをキューに入れるためのソリューションにはなりません。

問題と洞察を作成していただきありがとうございます@kevinwhoffman。 グーテンベルクのメタボックスについて今日私たちが持っているのは実験であると少し考えるのは良いことです。多くの点で、プロジェクトが進むべき方向を決めるとき、それは保持パターンです。 それは「今のところ」機能するものですが、私たちが同梱するものではないと言っています。

以上のことから、将来メタボックスが何に使用されるかを検討することが重要だと思います。 ブロックに変換されないケース（ある場合）は何ですか？ すべてのメタボックスはモバイルで動作する必要がありますか？ 私たちが探求していない代替インターフェースさえありますか？ きっとあります。 今のところ、それはそれらの可能性を見て、現在の州と将来の州のために働く道に乗ることについてです。

現在、グーテンベルクのメタボックスの現在のバージョンに存在するバグを修正する必要があり、それが焦点となっています。 この修正にはパフォーマンスが必要です。 モバイルに関しては、メタボックスは長い間問題となってきましたが、ここでは悪化していません。 それは私達が将来よりよい解決のために働くべきであると言った。 ループバックして、これは「今日」の解決策にすぎないことを覚えておくことが重要です。繰り返し、より良いオプションを自由に考え続けることができるからです。

グーテンベルクのメタボックスについて今日私たちが持っているのは実験であると少し考えるのは良いことです。多くの点で、プロジェクトが進むべき方向を決めるとき、それは保持パターンです。 それは「今のところ」機能するものですが、私たちが同梱するものではないと言っています。

「今のところ」だけでなく、iframeアプローチは機能しません。 上記の関連する問題は、メタボックスが主要な方法で機能しない例を示しています。 さらに、これらの問題が修正されたとしても、ページの重みとリクエストの数が3倍になっても、どのような状況でも「機能している」と見なされるべきではありません。

以上のことから、将来メタボックスが何に使用されるかを検討することが重要だと思います。

敬意を表して、これはメタボックスの問題が発生するたびに発生します。 会話を将来のメタブロックに移すのではなく、既存のメタボックスが直面している問題についてこの議論を組み立てることが非常に役立ちます。 もう一度：

メタボックスを生成するテーマやプラグインを変更せずに、これらの問題に対処できますか？

これまで、メタボックスがグーテンベルクと連携し続けることを示唆する証拠は見たことがありません。 答えが「いいえ」の場合は、5.0が単なるWordPressリリースであるというふりをやめ、下位互換性を破ることについて正直になり始める必要があります。

こんにちはケビン、

詳細なご報告ありがとうございます。 多くの問題はある程度修正できると思います。 これは、iframeアプローチが機能するかどうか、およびそれをどこまで実行できるかについての調査でもあるため、この種の対話を行い、このアプローチの欠点を記録することをお勧めします。

iframeを超えて拡張するメタボックスからコンテンツウィンドウを起動することは可能ですか？

ページ全体を占めるモーダルライトボックスのような意味ですか？

ページ全体を占めるモーダルライトボックスのような意味ですか？

これは一例ですが、iframeの範囲内にないコンテンツを公開する必要があるシナリオを参照しています。

たとえば、ページの中央にあるコンテンツボックスをトリガーするサイドバーのボタンをクリックできますか？ そのコンテンツボックスがiframeの内側にある場合、サイドバーのiframeのサイズの外側には表示されません。

論理的な次のステップは、代わりにiframeから親ドキュメントの関数を呼び出すことです。 しかし、プラグインは現在そのように機能するように作成されておらず、プラグインを変更する必要があると、_legacy_メタボックスをサポートするという目的全体が無効になります。 決定されたソリューションが、既存のテーマやプラグインを変更せずに機能する必要があることを強調することはできません。

プラグイン/テーマアセットに関してiFrameの実装がどれほど否定的であるかを知っているので、これはプロジェクトを一時停止させるはずだと思います。 ここでの本当の答えは、WordPressがFields API https://github.com/sc0ttkclark/wordpress-fields-apiを出荷していることです。それがなければ、パフォーマンスを気にすると、Gutenbergでメタボックスを効果的に実装することは事実上不可能です。

「準備が整う」までGutenbergを実際に出荷しない場合は、フィールドAPIにも同様の注意を払って、MetboxがGutenbergのReactと正しくシームレスに動作するようにする必要があります。

論理的な次のステップは、代わりにiframeから親ドキュメントの関数を呼び出すことです。 しかし、プラグインは現在そのように機能するように作成されておらず、プラグインを変更する必要があると、レガシーメタボックスをサポートするという目的全体が無効になります。 決定されたソリューションが、既存のテーマやプラグインを変更せずに機能する必要があることを強調することはできません。

うん、間違いなく私がこれをしている間に持っていた懸念。 iframe間の相互通信はあまり良く聞こえません。 探索する他の選択肢もあります。

ただし、特定のテーマプラグインが壊れて、考えられるすべてのユースケースに対応できるわけではない場合は間違いなくあります。おそらく、大多数のユーザーとユースケースに優れたエクスペリエンスを提供することがより良い目標だと思います。 。 現在のiframeソリューションがその目標を達成していない可能性は十分にあります。

最近のCoreCustomizer Dev Note Postで、iframeを_改善_として使用しないように注意が向けられたことは注目に値するかもしれません。 ここでソリューションとしてiframeを実装することは、一歩後退したように見えます。

こんにちは数学、

「準備が整う」までGutenbergを実際に出荷しない場合は、フィールドAPIにも同様の注意を払って、MetboxがGutenbergのReactと正しくシームレスに動作するようにする必要があります。

FieldsAPIがいくらかいいと思うことに同意します。 ただし、それには、フィールドAPIを採用する必要があることも必要になります。 グーテンベルクのプラグイン/テーマを書き直すことをいとわない人があまりいない場合、FieldsAPIの場合はそうするつもりはないと思います。 また、前号のどこかで取り上げられたと思いますので、GitHubの歴史の中でそれを探し出し、FieldsAPIがグーテンベルクにどのように役立つかについての考えを追加することをお勧めします。

...考えられるすべてのユースケースに対応することは不可能です。おそらく、より良い目標は、大多数のユーザーとユースケースに優れたエクスペリエンスを提供することだと思います。

私は同意します。グーテンベルクがページ全体を引き継ぐのではなく、エディターのオーバーホールに固執した場合、目標ははるかに達成可能になると思います。 次に、既存のフックをそのままにして、メタボックスが現在と同じように相互に通信し続けることができます。 また、アセットのエンキューは、今日と同じように機能するため、問題にはなりません。

私はYoastが提唱したこの概念に強く同意しています。これは、プロジェクトの範囲を縮小してエディターコンポーネントに焦点を合わせながら、すでに行われた作業の多くを維持するように思えます。

出典： https ：

また、Yoastが提案した提案にも強く同意します。 プラグインの作成者がメタボックスを新しいブロックに変換する時間を提供する、優れた中間段階を提供します。 次に、エディターエクスペリエンス全体を最終的に置き換える計画の一環として、プロジェクトとしてのWPは、「xバージョンでは、メタボックスは非推奨になります」のように言うことができるため、より良い最終目標に向けて進むための_plan_が用意されています。

通信する中央のTinyMCEインスタンスがないため、この概念は既存のメタボックスを破壊することに注意してください。 メタボックスの80％をサポートする代わりに、これは90％をサポートします（私はこれらの数値を作成しました）。

この概念は下位互換性の問題を解決しませんが、同じ問題で解決を後で遅らせるだけです。 グーテンベルクはWPのJSインターフェースへの第一歩であり、グーテンベルクにとどまりません。

グーテンベルクの部分を再利用してこの概念を構築することは比較的実行可能ですが、これは最適化するUXではありません。最初に可能な限り最高のエディターを構築し、下位互換性の懸念（新規インストール、メタボックスなし）なしで利用できるようにします。 。）。

グーテンベルクの理想的なビジョンを出荷する準備ができたら、アップグレードパス戦略について話し合う時間があります。このようなコンセプトはアップグレードパスのオプションですが、最終製品としては絶対にありません。 他のアップグレードパスも可能です。

可能な限り最高のエディターを作成しましょう。

グーテンベルクの理想的なビジョンを出荷する準備ができたと思ったら、アップグレードパス戦略について話し合う時間があります...

私はこれにこれ以上反対することはできませんでした。 既存のサイトと互換性を持たせることができないのに、なぜ理想的なエディターの開発に何千時間も費やすのでしょうか。 依存しているUIが壊れているという第一印象がある場合、ユーザーはそもそも理想的なエディターを体験することはありません。

既存のサイトと互換性を持たせることができないのに、なぜ理想的なエディターの開発に何千時間も費やすのでしょうか。

ただ明確にします、

• プラグインはDOMに完全にアクセスできるため、エディターに選択したオプションに関係なく、既存のWebサイトと100％互換性を保つことは不可能です。DOMで変更すると、互換性が失われます。
• 変更に対して100％の下位互換性を確保する唯一の方法は、変更を加えないことです。 グーテンベルクを無効にするプラグインはすでに利用可能です。
• エディターはすでに膨大な数のウェブサイトと互換性があります。 しかし、他のすべてのように、それが壊れたとき、それは常により目に見えます。

既存のウェブサイトと100％互換性を持つことは不可能です

これが明確になったので、WordPressの将来に最適だと思われるエディターを作成しましょう。

すべてのメタボックスはモバイルで動作する必要がありますか？

はい、なぜ彼らはそうしませんか？

ブロックに変換されないケース（ある場合）は何ですか？

ブログ投稿の場合、Blocks For Everythingが理にかなっている理由は理解できますが、これはメタデータの一般的な使用例、つまり目に見えないデータを無視している可能性があります。 同様に、メタボックスを使用してUIを公開し、分析データを投稿に追加する場合があります。

カスタム投稿タイプのように、メタボックスのみで構成されている可能性がある場合、新しいUIを理解するのに問題があります。 WordPressにはデータ用の包括的なCRUDAPIがないため、多くの開発者はWP_Queryとそれに関連するAPIのスイートを代用として使用し、CPT編集画面のメタボックスを使用して特定のデータを追加するためのUIを分離します。協会。 野生のカスタム投稿タイプの多く（大多数）は、「コンテンツ」の従来の使用を強調しないか無視します-したがって、ブログ投稿の場合、はい、コンテンツは最前線ですが、多くのCMSユースケースでは、WYSIWYGは作成しません多くの意味。

この現在の反復では、メタボックスのサポートはアドオンです。多くの人の現実では、メタボックスはUI、API、CMSを構成するために使用するメカニズムです。 <iframe>は、グラグです。

そして、WPが永遠に構築されてきた価値を忘れています。WPの最新バージョンに更新できるはずであり、何も書き直す必要はありません。 私はWPで非常に多くのプロジェクトを抱えているので、二度と触れることはありません。 それらのいくつかがこの変更で激しく壊れないことを私は確信できますか？

この例で終わります。「古い」メタボックスの1つがメディアのUIを開くようにトリガーした場合、iframe内から、誰か（私がもう使用していないクライアント）なしで、この「新しい」シナリオでどのように機能しますか）コードを書き直しますか？

これらの会話に沿って追跡してきたので、グーテンベルクに関する開発とショットを行っている力は、メタボックス自体を使用または処理していないと感じざるを得ません。 それは、手段がそもそも有意に評価されていないので、そう言うのは簡単な、手段を正当化する一種の議論のように感じます。

私たちの多くにとって、WordPress 5.0に更新するとすぐに壊れてしまうサイトが数十あることを理解してください。これは、下位互換性についての躁病であるため、アップグレードしても安全であると歴史的に人々に教えてきた製品です。 ここで説明しているのは、マイナーな（スタイリングなどの）中断ではなく、数千（またはそれ以上）のサイトの管理者側を即座に使用できなくする可能性のあるショーストッパーです。 それは怖いものです。 業界として、WordPressの確かな信頼性で人々を売りました。

上記で指摘した@staylorのように、当社のWebサイトの大部分（中規模からハイエンドの複雑な企業サイト）では、メタボックスはUIです。 エディター（使用されている場合）は、その一部にすぎません。

グーテンベルクの理想的なビジョンを出荷する準備ができたら、アップグレードパス戦略について話し合う時間があります。このようなコンセプトはアップグレードパスのオプションですが、最終製品としては絶対にありません。 他のアップグレードパスも可能です。

これを先延ばしにするのは間違いかもしれないと思います。 特に、多くの組織では準備に少なくとも1〜2四半期が必要になるためです。

ここで覚えておくことが重要だと思うWordPressの複数の主要な開発者から聞いた格言があります：誰かが自分のサイトにWordPressを採用するとき、彼らはWordPress3.7またはWordPress4.8を採用していません、彼らはWordPressを採用しています。 この道を可能な限りシームレスにすることは絶対に必要です。 これは問題を引き起こします、そしてそれは問題ありません（WordPressのほぼすべてのリリースに下位互換性の問題があります）が、それらは最小化され、文書化され、伝達される必要があります。

既存のウェブサイトと100％互換性を持つことは不可能です

互換性がない場合は、必ず行って問題を解決してください。 最初のリリースをWP ++またはWPNGと呼びます。 物事が壊れる可能性が最も高いことを事前に宣言し、人々にその準備をさせる方がはるかに良いです。 物事がいつものように機能するかのような現在の「欺瞞」は、すべての人にとって悪いことです。

Iframeは使いやすさの点で行き止まりです。 メタボックスでjqueryベースの日付選択ウィジェットを開き、ウィンドウ上の他のランダムな場所をクリックしても閉じなかったときに驚いた。 クリックイベントが親ウィンドウにあり、iframeに伝播されなかったことに気付くのに少し時間がかかりました。 びっくりしましたが、結局はわかりましたが、そのようなことをユーザーにどう説明するのでしょうか？ 各プラグインが、そのような些細なUXの期待に関する各ユーザーの質問に答えることを期待していますか。
また、外部リンクがどのように機能すると思いますか？

人々が最後の手段としてのみiframeを使用する大きな理由があります。

私の生産的な提案は、yoast seoが適切に機能しない限り、メタボックスの準備ができていると宣言しないことです。 それは相互作用の点で少し複雑であり、サイトのたわごとの負荷にインストールされています。 グーテンベルクがそれを扱うことができない場合、おそらく誰もそれを使用するつもりはありません。

私の生産的な提案は、メタボックスの準備ができていると宣言しないことです

上記の@karmatosedが指摘して

いくつかの実際のデータを提供するために、私は過去に取り組んだWordPressサイトからこのインターフェースを共有したいと思います。 コンテンツフィールドはこのカスタム投稿タイプのマイナーな部分であり、一部のカスタムメタボックスフィールドはブロックに変換できますが、大部分には、管理者が使用するデータ、RESTAPIを介してサードパーティサービスが使用するデータが含まれます。または、エントリにメタデータを追加するために使用されます。 少し混沌としているように見えるかもしれませんが、このセットアップはクライアントのワークフローで機能するように特別に設計されており、明確な分離に基づく厳密なコンテンツモデルを使用して、サイトの将来のバージョンが各タイプのコンテンツを独立して処理できるようにします。

グーテンベルクの現実の中で機能するようにこのサイトをリファクタリングするには時間がかかり、かなりのリソースが必要になるため、メタボックスが既存のものと厳密に一致する方法で処理されない限り、このサイトの所有者はグーテンベルク以前のバージョンのWPに戻って滞在する可能性がありますそこに無期限に。

参考までに、これは広範囲に見えますが、私が構築した中で最も複雑なメタボックスセットアップでも、これまでに見た中で最も複雑なセットアップでもありません。 この例が示しているのは、メタボックスを介した実際の回避策であり、コンテンツブロブを超えた適切なコンテンツモデリングと分離の必要性に対応します。これは、グーテンベルクが適切かつ機能的に処理する必要があります。

この道を可能な限りシームレスにすることは絶対に必要です。

同意しました

これは問題を引き起こします、そしてそれは問題ありません（WordPressのほぼすべてのリリースに下位互換性の問題があります）が、それらは最小化され、文書化され、伝達される必要があります。

同意しました

プラグインはDOMに完全にアクセスできるため、エディターに選択したオプションに関係なく、既存のWebサイトと100％互換性を保つことは不可能です。DOMで変更すると、互換性が失われます。

同意しました、私は誰もここであなたに反対しないと思います。 しかし、何が壊れたのいつ壊れたのかについてはまだ議論の余地があると思います。 これらの種類の決定は、壊れたものを修正するために開発者がしなければならない作業の種類にも影響を与えます。 domセレクターが変更されたために調整することと、メタボックスが機能するだけの新しいグーテンベルクパラダイムに合うようにカスタムコンテンツモデルを書き直す必要があることとの間には大きな違いがあります:)メタボックスに関する競合は、おそらくそうではないことを私に示していますコアのグーテンベルクの初期リリースでの破壊をターゲットにするのは良いことです。

私はこれがすべて実験であると_get_します。

また、マージの提案が行われるまで、開発者が既存の作業をグーテンベルクに変換するという大規模な増加は見られないと思います。

tldr; グーテンベルクでの破損は予想されますか？ はい！ しかし、それでも、破壊するものと、コアにマージされたグーテンベルクの初期反復でその破壊がどこまで進むかについては、選択する必要があります。

はい、私たちは皆、WordPressの開発に携わってきたので、リリースごとにいくつかの問題が発生することが予想されます。 そして、まさにそれが私のポイントです。 グーテンベルクを単なる別のWordPressアップデートとして提示している限り、他のアップデートよりも多かれ少なかれ何かを壊してはなりません。 私たちがその信頼を破った場合、編集者が一日の終わりにどれほど優れているかは問題ではありません。

これは、私が過去数か月にわたって開発してきたプラグインの現在のスクリーンショットです。 この状況では、ビジュアルエディターはまったく価値がなく、コンテンツのビジュアル編集用に設計されたインターフェイスに必要な種類のインターフェイスを追加しようとしても意味がありません。

次のバージョンですべての作業が取り消される可能性があることを考えると、WordPress用にこれを開発し続ける必要があるかどうかを実際に真剣に検討しています。

ご覧のとおり、メタフィールドでメディアアップローダーにアクセスする必要があり、ページの大部分をiframeに委任すると、このインターフェイスが非常に不器用になります。

WordPress上に構築されたプラグイン、ツール、カスタムサイトには、このようなインターフェイスが何百万もあります。 ブロックの「新しい熱さ」を支持して、これらのユーザーを二級市民のように扱うことは受け入れられません。 メタボックスは、編集ページで現在のレベルの統合と卓越性を維持する必要があります。

Yoastのグーテンベルクに対する見方を強く支持します。 「ビジュアルエディターのアップグレード」がグーテンベルクチームによって「ポストエディットインターフェイス全体を置き換える」とどのように再解釈されたかは私にはわかりませんが、いわゆる「テセウスの船」と直接対立しているようです。

この場合、既存の標準ワークフローに対する明確な方向性とサポートの欠如が、現在開発者を積極的に傷つけています。 信頼できるフックとツールのセットを信頼せずに、プロジェクトの構築を進めるにはどうすればよいですか？ このような大規模なソフトウェアプロジェクトが、1回の更新で開発者の標準ワークフローを完全に覆すと考えるのは無礼です。 そして、これらの会話がちょうど今、11月に行われているのは非常識です。そのとき、年の初めに合併が承認される予定です。

ここでの通信に問題があるようにのように@aaronjorbinだけでなく、思わhttps://make.wordpress.org/core/2017/10/24/whats-new-in-gutenberg-24th-october/それが明示的に言われました

このリリースには、待望のメタボックスのサポートが含まれています（テストが必要です！）。

それは「アイデア」ではなく、「実験」でもありません。すべてのソフトウェアと同様に、まだバグが含まれている可能性があります。 その投稿で「実験」と呼ばれていたら、私はそれをテストしなかっただろう。

話を戻すと、ここでの主な問題は、破損の宣言を回避しようとすることであることがわかります。 JSフレームワークについての私の限られた理解から、それらを「半分妊娠」することは非常に困難であり、メイン画面の制御がそれらで行われると決定したら、すべてをそれらで行う必要があります。したがって、前進する唯一の方法はグーテンベルク編集画面でメタボックスをファーストクラスの市民にします。
「レガシー」プラグインが適応する可能性は低いため、これは、グーテンベルクが既存のサイトの明示的なオプトインオプションである必要があることを意味します。 私はUXフォークのアイデアが嫌いですが、少なくともこの方法で機能する方法があり、それが宣言されれば、人々は準備できるようになります。

ディスカッションを読み、WordPressで構築したプロジェクトや、WordPressで人々が行っていることについて考えた結果、Gutenbergはカスタム投稿タイプをオプトインする必要があるという結論に達しました。 これにより、構造化データにCPTを使用する現在のWebサイトが引き続き機能し、WordPressがCMSとして使用される新しいWebサイトを構築できるようになります。 投稿タイプを登録するときに、他の機能と一緒にエディターフィールドのサポートを明示的に宣言できることを思い出してください。 それなら、グーテンベルクの明示的なサポートをそこに追加してみませんか？ もちろん、これによって投稿やページにメタボックスが追加される問題は修正されませんが、将来的にはWordPressをCMSとして使用できるようになります。

それらのiframeに1つの新しい問題を追加できます。 ユーザーセッションが終了すると、WPログイン画面がグーテンベルク上とiframe内に2回表示されます。

開発者がそれを知っているためだけに。

私はこれらすべてにもっと従うほど、Microsoftのように可能な方法しかないと確信しています。

Windows XP =グーテンベルクのないWordPress
Windows 10 = Gutenbergを使用したWordpress。

これら2つを他のパッケージと組み合わせて更新することはできません。

JoomlaとDrupalがそれを行いました。 何故なの。 私が好むものではありませんが、代替手段は何ですか。

ディスカッションを読み、WordPressで構築したプロジェクトや、WordPressで人々が行っていることについて考えた結果、Gutenbergはカスタム投稿タイプをオプトインする必要があるという結論に達しました。

分割管理者は、グーテンベルクから出てくる可能性のある最悪の結果の1つです。 https://github.com/WordPress/gutenberg/issues/3330#issuecomment-341752490でその理由を概説しました。

この議論は本当にカフカエスクになりつつあります。 現在の問題点に実際的な解決策を提案する人がいくつあっても、批判に完全に影響されないように見える重要な人が数人いるようです。 残念ながら、これらの人々が最終決定権を持っています。これまでの議論では、数百人の心配している開発者を数人のキーパーソンが実行できることが示されているためです。 これがWordPressエコシステムに与えるすべての損害について心配しています。 グーテンベルクを編集画面ではなく編集者にします。 WordPressを壊さないでください。

ケビン・ホフマン：

私はYoastが提唱したこの概念に強く同意しています。これは、プロジェクトの範囲を縮小してエディターコンポーネントに焦点を合わせながら、すでに行われた作業の多くを維持するように思えます。 出典： https ：

Yoastによって提案された前進の道は、WordPressCoreの大きな改善になると思います。 多くのユーザーが現在のものよりも改善されたものとして受け入れるコンテンツを作成するための新しいエディター。 WordPressの小さなステップですが、ユーザーにとっては大きな改善です。

これは白熱した主題です。 私たち（少なくとも私）が私のコメントを否定することがあることを認めます。これについてお詫び申し上げます。 良い、悪い、客観的、役に立たないなど、多くのフィードバックを受け取っており、それらを区別するのが難しい場合があります。 私たちは人間です。 方程式の反対側にいて、このことを構築し、このすべてのフィードバックを受け取る人になるようにしてください。 ITは「個人的な攻撃」に近いと感じる可能性があり、脳は否定的に反応する傾向がありますが、そうすべきではありません。

ブログの投稿にコメントしたり読んだりする人々は、メタボックスの問題とそれに関連するすべてのものを発見していると思うことがよくあります。 そうではなかった。 私たちはグーテンベルクに1年間取り組んでいます。 グーテンベルクを発見/試したばかりかもしれませんが、私たちはそうではありません。下位互換性の問題のほとんどに慣れるために十分な時間取り組んでおり、それらのほとんどに対する回答があります。

どうか、心を開いて、いくつかの質問に答えることから始めましょう。

グーテンベルクの目標は何ですか？

グーテンベルクの主な目標は、WordPress Coreの未来への道を開くことではありませんし、決してそうではありませんでした。 技術的には、REST API、クライアント側UIを活用し、コアコンセプト（ウィジェット、ショートコード、ブロック、コンテンツメタボックス）を独自のコンセプト「ブロック」に統合し、次の質問に答えることで賢明な経験をします。ウェブサイトの構築を簡素化するにはどうすればよいですか（カスタマイズを考えてください） WordPressでコンテンツを公開します（エディターを考えてください）。

グーテンベルク編集者の目標は何ですか？

あなたがあちこちで読んだものとは異なり、焦点は常にページ全体の再設計にありました。グーテンベルク編集者ページの最初のモックアップは、2回目または3回目の毎週のグーテンベルク会議で示されました。 私たちはまだプロトタイピングの段階にありました。 最初のアルファの数か月前。 デザインは私たちが今持っているものに近かった。

メタボックスはどうですか、WordPressにとって重要ですか？

彼らです。 ショートコードやカスタムTinyMCEボタンと同様に、WordPressのエディターページを拡張するために頻繁に使用され、悪用されています。

ショートコード、TinyMCEボタン、メタボックスの違いは何ですか？

主な違いは、「メタボックス」には「目的」がないことです。これは、一貫性のないエディターページを拡張する方法であり、ShortcodesボタンとTinyMCEボタンには一貫性があります。

ショートコードはレンダリングフェーズでコンテンツに変換される文字列です。TinyMCEボタンはTinyMCEツールバーに追加されるカスタムボタンであり、TinyMCEAPIを使用してエディターのコンテンツと通信します。 メタボックス？ わかりません。何でもかまいません。HTML、Javascript、PHPを追加するだけで、エディターのページと保存時の動作を拡張できます。

この「目的」の欠如は問題ですか、それとも利点ですか？

上手！ プラグインは次のようなものを含め、エディターでやりたいことを何でもできるので、「プロ」と見なすことができます。

• ボタン、textarea、input、div、その他すべてを置き換えます。 DOMへのフルアクセス
• TinyMCEのグローバルインスタンスを含む任意のグローバルJavaScript変数を使用する

柔軟な権利！ しかし、WordPressのアップデートはどうですか。 エディターの画面の更新。 TinyMCEの更新、クラスの変更、新しいdiv 、ボタンの削除/移動、変更はプラグインとの互換性を損ないます。コアWordPress開発者は、どのプラグインがメタボックスを使用しているかわからないためです。

WordPressの長期にわたって、メタボックスは（グーテンベルクに関係なく）その進化をロックしていると結論付けることができますか？

はい、そうです。 そして、インターネットの歴史は何度も証明されたため、進化しないテクノロジーは死にました。 （👎に反応しないでくださいこの答えが気に入らない場合、それは事実であり、意見ではありません）

わかりました、しかし、メタボックスで立ち往生している場合、どうすればWordPressを前進させることができますか？

これは良い質問です。答える前に、WordPressプラグインでのメタボックスの現在の使用法を理解する必要があります。

現在のプラグインはメタボックスを何に使用していますか？

「メタボックス」プラグインには2つのカテゴリがあると思います。

• コンテンツとしてのメタボックス（多くの場合、ポストメタに保存されますが、常にではありません）
• エディターエクスペリエンスの強化としてのメタボックス（SEO、スペルチェック、…）

さて、これを知って、どうすれば前進できますか？

3つのものが必要です。

• Gutenberg（またはWordPressのアップデート）の出荷中にこれらのプラグインをビルドまたはアップグレードする方法を提供します。
• これらのプラグインを使用している人々に可能な限り最良のアップグレードパスを提供します。 これには以下が含まれます：これらのプラグインが今後の進化でまだ機能するかどうか、そして破損を最小限に抑える方法を確認してください。

わかりましたが、エディターページを変更すると、プラグインが破損する（コンテンツ領域のみの置き換えを含む）とは言いませんでしたか？

正しい！ したがって、プラグインを壊さないことを希望する場合は、独自のオプションが残されています。 変更せずに現在の編集ページを維持する方法を提供します。 それこそが、グーテンベルクを無効にするプラグインの目的です。

私はこれを個人的に良いアップグレードパスとは呼びません、それはアップグレードでさえありません、何かより良いですか？

このアップグレードパス（グーテンベルクを無効にする）は必要ですが、はい、もっとうまくいくことができます。 Metaboxesを使用してプラグインを見ると、それらの90％はコンテンツ領域と相互作用していません。したがって、コンテンツ領域のみを置き換えると（yoastアプローチ）、プラグインの10％のみが壊れます。

したがって、破損しない唯一の方法は、グーテンベルクを無効にすることです。

最適なGutenbergユーザーエクスペリエンスは、メタボックスプラグインを、新しいGutenberg ExtensibilityAPIと同じ機能を提供するプラグインに置き換えることで構成されます。

とはいえ、メタボックスを使用するプラグインのほとんどは、メタを投稿するために保存されるコンテンツとしてそれらを使用していることに気付きました。プラグインの作成者がプラグインをアップグレードしている間、グーテンベルク画面でそれらを動作させて全体のエクスペリエンスを楽しむことができます。

これは誰もが話しているiframeソリューションですか？

はい、そうです。 欠点（リンク、モーダル、アセットの再読み込み）があるiframe内のメタボックスを示しますが、同時に、プラグインの80％がGutenbergエクスペリエンス全体を楽しみながら機能することを可能にします。 このソリューションは着陸したばかりで、まだ実験中です。 確かなことは、すべてのメタボックスを機能させてエディターに変更を加える方法はないということです。

なるほど、アップグレードの可能性を要約していただけますか？

承知しました。

1-グーテンベルクを無効にする：プラグインを100％壊さないでください
2-グーテンベルクはコンテンツ領域のみを置き換えます：プラグインの90％が機能し、UXが苦しんでいます
3-グーテンベルクが画面全体を置き換えます：プラグインの80％が機能し、UXが優れています
4-互換性のあるプラグインを備えたグーテンベルク：可能な限り最高のUX

では、何をする必要がありますか？

私たちの目標は、WordPressの将来にとって最良のオプションであるため、4番目のオプションを構築することです。 私たちの目標はまた、必要に応じて2番目と3番目のオプションを達成するためにその部分を再利用できる方法でグーテンベルクを構築することです。

オプションを別のオプションよりもオプトインするにはどうすればよいですか？

これはまだ決まっていません。 必要なアップグレードパスを選択するプラグインがある可能性があります。 一部のメタボックスを検出して自動的にダウングレードすることはオプションです...

これが、これらの問題の背後にある理由を説明するための私の見解です。「ばかげている」、「管理が不十分」、「実装が不十分」などの言葉で答えたい場合は、1年かけて考えた単純な開発者としての私の忍耐力WordPress全体（コアとコミュニティ）にとって可能な最善の方法は限界に近づいています。 私は個人的にこの問題についてこれ以上返信しないかもしれませんが、フィードバックを聞いており、フィードバックに納得した場合は私の推論を適応させます。

私たちは皆同じ船に乗っています。WordPressに最高のものを求めています。

非常に徹底的な説明、リヤド。 それらを書く時間を作ってくれてありがとう。 💪と🤗でその制限を回避するのを手伝いましょう。 それが役に立てば幸い。

メタボックスに関しては、FieldsAPIをコアに持つことは非常に重要です。 しばらくすると、カスタムメタボックスソリューションが収集する傾向のあるすべての混乱を取り除くために、プラグインを書き直します。

複雑なメタボックスの設定をしている人にとって、Fields APIは、ACFやCMBなどのフレームワーク上に構築されている限り、彼らの救いです。 これらのフレームワークの開発者は、新しいAPIに切り替えるだけで、すべて問題ありません。 簡単な作業ではありませんが、誰にとっても良い作業です。 「ハードコードされた」ものが横になっている人にとっては、今はこれまでになく、よりクリーンで将来性のある方法で物事を再編成する良い機会です。 グーテンベルクかどうかにかかわらず、あなたはより良い状態にあります。

私たちは人間です。 方程式の反対側にいて、このことを構築し、このすべてのフィードバックを受け取る人になるようにしてください。 ITは「個人的な攻撃」に近いと感じる可能性があり、脳は否定的に反応する傾向がありますが、そうすべきではありません。

グーテンベルクに非常に熱心に取り組んでいる人間がいます。 生計（彼らのテーマとプラグイン）がグーテンベルクの影響を受ける人間がいます。 そして、グーテンベルクの影響を受けたテーマやプラグインを使って自分の仕事をしている人間もいます。 私たちは皆お互いに気を配っていて、一日の終わりにWordPressのために最高のものを望んでいます。 「最高」の意味については熱心に意見が分かれるかもしれませんが。

あなたがあちこちで読んだものとは異なり、焦点は常にページ全体の再設計にありました。グーテンベルク編集者ページの最初のモックアップは、2回目または3回目の毎週のグーテンベルク会議で示されました...

モックアップだけでは、編集ページ全体のコードベースがReactで書き直されることを示していませんでした。 重要なフックが削除されたり、メタボックスが壊れたりするモックアップを見て、誰も知ることができませんでした。 しかし、ページ全体の乗っ取りがメタボックスに問題を引き起こすことが明らかになったとき、 0.1.0がリリースのタグを付けられる前日の6月15日にその懸念を表明しました。 4か月と15回のリリース後、iframe内のインターフェイスにメタボックスが実際に表示されるのは初めてでした。

この問題は、プレアルファ段階からグーテンベルクを綿密に追跡してテストした経験に基づいて作成しました。 これは、進行中のメタボックスの課題に関連する最新の問題ですが、重要なことに、グーテンベルクのメタボックス実装の具体的なテストに基づく最初の問題です。

主な違いは、「メタボックス」には「目的」がないことです。これは、一貫性のないエディターページを拡張する方法であり、ShortcodesボタンとTinyMCEボタンには一貫性があります。

これも、プラグインおよびテーマの開発者がメタボックスをどのように使用するかについての根本的な誤解を示しています。 ショートコードとTinyMCEボタンは、実際にはコンテンツエディター内で使用されるため、適応させる必要があると予想されます。 メタボックスはそうではありません。

カスタムWordPress開発の基本的な構成要素であるメタボックスに目的がないことを示唆することは、Gutenbergがプラグインとテーマの開発者を犠牲にして「新規インストール」のコアエクスペリエンスを優先していることをコミュニティに再び伝えます。

エディターの画面の更新。 TinyMCEの更新、クラスの変更、新しいdiv、削除/移動されたボタン、変更はプラグインとの互換性を損ないます。コアWordPress開発者として、どのプラグインがメタボックスを使用しているかわからないためです。

メタボックスの目的はわからないかもしれませんが、メタボックスとそれらが使用するフックを登録するための基本的な要件はわかっています。 それらのどれもiframe内で動作するように開発されていないことを私たちは知っています。 何年もの間、WordPressを壊さずに拡張および拡張する方法を理解してきました。 繰り返しになりますが、5.0が単なる別のWordPressリリースである場合、破損の量は他のリリースと変わらないはずです。

欠点（リンク、モーダル、アセットの再読み込み）があるiframe内のメタボックスを示しますが、同時に、プラグインの80％がGutenbergエクスペリエンス全体を楽しみながら機能することを可能にします。

常に参照されているこれらの80％/ 90％の数値の証拠がある場合は、それを共有してください。 それ以外の場合は、コミュニティにこの規模の決定を依頼するときに、架空の統計を使用しないでください。

後でではなく、今すぐ停止して再評価してください

この議論と私はアイフレームが実行可能な長期的な解決策ではないことの証明だと思ったのすべての後、私が出会ったhttps://github.com/WordPress/gutenberg/issues/3165#issuecommentルックスが三分の一を追加すること-341476059グーテンベルクへの

制限が存在しないかのように理想的なエディターの追求をやめ、WordPressを壊さないアプローチを検討し始めるのは過去のことです。

初日からグーテンベルクの編集者を見て議論している開発者として言えば、リヤドの議論にはいくつかの大きな穴があると言って申し訳ありません。

第一に、人々は初日からメタボックスの問題を提起しており、他のいくつかの問題はまだ空中にあります。 モックアップフェーズでは、「すべてが視覚的なベストケースであり、メタボックスについては後で説明します」と言われました。 次に、プロトタイプフェーズでは、「これはすべて概念実証コードであり、メタボックスは後で処理されます」でした。 その後、機能プラグインの最初のイテレーションがリリースされたとき（これは、誰にとっても大きな驚きであり、結局のところゼロからの書き直しではなく、現在の概念実証コードの再パッケージ化でした）、議論は突然になりました「メタボックスのようなレガシーインターフェースは今のところある程度サポートされるでしょう」。 その後、国民の抗議が耳をつんざくようになったとき、それは「私たちは誤解しました、メタボックスはレガシーではありません」でした。 しかし今、この議論は「レガシー」アジェンダを再び押し進めているだけです。

現在、実行可能な代替手段がないため、メタボックスはレガシーコードではありません。

メタボックスでは、 wp_editorを使用して、フル機能のネストされたエディターを簡単に追加できます。 グーテンベルクには現在、ネストされたブロックのUIがなく、5.0リリースの予定もありません。そのため、大量のカスタムUIコードがないと、同等の機能を実行できません。

これは1つの例ですが、グーテンベルクが同等を超えるまで、メタボックスのエクスペリエンスを低下させることは許容できる解決策ではありません。 それはWP5.0では起こりません

これは、実際に機能するグーテンベルクの「統一管理者」計画へのロードマップです。

• 初期リリースをwp_editorが現在入力している領域に制限しますが、そのスペース内に完全なブロックUIを提供します
• そのスペースでの設計を簡単にするフィールドAPIを出荷することにより、ブロックUIが可能にする柔軟性と機能を促進および拡張します。
• 人気が高まるにつれて、UIの他の部分を同様のサンドボックス化されたグーテンベルクインスタンスに置き換えます。 メニュー、ウィジェット、カスタマイザー、およびメディアライブラリはすべて、開発者にとって比較的停滞しているインターフェイスであり、共通のUI構造の恩恵を受ける可能性があります。
• 共通のUIがより柔軟で強力になると、共通のツールセットとより多くのオプションが提供されるため、メタボックスではなくUIを使用することを選択するようになります。
• それらのスペースでの開発が停滞するにつれて、孤立したグーテンベルクインスタンス間の穴を徐々にマージします。

そうすれば、開発者は、現在の機能を失うことなく、本番ツールでグーテンベルクを利用し始めることができます。 グーテンベルクは、これらの開発者向けに開発されたすべてのエッジユースケースの恩恵を受け、現在メタボックスを使用している人々のニーズを実際に満たす柔軟なソリューションを作成します。

メタボックスが非推奨になるまでに、プラグインの作成者は、野生のグーテンベルクの利点を学び、使用するのに十分な時間を持っているでしょう。それは当然の選択です。

グーテンベルクはコンセプトカーのようなものです。 今すぐ縮小して、（エディターページではなく）エディターに反復的な改善を出荷します。 その後、次の1、2年で、プロジェクトを100％の管理者カバレッジに向けて進めることができます。

私は、WordPressの下位互換性への声のコミットメントを参照して、更新がWebサイトを壊すというクライアントの懸念を和らげる、クライアントサービスプロバイダーの観点から飛び込みたいと思っています。 それで、WordPressの使用が編集画面の認識を歪めたり偏らせたりした可能性があることを認識しています。

これまで、カスタム投稿タイプが簡単に広く使用できるようになって以来、私の世界ではメタボックスがWordPressの「主要な」セールスポイントであったときに、この問題はパント/却下/軽視されてきたように感じます。 この議論が行われていることをうれしく思います。

グーテンベルクは印象的なプロジェクトですが、私が働いたクライアントは、提供されているメタボックスベースのソリューションに非常に満足しています。 グーテンベルクを無効にするオプションがあるのはいいことですが、プラグインを介してオプトアウトされるのではないかと心配しています。 顧客を指導するための最善の努力にもかかわらず、顧客が自分で新しいプラグインをインストールすることをいとわないだろうとは思いません。また、アップグレードのウェルカム画面に露骨に表示されていても、グーテンベルクが何であるかを彼らは知りません。

クライアントサイトで使用したメタボックスプラグインが「グーテンベルク互換」に更新される可能性はありますが、それでもワークフロー全体がそれらのクライアントで一夜にして変更されます。 かなり前にサイトが配信されて以来、既存のワークフローがうまくいったかどうかを多くのクライアントに尋ねているように感じます。

私はグーテンベルクがユーザーエクスペリエンスを向上させるという目標を完全に支持していますが、コンテンツ編集にメタボックスを使用するために（意図的かどうかにかかわらず）導入された先例を避けることはできないと思います。 Yoastのアプローチは素晴らしいと思います。これは、この問題に対するさまざまな潜在的な解決策について、いくつかのチェックボックスをオンにするものです。

ここで結果を観察するのを楽しみにしています。

グーテンベルクで動作するプラグインの数は、私たちのテストのように80％、90％、または0％である可能性があります。避けるべきことは、何千ものサイト所有者が、構成がおそらく機能するかどうかを自分で確認する必要があることですグーテンベルクと。 それは莫大な時間（=お金）の浪費であり、多くの混乱を引き起こし、多くの信頼を殺します。

グーテンベルクと互換性がある/互換性がない（または「関連性がない」）とマークされたプラグイン/テーマを見たいので、サイトの所有者は、潜在的な問題がサイトでアクティブになる前に通知され、それに応じて行動できます。 データは、プラグインの所有者からだけでなく、ベータテスト期間中（実際のベータ...であり、その期間は数週間だけでなく長くなるはずです）以降のコミュニティテストからも取得できます。

これが完全または100％正確になることは決してないことを私は知っていますが、最も著名なプラグインに対しては実行可能であるはずです。

PS。
私自身のプロジェクト（30.000人を超える従業員向けのイントラネットマイクロサイトプラットフォーム、および多数の中小企業/非営利サイト）では、少なくとも1年が成功するまで、グーテンベルクを無効にすることにしました。

とにかく、パーセンテージがすべてを物語っているわけではありません。 グーテンベルクの影響について議論する場合は、影響を受けるプラグインの数ではなく、メタボックスの実装によって影響を受けるWebサイトの数を考慮する必要があります。 最も広く使用されているプラ​​グインのいくつかはメタボックスとカスタムフィールドに依存しているため、グーテンベルクはほんの一握りのプラグインに影響を与え、それでも数百万のユーザーに影響を与える可能性があります。ACFとYoastSEOが2つの明白な例です。

私はグーテンベルクの開発を何ヶ月も遠くから追跡してきましたが、メタボックスの問題が長い間存在していたことを_知っています_。 私はグーテンベルクの背後にある哲学を支持し、最終的にグーテンベルクはWordPressコアの非常に強力な部分になり、WordPressを将来何年にもわたって実行可能で競争力のあるソフトウェアにすることができると思います。 私はグーテンベルクの概念全体とその目的に非常に精通しています。

私が理解していないのは、一度に0から100になりたいという願望です。 反復リリースがここで採用されているパスではないのはなぜですか？ 2つのオプションが「何も壊さない」または「すべてを壊す」のはなぜですか？

メタボックスは、WordPressがそれと同じくらい強力である理由です。 その目的は、編集画面を拡張することです。

グーテンベルクが画面全体をオーバーホールしたいのは素晴らしいことだと思いますが、特にそれがWordPressの最も重要なコンポーネントの1つを扱うことを意味する場合（カスタム開発に関しては）、一度に行うのは現実的ではないと思います。余談ですが、WordPressの成功の大きな部分を占めています。

2-グーテンベルクはコンテンツ領域のみを置き換えます：プラグインの90％が機能し、UXが苦しんでいます

UXは影響を受けません。 ユーザーは、エディターセクションが刷新されると表示されます。 これにより、コンテンツを作成するための新しい方法が提供されます。調整後にほとんどの人が力を得ることができ、既存のワークフローを壊したり、以前のことをどのように達成するのか疑問に思ったりすることはありません。編集者。

4-互換性のあるプラグインを備えたグーテンベルク：可能な限り最高のUX

これは優れた目標ですが、長期的な目標です。 最終的にはそうです、絶対に、それはグーテンベルクの経験と一緒にまたは内部で動作するプラグインを備えたグーテンベルクでなければなりません。

私たちの目標はまた、必要に応じて2番目と3番目のオプションを達成するためにその部分を再利用できる方法でグーテンベルクを構築することです。

これが何を意味するのかよくわかりません。 プラグインがすべてそれで動作することを前提としてグーテンベルクを構築し、そのソリューションを使用してオプション2と3にペダルを戻したいですか？ 最初に2に向かって構築し、次に3に繰り返して、それが4に到達するのではないでしょうか。

@gschoppeによって提案されたロードマップが好きです。カスタムWordPressWebサイトを構築する開発者として、これは私が後れを取ることができるアプローチであり、開発者やそのクライアント、または通常のWordPressユーザーに悪影響を与えることはなく、それでも私たちを最後までやり遂げます。グーテンベルクの目標-飲み込みやすいペースではありますが。

Kevinのiframeに関する懸念に加えて、アクセシビリティに関する懸念をいくつか指摘したいと思います。 まず、サイトを視覚的に体験するユーザーは、フレームセットとiframeをページの他の部分と一緒にまとまりのある全体として体験しますが、スクリーンリーダーのユーザーはそうではありません。 スクリーンリーダーのユーザーは、フレームセット内の各フレームを体験します。Webページは直線的に体験されるため、各iframeは、ページの残りの部分とは別の別個の部分として体験されます。 一部のスクリーンリーダー（特に、WEBAIMの年次スクリーンリーダー使用状況調査によると市場シェアが最も高いJaws for Windows）には、一部の画面に非常に不快感を与える可能性があるため、インラインフレームを含むフレームを無視する構成設定があります。リーダーユーザー。 フレームを無視する設定が呼び出されると、フレームとiframe内のコンテンツが消えます。 グーテンベルクがiframeに関してすべてのアクセシビリティのベストプラクティスに従っている場合でも、コンテンツを完全に編集できるようにするためにこの設定を無効にするようにユーザーに求めると、ネット上のiframeとフレームの最悪のプラクティスのすべてのインスタンスにユーザーがさらされます。 これらのユーザーに対する他の唯一の選択肢は、グーテンベルクを使用するためだけに別のプロファイルを作成するように依頼することです。これは、すべてのブラウザー設定と音声設定をもう一度構成する必要があるため、単純なプロセスではありません。 また、少なくとも2つの個別のブラウザプロファイルについていく必要があることも意味します。 理由から、Jaws forWindowsユーザーにフルタイムでNVDAに移行するように指示するのは私が最初です。 メタボックスのサポートにiframeを使用しているグーテンベルクはそれらの理由の1つではありません。

.. WordPress全体（コアとコミュニティ）の最善の方法を考えて一年を費やした単純な開発者としての私の忍耐力は限界に近づいています。

失礼なことは嫌いだと誓いますが、その場合は肌を厚くする必要があるかもしれません。 これについて考えて過ごした「1年」に直面したときの反応に不満を感じ、そうしてくれてありがとう。しかし、これらは他の人が行った複数年の仕事に影響を与える決定です。

私の場合、私が読んでいることから、過去3年間に構築したほぼすべてのWebサイトがすぐに壊れてしまう可能性があります。 私はこれらのサイトの責任を負いませんが、数十のクライアントが壊れたサイトで一度に電話をかけているときに、私が以前働いていた代理店で何が起こるのでしょうか。 それはその小さな代理店、彼らの日々の仕事、彼らの収益にどのように影響しますか？ それは彼らのクライアントにどのように影響しますか？ これらは私の懸念事項であり、私はこの比較的大規模なエコシステムのほんの小さな（比喩的に）開発者です。

私たち（少なくとも私）が私のコメントを否定することがあることを認めます。これについてお詫び申し上げます。

人々は心配し、イライラし、グーテンベルクに取り組んでいるチームはメタボックスがどのように使用されているかについてほとんど理解しておらず、影響がどうなるかについてほとんど懸念していないという認識があるため、そうする権利があるように思われます。何があっても彼らのビジョンを前進させようとしています。

これを書くのは悲しいことですが、100万年後にはWordPressで大規模なプロジェクトを今すぐ始めることを提案することはありません。

2-グーテンベルクはコンテンツ領域のみを置き換えます：プラグインの90％が機能し、UXが苦しんでいます

@ youknowriad 、UXがGutenberg対TinyMCEで苦しんでいないとどうして言えますか？ 私は本当にその質問をしているのであって、嘲笑しているのではありません。 TinyMCEやメタボックスと比較して、グーテンベルクではUXが実際に大きな打撃を受けていると言えます。 私はあなたがこれをあなた自身のために見つけることを勧めます：

（1）マウスのプラグを抜きます。
（2）Mackを使用している場合は、command + f5を押して、VoiceOverを使用して生産的な作業を実行してみてください。
（3）PCを使用している場合は、NVDAをダウンロードしてインストールし、マウスのプラグを抜いて、同じテストを実行します。 そのような状況では、グーテンベルクで何か生産的なことをしてみてください。

現時点では、UXは絶対的な悪夢であることがわかると思います。 それはそれがより良く変わることができないということではありません。 グーテンベルクは、WordPressがアクセシビリティに関する多くの技術的負債を解消する機会を提供します。これを注意深く正しく行うと、いくつかの大きな成果を上げることができます。 しかし、これが誤ってまたは不注意に行われた場合、WordPressアクセシビリティチームおよび他の主要な貢献者が2012年以降に行った多くの作業を再開する必要があります。 WordPressを、当初と同じ過ちを犯さないプロジェクトとして見たいと思います。最初からWebアクセシビリティを考慮していません。つまり、アクセシビリティチームやその他の関係する貢献者は、事後にアクセシビリティを強化していることに気づきました。これはタスクです。 WordPressは停滞したコードベースではないため、これに追いつくことはできません。

皆さんはグーテンベルクに1年間取り組んできたと思います。 また、これに取り組むこと自体が困難であり、否定的なフィードバックはその状況を助けないこともわかります。 最後に、私たちと同じくらい批判的である私たちの人々は、あなたの赤ちゃんを醜いと呼んでいるか、単に変化への恐れに反応しているように見えるかもしれません、そして創造者として、それはせいぜいイライラし、最悪の場合は傷つきます。 しかし、私自身のために言えば、赤ちゃんは醜いではありません。 それは、ブロックで最もクールな子供になるか、すべての人の人生を悲惨にする小さなジャークになる可能性がたくさんあります。 前者であり、後者ではないことを望んでいます。 特にメタボックスに関しては、WordPressカスタム開発の文字通りの定番であり、おそらくショートコードやTinyMCEボタンよりも重要です。 それらを取り除く方法がわかるまで、軽くはがしたり、iframeに押し込んだりしないでください。

WordPressに関する私の簡単な話は、10年以上の間、個人、中小企業、および企業の顧客向けのWebサイトを作成するために選択したWebサイトエンジンであるということです。 その時、WordPressを選択したツールにした3つのことがありました：

1. オープンソース。 この聴衆は、これがどれほど強力で有利であるかについて同意できると思います。
2. 使いやすさ。 WordPressにより、開発者以外の人がコンテンツを驚くほど簡単に作成および更新できるようになりました。 これは、個人や企業向けのWebサイトを作成した初期の頃は非常に大きなものでした。
3. コンテンツの定義。 カスタム投稿タイプ、カスタム分類法、およびカスタムメタボックス。 これらに至るまでのすべてが特異点に達したとき、WordPressが単なるブログソフトウェア以上のものとしてビジネスコミュニティに「販売可能」だったと言っても、私は到達していないと思います。 （WordCamp Phoenix 2012-CMB。投稿タイプ、分類法、メタボックスの定義に関するJustin Tadlockの優れた執筆。）

私は、カスタムメタボックスと言っても過言ではありません。カスタム管理インターフェイスを作成し、人々に優れたユーザーエクスペリエンスを提供するこの機能は、非常に大きなものです。 それを破ると、WordPressを破ることになります。

グーテンベルクの背後にあるアイデアは、コンテンツエディターのエクスペリエンスをより強力にするという素晴らしいアイデアです。 やる価値はありますが、急いではなく、注意して正しく行う必要があります。 今、それは非常に急いでいて、どこにも準備ができていないように感じます。

@jchristopherはそれを非常によく言います：

私はグーテンベルクがユーザーエクスペリエンスを向上させるという目標を完全に支持していますが、コンテンツ編集にメタボックスを使用するために（意図的かどうかにかかわらず）導入された先例を避けることはできないと思います。 Yoastのアプローチは素晴らしいと思います。これは、この問題に対するさまざまな潜在的な解決策について、いくつかのチェックボックスをオンにするものです。

@jnicolと@auroobaは素晴らしいポイントを作り、良い質問をします。 反復的なロードマップではなく、すべてまたはまったくないように見えるのはなぜですか？ Yoastの代替案は、これまでに見られたものよりもはるかに賢明であり、「iframe実験」がその点を証明していると思います。 @amandarush 、アクセシビリティの問題を指摘してくれてありがとう。 私は、グーテンベルクが概説した方法でグーテンベルクと一緒に仕事をするようにみんなに挑戦します。 それはいくつかの見方を変えるかもしれません。

@aaronjorbinは以前に言った、誰かがWordPressを採用するとき、彼らはWordPress（バージョン番号-ここ）を採用しておらず、全体としてWordPressを採用している。

それの別のバージョンがあります、それはクライアントサービスの誰もがおそらく頻繁に聞くでしょう。 誰かがあなたのところに来て、新しいWebサイトが必要だと言ったとき（ブログについては話していません）、通常、「新しいWordpress Webサイトが必要です」、「新しいDrupalサイトが必要です」などとは言いません。彼らはただ、うまく機能し、うまく機能する新しいサイトを望んでいます。

WordPressは、何百万ものWebサイトにとって最良のソリューションでした。使いやすさとオープンソースが重要です。 新しいエディターインターフェイスの急いでの実装でカスタムメタボックスを壊すと（プラグイン番号を忘れて、カスタム管理UIを備えた既存のすべてのWebサイトはどうですか？）、使いやすさが損なわれます。

WordPress全体（コアとコミュニティ）のために可能な限り最善の方法を考えて一年を費やした単純な開発者としての私の忍耐力は限界に近づいています。

私はここで率直になります：

これとこのような他のいくつかのコメントは、あなた方の何人かがこのプロジェクトにおける意思決定の役割から離れるべきだと私に思わせます。 製品について正直でよく考えられているが批判的なフィードバックを受け取ることができない場合は、率直に言って、製品チームで意思決定の役割を担うべきではありません。 私は何度もあなたの立場に立っており、通常は対面の会議で、成功した場合、部屋の全員が、議論がどれほど熱くても、顧客に可能な限り最高の製品を提供することであることに気づきました。 製品のアイデアや方向性について批判することは、製品チームの意思決定者になることの一部であり、すべてを行うための最善の方法を誰も考えられないため、より良い製品につながるはずです。 それはチームにも当てはまります。

コアチームの全員が素晴らしいWordPressのリビジョンを提供したいと思っていることは間違いありませんが、必然的にプロジェクトに近づくことになります。 あなたは何が議論され、検討され、拒絶されたかなどを知っており、外部の視点から物事を引き上げて見るのは難しいです。 しかし、あなたはWPコミュニティの全体ではありません。 あなたはすることはできません。 あなたが聞いていることは、製品の方向性についての正当な懸念です。 それを受け入れることができない場合は、何が言われているのか、なぜ言われているのかを考えてください。グーテンベルクの方向性についての決定から離れてください。

あるいは（そしてこれははるかに良いでしょう）、これらの考えを取り入れてください。 人々が言っ​​ていることを真に考えてください。 WordPressを使用するビジネスを運営する人々としての私たちの懸念を理解し、私たちが自分自身だけでなくクライアントにも関心を持っていることを理解してください。

私は2008年の初めからWPを使用していますが、現在の形でのグーテンベルクの導入ほど多くの分裂を生み出した新しい機能や決定は考えられません。

WordPressはユーザーを対象としていますが、これは単なるツールであり、目標の達成を支援するWPの専門家がいない場合、ユーザーはそのツールを利用できません。

新規インストールのユーザーに対応したいという言及がありますが（何ですか？Webの年間増加率は約1％ですか？）、既存のユーザーベース（約28％）を犠牲にしているようです。その大部分は、少なくとも1つのメタボックスを持つプラグインを実行している可能性があります。 それはどんな規模でもビジネスセンスが悪いようです。

私はイデオロギーを理解しています。ベストケースのエディターを作成し、アダプターパターンを使用して古いものから新しいものへの会話を始めます。 問題は、PHPとJSは異なるテクノロジーであり、その問題をHTML iframeの世界に伝えることは、前述のすべての理由から実行可能ではないということです。

それは最初のパスであり、実験でしたが、この努力は成功していません。 承認が早ければ早いほど、次の提案にすばやく進むことができます。

しかし、すべての関係者を満足させるメタボックスの場合に関しては、誰も適切な解決策を考え出していません。

つまり、一方の当事者は容赦する必要があります。それが10〜50人のプログーテンベルク開発者なのか、それとも「怖い」開発者なのか、ユーザーはもちろんのこと、変更が彼らに与える影響なのかはわかります。

すべての回避策の提案が尽きると、おそらく、ページ全体をオーバーライドすることはすべての関係者にとって実行可能ではないという譲歩があります。 少なくとも、現在試みられているシングルヒットではそうではありません。

元の質問に戻ります-iframeはメタボックスの長期的な解決策ですか？ 複数の開発者（そして忘れないでください、彼らもユーザーです）は、答えがノーである理由を説明しています。

ここでは、主に建設的な議論を行ってきました。 覚えておいてください：

私たちはアイデア、コード、ピクセルを批判しますが、その背後にいる人間は批判しません。 今後の最善の道については異なる意見があるかもしれませんが、資格情報については質問しません。 私たちが個人に話しかけるとき、それは彼らを持ち上げて、よくやった仕事の功績を認めることです。 世界でたくさんのことが起こっているので、私たちはお互いに気を配らなければなりません。 これは途方もない挑戦ですが、私たちは一緒にそこに着きます。

グーテンベルクのメタボックスは、@ BE-Webdesignがステップアップしてこれを実行した結果であり、他の誰からもほとんど助けを借りずに、どこからともなく現れたことを思い出させてください。 @ BE-Webdesignがなかったら、グーテンベルクにはメタボックスはありませんでした。 ここに残された47のコメントのうち、レビューとUXの目的で実際にメタボックスコードに触れたのはおそらく2人だけでした。

ただし、ここでの基本的な問題は、安全でないコードを作成せずに、メタボックスを一級市民としてページに安全に配置する方法です。これにより、ハッキーな応急修理や落とし穴のトレードオフが発生します。

• 最初の反復には落とし穴があり、WPにedit.phpページにあるふりをさせ、その方法でメタボックスを生成しました。 初期の報告によると、互換性の問題があり、非常にハッキーであり、実行可能な解決策ではありませんでした。 これは、多くのプラグインは、特定の状況が満たされた場合にのみメタボックスを登録し、WPがそれらをいつレンダリングするかを信頼しないためです。
• マージされた2番目の反復はiframeを使用するため、メタボックス以外はすべて削除されていますが、メタボックスはクラシックエディターに表示されます。 これは少し厄介ですが、問題はありますが、メタボックスが機能するようになりました
• HTMLコードをフェッチし、それをコンポーネントに大規模に挿入するソリューションもあります。これは、非常に明白なソリューションであるにもかかわらず、セキュリティの大惨事になります。 したがって、なぜそれがこのように行われなかったのか。

私の提案は次のとおりです。

設定ページでグーテンベルクをロードする代わりに、メインのクラシックエディターページにロードし、ネイティブ環境でメタボックスをロードしてから、JSを介してコンテナーDOMノードをコンポーネントに持ち上げます。

次に、別の種類のトグルを使用して、クラシックエディターを引き続き使用できることを確認します。 こちらです：

• iframeのナンセンスを避けます
• メタボックスは、登録に関する限り、いつものように機能します
• 既存のJSは期待どおりに機能し、PHP側で機能させるためにハックは必要ありません

また、ヨーストのデザインはきれいですが、ブロックメタはどこに行きますか？

残念ながら、実際のコードをグーテンベルクに提供するために必要なレベルのjsの経験はほとんどありません。 私はWordPressの上に開発するのではなく、WordPressを開発する世界に足を踏み入れ始めたばかりです。 ですから、私にできる最善のことは、フィードバックを提供し、エディターをテストし（私は個人のブログでグーテンベルクを積極的に使用しています）、提案や考えを提供することです。 私がコードを提供することができれば、絶対にそうします。 私が助けることができる別の方法があれば、私は知りたいです。 私はこれをとても気にかけているからです。 :)

貢献にはさまざまな形があります。 この試みの開発に費やされた時間と労力は高く評価されていますが、将来の埋没費用を防ぐためのテストと議論も同様に価値があります。 たとえば、iframeの実装に関連して新たに開かれた問題がいくつかあります。 これらの問題の修正にさらに多くの時間を費やすか、このスレッドのテストと理論的根拠を使用して、別の方向性が必要かどうかを判断することができます。 それが私たちがグループとして到達した認識だといいのですが。

グーテンベルクのメタボックスは、@ BE-Webdesignがステップアップしてこれを実行した結果であり、他の誰からもほとんど助けを借りずに、どこからともなく現れたことを思い出させてください。 @ BE-Webdesignがなかったら、グーテンベルクにはメタボックスはありませんでした。

賞賛と崇拝は素晴らしいですが😄、私は間違いなく助けを借りました、そしてそれは主に多くの人々からのチームの努力です。

私の提案は次のとおりです。

設定ページでグーテンベルクをロードする代わりに、メインのクラシックエディターページにロードし、ネイティブ環境でメタボックスをロードしてから、JSを介してコンテナーDOMノードをコンポーネントに持ち上げます。

はい、これはおそらく次の反復であり、これは素晴らしい提案であり、建設的なアイデアでもあると思います。 これをきれいに行う方法はまだ100％わかりませんが、iframeを使用せず、グーテンベルクがすでに提供しているのと同じ改善されたUXを使用することは完全に可能です。 メタボックスのエクスペリエンスを改善するためのアップデートが予定されており、iframeの削除が含まれる可能性があります。 iframeメソッドは、メタボックスのサポートを実装する方法を確認する方法として機能しました。現在、より良い改善が行われる予定です。 何ヶ月も前にメタボックスで物事が最初に調査されていたとき（新しいトピックではありません）、当時のグーテンベルクの状態のため、iframeアプローチを進めることは理にかなっています。現在、それはマージされ、他の多くの部分が移動しています。技術的な観点から、iframeの使用はおそらくもはや必要ありません。 さらに作業を行う必要があります。

@ BE-Webdesignあなたの努力とここへの入力に感謝します。 これを閉じて、そのアプローチについて話し合う準備ができたら、新しい問題を始めましょう。

後でではなく、今すぐ停止して再評価してください

誰もがプロジェクト設計へのこのアプローチに慣れているわけではありませんが、これはほとんどすべての継続的な毎日の再評価に続くプロジェクトです。 元のモックアップを現在のエディターと比較します。 物事は変わります。 ほとんどの作品は石に設定されていません。 何かがうまくいくかどうかを真に評価する唯一の方法は、実際にそれを行うことです。 誰もが同じように製品設計に取り組むわけではありませんが、グーテンベルクの急速な反復は、未知のものを事前にハッシュしようとするのではなく、うまく機能していると思います。

議論してくれてありがとう。 トピックの問題の最後に再び焦点を当てた会話をうれしく思います：_iframe内のメタボックスへの現在のアプローチは実行可能ですか？ 答えはノーです。 iframeは実装の詳細であり、比較的簡単に削除できると思います。 それでは、それに焦点を当てましょう。

いくつかの結論として、編集画面について何も変更しないことが、私たちにとって最も簡単な方法であることを付け加えたいと思います。 また、プロジェクトの目標やWordPressの長期ユーザーにとっても公平ではありません。 一部の人々が実用的なアプローチと呼んでいることは、このプロジェクトが最初から持っていた設計の方向性（完全なサイトのカスタマイズに向けて）、およびこれまでの決定を決定したものと一致していません。 ここでは最終的な解決策である必要はありません。私たちは設計施設内で何が可能かを調査し、テストのためにそこに出します。 これは私たちだけで構築することはできません。克服すべき困難な問題がいくつかあるため、皆様からのあらゆる支援を心から歓迎します。

WordPressは常にユーザーと一緒に移動し、既存のコードの移行を容易にするために開発パスを把握する責任を負います。 プロジェクトとして、WordPressからのメタボックスのサポートを終了するのではなく、新しいパラダイム内で行う必要のあるインターフェイスの決定を調査する必要があることも前に述べました。これには、クラシックエディターをロードする可能性も含まれます。処理できないメタボックス、またはコンテンツとは何か、メタデータとは何かをより明確に描写しようとするエディターと直接競合するメタボックスを検出します。 現在、デフォルトのグーテンベルク体験の恩恵を受けることができる人々がいます。 開発者として、私たちはソリューションを製造できるという特権を持っていますが、そうでなければ苦労する人々がオープンウェブ上に存在できるようにするために必要な変更を回避しない責任もあります。

@mtias私はあなたの賢明なコメント、特に「WordPressは常にユーザーと一緒に動く」についての部分に心から感謝します。

残念ながら、それは@youknowriadがこのスレッドで通信していることと完全に対立しています。あなたは両方ともAutomatticで働いているので、製品の方向性について彼に話すことをお勧めします。

残念ながら、既存のメタボックスとの互換性を保ちながら、グーテンベルクのすべての柔軟性を提供する提案されたYoastスケッチに対処しませんでした。 なぜあなたがこのアプローチを検討していないのか誰かが認められないのですか？

残念ながら、それは@youknowriadがこのスレッドで通信していることと完全に対立しています

あなたは私が言ったことを誤解したと思います、私はただ事実を列挙していました、そして私は@mtiasの考えを100％共有します

@mtias

一部の人々が実用的なアプローチと呼んでいることは、このプロジェクトが最初から持っていた設計の方向性とは一致していません—完全なサイトのカスタマイズに向かっています

私はこの見方に本当に同意しません。 エディター自体に制約されているが、メタボックスを置き換える力を備えた反復的な拡張を行うこと、およびフィールドAPIをリリースおよびプロモートすることは、プラグインの大部分をブロックパラダイムに簡単に移行するためのスムーズな方法です。 、現在の破壊された風景と比較して。

その中間的な移行をスムーズに行うことで、post_edit画面での直接DOMの生成/操作を非推奨にすることがはるかに簡単になります。それまでに、標準の実際のソリューションではそのような操作が不要になるためです。 「直接のDOM操作は永遠に主要な経験である必要がある」と誰も言っているとは思いません。 彼らは「それが今の主要な解決策である」と言っています。

フルスクリーンソリューションでDOM操作の完全な柔軟性を維持できる場合は、それを選択してください...しかし、それは非常に高い目標のようであり、従来の編集画面からの巻き上げの形式が実際に実現できるとは思えません。妥当なレベルの互換性。 おそらく私は間違っていますが、より反復的なアプローチで同じ仕事をすることができる場合、ユーザーを移行しようとするのは非常に複雑なハックのようです。

現在のパラダイムの優位性を維持しながら、新しいパラダイムをリリースすることで、現在の経験を損なうことなく採用を促進します。 次に、ほとんどのワークフローがブロックパラダイムに移行すると、フルスクリーンソリューションを優先して、直接DOM制御を廃止することができます。

プロジェクトの目標を裏切ることはなく、リリーススケジュールに対処して、何千もの機関や開発者が変更を管理しやすくするだけです。

@youknowriad私が言っていることをサポートするために、あなたが書いたもののスニペットをいくつか投稿しましょう。

REST API、クライアント側UIを活用し、コアコンセプト（ウィジェット、ショートコード、ブロック、コンテンツメタボックス）を独自のコンセプト「Aブロック」で統合する

「コンテンツメタボックス」をブロックに変換するように依頼した人は誰もいませんでした。グーテンベルクが最初のバージョンを出荷するまで、それは伝達されませんでした。 実際、これが議論の核心です。 メタボックスはページコンテンツではないことが非常に多いというだけで、他の人が言ったことを繰り返すことはしません。

あなたがあちこちで読んだものとは異なり、焦点は常にページ全体の再設計にありました。グーテンベルク編集者ページの最初のモックアップは、2回目または3回目の毎週のグーテンベルク会議で示されました。 私たちはまだプロトタイピングの段階にありました。

グーテンベルクのチームは、スケッチは見せるだけのものであり、最終的なデザインではないと言い続けました。 さらに、スケッチでは、編集画面全体がReactに変換されているのか、スタイルが異なるだけなのかを示すことはできません。 ページ全体が再設計されるという事実は、私が話をしたすべての人にとって大きな驚きでした。

ショートコード、TinyMCEボタン、メタボックスの違いは何ですか？
主な違いは、「メタボックス」には「目的」がないことです。これは、一貫性のないエディターページを拡張する方法であり、ShortcodesボタンとTinyMCEボタンには一貫性があります。

これは、Automattic内で眉をひそめるはずの巨大な誤解です。 （そして、 @ mtiasと@mが聞いていることを願っています）。 それは単に真実ではなく、私はこの声明に続くあなたの判断に本当に疑問を投げかけます。

WordPressの長期にわたって、メタボックスは（グーテンベルクに関係なく）その進化をロックしていると結論付けることができますか？
はい、そうです。

ここではほとんど誰もあなたに同意しないと思いますが、Automatticは製品の方向性を決定するためにこれを投票する必要があると思います。

また、 @ mtiasに質問して、貢献する必要のある人のようなことを言っています。 Automatticに関連するグーテンベルクチームが1インチも出ていないことは明らかであり、すべての批判をそらしています。

私は文字通り、グーテンベルクを単なる編集コンポーネントに減らすためにPRを行うとしたら、Automattic内の数人の個人の発言により、グーテンベルクチームによって検討されるとは信じていません。

@mtias 、

いくつかの結論として、編集画面について何も変更しないことが、私たちにとって最も簡単な方法であることを付け加えたいと思います。 また、プロジェクトの目標やWordPressの長期ユーザーにとっても公平ではありません。

一度に1つのステップを実行しても、プロジェクトの目標が損なわれることはありません。 それが目標であれば、フルサイズのカスタマイズに進むこともできますが、段階的に行うことで、残りの開発者コミュニティを連れて行くことができます。

カスタマイザーは、この典型的な例です。 はい、批評家もいますが、最終的なコンセプトは、特定のユーザーグループがサイトを管理するためのツールとしてWPを効率的に利用できるようにする機能として、時間の経過とともに実現されます。

現在、デフォルトのグーテンベルク体験の恩恵を受けることができる人々がいます。

絶対に。 しかし、現在、デフォルトのグーテンベルクで有害な経験をする人はかなり多くいます。

私たちは皆、敬意を持って前進し、私たちの応答で人々を製品から切り離すことができることを願っています。 情熱は素晴らしいですが、私たちがこのようなスレッドで対話している人間について考えることが重要です。 このプロジェクトに関係するすべての人が気にかけます。そうしなければ、これらのスレッドに参加して対話することはありません。 さて、息を呑んで、私たち全員がWordPressをどれだけ気にかけているかを思い出し、コメントの中心にこのコミュニティを安全で、すべての人にとって生産的に保ちたいと思っています。

@khromov 、このプロジェクトのデザインリーダーとして、Matiasが技術リーダーであるように、私は@youknowriadの100％後ろに立っています。 あなたは情熱的だと思いますが、敬意を払っていません。 一人の人を呼んで、あなたが取っているアプローチを調整してください。 個人的なことはやめましょう。

グーテンベルクで働いている人々の多くは、以前はWordPressコミュニティのメンバーであり、以前は（今でも）主要な貢献者であったことを覚えておくことも重要です。 はい、それは私を含みます。 私はここで非常に個人的な話をします。PRを行ったら私に通知してください。レビューがどこから来たとしても、すべてのレビューが同じように尊重されていることを確認します。 どうか、このプロジェクトを「私たち対彼ら」のプロジェクトとして見ることから先に進みましょう。 そうではなく、ここにはAutomattic以外の驚くべき貢献者がいますが、その声明は彼らに不利益をもたらします。

@khromov

私の投稿やコメントはアプローチと実装で見た問題を強調しているため、私は一般的にグーテンベルクを批判していると見なされていますが、グーテンベルクの目標と進捗状況は、誤解や理解の欠如のためにコメントで誤解されることがあると感じていますプロジェクトの包括的な目標。

ブロックは、投稿コンテンツを視覚的に表現および編集する方法ではありません。また、コンテンツピッカーメニューの一部である必要も、ドラッグ/ドロップ可能である必要もありません。 もちろん、それらはそれらのことに使用できます。それは、グーテンベルクの目に見える部分の多くが強調しているワークフローです。 ただし、そのパラダイムについて知っていることはしばらく無視し、代わりに次のように見てください。

ブロックは、インターフェイスやストレージに関係なく、サイトの基本的な制御構造となることを目的としています。

• ウィジェットはブロックになる予定です。 これは、それらがエディターに存在し、post_contentに保存されることを意味するものではありません。 これは、JavaScriptフレームワークに組み込まれたシステムと、単一の共通APIを使用して制御されることを意味します。
• カスタマイザーはブロックに置き換えられる予定です。 インターフェースはおそらく（ほぼ）同じままですが、カスタマイザーのセクションは同じAPIによって制御されます。
• プラグインページ、テーマエディター、ダッシュボード自体はすべて、最終的にブロックになる予定です。 これらのセクションのアイデアがそのままでは、一般的なAPIで再作成されることを想像できない場合は、WordPressの用語で、ブロックとは何かに関連する誤解がある可能性があります。

問題は、メタボックスをブロックパラダイム内で再作成できないことではありません。実際、プログラムで投稿タイプに追加され、所定の位置にロックされ、post_contentではなくpost-metaに保存される非フロントエンドブロックが予定されています。 WordPress 5.0リリース（間違っている場合は訂正してください）。

本質的に、それはテキストボックスや選択のような些細なメタフィールドのすべてのニーズをカバーします。 必要に応じて、そのインターフェイスをブロックで正確に複製することも、供給をブロックする新しい視覚言語に基づいて、その一部を合理化することもできます...それは完全にあなたの呼び出しです。

問題は、メタボックスがブロックになることができないということではありません。 問題は、現在、メタボックスで作成されたインターフェースがあり、ブロックでまだサポートされていないことです（WordPressまたはサードパーティのいずれかによって）。特にこれらのツールが構築されていないため、その作業を再実装することは開発者にとって非常に困難な作業です。提案されたFieldsAPIのような一般的なAPIからですが、ページのDOMを直接変更し、アドホックで管理されていない方法でリソースをキューに入れるホッジポッド方式です。

この現在の状態は、開発者にとっても問題を引き起こします。 たとえば、フィールドにPiklistとともにVisual Composerを使用すると、Piklistは多くの管理スタイルを上書きするため、VCのナビゲートが非常に困難になります。

または、新しいバージョンのSelect2ライブラリをエンキューするプラグインと一緒にWooCommerceを使用している場合、どちらか一方が管理インターフェイスを壊し、重大なJSエラーが発生します。

2つの異なるプラグインが異なるバージョンのCMB2フレームワークに依存している場合も、同じことが起こる可能性があります。

ブロックは、さまざまなページの追加に関する共通のフレームワークを導入することにより、これらの問題を解決することを目的としています。 このフレームワークの一部は、編集者にwiz-bangドラッグアンドドロップの視覚的なものを提供することに焦点を当てていますが、大部分は実際にはそれに結び付けられていません。 adminに表示されるものが一般的な方法で管理されていることを確認しているだけです。

さて、WordPressがWild Westの開発者の態度で繁栄し、この共通のフレームワークが反応を知らない開発者の参入障壁を高めるという正当な議論があります。 そして、ブロックインターフェースはリリース前に広く普及している開発者の採用に近いものには到達しないという有効な議論があります。 現在のブロックAPIは少しナイーブであり、多くの一般的なワークフローを考慮していないため、これらの機能が作成されて文書化されるまでプラグインを適応させることができないという有効な議論もあります。

しかし、Metaboxはそのままで、すべてを網羅するソリューションであり、永遠に保存する必要があると主張しても、誰にとっても素晴らしい道はありません。 WordPressがすべてのユーザー（開発者を含む）に優れたオプションを提供できるようにするには、ある種の共通システムが存在する必要があります。

このシステムが数年前に一般的なFieldsAPIであったとしたら、これらの変更はすべて、ほとんどの場合、そのAPIのレンダリング手順の代わりになりますが、現状では、今後の道筋を見つける必要があります。

とはいえ、最終的な共通UIに移行するための最良の現実的な方法であるとして、私は依然としてYoastが提案する暫定ソリューションに強く賛成しています。 もちろん、私は批判的であり続けますが、誤解ではなく、事実に批判的であることを確認したいと思います。

残念ながら、それは@youknowriadがこのスレッドで通信していることと完全に対立しています。あなたは両方ともAutomatticで働いているので、製品の方向性について彼に話すことをお勧めします。

ここではほとんど誰もあなたに同意しないと思いますが、Automatticは製品の方向性を決定するためにこれを投票する必要があると思います。

Automatticに関連するグーテンベルクチームが1インチも出ていないことは明らかであり、すべての批判をそらしています。

私は文字通り、グーテンベルクを単なる編集コンポーネントに減らすためにPRを行うとしたら、Automattic内の数人の個人の発言により、グーテンベルクチームによって検討されるとは信じていません。

当たり前のことを述べたいと思いますが、

AutomatticはWordPressを「リリース」または「ビルド」せず、GutenbergはAutomattic製品ではありません

さらに、この会話がさらに感情的になり、人々が木々のために森を見失う前に、グーテンベルクチームに割り当てられたタスクの難しさと、彼らがそれをどれだけうまく処理しているかを時間をかけて理解したいと思います。一般に。 彼らは、インターフェースの1つの小さなコーナーでのみその有効性を実証できる制約の範囲内で、WordPressの管理エクスペリエンス全体の基礎となるパラダイムを作成する任務を負っています。

「編集者が引き継ぐ」という考えによって引き起こされる誤解の量は計り知れず、管理するのは非常に難しいに違いありません。 彼らの目的は、WordPressの管理者向けの共通の構成要素を作成し、エディターを再構築してそれらをテストすることです。 wp_editor()インターフェースを再構築し、そこから拡張するだけであれば、このタスクは一般の人々にとってはるかに口当たりが良く、柔軟性があると思いますが、「編集エクスペリエンス」の接続されたすべてのコンポーネントが提案された新しいパラダイムのより完全な試行。

私は理解し、この仕事に費やされた努力の年に感謝します。 私はまだいくつかの決定に批判的であり、最初の採用を大幅に改善するいくつかの変更を加える時間があると信じていますが、最終的にWordPress管理エクスペリエンスのためのより構造化されたフレームワークを提供するという包括的な目標に完全に同意します、開発者とユーザーの両方。

@karmatosed

私が@youknowriadに言及した理由は、彼だけが議論に参加したからです。 開発者側からの明確なコンセンサスがあるにもかかわらず、何百人もの開発者と何千時間も前進せずに関与した議論。 たとえ特定の人を呼ぶことを伴うとしても、開発者の小さなグループによって下された決定の正当性を疑うことは失礼ではないと思います。

とにかく、私は@youknowriadとプライベートチャットをし外部に伝えられているものより賢明に聞こえます。

@tomjn

私は敬意を表して反対します。 重要な決定はAutomatticiansによって行われ、 @ youknowriadとの

@gschoppeこの「パラダイムシフト」がオープンに議論され、開発者コミュニティと協力して行われたことを願っています。 それが意図かもしれませんが、その場合、コミュニケーション側はあまりうまく機能していません。

なぜあなたがこのアプローチを検討していないのか誰かが認められないのですか？

@khromovはすでにあり、エディターチャットなどの他の場所にもありました。この問題は特にiframeの実装に関するものでした。

私は文字通り、グーテンベルクを単なる編集コンポーネントに減らすためにPRを行うとしたら、Automattic内の数人の個人の発言により、グーテンベルクチームによって検討されるとは信じていません。

どういたしまして。 私たちはそれを非常に早い段階で自分たちで考えました。それは制限が多すぎて、私たちが持っていたビジョンを推進するには適切ではないと考えていました。 それでも多くの人にとって妥当な妥協案であり、探索するのに適したプラグインになる可能性があります。 しかし、それを実現するために必要な作業は、グーテンベルクをより再利用可能にすることで一般的に改善するので、私はそれに取り組んでいる人々に反対しません。 誰かがそのようなPRに取り組んだ場合、私はおそらく、それをデフォルトにするのではなく、動作を切り替えるために書き込みセクションに設定を追加することをお勧めします。

ネストされたブロック、グローバルブロック、ブロックテンプレート、列の宣言などに関連する重要な機能があります。これらの機能は、コンテンツシートがページ全体であるというメリットがあり、それ以外の場合はかなり質が悪く、開発者が実行できることとユーザーが体験できることを制限します。 TinyMCEの単なる置き換えで考案される、フルスクリーンエディタにシームレスかつリアルタイムで統合されるドキュメントアウトラインのような優れたツールもあります。

一度に一歩進んでも、プロジェクトの目標が損なわれることはありません。

間違いなく！ マットの元の新しいフォーカスポストから段階的なアプローチを提案しましたが、それはステップを異なる方法で検討するだけです。 グーテンベルクプロジェクトには、一般に、投稿エディタからページテンプレート、サイト構築までの3つの段階があります。 根本的なことは、パラダイムは、コンテンツが単一の領域であり、_block_を主要な概念とし、結果を明確に、過度の抽象化なしに視覚的に表現できるものであるということです。

絶対に。 しかし、現在、デフォルトのグーテンベルクで有害な経験をする人はかなり多くいます。

もちろん、それが両方とも現在のエクスペリエンスに自由に戻るためのプラグインがある理由です。また、非互換性を処理するメカニズムがあり、より多くのものをオプトインできるようになります（メタボックスに慣れている場合など）グーテンベルクでそれを支持することを宣言することができます、またはその逆）。

@gschoppe過去にかなりの意見の不一致があったことは承知していますが、ここでのコメントと、さまざまな観点から見てもいただきありがとうございます。 あなたはブロックの凝集因子についていくつかの良い点を述べています。 たぶんいつか私たちはトイレの会議で会い、テセウスの船のパラドックスについての楽しい哲学的議論に着手することができます。 知るか。 😉

Automatticのあなたは、私たちがあなたの仕事を尊重できないこと、そして私たちがあなたを大いに押し進めていることを不平を言うべきではありません。
7000から10.000€のプロ月給ではありません。 愚かな。 人々がWPTracについて開発者のボランティアに不平を言うのとは異なります。
グーテンベルクがあなたに頭痛の種を与えるなら、あなたの上司に話してください。 彼はあなたに不可能な仕事を与えました。

第二に、あなたはここでコメントした大多数の人々よりもはるかに優れたコーダーです。 なぜ「Iframes」ソリューションに合格しようとしたのですか？
私はあなたに言った、あなたは人々を子供のように扱う。 iframeを試してみて、人々が大いに悲鳴を上げ、非常に感情的になるかどうかを見てみましょう。 ノイズが多い場合は、iframeから離れます。

なぜ「Iframes」ソリューションに合格しようとしたのですか？
私はあなたに言った、あなたは人々を子供のように扱う。 iframeを試してみて、人々が大いに悲鳴を上げ、非常に感情的になるかどうかを見てみましょう。 ノイズが多い場合は、iframeから離れます。

メタボックスのサポートが最初に実装されたとき、新しいエディターはpost.phpではなく、まったく新しい管理ページに存在し、エディターのロードが異なり、一般に、iframeを使用してメタボックスの問題を解決することの一部である多くの制約がありました。もはや存在しないこれらの制約のうち、結果としてメタボックスは、おそらくiframeを使用する必要がなくなります。

このプロジェクトは、単一のリリースでの完全性よりも、リリース全体での段階的な改善を支持しています。 人々が悲鳴を上げるかどうかを誰も見ようとはしていません。 現実には、iframeアプローチは、人々がこれを実現したにもかかわらず、ほとんどのメタボックスでうまく機能しました。 今ではさらに改善され、ますます少なくなります😱🙀。

@StaggerLeeeは、どこで働いていても、このプロジェクトのすべての人に敬意を払ってください。 誰かにあなたを上手に扱ってもらいたいのと同じように、他の人にも同じことをしてください。

私はこのプロジェクトのデザインリーダーとして、あなたが誰かに言ったような個人的な声明を見ることはありません。 私は誰かがどこで働いているか、または彼らの背景のいずれかを気にしません、それはあなたが呼び出す権利がない個人的な詳細です。 個人をドロップして、製品に集中することに戻ってください。

それでは、次に進んで、可能な限り最高の製品を作ることに焦点を当てましょう。 私はあなたのポイントがしばしば情熱の場所から来ることを絶対に理解しています。 あなたは敬意と情熱を持つことができます、それであることに戻ってください。

Automatticのあなたは、私たちがあなたの仕事を尊重できないこと、そして私たちがあなたを大いに押し進めていることを不平を言うべきではありません。
7000から10.000€のプロ月給ではありません。 愚かな。 人々がWPTracについて開発者のボランティアに不平を言うのとは異なります。
グーテンベルクがあなたに頭痛の種を与えるなら、あなたの上司に話してください。 彼はあなたに不可能な仕事を与えました。

@StaggerLeeeたくさんのヒントが支払われたらいいのにと思います😂しかし、AutomatticはGoogleではなく、WPの世界の他の場所でもっと稼ぐことができます。 ここでの私自身の存在は、純粋に私自身の背中から離れています。私はここにいることで報酬を得ていません。また、他の多くの人々もこれに取り組んでいません。 私は実際にコードレビューを行い、エンタープライズクライアントの立ち上げを支援するために報酬を受け取っています！

したがって、メッセージが受信されたことを信頼してください。証拠は上部の[プルリクエスト]タブにあります。これは、コードを解読してクライアントをp **するAutomatticの陰謀ではありません（_忘れないでください、Automatticは有料のクライアントを持っていますメタボックスも使用する_）

まだiframeに

メタボックス実装の次の反復として、互換性の問題をテストして特定するのは良いことです。腐った果物をA8Cに向けて投げるのは気分が良いかもしれませんが、それは役に立ちません。