はじめに
ブロック開発を続けていると、設定がPHPやJavaScriptに散らばり、どこを直せばよいか分かりづらくなることがあります。機能追加のたびに修正箇所が増えると、レビューや運用での負担が大きくなります。
block.json は、ブロックのメタ情報・属性・サポート設定・読み込みアセットを宣言するためのファイルです。エディターとフロントの設定差分を減らしやすいのが利点です。
実務では「仕様は block.json、実装は JS/PHP」という役割分離にすると保守しやすくなります。設定起点が1か所になるため、変更時の影響範囲を把握しやすくなります。
基本の使い方
まずは block.json で最小ブロックを定義します。
JSON
{
"apiVersion": 3,
"name": "acme/callout",
"title": "Callout",
"category": "widgets",
"icon": "megaphone",
"attributes": {
"message": {
"type": "string",
"default": "お知らせを入力してください"
}
},
"supports": {
"html": false
},
"editorScript": "file:./index.js",
"style": "file:./style.css"
}
PHP
<?php
add_action('init', function () {
register_block_type(__DIR__ . '/blocks/callout');
});
この段階で、登録・表示・編集の最低限が成立します。最初に小さく動作確認してから機能を足すのが安全です。
便利な使いどころ
block.json 中心設計は、複数ブロックをチームで運用する案件で効果が出ます。設定フォーマットが揃うため、引き継ぎコストが下がります。
また、テーマ刷新やエディター拡張時にも有効です。設定情報が分散していないので、互換性確認を進めやすくなります。
応用コード
次は、編集UIと保存処理を分離した運用向け構成です。
JavaScript
import { registerBlockType } from '@wordpress/blocks'
import { RichText, useBlockProps } from '@wordpress/block-editor'
registerBlockType('acme/callout', {
edit({ attributes, setAttributes }) {
return (
<div {...useBlockProps()}>
<RichText
tagName="p"
value={attributes.message}
onChange={(message) => setAttributes({ message })}
placeholder="メッセージを入力"
/>
</div>
)
},
save({ attributes }) {
return <p {...useBlockProps.save()}>{attributes.message}</p>
}
})
CSS
.wp-block-acme-callout {
padding: 12px 14px;
border-left: 4px solid #0ea5e9;
background: #f0f9ff;
border-radius: 8px;
}
PHP
<?php
add_action('init', function () {
register_block_type(__DIR__ . '/blocks/callout');
});
この構成なら、設定変更は block.json、見た目変更はCSS、編集体験はJSという分離が保てます。
注意点
block.json の定義と実装コードの不一致はバグの原因になります。属性名やサポート設定を変更したら、必ずJS側とセットで確認してください。
また、複数ブロックを管理する場合は命名規則を統一してください。プレフィックスとディレクトリ構成を固定すると、長期運用での混乱を防げます。
まとめ
block.json 中心の設計は、ブロック開発の見通しを保ちやすく、保守性を高める実践的な方法です。小さく導入してルールを固めるほど、後の拡張が楽になります。
まずは1ブロックを基準実装として整備し、その設計を横展開するのがおすすめです。
ポイント
- 設定起点を
block.jsonに寄せると管理しやすい - JS/PHP/CSSの責務分離で変更影響を抑えられる
- 命名規則とディレクトリ構成を先に決めると運用が安定する