Block Directoryへのプラグイン提出ガイド

Block Directoryの目的は、WordPressユーザーが新しいブロックを見つけてインストールするための安全な場所を提供することです。

ユーザーの期待

  • ユーザーは、WordPress管理画面とWordPress.orgの両方で、主要なセキュリティ問題について事前に審査されたブロックをダウンロードしてインストールできる場所を持つことができます。
  • ユーザーは、管理画面からブロックを1つずつワンクリックでインストールできるようになります。
  • インストールとアクティベーション後、ブロックはブロックライブラリに表示されます。
  • ブロックは、侵入的な広告やアップセルなしでシームレスかつ即座に機能します。

開発者の期待

  • 開発者は、Block Directory用のブロックを書く際に従うべき具体的な要件とガイドラインを持つことになります。
  • これらのガイドラインに従うことで、開発したブロックがエディターにシームレスにインストールできることが保証されます。
  • Block Directoryに提出されたブロックは、一般的なWordPressプラグインよりも厳しい技術的およびポリシーのルールに従います。
  • Block Directoryガイドラインを満たさないブロックを含むプラグインは、プラグインディレクトリに提出することができます。

定義

Block Directoryの目的のために、私たちは2種類のプラグインを区別します：

  • 1. ブロックを配布するためだけに存在するプラグイン。
  • 2. 多くの独立したブロックをバンドルするプラグイン、他の機能に加えてブロックを含むプラグイン、または全くブロックを含まないプラグインを含むすべての他のプラグイン。

これらのガイドラインは、Block Pluginと呼ばれる最初のタイプのプラグインに特に適用されます。プラグインが2番目のタイプである場合、さらなるガイドラインや制限は適用されません。ブロック専用であろうとなかろうと、すべてのプラグインは詳細なプラグインガイドラインに従う必要があります。

ブロックプラグインとBlock Directory

Block Directoryには、単一の独立したトップレベルブロックと最小限のサポートコードのみを含むブロックプラグインのみが含まれます。ブロックプラグインには以下の特徴があります：

  • 1. 同じ構造を持つ特定のタイプのWordPressプラグインで、readme.txtファイルを含みます。
  • 2. ブロックのみを含む（通常は単一のトップレベルブロック）。
  • 3. 最小限のサーバーサイド（つまりPHP）コードを含む。
  • 4. 投稿エディターの外にUIを持たない自己完結型。

すべてのWordPressプラグインに適用されるガイドラインに加えて、Block Directoryに提出されるブロックプラグインは、これらのガイドラインに従う必要があります：

ガイドライン

1. ブロックプラグインはブロックエディター用です。

ブロックプラグインは、ブロックと最小限の他のサポートコードを含む必要があります。エディターの外にWordPressオプションやwp-adminメニューなどのUXを含むことはできません。サーバーサイドコードは最小限に抑えるべきです。

他の既存のブロックを拡張またはスタイルを提供するだけのプラグインは、現在Block Directoryに含まれる資格がありません。この時点では、これらはブロックエディターのシームレスなインストールプロセスによってサポートされていません。新しいブロックを登録するブロックプラグインのみが現在サポートされています。

2. ブロックプラグインは独立したブロックです。

ブロックプラグインは、単一目的の独立したブロックであり、複数のブロックのバンドルやコンペンディウムではありません。ほとんどの場合、ブロックプラグインは単一のトップレベルブロックのみを含むべきです。Block Directoryには、合理的に分割できるブロックのコレクションは含まれません。

ブロックプラグインは、明確に必要な親/子またはコンテナ/コンテンツの依存関係が存在する場合、1つ以上のブロックを含むことができます。例えば、リストアイテムブロックを含むリストブロックなどです。

3. プラグインとブロックの名前はブロックの目的を反映するべきです。

プラグインタイトルとブロックタイトルは、ブロックが何をするかを説明し、ユーザーがその目的を簡単に理解できるようにするべきです。ほとんどの場合、プラグインタイトルとブロックタイトルは同一または非常に似ているべきです。良いプラグインとブロックの名前の例には以下が含まれます：

Rainbow Block

Sepia Image Grid

Business Hours Block

ブロック自体に関連しないプラグインやブロックのタイトル、またはコアブロックと簡単に区別できないものは避けてください。役に立たないプラグインやブロックの名前の例には以下が含まれます：

PluginCo Inc Block 

  2. `````Image Block

プラグインタイトルに対する商標制限は、ブロックタイトルや名前にも適用されます。これは、ブロックが「Facerange Block」と名付けられることは、Facerangeの法的代表者によって開発されていない限り許可されないことを意味します。

3a. ブロック名はユニークで適切に名前空間化されるべきです。

ブロック名（nameパラメータをregisterBlockType()におよびnameをblock.jsonに意味する）は、ブロックに対してユニークである必要があります。タイトルと同様に、商標や他のプロジェクトで一般的に使用される名前を尊重し、衝突しないようにしてください。

ブロック名の名前空間プレフィックスは、プラグインの著者またはプラグインスラッグを反映するべきです。例えば：

name: "my-rainbow-block-plugin/rainbow"、または

name: "john-doe/rainbow"、または

name: "pluginco/rainbow"。

名前空間は、coreやwordpressのような予約されたものではない必要があります。

4. ブロックプラグインにはblock.jsonファイルを含める必要があります。

ブロック登録RFCは、block.jsonファイルのフォーマットを概説しています：https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/block-api/block-metadata.md

ブロックプラグインには、有効なblock.jsonファイルを含める必要があります。RFCで指定された要件に加えて、block.jsonには以下の属性が含まれている必要があります：

  • name
  • title
  • 少なくとも1つ：script、editorScript
  • 少なくとも1つ：style、editorStyle

5. ブロックプラグインは独立して動作する必要があります。

ブロックプラグインは、他のWordPressプラグインやテーマなどの外部依存関係を必要とせずに機能する必要があります。

ブロックプラグインは、他のWordPressプラグインやテーマのコードやフックを利用することができますが、ブロックプラグインはそのプラグインやテーマがインストールされていなくても使用可能である必要があります。例えば、レシピブロックプラグインは、スライダープラグインで実装されたフィルターを適用して画像表示を改善することが許可されていますが、レシピブロックプラグインはスライダープラグインなしでも使用可能である必要があります。

6. ブロックプラグインはシームレスに動作するべきです。

ブロックプラグインは、エディターからインストールされたときにシームレスかつ即座に動作することを意図しています。つまり、ユーザーに追加の手順や前提条件を課すべきではなく、他のプラグインやテーマのインストール、アカウントの登録、ログイン、または外部サービスへの手動接続などを要求してはいけません。

ブロックプラグインの使用に対して支払いを要求することは許可されていません。プラグインのreadme内で寄付リンク機能を使用したり、完全なプラグインリストからリンクを貼ることは許可されていますが、ブロックプラグイン自体は無料で使用できる必要があります。支払いサービスを必要とするブロックプラグインや、アップセルやプレミアム機能を含むものは、ガイドラインに従ってWordPressプラグインディレクトリに含まれることが許可されています。

ブロックプラグインは、必要に応じて外部/クラウドAPIを使用することができますが、ログインやアクティベーションキーを要求せずにシームレスに行える必要があります。

ローカルで実行できる機能に対して外部APIやクラウドサービスに依存するべきではありません。

7. サーバーサイドコードは最小限に抑えるべきです。

ブロックプラグインはWordPressプラグインであるため、メタデータや初期化のためにPHPコードを含む必要があります。可能な限り、追加のPHPコードやサーバーサイドライブラリを含むことは避けるべきです。WordPress REST APIは、カスタムサーバーサイドコードではなく、WordPressへの推奨インターフェースであるべきです。

REST APIには制限があり、サーバーサイドPHPが機能を実装する唯一のパフォーマンスの良い方法である状況もあります。そのような状況では、PHPコードを含めることができますが、明確に書かれ、できるだけ少なく使用され、十分に文書化されている必要があります。

8. 広告やプロモーション通知を含めてはいけません。

ブロックプラグインは、ブロックの目的に関連しない警告、ダッシュボード通知、または同様の侵入的なメッセージを表示するコードを含めてはいけません。