新しいパッケージプロジェクトリーダーの背後で、テーマレビューチームが管理者通知ソリューションを開始

公開: 2019-09-19

邪魔な管理者通知を抑制するWordPressテーマレビューチームの計画の一環として、チームは管理者通知パッケージのバージョン1.0を公開しました。新しいパッケージは、テーマ作成者が管理者通知を表示するための標準APIを提供します。

8月下旬にパッケージプロジェクトのリーダーとしてAriStathopoulosが引き継ぎました。 Stathopoulosは、プラグインとして現在300,000以上のアクティブなインストールが行われている、高評価のKirkiカスタマイザーフレームワークの主要な開発者および作成者です。ただし、フレームワークは、テーマの作成者がテーマ内にバンドルできる個別のモジュールとしても利用できます。

Admin Noticesパッケージは、チームによって作成された3番目のパッケージであり、Stathopoulosが先頭に立った最初のパッケージです。

WordPressに基本的な管理者通知を追加することは、ほとんどの開発者にとって比較的簡単です。ただし、永続的な却下可能なアクションなどの機能の処理はより複雑です。 Admin Noticesパッケージは、これをそのまま処理します。

パッケージの一部のオプションには、次の機能が含まれます。

タイトルとメッセージを設定します。
適切なUIクラス（情報、成功、警告、エラー）を追加するタイプを選択します。
通知が表示される管理画面を選択します。
すべてのユーザーに表示されないように、ユーザー機能によってメッセージを制限します。

管理者通知パッケージを使用した情報、成功、警告、およびエラー通知のスクリーンショット。

上のスクリーンショットは、利用可能な4つのタイプの基本的な管理者通知出力の例を示しています。却下アクションはJavaScriptによって処理され、ページをリロードせずに機能します。却下されると、ユーザーには通知が表示されなくなります。

「それについて最も難しいことは、それをどれだけ制限したいかを決めることだったと思います」と、このパッケージを構築する際の課題についてStathopoulos氏は述べています。このパッケージは、テーマの作成者をバージョン1.0の段落、リンク、太字、および斜体の要素に制限します。実験の余地はあまりありませんが、標準化が目標です。許可される要素が多いほど、ツールが管理者の通知を邪魔にならないようにするというチームの問題を解決しない可能性が高くなります。

ユーザー通知は複雑な問題です

WordPressは、ユーザー通知用の正式なAPIを提供していません。ただし、CSSクラスの標準セットと通知を添付するためのフックを提供します。コーデックスには、ベストプラクティスの例もいくつかあります。正式なAPIがないため、テーマとプラグインの作成者は自分のデバイスに任せています。ユーザーは、実装が大きく異なることや、非表示の広告などの一般的な問題のために苦しんでいます。

Tim Hengeveldは、2018年にTracで通知センターAPIを提案しました。チケットには、健全で継続的な議論といくつかのUI提案が含まれています。提案はまだ「レビュー待ち」とマークされており、WordPress5.4以降よりも早く出荷される可能性は低いです。

現在、多くのプラグインとテーマは、ユーザーのオンボーディングに管理者通知を使用しています。これは、解決策が必要な別の問題です。 WordPressの新規ユーザーのオンボーディングについて説明している4年前のチケットがありますが、プラグインとテーマのこの問題を解決する動きはあまりありません。

TRTのパッケージは、ユーザー通知に関連するすべての問題に対処するわけではありませんが、短期的な損害の一部を制限するのに役立ちます。

作品のより多くのパッケージ

現在、さらに多くのパッケージが構築されており、他のパッケージは計画段階にあります。

プロジェクト全体の目標は、テーマの作成者に、テーマにバンドルできるドロップインモジュールを提供することです。パッケージはすべてPHP5.6 +で記述されており、テーマの作成者をより現代的なコーディング手法に向かわせることを望んでいます（PHP 7.4は今年リリースされるため、比較的言えば）。また、すべてを社内で構築するのではなく、より多くのテーマ作成者がパッケージを採用する場合は、レビュープロセスを合理化するのに役立ちます。

「最も要望の多かったもののパッケージを作成すれば、人々が質の高いテーマを簡単に作成できるようになることを願っています」とStathopoulos氏は説明します。「パッケージはテーマの構成要素だと思います。」

Stathopoulosは、アルファ透明度のある色を選択するためのカスタマイザーコントロールに取り組んでいます。これは、早ければ来週にリリースされる可能性があります。これにより、テーマユーザーは、それを実装するテーマの色がどのように表示されるかをより細かく制御できます。

「基本を構築した後、テーマのa11yとプライバシーを強化するパッケージに焦点を当てたいと思います。テーマが不足している2つの領域です」と彼は言いました。「それは多くの人々を助けるでしょう、そしてそれは最終的に私たちの目標です。」

テーマの作成者は、過去数年間でNPMを介してJavaScriptおよびCSSパッケージをインストールすることに慣れてきました。ただし、PHP依存関係マネージャーとしてのComposerの使用は遅れています。ある部分では、これはWordPressがPHPの最小バージョンをバンプすることを以前は嫌がっていたことが原因である可能性があります。メインのComposerリポジトリであるPackagistで利用可能な多くのパッケージは、古いバージョンのPHPでは機能しません。 WordPressの最近のPHP5.6以降への移行と、将来的に7以降への移行の計画により、より多くのテーマ作成者がPHPの依存関係管理を検討するようになる可能性があります。

TRTにはPackagistアカウントがあり、Composerを介してすべてのパッケージをインストールできるようになっています。

パッケージを使用する必要はまだありません

TRTが特定の機能のためにこれらのパッケージの使用を要求し始める現在の計画はありませんが、少数のチームメンバーがそうすることを提案しています。

「これらのパッケージの使用を強制する正当な理由がありますが、それは一夜にして行うことはできません」とStathopoulos氏は述べています。「リポジトリ内のテーマにいくつかの標準を持たせたいのですが、西部開拓時代にはなり得ません。コードの品質を向上させる必要があります。これらのパッケージは、人々の生活を楽にし、最終的にはすべての人の時間を節約する方法です。」

Stathopoulosは、チームが構築したものを改善できる場合、カスタム実装を構築するテーマ作成者に門戸を開いていますが、作成者は「コミュニティ全体が利益を得ることができるように、パッケージリポジトリでアイデアについて話し合い、プルリクエストを送信する」ことを望んでいます。

テーマの作成者を巻き込むことは、チームが苦労している分野の1つです。パッケージに貢献することは、コミュニティ全体に利益をもたらす可能性があります。「彼らはどこにもリストされていないので、ほとんどの人はそれらについてさえ知りません」とStathopoulosは言いました。「テーマの作成者は現在それらを探す必要があり、それらを探すために誰かがそれらが存在することを伝える必要があります（これは起こりません）。」次のステップの1つは、TRTのドキュメントにリストされているパッケージを取得することです。

共通のテーマ機能で一緒に作業することで、テーマの作成者とレビュー担当者の間の架け橋となり、問題を一緒に解決できるようになります。

注：この記事の作成者は、最初のテーマパッケージの提案と、最初のパッケージリリースの開発者に関与していました。