WordPress 5.6 「Simone（シモン）」がリリースされました。2020年の最新バージョンのWordPressのコアにマージされた注目すべき機能とその他の変更点について、詳しくみていきましょう。

以前のリリースと同様に、WordPress 5.6にはブロックエディタのいくつかのバージョンが組み込まれるかたちとなり、Gutenbergプラグインをまだインストールしてサイトを更新していないWordPressユーザーにとっては、編集画面の進化が明白になります。

ただし、改善点はブロックエディタだけではありません。新しいデフォルトテーマであるTwentyTwenty-One、メジャーリリースの自動更新、PHP 8.0サポートの改善、REST API認証のアプリケーションパスワードなど、複数の機能がWordPress本体に追加されています。

WordPress5.6には、もちろん、さらに多くの変化が。アクセシビリティの改善、UIの機能強化、多数のバグ修正、そして、その他にも開発者向けの膨大な数の変更点があります。

WordPress 5.6の開発サイクルの詳細もあわせてご確認ください。

それでは、詳細を見てみましょう。

ブロックエディタの新機能

WordPress 5.6では、Gutenbergプラグインの複数バージョンがコアに組み込まれているため、WordPressで執筆を行う人は、その改善点に気付くはずです。ブロックパターンの強化、情報パネルの文字数、キーボードナビゲーションの強化、ドラッグアンドドロップUIの改善など。

ブロックエディタに追加されたすべての改善と変更点は、リリースアナウンス（8.6、8.7、8.8、8.9、9.0、9.1、9.2）をご確認ください。Gutenberg 9.3および9.4で実装されたバグの修正とパフォーマンスの改善もWordPress 5.6に組み込まれています。

ブロックエディタに見られる、興味深い変更点がこちら。

  1. ブロック、パターン、UIの改善
  2. ブロックAPI V2
  3. ブロック開発者向けの追加機能と改善点

ブロック、パターン、UIの改善

新しいブロック機能、拡張機能、バグの修正により、全体的な編集のしやすさが向上。また、アクセシビリティに関しても素晴らしい改善が見られます。ウェブサイトをWordPress 5.6に更新すると、以下のようなブロックエディタの強化が期待できます。

カバーブロック内ビデオの位置制御

Gutenberg 8.6からカバーブロックに追加されたビデオ位置のコントロールにより、焦点を移動したり、ビデオの位置を設定したりできます。この機能は、以前は画像背景でのみ使用できました。

カバーブロック内ビデオの位置制御
カバーブロック内ビデオの位置制御

位置の値は、フォーカルポイントピッカーで好みの場所をクリックするか、キーボードの矢印キーを使用して設定します。Shiftキーを押したままにすると、値を10ずつ動かせます（#22531も参照のこと）。

ブロックパターンの更新

WordPress 5.6には、Gutenberg 8.6で追加された各種ブロックパターンの改善も含まれています。

大見出しと段落のレイアウト、テキスト、色が更新されました（#23858）。

2カラムのテキストの見出しがテキストブロックから出て、カラム上に配置されるようになりました（#23853）。

引用パターンで、上部に画像、下部に区切り線が組み込まれました。

新しい引用パターンの画像と区切り線
新しい引用パターンの画像と区切り線

Gutenberg 8.7で、新しい見出しと段落のパターンが追加されています（#24143）。

WordPress5.6の見出しと段落のパターン
WordPress5.6の見出しと段落のパターン

ブロック挿入画面で、ブロックパターンのカテゴリドロップダウンが追加され、使いやすさが向上しました。これにより、パターンをカテゴリでフィルタリングできます。パターンがたくさんある場合に非常に便利です（#24954）。

ブロックパターンのカテゴリドロップダウン
ブロックパターンのカテゴリドロップダウン

動画字幕のサポート

動画ブロックが動画字幕をサポートするようになりました。

動画ブロックで字幕を追加
動画ブロックで字幕を追加

ちなみに、WebVTT（Web ビデオテキストトラック）（<track>要素を使用し、時間軸の組み込まれたテキストトラック（字幕やキャプションなど）を表示するための形式）で字幕原稿を用意する必要があります（#25861）。

track要素で複数言語の字幕にリンクする
track要素で複数言語の字幕にリンクする

.vttファイルを読み込むと、サイトの閲覧者は好きな言語で字幕を表示できるようになります。

動画字幕のユーザー設定
動画字幕のユーザー設定

複数のブロックをカラムブロックに変換

選択した複数のブロックをカラムブロックに変換する機能が便利です。

複数のブロックを選択
複数のブロックを選択

カラムに使いたいブロックを選択し、ブロックツールバーにあるボタンをクリックします。

すると、選択したブロックが、カラムブロックの中身として変換されます。

3つのブロックを3カラムに変換
3つのブロックを3カラムに変換

カバーブロックの背景パターン

カバーブロックに背景パターンを表示できるようになりました。

カバーブロックの背景パターン
カバーブロックの背景パターン

背景パターンを追加するには、パターン画像をアップロードし画像の繰り返しを有効にします（WordPressのメディアライブラリについてもあわせてご覧下さい）。

完了したら、好みで焦点を調整し、固定の背景とさまざまな組み合わせを試してみましょう。

画像サイズコントロールがメディアと文章ブロックに登場

Gutenberg 9.1で、メディアと文章ブロックの画像に、新しい画像サイズコントロールが採用されました。

用意されている全画像サイズから好みのものを選択できます（#24795）。

メディアと文章ブロックの画像サイズ
メディアと文章ブロックの画像サイズ

Block API V2

新たなBlockAPIバージョンでは、ブロックによるラッパー要素のレンダリングが可能です。このバージョンの目標は、Ella van Durpe氏によると、エディタのDOMを軽量化し、フロントページコンテンツとのマッチを実現することだそうです。

これの最大のメリットとして、マークアップがエディタで同じである場合、テーマやプラグインからブロックコンテンツのスタイリングをより簡単に行えるようになります。

このバージョンでは、ブロックタイプの登録時にapiVersionプロパティを宣言する必要があります。

registerBlockType( name, { apiVersion: 2 } );

新しいAPIでは、ブロックEdit関数のuseBlockPropsフックも必要になります。このフックは、ブロックのラッパー要素をブロック要素としてマークするためのものです。

このフックに渡されたプロパティはすべてマージされ、ラッパー要素に返されます。開発ノートには次の使用例が掲載されています。

import { useBlockProps } from '@wordpress/block-editor';
 
function Edit( { attributes } ) {
	const blockProps = useBlockProps( {
		className: someClassName,
		style: { color: 'blue' },
	} );
	return <p { ...blockProps }>{ attributes.content }</p>;
}

その他の例については、Block APIバージョン2をご覧ください。

ブロック開発者向けの追加機能と改善点

Block APIバージョン2の他にも、以下のような開発者向けの追加点があります。

Block Supports API

Block Supports APIを使用し、ブロック開発者はブロックに機能を追加できるようになります。色、背景、フォントサイズが、その一例です。

WordPress 5.6では、「一貫性を高め、これらのオプションをブロックに簡単に導入できるようにする」ためのいくつかの新しいブロックサポートも導入されています。

新しいブロックサポートを使用し、対応するキーをblock.jsonファイルのsupportsプロパティに追加するか、registerBlockType関数に直接追加できます。

Block Supports開発ノートの次の例から、その役割がわかります。

supports: {
	color: {
		background: true, // Enable background color UI control.
		gradient: true, // Enable gradient color UI control.
		text: true // Enable text color UI control.
	},
	fontSize: true, // Enable font size UI control.
	lineHeight: true // Enable line height UI control.
}

スタイル値は、has-<value>-<preset-category>クラス（プリセット値の場合）またはstyle 要素（カスタム値の場合）のいずれかを介しラッパー要素に自動的に付加されます。

このため、ブロックサポートはBlock API V2での使用が想定されています。

ブロックサポートは、ダイナミックブロックでも使用できます。

createBlocksFromInnerBlocksTemplate API

開発者であれば、InnerBlocksコンポーネントを使用して、他のブロックを含むカスタムブロックを作成できます。例としては、ColumnsブロックやSocialLinksブロックなどが挙げられます。

createBlocksFromInnerBlocksTemplateブロックAPIを使用し、InnerBlocksテンプレートからブロックを作成できます。

詳細やコードの例については、開発ノートをご覧ください。

ツールバーコンポーネント

ツールバーコンポーネントにも変化が見られます。

1. ToolbarGroupコンポーネント

WordPress 5.6以前は、ツールバーコンポーネントにより、関連するオプションを共通のコンテナでグループ化できました。そして、これからは、代わりにToolbarGroupコンポーネントを使用することになります。

<BlockControls>
	<ToolbarGroup>
		<ToolbarButton />
	</ToolbarGroup>
</BlockControls>
2. ToolbarButton、ToolbarItemコンポーネント

タブとして使用可能な要素をツールバーの項目（つまり、<button>）として直接使用することは非推奨になりました。アクセシビリティ向上を目的として、ボタン用にToolbarButton、他のコントロール用にToolbarItem を使用してツールバーアイテムを追加することができます。ボタンとドロップダウンメニューの例は以下にある通りです。

<BlockControls>
	<ToolbarItem as="button" />
	<ToolbarButton />
	<ToolbarItem>
		{ ( itemProps ) => ( <DropdownMenu toggleProps={ itemProps } /> ) }
	</ToolbarItem>
</BlockControls>

コアブロックパターンの無効化

core-block-patternsサポートフラグを使用してコアパターンを無効にできるようになりました（#24042）。

インライン画像エディタの無効化

Gutenberg 8.4では、インライン画像編集機能（ブロックエディタから直接画像を編集できる機能）が追加されました。

インライン画像編集
インライン画像編集

block_editor_settingsフィルタを使用すれば、画像エディタを無効にすることが可能です（#23966）。

add_filter( 'block_editor_settings', function( $settings ) {
	$settings['imageEditing'] = false;
	return $settings;
} );
インライン画像エディタの無効化
インライン画像エディタの無効化

再利用ブロックが別のパッケージに移動

以前は@wordpress/editorパッケージの一部であった再利用ブロックは、他のエディタで使用できるように@wordpress/reusable-blocksパッケージに移動されました。

新しいデフォルトテーマ「Twenty Twenty-One」

WordPress 5.6には、最新のデフォルトテーマがあります。Twenty Twenty-Oneは、アクセス性を重視した、ミニマリストデザインのWordPressテーマで、シングルカラムレイアウトとフッターサイドバーが特徴です。

この新たなテーマにはシステムフォントとパステルカラーの背景を基本とした、ミニマルデザインのカラーパレットが採用されています。

Twenty Twenty-One
Twenty Twenty-Oneテーマのプレビュー（画像引用元：Make WordPress Core）

Twenty Twenty-Oneの詳細についてはこちらの記事をご覧ください：Twenty Twenty-One—新たなWordPressのデフォルトテーマを深掘り。

メジャーリリースの自動更新

自動更新はサイトの安全性を向上し、WordPressサイトを常に最新の状態に維持することを目的にWordPress 3.7に導入されました。

マイナーリリースの自動更新は以前のバージョンから導入されていましたが、WordPress 5.6では、メジャーリリースの自動更新も手動で選択することができます（しかもその操作は簡単です）。

残念ながら、それでもこの重要なメンテナンスにかかる一連の作業は技術的知識が豊富でない方にとっては、ややとっつきにくいものかもしれません。自動更新に関する詳細はWordPressの自動更新についてという記事でご覧いただけます。

WordPress 5.6では新しいインターフェースが採用され、メジャーリリースの自動更新を有効化できるようになりました。

この機能はWordPress 5.6のベータ版開発サイクルの中で変更され、元の開発ノートには修正が加えられています。これについて、Jb Audras氏は次のように説明します。

WordPressコアの自動更新機能は次のとおりに変更されました。

  • UIデザインの一部が更新されます。
  • 既にインストール済のソフトウェアの挙動については現状のままとなります。デフォルトではマイナーリリースの自動更新が有効化されていますが、メジャーリリースの更新を適用するかどうかはユーザーが選択する必要があります（サーバーやサイト管理者によって既に使用されている定数やフィルタが優先されます）。
  • 新規インストールしたソフトウェアについては、デフォルトの挙動が変更されます。マイナーアップデート、メジャーアップデートともに自動更新がデフォルトで有効になります。

WordPress 5.6からは、新しいUIの「更新」画面でメジャーリリースの自動アップデートを有効化できます。WordPressの全ての最新バージョンへの自動更新を有効化するには、チェックボックスを利用します。

WordPressの全ての最新バージョンへの自動更新を有効化
WordPressの全ての最新バージョンへの自動更新を有効化

メジャーリリース自動更新を有効化した後、メンテナンスとセキュリティのリリースのみの自動更新に切り替えることを選択し、その範囲を限定することもできます。

メンテナンスとセキュリティのリリースのみの自動更新に切り替える
メンテナンスとセキュリティのリリースのみの自動更新に切り替える

開発者向けのメジャーリリースの自動更新

まず、WordPressコアのメジャーリリース自動アップデートが有効化されると、auto_update_core_majorオプションが、option_valueが有効化された状態でデータベースに保存されます。そのため、get_site_option( 'auto_update_core_major' )が trueを返すと、自動更新のチェックボックスにチェックが入ります。

すると、WordPressが本体のメジャーリリースの自動更新が有効化されているかどうかをWP_AUTO_UPDATE_CORE定数もしくはallow_major_auto_core_updatesフィルタで確認し、それに応じてチェックボックスを設定します。

開発者は、次のとおりWP_AUTO_UPDATE_CORE定数をfalseまたはminorに設定することでメジャーリリースの自動更新を無効化することもできます。（あわせてwp-config.phpでバックグラウンド更新を制御する方法もご覧ください）

# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables minor updates:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

WP_AUTO_UPDATE_COREで定義できる値は、true（全て）、'beta'、'rc'、'minor'、falseであることもあわせてご確認ください。

メジャーリリースの自動更新をデフォルトで無効化するもう一つの方として、新しいフィルタであるallow_major_auto_core_updatesを使うこともできます。

add_filter( 'allow_major_auto_core_updates', '_return_false' );

WordPress自動更新に関する補足

2018年にMatt Mullenweg氏は2019年の9つの優先事項を発表。その中で「ユーザーがメジャーリリースの自動更新を選択できるようにする」は7つ目の項目でした。少し遅れたものの、それが今回ついに実現しました。

メジャーリリースの自動更新は、WordPressのセキュリティと使い勝手に大きな影響を与えるはずです。一つ明確なことがあります。技術面では、メジャーリリースの自動更新はWordPress 5.6では完全には達成できない、複雑な作業です。

Slackでの深い議論の末、Josepha Haden氏はコア・コントリビューターからの懸念や質問をまとめました。

主な長期的な目標は、大多数のWordPressサイトで自動更新を適用することで、WordPressのエコシステム全体（ウェブ全体の30%以上）のセキュリティを向上することです。

いずれにせよ、コア・リード・デベロッパーのHelen Hou-Sandí氏は次のように話しています。

まだとても難しい技術的な問題がいくつか残されていて、それを実行するには非常に統制のとれた重点的な技術製品の所有権が必要になります。

このように、メジャーリリース自動アップデートUIには今後も新たな変更や改善が見られるでしょう。具体的には今後次のような変更が見込まれます。

WordPress 5.6:

  • インストール済みのソフトウェアでは、メジャーリリースの更新はユーザーによって有効化されなければなりません。既に使用されている定数やフィルタが優先されます。マイナーリリースの更新はデフォルトで有効化されます。
  • 新規インストールでは、マイナーリリース、メジャーリリースともにデフォルトで更新が有効化されています。

WordPress 5.6.1:

  • フィードバックを受けて自動更新UIにいくつかの変更点が見られるはずです。

WordPress 5.7:

  • メジャーリリースの自動更新を有効化していないユーザーに対して、サイトヘルス画面に有効化を促すメッセージが表示されることが予想されます。
  • WordPress 5.7インストールの過程に、自動更新の選択画面が追加されるはずです。

自動更新についての大きな懸念はユーザーの信頼感です。Helen氏は次のように話します。

ユーザー、特にこれまでWordPressの更新に関して嫌な経験をしたことのある方の信頼を獲得するために、まだするべきことはたくさんあると思います。

とは言え、全てのWordPressサイトは本体とプラグイン、テーマの組み合わせに他なりません。Helen氏の言葉を借りると、次の通りです。

WordPressの更新は基本的に安全で、保護機能も内蔵されていますが、サイトにはあらゆるソースからの様々なコードが使用されているので、「全てのWordPressサイト」にとって「100%」安心ということはあり得ません。

本体の自動更新を有効化しているユーザーは定期的にサイトのバックアップをとるか、自動バックアップを提供するレンタルサーバーを選ぶべきでしょう。

WordPressの自動更新は、プラグインやテーマの自動更新を含め、全体的な更新の操作にも影響を与えるでしょう。Joost de Valk氏は次のように話します。

WordPressの自動更新をデフォルトで有効化した場合、プラグインの自動更新も有効化する必要があります。そうでないと、本体の更新に伴い変更しなければならない点をプラグインやテーマで変更できません。ユーザーは「WordPressが自動更新をするのであればプラグインとテーマも自動更新する」ことを期待するでしょう。

WordPress 5.6でのサイトヘルスに関する変更

これまで見てきた機能以外に、WordPress 5.6ではサイトヘルスツールの機能も改善されており、バックグラウンドでこれまでとは異なる動作をします。

サイトヘルスチェックのデータ検証

サイトヘルステストの問題点のレスポンスを検証機能が確認します。検証機能は無効なレスポンスを破棄することで、サイトヘルスが致命的な問題を引き起こし、その後の操作を停止してしまうのを防ぎます。

今回の改善により、無効なレスポンスはサイトヘルスのステータスに影響を与えないようになりました（#50145）。

RESTエンドポイントを利用した非同期テスト

サイトヘルスはサイトの健康状態を監視する便利なセキュリティ機能です。

この機能ではサイトの健康状態についての全体像をユーザーに示すために、いくつかのセキュリティテストが実行されます。

このテストは2つのカテゴリーに分類できます。ページの読み込み時に実行する直接的テストと、完了までに一定の期間を要する場合があり、JavaScriptを通して後ほど実行する非同期のテストです。

以前これらのテストはadmin-ajax.phpを用いて実行されていました。WordPress 5.6では、admin-ajax.phpではなく、新たなREST APIエンドポイントが利用されます。WordPress 5.6からは非同期テストは/wp-json/wp-site-health/v1というネームスペースに位置します。

新たなREST APIの強化により、プラグインやテーマもRESTエンドポイントを利用することができ、その用途はヘルステストのAjaxに限られません。

今後、全ての非同期テストで、デフォルトではfalseの値となるhas_rest引数を宣言することができます。

wp-admin/includes/class-wp-site-health.phpの次のコードは、WordPress 5.6の非同期テストの配列です。

'async'  => array(
	'dotorg_communication' => array(
		'label'             => __( 'Communication with WordPress.org' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/dotorg-communication' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_dotorg_communication' ),
	),
	'background_updates'   => array(
		'label'             => __( 'Background updates' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/background-updates' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_background_updates' ),
	),
	'loopback_requests'    => array(
		'label'             => __( 'Loopback request' ),
		'test'              => rest_url( 'wp-site-health/v1/tests/loopback-requests' ),
		'has_rest'          => true,
		'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_loopback_requests' ),
	),
	'authorization_header' => array(
		'label'     => __( 'Authorization header' ),
		'test'      => rest_url( 'wp-site-health/v1/tests/authorization-header' ),
		'has_rest'  => true,
		'headers'   => array( 'Authorization' => 'Basic ' . base64_encode( 'user:pwd' ) ),
		'skip_cron' => true,
	),
),

スケジュールに基づくサイトヘルス診断

非同期テストはページの読み込みの遅さやタイムアウトを防ぐために実施されてきましたが、そんな懸念はスケジュールに基づくテストにはありません。

これを考慮して、上述のhas_rest引数に加え、テストの配列では呼び出し可能なインスタンスであるasync_direct_test引数を（上記のコードを使って）宣言することも可能です。

テストがスケジュールされたイベントの最中に実行される場合、テストはREST APIエンドポイントを使用せず直接実行されます。

REST API認証用アプリケーションパスワード

アプリケーションパスワードとは、様々なWordPress APIへ認証リクエストを行うための新たなシステムです。

パスワードは24文字のアルファベットの大文字、小文字、数字で構成され、手動で作成もしくはRST APIによって生成されます。

手動で新たなアプリケーションパスワードを作成するには、「あなたのプロフィール」画面を開き、ページをスクロールします。

「あなたのプロフィール」画面のアプリケーションパスワード
「あなたのプロフィール」画面のアプリケーションパスワード

アプリケーションパスワードの名前を選び、確認します。すると新しいパスワードが表示されます。

新しいアプリケーションパスワード
新しいアプリケーションパスワード

アプリケーションパスワードは次のとおり、4文字ずつスペースで区切られます。

gsUc UhkU 0ScI gdRd TGoU vrW5

ただし、パスワードはスペースを入れても入れなくても使用できます。

認証フロー上のアプリケーションパスワードにはスペースは含まれません。スペースは長いパスワードを手動で入力する際に分かりやすくする目的でのみ使われます。

区切っても、スペースなしでも、1文字ごとにスペースを入れたとしても使えます。

「あなたのプロフィール」画面では、アプリケーションパスワードの閲覧、作成、破棄ができます。最終使用日、IPの最後尾の欄は破棄すべき未使用のパスワードを探すのに便利です。

最終使用日とIP最後尾の欄
最終使用日とIP最後尾の欄

この記事の執筆時点では、アプリケーションパスワードは、REST API認証リクエストとXML-RPC APIで使用できます。しかし、将来的には他のAPIでも使用できるようになるでしょう。

アプリケーションパスワードの認証スキームはWordPressで今後採用されるAPIにも順次適用されることが予想されます。例えば、GraphQLなどのシステムがWordPressで採用されるようになれば、アプリケーションパスワードが信頼性の高い組み込みの認証インフラストラクチャとなるでしょう。

Postmanを使用したREST API認証
Postmanを使用したREST API認証

wp-login.phpでのアプリケーションパスワードの使用はできません。

この機能に関する詳細や技術的な情報は次のリンクをご参照ください。

PHP 8サポートの強化

PHP 8.0にはたくさんの新機能や最適化が反映されており、まさに開発言語革命の一歩です。PHPの新バージョンには後方互換性を損なうアップデートが採用されていて、非推奨の機能が今回公式に廃止されました。そのため、WordPressでPHP 8のサポートを強化するのは難しい試みだと考えられます。

実際、たとえWordPressのコア・コントリビューターがWordPress 5.6とPHP 8の互換性を実現するために懸命に努力したとしても、潜在的な問題を全て検出するのは難しいもの。今回の目標は、WordPressエコシステム全体のPHP 8との互換性を実現することですが、それは現状非常に難しい課題のようです。

さらに、WordPressサイトには必ず少なくとも1つのテーマと複数個のプラグインが使用されています。そのため、WordPress本体がPHP 8にうまく対応したとしても、プラグインやテーマがすぐにPHP 8と調和するとは考えにくいでしょう。

Jonathan Desrosiers氏の次の意見に私たちも賛同しています。

より広範なエコシステム（プラグイン、テーマなど）内でのPHP 8サポートの状態はつかむことができません。そのため、WordPress 5.6のPHP 8への対応は「ベータ版」とみなすべきでしょう。

この表現は、まだまだ課題が多いことを考慮しつつも、これまでの成果を讃えており、現状を良く指し示しているように思えます。

とは言え…

全てのプラグインやテーマ開発者、ホスティングサービスについては、コードにおけるPHP 8への対応が求められています。こうすることで、より早い段階で本当の意味で「完全に互換性のある」WordPressを実現でき、エンドユーザーの不安を払拭することができるでしょう。

知っておくべきPHP 8の変更点

上述のとおり、WordPressのPHP 8との完全な互換性は「現在進行形」です。Jonathan Desrosiers氏はWordPress開発者が知っておくべきPHP 8の機能と変更の一覧を公開しています。

名前付き引数

現在のPHPの名前付き引数は、パラメータの位置ではなく、パラメータ名に基づき引数を関数に渡すことができます。そのため、自己文書化コードを記述することができ、引数は順序に依存せず、デフォルトの値を自由にスキップできます。

残念ながら、現在の名前付き引数はWordPressで後方互換性の問題を引き起こすことがあります。その主な原因はパラメータ名が現在の監査完了までに変更される可能性があるからです。そのため、この記事の執筆時点では次のことが言えます。

WordPressの関数やクラスメソッドを呼び出す際に名前付き引数を使用する方法は（監査の最中にパラメータ名が通知なく変更される可能性があるため）監査が終了するまでは明確にサポートされておらず、推奨もされません。監査終了の際には、開発ノートでの発表となります。

内部関数の厳密な型/値の検証

不正な型のパラメータを渡すと、内部関数とユーザー定義関数の動作が異なります。ユーザー定義関数はTypeErrorを出し、内部関数はいくつかの条件に応じてさまざまな挙動をします。

これらの不整合を取り除くために、PHP 8では、パラメータタイプが一致しない場合、内部パラメータ解析APIは常にThrowErrorを生成します。

厳密な型の宣言はWordPressそのものでは使用されていません。ただし、コア・コントリビューターは、無効な型がWordPressの関数に渡されるのを防ぐために、これに取り組んでいます。その作業が完了するまで、このPHP 8の変更により、「特に、フィルターにフックされたコードによって値の型が誤って変更された場合」、TypeErrorが発生する可能性があります。

算術演算子とビット演算子のより厳密な型のチェック

以前のバージョンのPHPでは、配列、リソース、またはオーバーロードされていないオブジェクトに対して算術演算子とビット演算子を使用できましたが、動作に一貫性がなく、場合によっては非合理的でさえありました。

var_dump([] % [42]);
// int(0)

PHP 8では、挙動は常に同じであり、オペランドが配列、リソース、またはオーバーロードされていないオブジェクトの場合、すべての算術演算子とビット演算子はTypeErrorという例外へとつながります（RFCを参照のこと）。

これについても、多くのエラー、警告、通知の変更などと同様に、コア・コントリビューターによる追加の作業が必要になります。

繰り返しになりますが、まだ解決されていない問題が複数あるため、本番環境でPHP 8に切り替える前に、ステージング環境または開発環境で互換性テストを実行することを強くお勧めします。WordPressとPHP8.0の詳細をご覧ください。

開発者向けのその他の変更点

WordPress 5.6では開発者向けに多くの変更が導入されており、すべてを網羅することはできませんが、重要なポイントを3つご紹介します。

1. wp_after_insert_postアクションフック

WordPress 5.6より前は、save_postsまたは同様のアクションを使用して、投稿が公開された後に任意のコードを実行できました。WordPress 5.6では、新しくwp_after_insert_postアクションフックが導入されました。このフックは、タクソノミーのアイテムやメタデータが保存されたときにのみ実行されます。

さらに、これらのフックの実行を防ぐ用途でいくつかの関数が更新されました。新しい$fire_after_hooksパラメータがwp_insert_posts()、wp_update_post()、そしてwp_insert_attachment()関数に追加されました。falseに設定すると、挿入後のフックが実行されなくなります。

詳細については、開発ノートをご確認ください。

2. 型変換

型変換関数intval()、strval()、floatval()、およびboolval()が、直接型変換を優先するかたちで削除されました。

  1. intval() → (int)
  2. strval() → (string)
  3. floatval() → (float)

直接型変換は型変換関数よりも最大6倍高速であるため、この変更はパフォーマンスに直接影響を及ぼします。

3. WP_Errorオブジェクト

WP_Errorクラスが拡張され、複数のWP_Errorインスタンスを1つにマージできるようになりました。以前は、これは手動でしか実行できませんでした。現在、WordPress 5.6では、複数のWP_Errorインスタンスの処理に効果を発揮する3つの新しいメソッドが導入されています。以下のコードは、開発ノートにある例です。

<?php
$error_1 = new WP_Error(
	'code1',
	'This is my first error message.',
	'Error_Data'
);
 
$error_2 = new WP_Error(
	'code2',
	'This is my second error message.',
	'Error_Data2'
);
 
// Merge from another WP_Error.
$error_1->merge_from( $error_2 );
 
// Retrieve all error data, optionally for a specific error code.
$error_1->get_all_error_data( 'code2' );
 
// Export to another WP_Error
$error_1->export_to( $error_2 );

開発者のためのその他の読み物

WordPress 5.6で導入された変更点すべてを説明することはできませんが、以下のリソースから詳しく掘り下げることができます。

まとめ

WordPress 5.6は、ユーザーと開発者の両方にとっての多くの機能と変更点が加えられたメジャーリリースです。Webテクノロジーの進化が、WordPressのセキュリティ、パフォーマンス、使いやすさ、アクセシビリティにもたらす影響を観察するのは楽しいものです。

進化に終わりはありません。今後のリリース予定日をすでに確認できます。

WordPress 5.6に実装された機能の中でどれが一番気に入っていますか？そして、WordPress 5.7にはどんな機能の追加を期待しますか？

Carlo Daniele Kinsta

ウェブデザインとフロントエンド開発をこよなく愛し、WordPress歴は10年以上。イタリアおよびヨーロッパの大学や教育機関とも共同研究を行う。WordPressに関する記事を何十件も執筆しており、イタリア国内外のウェブサイトや雑誌に掲載されている。詳しい仕事情報はXとLinkedInで公開中。