グーテンベルクの貢献者は、メタボックスにiframeを使用する代わりの方法を模索しています

公開: 2017-11-08

グーテンベルクでのメタボックスへのiframeの使用を取り巻く議論は、関係する開発者がチームに現在のアプローチの不利益を検討するように求めたため、週末にさらに熱くなりました。グーテンベルクのリーダーシップからの反応は当初、懸念をそらし、iframeの実装を「今のところ」機能する実験として提示しましたが、チームが出荷するものではありません。

Kevin Hoffmanは、iframeアプローチのパフォーマンスとアクセシビリティに関する特定の懸念に対応する代わりに、メタボックスの将来と「ブロックに変換されないケース（ある場合）」について考えるように促されました。開発者コミュニティが繰り返しテストとフィードバックの提供を求められたが、WordPressをCMSとして使用しているサイトにとって重要な問題についての偏向に遭遇すると、GitHubの議論はさらに熱くなり始めます。

「人々は心配していて、イライラしています。グーテンベルクに取り組んでいるチームはメタボックスがどのように使用されているかについてほとんど理解しておらず、影響がどのようなものになるかについてほとんど懸念していないため、そうする権利があるように思われます。ジョンズホプキンスの外務局の主任開発者であるジミースムテック氏は、グーテンベルクの協力者がフィードバックを否定したことを認めたことに応えて、次のように述べています。

数回の開発者がスレッドに参加して、メタボックスのiframeが「今のところ機能する」という概念を覆した後、Gutenbergのリード開発者であるMatias Venturaが昨日ディスカッションに参加し、実験がかなり早く中止される可能性があることを確認しました。

「このトピックの問題に最後に焦点を合わせた会話ができてうれしいです。iframe内のメタボックスへの現在のアプローチは実行可能ですか？答えはノーです」とベンチュラは言いました。「iframeは実装の詳細であり、比較的簡単に削除できると思います。それでは、それに焦点を当てましょう。」

彼はまた、メタボックスのオーバーホールを進める前に、WordPressがエディター自体（ページ全体ではなく）を繰り返し拡張する必要があるという一般的な意見にも言及しました。

「一部の人々が実用的なアプローチと呼んでいることは、このプロジェクトが最初から持っていた設計の方向性（完全なサイトのカスタマイズに向けて）、およびこれまでの私たちの決定を決定づけたものと一致していません」とベンチュラは言いました。「ここでは最終的な解決策である必要はありません。私たちは設計施設内で何が可能かを調査し、テストのためにそこに置いています。」

ベンチュラ氏は、編集画面の他の側面に変更を加えないことは、グーテンベルクにとって確かに最も簡単な道であるが、「プロジェクトの目標とWordPressの長期ユーザーにとって公平ではない」と述べた。

WordPressの開発者であるGaryJonesは、より反復的なアプローチを追求してもプロジェクトの目標は変わらないが、プロセス中にさらに多くのサイトが参加できるようになると主張しました。

「一度に一歩進んでも、プロジェクトの目標が損なわれることはありません」とジョーンズ氏は述べています。「それが目標であれば、フルサイズのカスタマイズに進むこともできますが、段階的に行うことで、残りの開発者コミュニティを一緒に連れて行くことができます。」ジョーンズは、WordPress内の機能の例としてカスタマイザーを引用しました。この概念は、多くの反復で時間の経過とともに実現されています。

Venturaは、プロジェクトを反復するためのGutenbergチームのアプローチ、つまり最初からブロックベースのコンテンツ作成をサポートするパラダイムシフトについて説明しました。

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

Venturaはまた、プロジェクトがメタボックスのサポートを終了することはないが、さまざまなインターフェイスオプションを試すにはもっと時間が必要であることを、議論に沿ってフォローしている人々に保証しました。

「WordPressは常にユーザーと一緒に動きます。既存のコードの移行を容易にするために、開発パスを見つける責任を負います」と彼は言いました。「プロジェクトとして、WordPressからのメタボックスのサポートを終了するのではなく、クラシックエディターの読み込みの可能性など、新しいパラダイム内で行う必要のあるインターフェイスの決定を検討する必要があることも前に述べました。処理できないメタボックスを検出した場合、またはコンテンツとは何か、メタデータとは何かをより明確に描写しようとするエディターと直接競合する場合。」

彼はまた、チームが非互換性を処理するためのより多くのメカニズムを作成し、「より多くのものをオプトインできるようにすることを計画している」と述べました（たとえば、グーテンベルクに表示されるメタボックスに慣れている場合は、サポートを宣言できます。その逆も可能です。」

iframeを使用せずにメタボックスをレンダリングする新しいアプローチが現在進行中です。 Riad Benguellaは、iframeを元に戻して、TomNowellがディスカッション中に提供した提案を実装しようとするプルリクエストを作成しました。

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

次に、別の種類のトグルを使用して、クラシックエディタを引き続き使用できることを確認します。こちらです：
–iframeのナンセンスを回避します
–メタボックスは、登録に関する限り、いつものように機能します
–既存のJSは期待どおりに機能し、PHP側で機能させるためにハックは必要ありません

新しいアプローチには、リンク、モーダル、重複するスタイルシート、およびiframeを使用する際のその他の欠点に問題がないという利点があります。

グーテンベルクチームは新しいコミュニケーション戦略を必要としています

メタボックスにiframeを使用することの長期的な実行可能性に関する議論は、グーテンベルクのリード間の統一されたメッセージまたはコミュニケーション戦略の欠如を浮き彫りにしました。プロジェクトの共同作業者は、ビジョンを把握していないことでコミュニティに焦りを感じていますが、コミュニケーションはさまざまなブログ、コメント、Slackチャネル、GitHubディスカッションに散在しています。

Morten Rand-Hendriksenは、グーテンベルクの範囲、方向性、および目標のわかりやすい概要として機能できる一元化されたリソースを要求する新しい問題を開きました。

「私の観察では、この情報を含む単一の信頼できる平易な言語リソースがないため、コミュニティはグーテンベルクプロジェクトのより広い範囲を見るのに苦労しています」とランドヘンドリクセンは言いました。「これは、すべての関係者からの高度な憶測、誤解、およびフラストレーションを生み出し、結果としてプロジェクトは苦しみます。」

グーテンベルクにはドキュメントハブがありますが、これまでのところ、これらのドキュメントはより技術的であり、チームが目標の達成をどのように目指しているかについての実用的なロードマップがありません。現在のドキュメントのFAQセクションは、Rand-Hendriksenがチケットで要求しているプレーンランゲージリソースに最も近いものです。 GutenbergのGitHubリポジトリとWordPress.orgプラグインの両方のreadme.txtファイルは、プロジェクトが現在のエディターをブロックベースに更新しているだけで、エディター画面全体をオーバーホールしていないという印象を与えます。

「この情報は壊れているため、プロジェクト全体を明確に把握することは誰にとっても困難です。マティアスとマットの投稿はプロジェクトの壮大なビジョンをうまく説明していますが、具体的なわかりやすい言葉の内訳はありません。コミュニティがこのプロジェクトが何であるか、そしてそれがどこに向かっているのかをしっかりと理解するために必要な必需品」とランドヘンドリクセンは言いました。「それらは、プロジェクト自体のコア部分ではなく、プロジェクトを周回する情報の独立した衛星としても存在します。」

コミュニティは、GitHubの問題について、より透明性の高い平易な言語の製品ロードマップで回答してもらいたい質問に取り組んでいます。このようなドキュメントは、グーテンベルクチームがプロジェクトの目標をより適切に伝達し、不必要な混乱を引き起こす混合メッセージの送信を回避するのに役立つ可能性があります。