バーテンダーに尋ねる：ブロックテーマがアクティブな場合、カスタマイザーはどうなりますか？
公開: 2021-10-16私のレーダーに今あるのは、カスタマイザーに設定があるサードパーティのプラグインです。 いくつかのプラグイン会社内でカスタマイザーやフロントエンドのものに取り組んでいる開発者である友人の私が集めたもの、グローバルスタイルとブロックスタイルはまだ彼らのレーダーにありません。 では、誰かがTwenty Twenty-Twoまたは別のブロックベースのテーマをインストールするとどうなりますか？ カスタマイザーの左側の管理メニューはありません。 そこにたどり着くための厄介な方法は、[外観]> [テーマ]> [カスタマイザー]を使用することです。 ただし、サードパーティのプラグインとテーマで設定を移動する必要があることが予想されます。 実際、これは、しばらくの間、両方の場所で設定を複製する必要があるようです。
匿名
ループの外にいる人のために、このトピックについて簡単に復習しましょう。 WordPress 5.9がリリースされると、新しいサイトエディターとグローバルスタイルインターフェイスが付属する予定です。 ただし、ブロックテーマを実行していない限り、ほとんどのユーザーにはこの画面は表示されません。
今後のTwentyTwenty-TwoもWordPress5.9で出荷され、過去のデフォルトテーマの人気を判断すると、何千人ものユーザーがこのまったく新しい世界に移動すると予想されます。 一部の人にとっては、これは5.0でのブロックエディタの起動と同じくらい衝撃的かもしれません。
ブロックテーマがアクティブな場合、古くて使い慣れたカスタマイザーにアクセスするためのリンクがユーザーインターフェイスから消えます。 ウィジェットとナビゲーションメニュー画面も表示されません。 ただし、画面のURLを知っていれば、引き続きアクセスできます。
昨年、Gutenberg 9.3リリースの一部として、これが当てはまることが最初にわかりました。 サイトエディターがいくつかのコアWordPress設定と同等の機能を持っていることを確認するための未解決の問題もあります。
これらの機能は、ブロックテーマのユーザー向けに段階的に廃止されても問題ありません。 それらはすべて、サイト編集者が許可するものの個々の部分を作成するための初期の異なる試みでした。 WordPressは、これらすべての概念をよりまとまりのあるユーザーエクスペリエンスにまとめています。 これは、寄稿者が継続的に繰り返すことができる標準です。 それは完全なものではありませんが、コアプラットフォームのこの最初のバージョンは、より多くのユーザーがブロックテーマのインストールを開始するにつれて、それを改善するために必要なフィードバックを促進するはずです。
ここで紹介する問題は、プラグイン市場と関係があります。 カスタマイザーは当初、テーマ設定ツールとして構築され、主にその目的で使用されてきました。 しかし、多くのプラグインは、その9年の歴史の中でさまざまな設定をそれに結び付けてきました。 プラグインディレクトリでwp_customizeを検索すると、1,400を超える結果が表示されます。 customize_registerフックは1,900以上を示しています。 これらは、実際にパネル、セクション、設定、またはコントロールを追加するプラグインの数と必ずしも完全に一致するわけではありません。 ただし、これは、多くの人がエンドユーザーにオプションを提示するためにこれに依存していることを示しています。
それで、私たちは目前の質問に戻ります。 ユーザーがカスタマイザーに依存するプラグインを使用しているときに、次のTwenty Twenty-Twoなどのブロックテーマをインストールするとどうなりますか？
場合によります。
WooCommerceのような一部のプラグインは、管理メニューのカスタマイザーパネル/セクションへの直接リンクをすでに便利に配置しています。 これは、ユーザーにとっては問題になりません。 ただし、他のすべての人にとって、カスタマイザーは完全に消えるように見えます。
5.9から数週間のうちに、特にTwenty Twenty-Twoの採用がどれだけ迅速に行われるかに応じて、何千人もの混乱したユーザーを見ることができます。 もちろん、これらすべてはリリースに至るまでの間に変更される可能性があります。 しかし、これは今やらなければならない会話です。
「ここでの懸念はエンドユーザーに対するものです」と匿名の質問者は言いました。 「彼らはナレッジベースの記事、プラグイン設定の指示、および設定を探す場所を示す詳細を確認します。」
少なくとも現時点では、プラグインの作成者が自分のユーザーのためにこれに対処する責任があります。 しかし、彼らが降りたいと思うかもしれない複数の経路があります。
最も簡単な方法は、WooCommerceの先導に従うことです。 プラグインはgutenberg_is_fse_theme()を条件付きでチェックします（この関数名は変更される可能性があることに注意してください）。 trueを返す場合、プラグインはカスタマイザーパネルに直接リンクを追加します。
カスタマイザーパネル、セクション、またはコントロールへのリンクは簡単です。 プラグインの作成者は、開発者ハンドブックでURLを見つけることができます。 また、WooCommerceチームが採用した手法をコピーすることもできます。
これは、WordPress 5.9がリリースされる前にプラグインの作成者が変更を加えることができない場合に、ユーザーがオプションにアクセスできなくなることのないようにするための簡単な方法です。
長期的には、それは理想的な解決策ではありません。 カスタマイザーは長い間存在しますが、プラグインの作成者は、ブロックテーマとクラシックテーマの両方を実行しているユーザーの2つのセットを処理する必要があります。
プラグインはそれぞれ異なるため、ソリューションも異なる必要があります。 多くの場合、設定APIを使用してカスタムオプション画面を作成できます。 それが実行可能なソリューションである場合、ユーザーが実行しているテーマは重要ではありません。
ただし、現実には、両方のユーザーセットに対して2つのシステムを維持している可能性があります。 1つはカスタマイザーと統合し、もう1つはオプションをサイトエディターに取り込みます。 プラグインにデザイン関連の機能がある場合、ブロックテーマのユーザーは新しいインターフェイスに設定が表示されることを期待します。
テーマの面では、問題が少なくなるはずです。 とにかく、ブロックテーマはカスタマイザーでは何もしません。 未解決の問題の1つは、スターターコンテンツの変換であり、それをフルサイト編集に持ち込むためのオープンチケットがあります。
何よりも、ユーザーとのオープンなコミュニケーションを維持することは、移行を容易にするのに役立ちます。 その一部はコアWordPressから来るはずです。 ただし、多くのユーザーは、プラグインおよびテーマの開発者からそれを聞く必要があります。 これは、ブログの投稿、ナレッジベース、またはチュートリアルの更新であり、サポートに対応している可能性があります。
次に、WordPress自体が実装できる最終的な解決策があります。 それはまた、最も抵抗の少ない道でもあります。
WordPressは、カスタマイザー関連のフックのフィルターまたはアクションを自動的に検出する必要があります。 これにより、「サポートのカスタマイズ」フラグがトリガーされ、カスタマイザー画面への管理メニューとツールバーのリンクが維持されます。 これにより、開発者は、プロセスでユーザーを混乱させることなく、追いつくための時間を確保できます。 いくつかの誤ったフラグや統合の失敗があるかもしれませんが、それはユースケースの大部分を効果的に捕らえることができるはずです。