WordPress 6.7 "post editor" iframing with meta boxes.

を置くことを試みた後ポストエディタが iframe された後メタフレームの存在はブロック条件となり、iframe内のエディタコンテンツの読み込みを妨げ、iframeのこれらの利点を利用できなくします：

• エディタUIからブロックとテーマのCSSを分離
• メディアクエリとビューポート関連のCSSユニットの正確さ

これらの利点は、エディタとフロントエンドでCSSの再利用をサポートし、ブロックとテーマの開発を簡素化するために重要です。メタフレームが存在するにもかかわらず、コミュニティメンバーは投稿エディタにメタフレームを導入することに取り組んできました。試み(までは定める メタボックスを投稿内容から分離するインターフェースの調整方法。

現在。スプリットビューの実装この変更はエディタコンテンツとメタボックスの同時表示をサポートします。この変更により、エディタとフロントエンドビューの間で一貫したWYSIWYGエクスペリエンスが保証されます。さらに、メタフレームを以前よりも使いやすくし、メタフレームを使用する際に投稿コンテンツの任意の部分を直感的に参照できるようにします。

iframeの残りの例外

現在、iframe が常に使用されることを防ぐ最後の条件は、どのブロックもそのapiVersion登録未満3.ただし、この条件も将来のリリースで削除される可能性があります。グーテンベルク プラグインとブロックベースのテーマがアクティブな場合、すでに例外が発生します。

エッジコンディションと互換性

メタフレームを追加するプラグイン開発者は、2つのことに注意する必要があります。第一に、メタフレームコンテナはオーバーフロー要素をクリップするようになったため、ポップアップ UI（ドロップダウンメニューなど）がメタフレームコンテナから上にはみ出した場合、それらは切断されます。ただし、コンテナの外側の DOM の一部にレンダリングされる場合は、問題になりません。次に、プラグインがリッチテキスト書式を追加し、編集UIがテキスト選択に固定されている場合、その実装はiframeと互換性がなければなりません。これは新しい要件ではありませんが、投稿エディタを拡張するだけのプラグインでは見落とされるかもしれません。

オーバーフロークリッピング

これが問題にならないようにするには、ポップアップウィンドウに似たUIをメタフレーム内で開くようにするか、ポップアップウィンドウをメタフレームコンテナ内ではないDOMの一部にレンダリングします。例えば、後者は and コンポーネントのデフォルトの回避策です。ポップオーバー属ドロップダウン使うドロップダウンメニュー彼らワードプレス/コンポーネントは、UIがメタフレームコンテナの上端からはみ出したとしても、UIが切り取られないようにします。

リッチテキスト形式のUIアンカー

プラグインがUIをアンカーしたり配置したりするカスタムコードを実装している場合、これは単に心配なだけかもしれません。プラグインがすでに使用アンカー出づワードプレス/リッチテキストをすべて変更すれば、問題なく動作するはずです。そうでない場合は、Gutenberg自身のリンクエディターUIコンポーネントの典型的な使用例をご覧ください。