メタデータファイルの利点

ブロック定義は、JSONとして保存されたブロックタイプを処理する際に、JavaScript、PHP、および他の言語間でコードを共有できるようにし、block.jsonメタデータファイルでブロックを登録することは、その上に複数の利点を提供します。

パフォーマンスの観点から、テーマが遅延読み込みアセットをサポートしている場合、block.jsonで登録されたブロックは、アセットのエンキューが最適化されます。styleまたはscriptプロパティにリストされているフロントエンドのCSSおよびJavaScriptアセットは、ブロックがページに存在する場合にのみエンキューされ、ページサイズが削減されます。

さらに、ブロックタイプREST APIエンドポイントは、サーバー上で登録されたブロックのみをリストできるため、サーバーサイドでブロックを登録することが推奨されます。block.jsonファイルを使用すると、この登録が簡素化されます。

WordPressプラグインディレクトリは、block.jsonファイルを検出し、プラグインに含まれるブロックを強調表示し、そのメタデータを抽出できます。ブロックディレクトリにブロックを提出したい場合、プラグインに含まれるすべてのブロックには、ブロックディレクトリがそれらを認識するためのblock.jsonファイルが必要です。

定義されたスキーマ定義ファイルを使用することで、開発が改善されます。サポートされているエディタは、ツールチップ、自動補完、スキーマ検証などのヘルプを提供できます。スキーマを使用するには、block.jsonの先頭に次の内容を追加します。

  1. "$schema": "https://schemas.wp.org/trunk/block.json"

ブロックの登録を確認して、メタデータを使用してブロックを登録する方法について詳しく学んでください。

ブロックAPI

このセクションでは、ブロックタイプの動作とメタデータを定義するためにblock.jsonファイルに追加できるすべてのプロパティについて説明します。

APIバージョン

  • タイプ: number
  • オプション
  • ローカライズ: いいえ
  • プロパティ: apiVersion
  • デフォルト: 1
  1. { "apiVersion": 3 }

ブロックによって使用されるブロックAPIのバージョン。最新のバージョンは3で、WordPress 6.3で導入されました。

詳細については、APIバージョンのドキュメントを参照してください。

名前

  • タイプ: string
  • 必須
  • ローカライズ: いいえ
  • プロパティ: name
  1. { "name": "core/heading" }

ブロックの名前は、ブロックを識別する一意の文字列です。名前はnamespace/block-nameの形式で構成する必要があり、名前空間はプラグインまたはテーマの名前です。

注意: ブロック名には小文字の英数字、ダッシュ、そしてプラグイン固有の名前空間プレフィックスを指定するためのスラッシュを1つだけ含めることができます。文字で始める必要があります。

注意: この名前は、<!-- wp:my-plugin/book -->としてコメント区切りに使用されます。core名前空間のブロックタイプは、シリアライズ時に名前空間を含みません。

タイトル

  • タイプ: string
  • 必須
  • ローカライズ: はい
  • プロパティ: title
  1. { "title": "Heading" }

これは、ブロックの表示タイトルであり、翻訳関数を使用して翻訳できます。タイトルは、インサータやエディタの他の領域に表示されます。

注意: ブロックのタイトルをUIで読みやすく、アクセス可能に保つために、非常に長いタイトルは避けるようにしてください。

カテゴリ

  • タイプ: string
  • オプション
  • ローカライズ: いいえ
  • プロパティ: category
  1. { "category": "text" }

ブロックは、ユーザーがそれらをブラウズし、発見するのを助けるためにカテゴリにグループ化されます。

コアが提供するカテゴリは次のとおりです:

  • テキスト
  • メディア
  • デザイン
  • ウィジェット
  • テーマ
  • 埋め込み

プラグインとテーマもカスタムブロックカテゴリを登録できます。

実装は、未知のカテゴリを期待し、許容し、合理的なフォールバック動作(例:「テキスト」カテゴリ)を提供する必要があります。

  • タイプ: string[]
  • オプション
  • ローカライズ: いいえ
  • プロパティ: parent
  1. { "parent": [ "my-block/product" ] }
  1. <a name="ancestor"></a>
  2. ### 祖先
  3. - タイプ: `````string[]
  • オプション
  • ローカライズ: いいえ
  • プロパティ: ancestor
  • 以降: WordPress 6.0.0
  1. { "ancestor": [ "my-block/product" ] }
  1. <a name="allowed-blocks"></a>
  2. ### 許可されたブロック
  3. - タイプ: `````string[]
  • オプション
  • ローカライズ: いいえ
  • プロパティ: allowedBlocks
  • 以降: WordPress 6.5.0
  1. { "allowedBlocks": [ "my-block/product" ] }
  1. <a name="icon"></a>
  2. ### アイコン
  3. - タイプ: `````string
  • オプション
  • ローカライズ: いいえ
  • プロパティ: icon
  1. { "icon": "smile" }

アイコンプロパティは、ブロックを識別しやすくするために指定する必要があります。これらは、WordPressのDashiconsのいずれかである可能性があります(スラッグは非JSコンテキストでのフォールバックとしても機能します)。

注意: このプロパティは、SVG要素のソースでクライアント側でオーバーライドすることも可能です。さらに、このプロパティは、背景色と前景色を含むオブジェクトとしてJavaScriptで定義できます。これらの色は、適用可能な場合にアイコンと共に表示されます(例:インサータ内)。カスタムSVGアイコンは、自動的にwp.primitives.SVGコンポーネントにラップされ、アクセシビリティ属性(aria-hidden、role、focusable)が追加されます。

説明

  • タイプ: string
  • オプション
  • ローカライズ: はい
  • プロパティ: description
  1. {
  2. "description": "Introduce new sections and organize content to help visitors"
  3. }

これは、ブロックの短い説明であり、翻訳関数を使用して翻訳できます。これは、ブロックインスペクタに表示されます。

キーワード

  • タイプ: string[]
  • オプション
  • ローカライズ: はい
  • プロパティ: keywords
  • デフォルト: []
  1. { "keywords": [ "keyword1", "keyword2" ] }

時々、ブロックには、ユーザーが検索中にそれを発見するのを助けるエイリアスがある場合があります。たとえば、画像ブロックは「写真」としても発見されることを望むかもしれません。無制限の用語の配列を提供することで、これを実現できます(翻訳されます)。

バージョン

  • タイプ: string
  • オプション
  • ローカライズ: いいえ
  • プロパティ: version
  • 以降: WordPress 5.8.0
  1. { "version": "1.0.3" }

ブロックの現在のバージョン番号(例:1.0または1.0.3)。これは、プラグインのバージョン付けと似ています。このフィールドは、ブロックアセットと共にキャッシュ無効化を制御するために使用される可能性があり、ブロックの作成者がこれを省略した場合、インストールされているWordPressのバージョンが代わりに使用されます。

テキストドメイン

  • タイプ: string
  • オプション
  • ローカライズ: いいえ
  • プロパティ: textdomain
  • 以降: WordPress 5.7.0
  1. { "textdomain": "my-plugin" }

プラグイン/ブロックのgettextテキストドメイン。詳細情報は、テキストドメインセクションのプラグインの国際化方法ページで確認できます。

属性

  • タイプ: object
  • オプション
  • ローカライズ: いいえ
  • プロパティ: attributes
  • デフォルト: {}
  1. {
  2. "attributes": {
  3. "cover": {
  4. "type": "string",
  5. "source": "attribute",
  6. "selector": "img",
  7. "attribute": "src"
  8. },
  9. "author": {
  10. "type": "string",
  11. "source": "html",
  12. "selector": ".book-author"
  13. }
  14. }
  15. }

属性は、ブロックの構造化データのニーズを提供します。シリアライズされるときに異なる形式で存在する可能性がありますが、共通のインターフェースの下で一緒に宣言されます。

詳細については、属性のドキュメントを参照してください。

コンテキストを提供

  • タイプ: object
  • オプション
  • ローカライズ: いいえ
  • プロパティ: providesContext
  • デフォルト: {}

このタイプのブロックの子孫による利用可能なアクセスのために提供されるコンテキストは、コンテキスト名をブロックの属性の1つにマッピングするオブジェクトの形式です。

詳細については、ブロックコンテキストのドキュメントを参照してください。

  1. {
  2. "providesContext": {
  3. "my-plugin/recordId": "recordId"
  4. }
  5. }

コンテキスト

  • タイプ: string[]
  • オプション
  • ローカライズ: いいえ
  • プロパティ: usesContext
  • デフォルト: []

祖先プロバイダーから継承するコンテキスト値の名前の配列。

詳細については、ブロックコンテキストのドキュメントを参照してください。

  1. {
  2. "usesContext": [ "message" ]
  3. }

セレクタ

  • タイプ: object
  • オプション
  • ローカライズ: いいえ
  • プロパティ: selectors
  • デフォルト: {}
  • 以降: WordPress 6.3.0

任意のカスタムCSSセレクタ、root、機能、またはサブ機能によってキー付けされ、ブロックスタイルを生成する際に使用されます。

テーマ.json(グローバルスタイル)スタイルシートのためにブロックスタイルを生成する際に、カスタムセレクタを提供することで、どのスタイルがどのブロック要素に適用されるかをより細かく制御できます。たとえば、内側の見出しにのみタイポグラフィスタイルを適用し、外側のブロックラッパーには色が適用されるなどです。

詳細については、セレクタのドキュメントを参照してください。

  1. {
  2. "selectors": {
  3. "root": ".my-custom-block-selector",
  4. "color": {
  5. "text": ".my-custom-block-selector p"
  6. },
  7. "typography": {
  8. "root": ".my-custom-block-selector > h2",
  9. "text-decoration": ".my-custom-block-selector > h2 span"
  10. }
  11. }
  12. }

サポート

  • タイプ: object
  • オプション
  • ローカライズ: いいえ
  • プロパティ: supports
  • デフォルト: {}

エディタで使用される機能を制御するためのオプションのセットが含まれています。詳細については、サポートのドキュメントを参照してください。

ブロックスタイル

  • タイプ: array
  • オプション
  • ローカライズ: はい(labelのみ)
  • プロパティ: styles
  • デフォルト: []
  1. {
  2. "styles": [
  3. { "name": "default", "label": "Default", "isDefault": true },
  4. { "name": "other", "label": "Other" }
  5. ]
  6. }

ブロックスタイルは、ブロックに代替スタイルを提供するために使用できます。これは、ブロックのラッパーにクラス名を追加することによって機能します。CSSを使用して、テーマ開発者は、選択された場合にブロックスタイルのクラス名をターゲットにできます。

プラグインとテーマも、既存のブロックのカスタムブロックスタイルを登録できます。

  • タイプ: object
  • オプション
  • ローカライズ: いいえ
  • プロパティ: example
  1. {
  2. "example": {
  3. "attributes": {
  4. "message": "This is a notice!"
  5. }
  6. }
  7. }

これは、ブロックの構造化された例データを提供します。このデータは、ユーザーがブロックにマウスを乗せたときにインスペクタヘルパーパネルに表示されるブロックのプレビューを構築するために使用されます。

詳細については、例のドキュメントを参照してください。

バリエーション

  • タイプ: object[]|WPDefinedPath (詳細を学ぶ)
  • オプション
  • ローカライズ: はい(titledescription、およびkeywordsの各バリエーションのみ)
  • プロパティ: variations
  • 以降: WordPress 5.9.0
  1. {
  2. "variations": [
  3. {
  4. "name": "example",
  5. "title": "Example",
  6. "attributes": {
  7. "level": 2,
  8. "message": "This is an example!"
  9. },
  10. "scope": [ "block" ],
  11. "isActive": [ "level" ]
  12. }
  13. ]
  14. }

ブロックバリエーションは、ブロックが類似のバージョンを持つことを可能にするAPIですが、これらのすべてのバージョンは共通の機能を共有します。各ブロックバリエーションは、いくつかの初期属性または内部ブロックを設定することによって他のバリエーションと区別されます。ブロックが挿入されるときに、これらの属性および/または内部ブロックが適用されます。

注意: JavaScriptでは、isActiveプロパティに関数を提供し、iconにReact要素を提供できます。block.jsonファイルでは、両方とも文字列のみをサポートします

バージョン6.7から、block.jsonでPHPファイルを指定して、サーバー側でブロックバリエーションのリストを生成することが可能です:

  1. { "variations": "file:./variations.php" }

そのPHPファイルは、ブロックバリエーションを含む配列をreturnすることが期待されます。PHPファイルから返されたバリエーションに見つかった文字列は自動的にローカライズされません。代わりに、通常通り()関数を使用してください。

例:

  1. <?php
  2. // Generate variations for a Social Icon kind of block.
  3. return array(
  4. array(
  5. 'isDefault' => true,
  6. 'name' => 'wordpress',
  7. 'title' => 'WordPress',
  8. 'icon' => 'wordpress',
  9. 'attributes' => array(
  10. 'service' => 'wordpress',
  11. ),
  12. 'isActive' => array( 'service' )
  13. ),
  14. array(
  15. 'name' => 'mail',
  16. 'title' => __( 'Mail' ),
  17. 'keywords' => array(
  18. __( 'email' ),
  19. __( 'e-mail' )
  20. ),
  21. 'icon' => 'mail',
  22. 'attributes' => array(
  23. 'service' => 'mail',
  24. ),
  25. 'isActive' => array( 'mail' )
  26. ),
  27. );

詳細については、バリエーションのドキュメントを参照してください。

ブロックフック

  • タイプ: object
  • オプション
  • プロパティ: blockHooks
  • 以降: WordPress 6.4.0
  1. {
  2. "blockHooks": {
  3. "my-plugin/banner": "after"
  4. }
  5. }

ブロックフックは、ブロックが指定されたブロックタイプのすべてのインスタンスの隣に自動的に挿入されるAPIです。「フックされた」ブロックによって指定された相対位置でも挿入されます。つまり、ブロックは指定されたブロックタイプの前または後、またはその最初または最後の子として挿入されることを選択できます(すなわち、子ブロックのリストにそれぞれ追加または追加されます)。フックされたブロックは、フロントエンドとエディタの両方に表示されます(ユーザーによるカスタマイズを可能にします)。

キーはフックするブロックの名前(string)であり、値はフックする位置(string)です。利用可能な構成についての詳細は、ブロックフックのドキュメントを参照してください。

エディタスクリプト

  • タイプ: WPDefinedAsset|WPDefinedAsset[] (詳細を学ぶ)
  • オプション
  • ローカライズ: いいえ
  • プロパティ: editorScript
  1. { "editorScript": "file:./index.js" }

ブロックタイプエディタスクリプトの定義。これらは、エディタのコンテキストでのみエンキューされます。

wp_register_script関数で登録されたスクリプトハンドル、block.jsonファイルに対するJavaScriptファイルへのパス、または両方のミックスリストを渡すことが可能です(詳細を学ぶ)。

注意: WordPress 6.1.0以降、エディタスクリプトの配列を渡すオプションもあります。

スクリプト

  • タイプ: WPDefinedAsset|WPDefinedAsset[] (詳細を学ぶ)
  • オプション
  • ローカライズ: いいえ
  • プロパティ: script
  1. { "script": "file:./script.js" }

ブロックタイプのフロントエンドおよびエディタスクリプトの定義。これらは、エディタとサイトのフロントでコンテンツを表示する際の両方でエンキューされます。

wp_register_script関数で登録されたスクリプトハンドル、block.jsonファイルに対するJavaScriptファイルへのパス、または両方のミックスリストを渡すことが可能です(詳細を学ぶ)。

注意: WordPress 6.1.0以降、スクリプトの配列を渡すオプションもあります。

ビュー スクリプト

  • タイプ: WPDefinedAsset|WPDefinedAsset[] (詳細を学ぶ)
  • オプション
  • ローカライズ: いいえ
  • プロパティ: viewScript
  • 以降: WordPress 5.9.0
  1. { "viewScript": [ "file:./view.js", "example-shared-view-script" ] }

ブロックタイプのフロントエンドスクリプトの定義。これらは、サイトのフロントでコンテンツを表示する際にのみエンキューされます。

wp_register_script関数で登録されたスクリプトハンドル、block.jsonファイルに対するJavaScriptファイルへのパス、または両方のミックスリストを渡すことが可能です(詳細を学ぶ)。

注意: WordPress 6.1.0以降、ビュー スクリプトの配列を渡すオプションもあります。

ビュー スクリプト モジュール

  • タイプ: WPDefinedAsset|WPDefinedAsset[] (詳細を学ぶ)
  • オプション
  • ローカライズ: いいえ
  • プロパティ: viewScriptModule
  • 以降: WordPress 6.5.0
  1. { "viewScriptModule": [ "file:./view.js", "example-shared-script-module-id" ] }

ブロックタイプのフロントエンドスクリプトモジュールの定義。これらは、サイトのフロントでコンテンツを表示する際にのみエンキューされます。

wp_register_script_module関数で登録されたスクリプトモジュールID、block.jsonファイルに対するJavaScriptモジュールへのパス、または両方のミックスリストを渡すことが可能です(詳細を学ぶ)。

WordPressスクリプトとWordPressスクリプトモジュールは、現時点では互換性がありません。フロントエンドビューアセットがWordPressスクリプトに依存している場合は、viewScriptを使用する必要があります。WordPressスクリプトモジュールに依存している場合は、現在のインタラクティビティAPIを使用する必要があります。 より多くの機能が徐々にスクリプトモジュールに利用可能になります。

注意: WordPress 6.5.0以降利用可能。

エディタスタイル

  • タイプ: WPDefinedAsset|WPDefinedAsset[] (詳細を学ぶ)
  • オプション
  • ローカライズ: いいえ
  • プロパティ: editorStyle
  1. { "editorStyle": "file:./index.css" }

ブロックタイプのエディタスタイルの定義。これらは、エディタのコンテキストでのみエンキューされます。

wp_register_style関数で登録されたスタイルハンドル、block.jsonファイルに対するCSSファイルへのパス、または両方のミックスリストを渡すことが可能です(詳細を学ぶ)。

注意: WordPress 5.9.0以降、エディタスタイルの配列を渡すオプションもあります。

スタイル

  • タイプ: WPDefinedAsset|WPDefinedAsset[] (詳細を学ぶ)
  • オプション
  • ローカライズ: いいえ
  • プロパティ: style
  1. { "style": [ "file:./style.css", "example-shared-style" ] }

ブロックタイプのフロントエンドおよびエディタスタイルの定義。これらは、エディタとサイトのフロントでコンテンツを表示する際の両方でエンキューされます。

wp_register_style関数で登録されたスタイルハンドル、block.jsonファイルに対するCSSファイルへのパス、または両方のミックスリストを渡すことが可能です(詳細を学ぶ)。

注意: WordPress 5.9.0以降、スタイルの配列を渡すオプションもあります。

ビュー スタイル

  • タイプ: WPDefinedAsset|WPDefinedAsset[] (詳細を学ぶ)
  • オプション
  • ローカライズ: いいえ
  • プロパティ: viewStyle
  • 以降: WordPress 6.5.0
  1. { "viewStyle": [ "file:./view.css", "example-view-style" ] }

ブロックタイプのフロントエンドスタイルの定義。これらは、サイトのフロントでコンテンツを表示する際にのみエンキューされます。

wp_register_style関数で登録されたスタイルハンドル、block.jsonファイルに対するCSSファイルへのパス、または両方のミックスリストを渡すことが可能です(詳細を学ぶ)。

フロントエンド専用のスタイルは、インタラクティブなブロックに特に便利で、ユーザーが何らかのアクションを実行した後にのみ表示される部分をスタイル設定するために使用され、これらのスタイルはエディタでは決して必要ありません。styleプロパティを使用して、すべての共通スタイルを1つのスタイルシートにまとめることから始めることができます。エディタ固有のスタイルやフロントエンド固有のスタイルが必要な場合にのみ、editorStyleおよびviewStyleに拡張できますが、スタイルの共通部分はメインスタイルシートに保持できます。

レンダー

  • タイプ: WPDefinedPath (詳細を学ぶ)
  • オプション
  • ローカライズ: いいえ
  • プロパティ: render
  • 以降: WordPress 6.1.0
  1. { "render": "file:./render.php" }

フロントエンドに表示するためにブロックタイプをレンダリングする際に使用するPHPファイル。次の変数がファイルに公開されます:

  • $attributesarray):ブロック属性。
  • $contentstring):ブロックのデフォルトコンテンツ。
  • $blockWP_Block):ブロックインスタンス。
  1. ``````bash
  2. <div <?php echo get_block_wrapper_attributes(); ?>>
  3. <?php echo esc_html( $attributes['label'] ); ?>
  4. </div>
  5. `

注意: このファイルは、ページHTMLをサーバーでレンダリングする際に、ブロックタイプのすべてのインスタンスに対して読み込まれます。関数やクラスをファイルに宣言する際には、その点を考慮することが重要です。エラーのリスクを回避する最も簡単な方法は、別のファイルからその共有ロジックを消費することです。

アセット

WPDefinedPath

  1. **例:**
  2. `````block.json`````:
  3. ``````bash
  4. {
  5. "render": "file:./render.php"
  6. }
  7. `

WPDefinedAsset

  1. **例:**
  2. `````block.json`````:
  3. ``````bash
  4. {
  5. "editorScript": "file:./index.js",
  6. "script": "file:./script.js",
  7. "viewScriptModule": [
  8. "file:./view.js",
  9. "example-registered-script-module-id"
  10. ],
  11. "editorStyle": "file:./index.css",
  12. "style": [ "file:./style.css", "example-shared-style" ],
  13. "viewStyle": [ "file:./view.css", "example-view-style" ]
  14. }
  15. `

WordPressのコンテキストでは、ブロックがPHPで登録されると、block.jsonファイルに見つかったすべてのスクリプト、スクリプトモジュール、およびスタイルが自動的に登録され、アセットハンドルではなくファイルパスが使用されます。

そのため、WPDefinedAssetタイプは、wp_register_scriptwp_register_script_module、およびwp_register_styleを使用してスクリプト、スクリプトモジュール、およびスタイルを登録するために必要なパラメータをミラーリングする方法を提供する必要があります。そして、これらをブロックに関連付けられたハンドルまたはスクリプトモジュールIDとして割り当てます。

次の形状を取るオブジェクトを提供することができます:

  • handlestring) – スクリプトの名前。省略した場合、自動生成されます。
  • dependenciesstring[]|{ id: string, import?: 'dynamic'|'static' }[]) – このスクリプトが依存する登録されたスクリプトハンドルの配列。スクリプトモジュールは、静的依存関係に対して単純な文字列を使用するか、動的依存関係を示すためにオブジェクト形式を使用できます。動的依存関係は、実行時に使用されるかどうかが不明な依存関係であり、通常は動的import('module-id')構文と共に使用されます。デフォルト値:[]
  • versionstring|false|null) – スクリプトのバージョン番号を指定する文字列。これがある場合、URLにキャッシュバスティングのためのクエリ文字列として追加されます。バージョンがfalseに設定されている場合、現在インストールされているWordPressバージョンと等しいバージョン番号が自動的に追加されます。nullに設定されている場合、バージョンは追加されません。デフォルト値:false

定義は、.asset.phpで終わる別のPHPファイルに保存され、block.jsonにリストされたJS/CSSファイルの隣にあります。WordPressは、パターンマッチングを通じてこのファイルを自動的に検出します。このオプションは、@wordpress/scriptsパッケージでアセットファイルを自動生成するオプションになると期待されています。

例:

  1. build/
  2. ├─ block.json
  3. ├─ index.js
  4. └─ index.asset.php
  1. ``````bash
  2. { "editorScript": "file:./index.js" }
  3. `
  1. ``````bash
  2. <?php
  3. return array(
  4. 'dependencies' => array(
  5. 'react',
  6. 'wp-blocks',
  7. 'wp-i18n',
  8. ),
  9. 'version' => '3be55b05081a63d8f9d0ecb466c42cfd',
  10. );
  11. `

フロントエンドのエンキュー

WordPress 5.8リリースから、フロントエンドでレンダリングされるときにのみ、ブロックタイプのスクリプトとスタイルをエンキューするようにWordPressに指示することが可能です。これは、block.jsonファイル内の次のアセットフィールドに適用されます:

  • script
  • viewScript
  • style
  • viewStyle(WordPress 6.5.0で追加)

国際化

WordPressの文字列発見システムは、このドキュメントで翻訳可能としてマークされたフィールドを自動的に翻訳できます。最初に、ブロックメタデータを提供するtextdomainプロパティをblock.jsonファイルに設定する必要があります。

例:

  1. {
  2. "title": "My block",
  3. "description": "My block is fantastic",
  4. "keywords": [ "fantastic" ],
  5. "textdomain": "my-plugin"
  6. }

PHP

PHPでは、ローカライズされたプロパティは、_x関数呼び出しで自動的にラップされ、register_block_typeを実行する際にWordPressのバックエンドで処理されます。これらの翻訳は、プラグインのスクリプトハンドルまたはWordPressコアのwp-block-libraryスクリプトハンドルにインラインスクリプトとして追加されます。

  1. ``````bash
  2. <?php
  3. $metadata = array(
  4. 'title' => _x( 'My block', 'block title', 'my-plugin' ),
  5. 'description' => _x( 'My block is fantastic!', 'block description', 'my-plugin' ),
  6. 'keywords' => array( _x( 'fantastic', 'block keyword', 'my-plugin' ) ),
  7. );
  8. `

実装は、プラグインのメタデータを取得するためにプラグインの内容を解析する既存のget_plugin_data関数に従い、動的に翻訳を適用します。

JavaScript

JavaScriptでは、registerBlockTypeメソッドを@wordpress/blocksパッケージから使用し、block.jsonから読み込まれたメタデータオブジェクトを最初のパラメータとして渡すことができます。すべてのローカライズされたプロパティは、PHPでの動作と同様に、_x@wordpress/i18nパッケージから)関数呼び出しで自動的にラップされます。

例:

  1. import { registerBlockType } from '@wordpress/blocks';
  2. import Edit from './edit';
  3. import metadata from './block.json';
  4. registerBlockType( metadata, {
  5. edit: Edit,
  6. // ...other client-side settings
  7. } );

後方互換性

既存の登録メカニズム(サーバー側とフロントエンドの両方)は引き続き機能し、block.jsonに基づく登録のための低レベルの実装詳細として機能します。

すべての詳細が準備でき次第、Core Blocksは段階的に移行され、サードパーティのブロックには、ブロック登録APIのリファクタリングを促す警告がコンソールに表示されます。

以下のプロパティは、クライアント側の後方互換性の理由からサポートされる予定です。将来的には、いくつかは代替APIに置き換えられる可能性があります:

  • edit – 詳細については編集と保存のドキュメントを参照してください。
  • save – 詳細については編集と保存のドキュメントを参照してください。
  • transforms – 詳細については変換のドキュメントを参照してください。
  • deprecated – 詳細については非推奨のブロックのドキュメントを参照してください。
  • merge – 現時点では文書化されていません。その役割は、複数のブロックを1つに統合することです。
  • getEditWrapperProps – こちらも文書化されていません。その役割は、ブロック編集のコンポーネントラッパーに追加のプロパティを注入することです。

:

  1. import { registerBlockType } from '@wordpress/blocks';
  2. registerBlockType( 'my-plugin/block-name', {
  3. edit: function () {
  4. // Edit definition goes here.
  5. },
  6. save: function () {
  7. // Save definition goes here.
  8. },
  9. getEditWrapperProps: function () {
  10. // Implementation goes here.
  11. },
  12. } );

WordPressによってサポートされる動的ブロックの場合、render_callbackプロパティをサーバー上のregister_block_type関数を使用して登録することが依然として可能であるべきです。