グーテンベルク開発チームは、メタボックスAPIが正式に非推奨にならないことを確認しました

公開: 2017-08-09

写真提供者：Doors Open Toronto 2008 –トロントアーカイブ–（ライセンス）

参加者が最新のマイルストーンからメタボックスのサポートが削除されることを懸念してGitHubの問題についてコメントした後、週末にグーテンベルクがメタボックスをどのように処理するかについての議論が熱くなりました。

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

プロジェクトの主任開発者の1人であるJamesNylenは、グーテンベルクチームがこの問題を忘れていないというトピックのフォロワーを安心させました。むしろ、「非常に複雑な問題であり、多くの人と一緒に調査を始めたばかりです。エディターをうまく機能させるための他の多くの優先事項。」彼はまた、メタボックスをサポートするための実装の計画とテストにおいてコミュニティに助けを求めました。

この反応は多くのことを不明確にした。ディスカッションの参加者は、すべてのメタボックスをReactコンポーネントとして書き直さなければならない可能性を懸念している開発者であり、なぜメタボックスが新しいGutenbergエディターと一緒に機能しないのか、チームがメタボックスをに含めることを選択したのか疑問に思っています。プロジェクトの範囲。

「メタボックスや既存のフックを含むインターフェイスの残りの部分を変更せずに、既存のTinyMCEポストエディターをGutenbergに置き換えることは可能ですか？」ケビンホフマンは尋ねた。 Nylenが、今日書かれているように、Gutenbergがpost_contentエディターになることを意図していることを明らかにしたとき、Hoffmanは、多くの開発者が表明した懸念を要約しました。

グーテンベルクが本当にpost_contentエディターになることを意図している場合、メタボックスはpost_contentに関係しないため、そのままにしておく必要があります。
さらに、PHPメタボックスをReactメタボックスに変換するためのAPIの必要性は、製造上の問題です。問題になる必要はありませんが、 post_contentエディターを書き直すことでメタボックスの動作も完全に変更する必要があると判断されたため、問題になっています。

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

グーテンベルクの寄稿者がメタボックスの問題を調査し始めたばかりであると共有したため、プロジェクトが「レガシー」PHPメタボックスをどのように処理するかについてのロードマップがない理由が明らかになりました。 7月、Nylenは次のように述べています。「ここで最終的にどこに到達するかを推測する必要がある場合：現在のメタボックスは「レガシー」領域に移動され、「新しいスタイル」のメタボックスブロックを登録するためのAPI、ドキュメント、および例を提供します-もの。」

メタボックスライブラリ、エージェンシー、およびその他の関係者を管理するプラグイン開発者は、GutenbergリリースとしてターゲットにされているWordPress5.0の計画方法を見つけるためにチケットをフォローしています。 Andrey Savchenkoは、WordPressがメタボックスAPIを正式に非推奨にする予定があるかどうかを尋ねました。これにより、チームから明確な回答が得られました。マティアスベンチュラは答えた：

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

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

Venturaは、チームがメタボックスを処理するために検討したいくつかのオプションをリストし、最良のソリューションを構築するためにコミュニティに支援を求めました。

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

メタボックスが新しいエディターのコンテキストに含まれる理由の質問に答えるように迫られたとき、グーテンベルクのデザインリーダーであるJoen Asmussenは、チームがプロジェクトの範囲にメタボックスを含めることをどのように決定したかを明らかにしました。

グーテンベルクは、エディターボックスから始めました。キックオフの目標は、単一の統合ブロックインターフェイスの下で複数の異なるインターフェイスを統合することでした。この統合されたブロックインターフェイスを中心に展開する魅力的なエクスペリエンスを作成するには、設定と公開を含む完全な書き込みフローを検討する必要があることがすぐに明らかになりました。
WordPressの主な強みが、誰でも簡単にリッチな投稿を作成できるようにすることである場合、エディターの使用方法をすでに知っている私たちのためだけにデザインすることはできません。これまでWordPressを使用したことがないユーザーと、最新のパブリッシングインターフェイスに期待することを考慮する必要があります。そうでなければ、すでに重いインターフェースに認知的負荷を加えるだけです。

メタボックスがグーテンベルクエディタのコンテキストにどのように適合するかという問題はまだ解決されていません。ディスカッションの参加者は、下位互換性のために、またグーテンベルクの開発と画面設計に関する進行中の決定に影響を与えるため、この質問に回答してもらいたいと考えています。

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

メタボックスAPIは非推奨ではありませんが、Gutenbergが「レガシー」PHPメタボックスをどのようにサポートするかについての明確な道筋もありません。グーテンベルクチームは、リソース不足のために問題は解決されていないと述べた。チームがWordPressサイトの大部分を最小限の破損でグーテンベルク時代にシームレスに導くソリューションに着手する場合、プロジェクトにはコミュニティの意見とより良いコミュニケーションが必要です。

現在、コンテンツの下にレガシーPHPメタボックスをレンダリングする可能性には課題があり、まだ議論の余地があります。開発者が作業をJS駆動型メタボックスに書き直すのに十分な時間またはクライアントリソースがない場合、レガシーの「PHP」メタボックスを保持する必要があるサイトでは、Gutenbergインターフェースをオプトアウトするための明確なパスが必要になる場合があります。。