WordPress 7.1の新機能─クライアントサイドのメディア処理、デザインツール、Abilities APIなど多数

今年2回目のメジャーリリースとなるWordPress 7.1は、今月8月19日にリリース予定です。今回は、開発者や制作会社、ブロガーなど、WordPressを扱う幅広いユーザーにとって注目のアップデートになりそうです。

WordPress 7.1では、CMSのほぼ全体にわたってさまざまな機能が追加・改善されます。なかでも私たちが特に注目しているのが、クライアントサイドでのメディア処理です。ウェブパフォーマンスとサイト表示速度を重視するKinstaにとって、この新しいメディア処理の仕組みは大きな進歩といえます。サーバーの処理効率が向上し、ページの読み込み時間の短縮も期待できます。

メディア処理以外にも、ノート機能の強化により共同作業がしやすくなるほか、常時表示される管理バーやサイトエディターの「識別情報」画面など、管理画面にもさまざまな改善が加えられます。さらに、新規ブロックや既存ブロックの機能強化、デザインツールの拡充、開発者向けのアップロードも多数。

それでは早速、WordPress 7.1の新機能を掘り下げていきましょう。

クライアントサイドでのメディア処理

WordPress 7.0までは、フロントエンドで表示する画像のサイズやサムネイルの生成、フォーマット変換、画像の回転といった処理は、すべてPHPを使用してサーバー側で行われていました。WordPress 7.1では、新たなメディア処理の仕組みが導入されます。画像のリサイズ、フォーマット変換、EXIF情報に基づく回転、サムネイルの生成が、ユーザーのブラウザ上で直接行われるようになります。

これにより、サイトのパフォーマンス向上とサーバーリソースの使用量削減が期待できます。

以下、具体的に画像処理がどう変わるのか、詳しくご紹介します。

1. クライアントサイドのメディア処理とは

これまで画像処理には、PHPのGDやImagickライブラリが使用され、サーバー側で処理が行われていました。WordPress 7.1では、各サイズの画像生成、フォーマット変換、EXIF情報に基づく画像の回転が、ユーザーのブラウザ上で直接行われるようになります。ただし、SharedArrayBufferへのアクセスに必要なDocument-Isolation-Policy（DIP）ヘッダーをブラウザがサポートしている必要があります。

ブラウザ側で画像を処理するため、WordPressに送信されるのは元画像1枚だけではなく、処理後に生成された各画像ファイルになります。これにより、サーバーのCPUとRAMの使用量を抑えられる一方、個々のサムネイルをアップロードするためのHTTPリクエストは増加します。

本記事執筆時点で、Document-Isolation-Policyに完全対応しているのは、デスクトップ版のChrome 137以降とMicrosoft Edge 137以降のみです。SafariとFirefoxはWASMを使用した処理には対応していませんが、SafariではHEIC/HEIF形式をブラウザ上でJPGに変換できます。

2. クライアントサイドのメディア処理を支える技術

クライアントサイドのメディア処理は、主に以下の3つのコアパッケージで構成されています。

• @wordpress/vipsパッケージは、WebAssembly向けにコンパイルされたlibvipsライブラリ（wasm-vips）を使用して、クライアント側で画像を処理します。libvipsは、高速かつ効率的な画像処理ライブラリとして広く知られています。Web Worker内で並列処理を行うため、ユーザーインターフェースの動作を妨げることなく、純粋なJavaScriptによる処理よりも大幅に高いパフォーマンスを発揮します。
• @wordpress/upload-mediaパッケージは、アップロードキューや同時処理（最大5件の同時アップロードと2件の画像処理）、自動再試行、中断したアップロードの再開、オフライン対応など、アップロード処理全体を管理します。
• @wordpress/media-utilsパッケージは、HTTP通信とREST APIリクエストを処理します。

画像処理に加えて、この新機能ではアニメーションGIFをMP4またはWebM動画に自動変換できるようになります。この変換には、@wordpress/video-conversionパッケージが使用されます。Web Worker内でmediabunnyライブラリを使用し、背景が透明でないGIFを軽量な動画ファイルに変換します。

クライアントサイドのメディア処理に伴い、sideload、finalize、replace_fileというREST APIエンドポイントに加え、generate_sub_sizesとconvert_formatという2つのパラメータも導入されます。

3. WordPressユーザーにとってのメリット

クライアントサイドのメディア処理では、これまでサーバー側で行っていた画像処理をクライアント側に移します。さまざまなサイズのサムネイル生成、画像の回転、フォーマット変換といった負荷の高い処理をユーザーのブラウザで行うことで、サーバーの負荷を軽減できます。

主なメリットは以下のとおりです。

• PHPのメモリ不足エラーを削減：大きな画像ファイルの処理時に発生していたメモリ不足（PHP memory limit exceeded）エラーを回避。
• CPUとRAMの使用量を削減：サーバーのCPUとRAMの使用量を大幅に抑え、その分のリソースをほかの処理に使用できる。
• サイトパフォーマンスの向上：libvipsライブラリの高度な圧縮アルゴリズムにより、GDやImagickで生成した画像と比べて、ファイルサイズが平均約15%小さくなる。画像が軽量になることで、ページの読み込み時間も短縮される。
• アップロードの安定性向上：各画像は個別のHTTPリクエストでアップロードされるため、リクエスト数は増えるものの、それぞれ独立して処理可能。リクエストに失敗した場合は自動的に一時停止し、再試行される。

さらに、アニメーションGIFをより効率的な自動再生動画に変換したり、iPhoneからアップロードしたHEIC画像をブラウザ側でJPGに変換してから送信したりできるようになります。これにより、サーバー側の互換性に起因する問題を回避できます。また、クライアント側でデコードされた画像についてはMIMEタイプのチェックが省略されるため、サーバーがAVIFに対応していない環境でもAVIF画像を扱えるようになります。

4. 開発者への影響

開発者は、新たに追加されたwp_client_side_media_processing_enabledフィルターを使用して、以下のようにクライアントサイドのメディア処理を無効にできます。

add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );

このほか、プラグイン開発者に大きな影響はありません。メディア処理に関連するフックは、これまでどおりサーバー側で画像を処理した場合と同じように実行されます。

既存のフィルターもサーバーから設定を読み込み、従来どおり動作します。たとえば、wp_generate_attachment_metadataフィルターは2回実行されます。1回目は最初のアップロード時（create）、2回目はfinalizationエンドポイントの呼び出し後（update）です。このフィルターを使用しているプラグインも、引き続きこれまでどおり動作します。

テーマ開発者については、add_image_size()で登録した画像サイズもクライアント側で生成されるようになります。テーマで指定した画像サイズがWordPressのデフォルトの画像サイズと同じ場合は、重複する画像ファイルを生成せず、1つのファイルが両方のサイズ名で登録されます。

5. セキュリティ面でのメリット

クライアントサイドのメディア処理は、主にパフォーマンスと処理効率の向上を目的としたものですが、WordPressサイトのセキュリティにもいくつかのメリットがあります。

まず、攻撃対象となる領域を減らすことができます。前述のとおり、WordPress 7.1より前の画像処理では、GDやImagickなどのサーバー側のライブラリが使用されていました。これらのライブラリではこれまで、画像のデコード処理に関連するさまざまな脆弱性が確認されています。

クライアント側で画像を処理すると、サーバーには処理済みの画像が送信されるため、GDやImagickを使用する必要がなくなります。その結果、サーバー上で実行されるセキュリティ上重要なコードを大幅に減らすことができます。

また、画像処理はブラウザ内の隔離された環境で、Web Worker内のWebAssemblyを使用して実行されます。

処理に必要な負荷をクライアント側が担うため、DoS（サービス拒否）攻撃のリスク軽減にもつながります。

WordPressでは、クライアント側で画像を処理するためにSharedArrayBufferを使用します。これは、メインスレッドとWeb Workerで同じメモリ領域を共有できるJavaScriptオブジェクトです。

SharedArrayBufferへのアクセスを可能にするため、WordPressではDocument-Isolation-Policy: isolate-and-credentiallessヘッダーが有効になります。これにより、Chromium 137以降のブラウザ（Chrome 137以降、Edge 137以降）では、ブロックエディターを隔離された実行環境で動作させることができます。

つまり、クライアントサイドのメディア処理は、メディア処理のパフォーマンスと効率を高めるだけでなく、セキュリティの向上にもつながる機能です。

6. 公式リソース

クライアントサイドのメディア処理については、ユーザー向け・開発者向けの詳しいドキュメントが公開されています。詳細は、以下の公式リソースをご覧ください。

• WordPress 7.1のクライアントサイドメディア処理（開発者向けノート）
• クライアントサイドメディア処理の仕組み（ブロックエディターハンドブック）
• クライアントサイドメディア処理（実装ガイド）
• クライアントサイドメディア処理のフィルターとパラメータ（フックのリファレンス）

ノート機能の強化

WordPress 6.9で初めて導入されたノートには、さまざまな機能が追加・改善され、共同作業にさらに活用しやすくなりました。

WordPress 7.1では、ノートがリッチテキストに対応します。表現の幅が広がって内容も読みやすくなり、Googleドキュメント、Figma、GitHubなどの共同編集ツールで使い慣れた操作感に近づいています。

太字（Ctrl/⌘ + B）、斜体（Ctrl/⌘ + I）、リンク（Ctrl/⌘ + K）、絵文字など、基本的なインライン書式を使用できます。

テキストの一部を選択して、ブロック全体ではなく選択した箇所にノートを追加できるようになりました（ブロック内コメント）。また、同じブロックや選択したテキストに複数のノートを追加することもできます。

WordPress 7.1ではさらに、Notesで共同編集者を指定できる@メンションも導入されます。「@」を入力するとサイトのユーザー一覧が表示され、簡単に選択できます。メンションされたユーザーには、対象の投稿へのリンクを含むメール通知が送信されます。

また、表示方法にも改善が加えられています。長尺のノートはデフォルトで折りたたまれるようになり、画面を圧迫しにくくなりました。「さらに表示」／「少なく表示」を切り替えることで、全文の表示・非表示を切り替えられます。

WordPress 7.1で改良されたノート機能の詳細はこちらをご覧ください。

管理画面のUI改善

管理画面のUIには、インターフェースの一貫性を高め、画面間の移動を簡素化するいくつかの更新が施されました。

投稿エディターとサイトエディターに管理バーを常時表示

これまでは、投稿エディターとサイトエディターに管理バーが表示されませんでした。管理バー（ツールバー）は管理画面で頻繁に使用する要素であるにもかかわらず、エディターでは表示されないため、操作に一貫性がありませんでした。

WordPress 7.1ではこの仕様が変更され、投稿エディターとサイトエディターでも管理バーが常時表示されるようになっています。

ユーザーの配色がサイトエディターにも適用

管理画面全体のデザイン一貫性を考慮し、ユーザーが環境設定（「ユーザー」＞「プロフィール」＞「個人設定」の「管理画面の配色」）で選択した配色がサイトエディターにも適用されるようになります。これまでは、サイトエディターのサイドバーは黒で固定されていました。

WordPress 7.1では、エディターのサイドバーにも変更が加えられます。これまでエディターのツールバーに表示されていたサイトアイコンが削除され、WordPressツールバーに移動しました。

以前のバージョンでは、ダッシュボードに戻るにはサイトアイコンをクリックする必要がありましたが、このアイコンは本来「戻る」ためのボタンではありませんでした。

WordPress 7.1では、サイトアイコンは管理バーにのみ表示され、エディターのツールバーには、よりわかりやすい「戻る」ボタンが表示されるようになりました。

コマンドのカテゴリ分けとコマンドパレットUIの改善

コマンドパレットには、使いやすさを向上するためのさまざまな機能追加と変更が加えられています。まず、目的のコマンドを見つけやすくするため、利用可能なコマンドが「最新」「提案」「検索結果」のセクションに分けて表示されるようになりました。

また、モーダルのサイズが変更され（512px）、コマンドがより見やすくなっています。

サイトエディターに「識別情報」画面を追加

サイトエディターの「デザイン」メニューに、「識別情報」項目が追加されました。この画面では、サイトのタイトルとキャッチフレーズ、ロゴとアイコンを設定できます。これにより、サイトエディターを離れることなく、サイトの基本情報を編集できます。

メディアライブラリのグリッド表示で無限スクロールに対応

WordPress 7.0までは、media_library_infinite_scrollingフィルターを使用することで、メディアライブラリのグリッド表示で無限スクロールを有効にすることができました。ただし、デフォルトではfalseに設定されていました。開発者は、プラグインに以下のコードを追加することで、この設定を変更できました。

add_filter( 'media_library_infinite_scrolling', '__return_true' );

WordPress 7.1では、media_library_infinite_scrollingフィルターのデフォルト値がtrueに変更され、すべてのユーザーに対してメディアライブラリのグリッド表示で無限スクロールが有効になります。

また、ユーザープロフィールに新たな設定項目が追加され、ユーザーごとに無限スクロールのオン・オフを設定できるようになります。

WordPressでは、ユーザーが選択した設定がinfinite_scrollingメタキーを使用してユーザーオプションに保存されます。以下の方法で、ユーザーの設定を取得できます。

$infinite_scrolling = get_user_option( 'infinite_scrolling', $user_id );

コアブロックとブロックの改善点

WordPress 7.1では、2つの新しいブロックが導入され、既存のブロックにもさまざまな改善が加えられています。

プレイリストブロックとタブブロック

プレイリストブロックでは、コンテンツ内にシンプルなプレイリストを埋め込むことができます。

ユーザーは、タイポグラフィ、背景、サイズ、枠線、各種要素など、ブロックの外観をさまざまにカスタマイズできます。このブロック固有のスタイル設定には、「波形と再生ボタン」と「波形の背景」があります。また、「形状」設定では、音声の波形表示の形状を切り替えることができます。

プレイリストブロックは、WordPressで利用可能なすべての音声ファイル形式に対応しています。新しいMIMEタイプへの対応を追加した場合も、自動的にプレイリストブロックで使用できるようになります。

新たにコアブロックとして追加されたタブブロックでは、コンテンツをタブごとに整理して表示できます。各タブには任意のブロックを配置できるため、トピック別のコンテンツやよくある質問、製品・サービスの比較などに便利です。

カスタムHTMLブロック内のブロックを直接編集

カスタムHTMLブロックに新たな機能が追加され、HTMLコード内に編集可能なブロックを直接挿入できるようになりました。これにより、1つのコード内で固定のHTMLと編集可能なブロックを組み合わせることができます。

編集可能なブロックは内容を編集できますが、ビジュアルエディター上で移動したり削除したり、新しいブロックを追加したりすることはできません。一方、コードエディターでは元のコードを自由に編集できます。

以前は、コンテンツをすべて静的なHTMLで記述するか、すべてブロックで構成する必要がありました。WordPress 7.1では、HTMLとブロックを自由に組み合わせられるようになり、特にAIモデルを使ってコンテンツを生成する際に便利です。

これに加えて、ブロックバリエーションに静的なHTMLコードを追加できるようになっています。innerContentが新たにサポートされたことで、以下の例のようにHTMLコードブロックのバリエーションを登録できます。

wp.blocks.registerBlockVariation( 'core/html', {
	name: 'custom-image-card',
	title: 'Custom image card',
	description: 'A custom HTML block with static header/footer and an editable image.',
	innerContent: [ 
		'<h2>Static heading</h2>n', 
		null, 
		'n<footer>Static footer</footer>' 
	],
	innerBlocks: [ 
		[ 
			'core/image', 
			{ 
				id: 419,
				sizeSlug: 'medium',
				linkDestination: 'none',
				url: 'https://example.com/wp-content/uploads/...',
				alt: ''
			} 
		] 
	],
} );

innerContent内のnullは、画像ブロックを挿入する位置を示すプレースホルダーとして機能します。

なお、innerContentを使用できるのはカスタムHTMLブロックのみです。他のブロックのバリエーションに指定しても機能しません。

SVGアイコンシステムの改善

WordPress 7.0では、アイコンブロックとアイコンライブラリが新たに導入されました。WordPress 7.1では、アイコン管理システムに公開APIが追加され、プログラムからアイコンの登録、表示、削除を行えるほか、REST APIを介してアイコンを取得できるようになります。

アイコンの登録と登録解除

アイコンまたはアイコンセットを登録するには、wp_register_icon_collection()関数をinitアクションにフックして、アイコンコレクションを登録します。

function custom_icons_register_icon_collection() {
	wp_register_icon_collection(
		'my-icon-set',
		array(
			'label'       => __( 'My awesome icons', 'my-plugin' ),
			'description' => __( 'My personal set of icons.', 'my-plugin' ),
		)
	);
}
add_action( 'init', 'custom_icons_register_icon_collection' );

コレクションには、コアアイコンやサードパーテプラグインが登録した他のアイコンセットと区別するため、一意の名前を指定します。コレクション名の先頭と末尾には小文字を使用し、名前には小文字、数字、ハイフン（-）、アンダースコア（_）を含めることができます。

関数の第2引数には、アイコンライブラリに表示されるコレクション名と、任意の説明を含む配列を指定します。

コレクションを削除するには、wp_unregister_icon_collection()関数を使用します。コレクションを削除すると、そのコレクションに含まれるすべてのアイコンも自動的に削除されます。

個別のアイコンを登録するには、wp_register_icon()関数を使用します。以下はその例です。

wp_register_icon(
	'my-icon-set/motorbike',
	array(
		'label'   => __( 'Motorbike', 'my-plugin' ),
		'content' => '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">...</svg>',
	)
);

上の例では、SVG文字列を使用してアイコンを登録しました。.svgファイルから直接アイコンを登録することもできます。

wp_register_icon(
	'my-icon-set/motorbike',
	array(
		'label'   => __( 'Motorbike', 'my-plugin' ),
		'file_path' => plugin_dir_path( __FILE__ ) . 'icons/motorbike.svg',
	)
);

注意点として、SVGはwp_ksesによってサニタイズされ、現在使用できる要素は<svg>、<path>、<polygon>のみです。それ以外の要素はすべて除外されますが、今後、使用できる要素や属性が追加される可能性があります。

アイコンを削除するには、wp_unregister_icon()関数を使用します。

アイコンライブラリとブロックの更新

これに伴い、アイコンライブラリも更新され、サイトに登録されているアイコンコレクションの一覧がサイドバーに表示されるようになりました。

アイコンブロックにも変更が加えられています。これまでのバージョンでは空のプレースホルダーが表示されていましたが、デフォルトで「情報」アイコンが表示されるようになりました。さらに、ブロックツールバーに2つの新しい設定が追加され、アイコンを上下または左右に反転できるようになりました。

アイコン用の新REST APIエンドポイント

アイコンコレクションや個別のアイコンを取得するため、読み取り専用のREST APIエンドポイントも追加されました。

アイコンコレクションの取得には、以下のエンドポイントを使用します。

GET /wp/v2/icon-collections
GET /wp/v2/icon-collections/<collection>

アイコンの取得には、以下のエンドポイントを使用します。

GET /wp/v2/icons - Introduced with WordPress 7.0.
GET /wp/v2/icons/<collection>
GET /wp/v2/icons/<collection>/<name>

リクエストを実行するには、edit_posts権限を持つユーザーによる認証が必要です。

WordPress 7.1のアイコンシステムに関する詳細は、開発者向けノートをご覧ください。

新しいデザインツール

コンテンツ制作者や編集者向けにデザインツールが追加・改善され、カスタムCSSを使用しなくても、ブロックのスタイルをより細かく調整できるようになりました。

背景グラデーションのサポート

WordPress 7.1では、background.gradientがサポートされ、背景にグラデーションを設定するための新しいUIも管理画面に追加されます。

ブロック設定のサイドバーには新たに「背景」パネルが追加され、「画像」「色」「グラデーション」をそれぞれ設定できます。各設定が競合しないよう制御されているため、背景画像、背景色、グラデーションをさまざまに組み合わせて使用できます。

WordPress 7.1では、グループ、アコーディオン、プルクオート、投稿コンテンツ、引用ブロックで、background.gradientがデフォルトで有効になります。

テーマ開発者は、block.jsonのstyles.backgroundにgradientプロパティを追加することでbackground.gradientをサポートできます。また、以下のコードのように、ブロックごとに個別に設定することも可能です。

{
	"styles": {
		"background": {
			"gradient": "linear-gradient( 135deg, #1e3c72 0%, #2a5298 100% )"
		},
		"blocks": {
			"core/group": {
				"background": {
					"gradient": "linear-gradient( 135deg, #f5f7fa 0%, #c3cf8d 100% )"
				}
			}
		}
	}
}

最小幅のサポート

WordPress 7.1では、デザイナーやテーマ開発者にとって便利な機能として、minWidthがサポートされます。すでにサポートされているheight、minHeight、widthにminWidthが加わり、サイズを調整するための設定が一通り揃います。

テーマ開発者は、theme.jsonで外観ツールを有効にするか、settingsにdimensions.minWidthフィールドを追加することで、最小幅をサポートできます。

{
	"settings": {
		"dimensions": {
			"minWidth": true
		}
	}
}

最小幅のサポートは、サイト全体で有効にすることも、ブロックごとに個別に有効にすることもできます。

{
	"styles": {
		"dimensions": {
			"minWidth": "400px"
		},
		"blocks": {
			"core/group": {
				"dimensions": {
					"minWidth": "400px"
				}
			}
		}
	}
}

ブロック開発者も同様に、block.jsonにminWidthのサポートを追加できます。

{
	"supports": {
		"dimensions": {
			"minWidth": true
		}
	}
}

この設定は、デフォルトではサイドバーに表示されませんが、__experimentalDefaultControlsを使用してデフォルトの表示設定を変更できます。グローバルスタイルではデフォルトで表示されます。

グローバルスタイルでのテキストシャドウのサポート

WordPress 7.1では、グローバルスタイルでtext-shadowがサポートされます。これまでは、テキストに影を付けるにはプラグインやカスタムCSSを使用する必要がありました。

これは初期段階の実装で、エディターでテキストシャドウを調整する際にどのUIを使用するか、text-shadowをプリセットとして利用できるようにするかなど、いくつかの仕様はまだ決まっていません。

現時点では、以下のいずれかの方法でtheme.jsonにtext-shadowを定義できます。

{
	"$schema": "https://schemas.wp.org/wp/6.7/theme.json",
	"version": 3,
	"settings": {},
	"styles": {
		"typography": {
			"textShadow": "1px 1px 2em white, 0 0 2em yellow, 0 0 0.2em red;"
		},
		"blocks": {
			"core/paragraph": {
				"typography": {
					"textShadow": "1px 1px 2px red, 0 0 1em red, 0 0 0.2em red"
				}
			}
		},
		"elements": {
			"h2": {
				"typography": {
					"fontSize": "var:preset|font-size|x-large",
					"textShadow": "1px 1px 2em white, 0 0 2em yellow, 0 0 0.2em red;"
				}
			}
		}
	}
}

この結果は、以下のようになります。

開発者向けアップデート

WordPress 7.1では、テーマ・プラグイン開発者向けにも数多くのアップデートが加えられます。特に注目なのが、Abilities APIのさまざまな機能追加・改善と、デザインシステムのテーマ設定に関するアップデートです。

デザインシステムのテーマ設定

WordPress 7.1では、プラグイン開発者が管理画面の各種UI要素のスタイルをカスタマイズできる新しいデザインシステムが導入されます。このシステムは、「デザイントークン」とReactコンポーネント「ThemeProvider」の2つで構成されています。

デザイントークン

WordPressのデザイントークンは、一定の命名規則に従って定義されたCSSカスタムプロパティです。たとえば、Colorトークンファミリーでは、以下のような形式が使用されます。

--wpds-color-<property>-<target>-<tone>[-<emphasis>][-<state>]

上記の命名規則に基づくと、たとえば以下の変数は、通常の強調度を持つサーフェスの背景色を設定します。

--wpds-color-background-surface-neutral-strong

WordPress 7.1以降では、セマンティックデザイントークン一式を含む新しいwp-themeスタイルシートが導入され、プラグインの依存関係として利用できるようになります。これにより、管理画面にUI要素を追加するプラグインでデザイントークンを使用できます。

以下のように、wp-themeを依存関係に指定した独自のスタイルシートを読み込むことができます。

function myplugin_enqueue_admin_assets( $hook_suffix ) {
	wp_enqueue_style(
		'myplugin-admin-style',
		plugin_dir_url( __FILE__ ) . 'assets/css/admin.css',
		array( 'wp-theme' ),
		'1.0.0'
	);
}
add_action( 'admin_enqueue_scripts', 'myplugin_enqueue_admin_assets' );

デザイントークンを使用するメリットは、CSSプロパティの値を直接指定する必要がなくなることです。以下は、開発者向けノートで紹介されている例です。

.card {
	background-color: var(--wpds-color-background-surface-neutral-strong);
	color: var(--wpds-color-foreground-content-neutral);
	border: var(--wpds-border-width-xs) solid var(--wpds-color-stroke-surface-neutral-weak);
	border-radius: var(--wpds-border-radius-lg);
	padding: var(--wpds-dimension-padding-2xl);
}

デザイントークンは、ThemeProviderコンポーネントと組み合わせて使用することで、管理画面の特定の領域の外観をカスタマイズできます。

ThemeProvider

wp-themeスタイルシートで定義されているデザイントークンのデフォルト値は、管理画面のコンテンツを新しいReactコンポーネントThemeProviderでラップすることで上書きできます。以下は、開発者向けノートで紹介されている例です。

import { ThemeProvider } from '@wordpress/theme';
import { Card } from '@wordpress/ui';

function Application() {
	return (
		<ThemeProvider
			color={
				{
					primary: '#3858e9', 
					background: '#11004d' 
				}
			}
			cornerRadius="pronounced"
		>
			<Card.Root>
				<Card.Content>
					Card content
				</Card.Content>
			</Card.Root>
		</ThemeProvider>
	);
}

プライマリカラーと背景色のベースとなる色を指定すると、コンポーネントによって調和の取れた一貫性のあるカラースケールが自動的に生成され、UI要素間でアクセシビリティに配慮したコントラストが確保されます。

ThemeProviderを使用することで、プラグイン開発者はWordPress管理画面全体のデザインとの一貫性を保ちながら、特定のUI領域にブランド独自のデザインを反映できます。

この詳細は、開発者向けノートとデザイントークン、およびThemeProviderの公式ドキュメントをご覧ください。

Abilities APIの機能強化

Abilities APIにも複数の機能が追加され、できることがさらに広がります。

Abilities APIに新しい実行ライフサイクルを導入

まず、Abilityの実行前、実行中、実行後に適用される4つのフィルターが追加され、実行ライフサイクルが強化されました。

wp_pre_execute_abilityフィルターは、WP_Ability::execute()の開始時に実行され、WordPressが処理を開始する前にアクションの実行を中断できます。このフィルターがデフォルトの$pre以外の値（エラー、データ、真偽値など）を返すと、その時点で処理が停止し、各種チェックを行わずにその値が返されます。

このフィルターは、サイトのメンテナンス中にAbilityを無効にする、同じIPアドレスからのリクエストをレート制限する、ユニットテストでAbilityのレスポンスをモックするといった用途に活用できます。

wp_ability_normalize_inputフィルターは、デフォルト値の適用後、正式なスキーマ検証と権限チェックの前に実行されます。Abilityによる検証や処理が行われる前に、受け取ったデータを準備・変換するために使用します。たとえば、コンテキスト情報の追加、検証前のデータの正規化、AIプロンプトへの情報追加、エラー発生時のAbilityの実行中止などに利用できます。

wp_ability_permission_resultフィルターでは、Abilityの実行前に行われる権限チェックの結果を変更できます。より細かな認可ルールを追加したり、独自の権限管理の仕組みを構築したり、特定の条件下で権限チェックを省略したりすることができます。

なお、このフィルターを使用する際には注意が必要です。

プラグインでこのフィルターを使用する際は、特に注意が必要です。trueを返すと、Ability本来のpermission_callbackでアクセスが拒否されていても、その結果を上書きして実行を許可してしまう可能性があります

wp_ability_execute_resultフィルターは、Abilityの実行コールバックの完了後、出力の検証前に実行され、Abilityが返す最終的な結果を変更できます。これにより、Abilityによる処理結果を呼び出し元に返す前に変換できます。

Abilityの絞り込みと操作

$abilities = wp_get_abilities(
	array(
		'category' => 'content-generation',
	)
);

複数のパラメータを組み合わせて絞り込むこともできます。

$abilities = wp_get_abilities(
	array(
		'category'  => 'content-generation',
		'meta'      => array(
			'public' => true,
		),
	)
);

新しい公開フラグ

WordPress 7.1では、REST API、MCPアダプター、AIエージェントなどの外部クライアントからAbilityにアクセスできることを示す新しいメタデータフラグも導入されます。

Abilityを登録する際にmeta.publicを使用することで、REST APIのAbilitiesエンドポイントからAbilityを検出し、実行できるようになります。これまでは、公開するチャネルごとに個別の設定が必要でした。たとえば、REST API経由でAbilityを利用できるようにするには、'show_in_rest' => trueを指定する必要がありました。

Abilities APIのその他の改善

これまで紹介した変更に加えて、WordPress 7.1では、Abilities APIのさまざまな部分にさらなる改善が加えられています。

新しいwp_ability_validate_inputとwp_ability_validate_outputの2つのフィルターでは、WordPressのJSON Schemaでは表現できない、より複雑なルールを使用して入出力データを検証できます。前者は入力データの準備と最初のスキーマ検証が完了した後、後者はAbilityの実行後、最終的な結果が返される前に実行されます。

wp_ability_invokedアクションはWP_Ability::execute()の開始時に実行され、Abilityの呼び出しを試みるたびに追跡・記録できます。このアクションを利用することで、特定のAbilityへのアクセス試行の記録、サーバー負荷の測定、日次・月次の利用回数の集計、ブルートフォースによる呼び出しの検出などが可能です。

ただし、使用する際には注意が必要です。

このアクションには、正規化される前の入力データがそのまま渡されます。そのため、認証情報や個人情報などの機密データが含まれる可能性があることから、プラグインで入力データを無条件に記録しないよう注意が必要です

その他の開発者向けアップデート

WordPress 7.1では他にも、数多くの機能追加や改善が行われ、開発に役立つ新しいツールや、より安定した仕組みが導入されています。その他の主な変更点は以下のとおりです。

• サイトエディターの画面を設定する4つの新しいフィルター
• 投稿エディターを常にiframe内で表示
• エディターコンポーネントの更新
• jQuery UIを1.14.2に更新
• クライアントとの互換性に向けたJSON Schemaの対応
• 疑似状態へのスタイル適用
• レスポンシブなブロックスタイルと設定可能なビューポート
• ツールチップや補足情報を表示する新しい関数

最新のWordPressを支える次世代のサーバー環境

WordPress 7.1は、さまざまな面でCMSを大きく前進させるリリースです。

クライアントサイドのメディア処理は、画像処理の大きな転換点となります。これまでサーバー側で行われていた処理をクライアント側に移すことで、サーバーリソースをより効率的に使用でき、ページパフォーマンスの向上も期待できます。

AI関連では、WordPress 6.9と7.0で導入された大きな変更を受け、7.1ではその基盤がさらに強化されています。Abilities APIに新たな機能が加わり、開発者はより信頼性と安全性の高いAI連携や機能を構築できるようになります。

開発者や制作会社にとってもう1つ注目したいのが、ThemeProviderです。WordPress管理画面とのデザインの一貫性を保ちながら、プラグインのUIに独自のブランドデザインを反映できます。

このほかにも、ノート機能の強化、新しいブロック、SVGアイコンシステムの拡張など、多くのアップデートが含まれています。WordPressは進化を続け、これまで以上に今後のウェブを見据えたCMSになっています。

進化を続けるCMSには、最新技術に対応できるサーバー環境も欠かせません。Kinstaは、コンテナ化されたクラウドインフラ、高いパフォーマンス、堅牢なセキュリティ、迅速で高評価のサポートを通じて、次世代のWordPressサイトに適した環境を提供しています。

Kinstaをまだご利用でない方は、まずは無料トライアルをお試しください。ご質問や現在お悩みのことがありましたら、営業部門までお気軽にお問い合わせください。