フルサイト編集はWordPress5.8になりますか？ 決定が近づいています
公開: 2021-04-09昨日、Josepha Haden Chomphosyは、フルサイト編集（FSE）をWordPress5.8に導入するかどうかを決定するためのロードマップを発表しました。 4月14日にGutenberg10.4がリリースされた後、コアリードの小グループがgo / no-goデモに参加します。
次の人が電話に出ます：
- Matias Ventura –デモを主催するグーテンベルクプロジェクトリーダー。
- Matt Mullenweg –WordPressプロジェクトリーダー。
- Helen Hou-Sandi –リード開発者。
- Josepha Haden Chomphosy –エグゼクティブディレクター。
会議の議題は単純です。 Venturaがデモを主催し、グループが実装に関する質問について話し合い、カバーします。
ブロッカーがない場合は、FSEをWordPressにマージする計画を共有します。 より可能性の高い結果は、対処しなければならない少なくともいくつかの項目を見つけることです。 その場合、彼らはこれらを公に共有し、4月27日の2回目の合否日までにそれらに取り組む計画を立てます。
WordPress 5.8の最初のベータリリースは6月8日に設定され、7月20日に一般公開されます。チームは、テーマとプラグインの開発者が準備する時間を与えるために、リリースサイクルの早い段階で含めることを決定する必要があります。
多くの人が最終決定を待っていますが、現時点では誰もが少し忍耐力を持っている必要があります。 プロジェクトリーダーは、すべてを慎重に検討する必要があります。 その2番目の4月27日の締め切りまで、結果がわからない可能性があります。
FSE移行のほとんどは、サブセットユーザー向けのベータ版です。 これらの機能をコアに含めることは、WordPressがすぐにスイッチを切り替えて、Webの40％ですべてを有効にすることを意味するわけではありません。 全体的なFSEエクスペリエンスについては、ユーザーはブロックベースのテーマをインストールしてアクティブ化することを明示的に選択する必要があります。
そのことを念頭に置いて、オンボーディングエクスペリエンスは、潜在的な問題をユーザーに知らせながら、ユーザーをサイト編集に招待する歓迎的なエクスペリエンスである必要があります。 組み込みのベータ版である場合、彼らは本当に改善が近づいていることを理解する必要があります。
数年前にプロジェクトがブロックエディタを立ち上げたことを考えると、このようなインコアベータ版の実行も歓迎されます。 人々がブロックエディタを好きか嫌いかに関わらず、展開は誰にとってもスムーズではありませんでした。 WordPressは、エンドユーザーをオーバーホールされたシステムに落とし込みました。これは多くの人にとって衝撃的な変化でした。 今回のプロジェクトでは、ユーザーに機能を段階的に導入し、他のユーザーが自分で選択した新しいエクスペリエンスに没頭できるようにすることで、より良い成果を上げるチャンスがあります。
「共有する最も重要なコンテキストは、ユーザーにとって完全なデフォルトのエクスペリエンスとして出荷されていないことです」と、チームが過去の過ちを超えて成長していることを指摘し、Chomphosyは投稿に書いています。 「フェーズ1のマージプロセスからの最も明確なフィードバックの1つは、エクステンダー（エージェンシー、テーマ作成者、プラグイン開発者、サイトビルダーなど）が今後の変更に備えるための十分な時間がなかったことです。」
意思決定者は、一部の部品を出荷することを決定することもできますが、他の部品は出荷しないこともできます。 FSEは、いくつかのコンポーネントで構成されるプロジェクトです。
「フルサイト編集プロジェクト全体は、ツールとプロジェクトのコレクションの総称のようなものです。そのため、一部の作品は出荷され、他の作品は出荷されない可能性があります」とHadenChomphosy氏は述べています。 「あなたが言ったように、おそらくそれにはいくつかの例外がありますが、これらの多くは準備ができたときに出荷できます。」
彼女が言及していた例外は、一緒により意味のあるコンポーネントです。 たとえば、 theme.jsonファイルを介したブロックベースのテーマとほとんどのサイト編集ブロックは、個別の場合ほど有用ではありません。
もちろん、Queryブロックのようなものをサイトエディタの外部で使用できる場合もあります。 たとえば、ユーザーはサイトエディタを使用せずにページ内にカスタムクエリを作成する場合があります。
私の主な関心事は、サイトエディターに関連する機能ではなく、ブロックベースのウィジェットです。 これは、従来のテーマのユーザー向けの移行ツールです。 新しいナビゲーションメニュー画面とともに、それはブロックベースのテーマエクスペリエンスの一部ではありません。 目標は、ユーザーがより多くの場所でブロックの使用を開始できるようにすることです。 ただし、多くの場合、これによりUXが破損します。
ウィジェットのエクスペリエンスはまだ部分的に壊れており、各ブロックを個別のウィジェットとして扱います。 ユーザーは、サイトのフロントエンドにある正しいウィジェット関連のクラスのグループ（ウィジェットラッパー）に見出し（ウィジェットタイトル）と別のブロック（ウィジェットコンテンツ）を配置する方法を学ぶ必要があります。 一部のテーマでは、ユーザーがこれを行うかどうかは問題になりません。 他の人にとっては、それはせいぜい醜く見え、最悪の場合レイアウトを壊します。 この責任をエンドユーザーの肩にかけることは、許容できる解決策と見なされました。
私はこの問題に焦点を当てたかったのです。なぜなら、それはすべてのユーザーにとって単純に裏返される可能性があるものの1つだからです。 機能しているシステムから壊れている可能性のあるシステムに移行すると、でこぼこした乗り心地になるのではないかと心配しています。
WordPress 5.6リリースチームは、ブロックベースのウィジェットを出荷しないことを決定しました。 Hou-Sandiは、5.6のコア技術リーダーとして、決定の歴史的な説明と、それを含める準備ができていなかった理由を提供しました。
フロントエンドに影響を与える機能についての私の質問は、「自分のサイトを台無しにするというペナルティなしに、この新しいことを試すことができるか」ということです。 —つまり、ユーザーの信頼。 現時点では、テーマが実際に力を入れずにサイトに表示されるようなウィジェット領域は表示されず、実際のコンテキストビューを取得するには、変更を修正せずにライブで保存する必要があるため、ウィジェット領域ブロックは表示されません。実験にペナルティを課すことなく、この新機能を試すことができます。
ウィジェットはほぼ間違いなく改善されていますが、それでも答えは昨年10月と同じだと思います。 テーマ開発コミュニティから、ブロックエディタ自体をサポートするのに十分な賛同を得ていません。ましてや、新しいブロック関連の機能はありません。 ただし、ある時点で、プロジェクトは単に前進する必要があります。 Themersはただついていく必要があるでしょう。