WordPress6.0で追加された関数・クラス・アクション/フィルタ―フックまとめ

はじめに

2022年5月24日WordPress 6.0がリリースされました。

この記事では、PHPコードに焦点を絞り、新たに追加された関数・アクション/フィルタ―フック・クラスをまとめたものです。

あわせて、WordPress6.0でアップデートされた関数・クラス・アクション/フィルタ―フック、および非推奨となったものも最後にまとめています。

条件として、WordPress本体のソース内で「PHPファイルの中で、コメントに @since 6.0.0 と記載があるもの」を手動で抽出してリストアップしました。

注意点

  • マイナーリリースにより、仕様が若干変わる可能性があります。最新の仕様は、WordPressの開発リポジトリまたはWordPress.orgのリリースニュース(Make WordPress Core)などで確認してください。
  • 独断で「これは使えそう」「重要そう」と思った項目については、★マークを付けています。

関数

関数に関しては、以下のものを除外しています。

  • コメントのアクセス修飾子がprivateのもの( @access private
  • 関数名がアンダーバー始まり
  • おそらく内部的な利用にとどまるもの
  • 内部にフィルタ―フックが用意されており、直接呼ぶ事は想定されていないもの

wp_recursive_ksort

配列を再帰的に辿り、キーをアルファベット順にソートします。

$array = array(
    'c' => 'foo',
    'a' => 'bar',
    'b' => 'baz',
    'd' => array(
        'cc' => 'foo',
        'aa' => 'bar',
        'bb' => 'baz',
    ),
    array(
        'ccc' => 'foo',
        'aaa' => 'bar',
        'bbb' => 'baz',
    )
);
​
wp_recursive_ksort( $array );
var_dump( $array );
​
// ↓↓↓出力↓↓↓      
array (size=5)
  'a' => string 'bar' (length=3)
  'b' => string 'baz' (length=3)
  'c' => string 'foo' (length=3)
  'd' => 
    array (size=3)
      'aa' => string 'bar' (length=3)
      'bb' => string 'baz' (length=3)
      'cc' => string 'foo' (length=3)
  0 => 
    array (size=3)
      'aaa' => string 'bar' (length=3)
      'bbb' => string 'baz' (length=3)
      'ccc' => string 'foo' (length=3)

フィルターフック

media_date_column_time

メディアライブラリをリスト表示にした時の日付(登録日時)をフィルタリングします。

function custom_media_date_column_time( $h_time, $post ) {
  // 日付の形式をY/m/dに統一する
  return get_the_time( __( 'Y/m/d' ), $post );
}
add_filter( 'media_date_column_time', 'custom_media_date_column_time', 10, 2 );

before:

メディアライブラリ Before

after:

メディアライブラリ After

plugin_install_description

「プラグインを追加」ページで、プラグインカードに表示される説明文をフィルタリングします。

function custom_plugin_install_description( $description, $plugin ) {
  // 特定のプラグイン・特定のバージョンの時に説明文を変更する
  if ( 'gutenberg' === $plugin['slug'] && '12.9.0' === $plugin['version'] ) {
    return 'Hello Gutengerg!';
  }
  return $description;
}
add_filter( 'plugin_install_description', 'custom_plugin_install_description', 10, 2 );
プラグインカードに表示される説明文

edit_custom_thumbnail_sizes

メディアの編集ページで、変更をどの画像サイズに適用するかを選択するラジオボタン一覧に、カスタム画像サイズを選択肢として追加する事が出来ます。

デフォルトでは以下のように、「すべての画像サイズ」「サムネイル」「サムネイル以外の全サイズ」の三つから選択する事が出来ます。

デフォルトサイズプルダウン

ここに、add_image_size などで追加したカスタム画像サイズを選択肢として表示する場合は、このフィルターで true を返却します。

add_image_size( 'custom_1', 50 );
add_image_size( 'custom_2', 100 );
add_image_size( 'custom_3', 150 );
​
add_filter( 'edit_custom_thumbnail_sizes', '__return_true' );
カスタム画像サイズを選択肢として表示する

または、カスタム画像サイズのうち一部を選択肢としたい場合は、配列で返却します。

add_image_size( 'custom_1', 50 );
add_image_size( 'custom_2', 100 );
add_image_size( 'custom_3', 150 );
​
function custom_edit_custom_thumbnail_sizes( $edit_custom_sizes ) {
    // 追加したカスタム画像サイズのうち、custom_1, custom_2のみを選択肢に出す
    return array(
        'custom_1' => 'custom_1',
        'custom_2' => 'custom_2',
    );
}
// add_filter( 'edit_custom_thumbnail_sizes', 'custom_edit_custom_thumbnail_sizes' );

※カスタム画像サイズの選択肢が表示されるのは、add_image_size 関数でカスタム画像サイズを定義した後にアップロードされた画像に限られます。

wp_admin_bar_show_site_icons

マルチサイトにおいて、管理画面のツールバーに表示されるサイトアイコンをフィルタリングします。

デフォルトはtrue(アイコンを表示する)ですが、以下の記述で無効化する事が出来ます。

add_filter( 'wp_admin_bar_show_site_icons', '__return_false' );

大量のサイトがある場合のページパフォーマンス改善のために追加されたフックのようです。

before:

マルチサイトにおいて、管理画面のツールバーに表示されるサイトアイコン Before

after:

マルチサイトにおいて、管理画面のツールバーに表示されるサイトアイコン After

the_author_link

投稿者のURLをフィルタリングします。

ユーザー情報の「サイト」項目が設定されており、get_the_author_link または the_author_link が実行された時に、このフィルタを通過します。

function custom_the_author_link( $link, $author_url, $authordata ) {
    // $linkの値の例
    // <a href="https://www.google.co.jp/" title="admin のサイトへ移動" rel="author external">admin</a>
​
    // サイトURLを新しいウィンドウで開くようにする(target="_blank"を付与する)
    return str_replace( '">', '" target="_blank">', $link );
}
add_filter( 'the_author_link', 'custom_the_author_link', 10, 3 );

★register_{$post_type}_post_type_args / register_{$taxonomy}_taxonomy_args

特定の投稿タイプまたはタクソノミーを登録するためのパラメータをフィルタリングします。

これまでは、register_post_type_argsregister_taxonomy_args フィルターフックを使って、第二引数( $post_type or $taxonomy) によって処理を切り分けていたと思いますが、フィルターフック名で特定の投稿タイプ・タクソノミーをフィルタリング出来るようになりました。

function custom_register_post_post_type_args( $args ) {
    // 投稿のラベルを変更
    $args['label'] = 'ニュース';
    return $args;
}
add_filter( 'register_post_post_type_args', 'custom_register_post_post_type_args' );
​
function custom_register_category_taxonomy_args( $args ) {
    // カテゴリーのラベルを変更
    $args['label'] = 'ジャンル';
    return $args;
}
add_filter( 'register_category_taxonomy_args', 'custom_register_category_taxonomy_args' );

pre_wp_filesize / wp_filesize

PHPの filesize 関数のラッパーである wp_filesize 関数にある二つのフィルターです。

pre_wp_filesizefilesize 関数で処理される前、wp_filesizefilesize 関数で処理された後に通ります。

特別な理由がない限り、この二つのフックを使う機会は無いような気がします。

★wp_content_img_tag

コンテンツ内の img タグをフィルタリングします。

コンテンツ内の img タグは、wp_filter_content_tags 関数によって処理され、width / height / srcset / loading 属性等が付与されます。

このフィルタを使用する事で、コンテキストに応じて最終的な画像の出力データを変更する事が出来ます。

function custon_wp_content_img_tag( $filtered_image, $context, $attachment_id ) {
	// $filtered_imageの値の例
	// <img width="150" height="150" src="http://example.com/wp-content/uploads/XXXX/XX/XXX.jpg" alt="XXX" class="wp-image-1"/>

	if ( 'the_content' === $context ) {
		// the_contentで出力される時だけ、ここで何か処理する
		return str_replace( 'hoge', 'huga', $filtered_image );
	}

	if ( 1 === $attachment_id ) {
		// 画像IDが1の時だけ、ここで何か処理する
		return str_replace( 'hoge', 'huga', $filtered_image );
	}

	return $filtered_image;
}
add_filter( 'wp_content_img_tag', 'custon_wp_content_img_tag', 10, 3 );

term_exists_default_query_args

タームが存在するかどうかチェックする時のパラメータをフィルタリングします。

このフィルターフックは、タームが存在するかどうかチェックする term_exists 関数内に追加されており、内部的に get_terms のパラメータをフィルタリングするためのもののようです。

このフィルターフックについては、どのようなケースで使用するのか読みとれませんでした。

★wp_is_large_user_count

登録ユーザー数に基づいて、「サイトを大規模なものとみなすかどうか」をフィルタリングします。

マルチサイトにおいては、「大規模ネットワークとみなすかどうか」を判断する wp_is_large_network があり、大規模ネットワークとみなされた場合、いくつかの処理がスキップまたは延期されるようです。 (10000ユーザー以上または10000サイト以上)

シングルサイトにおいても同じような概念が導入され、登録ユーザー数を指標とし、大規模サイトとみなされた場合は、管理画面の動作負荷改善のために、いくつかの処理がスキップまたは変更されます。

調べた限りでは、大規模サイトとみなされた場合( wp_is_large_user_counttrue の場合)、以下のような変更が入るようです。

投稿・固定ページ一覧の「クイック編集」メニューで、「投稿者」プルダウンが表示されなくなる

投稿・固定ページ一覧の「クイック編集」メニューの「投稿者」プルダウン

ユーザー一覧ページで、権限でフィルタリングするリンクの横に人数が表示されなくなる

ユーザー一覧ページで、権限でフィルタリングするリンク

デフォルトの閾値は 10000 ですが、ユーザー数が増えて管理画面が重いと感じる場合は、この閾値を下げてみるとよいかもしれません。

// 常に大規模サイトと見なす
add_filter( 'wp_is_large_user_count', '__return_true' );
function custom_wp_is_large_user_count( $is_large_user_count, $count, $network_id ) {
	// 登録ユーザー数が1000人より多い場合は、大規模サイトと見なす
	return $count > 1000;
}
add_filter( 'wp_is_large_user_count', 'custom_wp_is_large_user_count', 10, 3 );

★send_retrieve_password_email / retrieve_password_notification_email

ユーザにパスワードリセット用メールを送信する関数(retrieve_password)に追加されたフィルターフックです。

今回追加された2つのフックを含めると、retrieve_password 関数には以下のようなフィルターフックが存在する事になります。

フィルターフック名説明
lostpassword_user_dataユーザーデータをフィルタリングする
lostpassword_errorsパスワードリセット要求時のエラーをフィルタリングする
send_retrieve_password_email(新規追加)パスワードリセット用メールを送信するかどうかをフィルタリングする
retrieve_password_titleパスワードリセット用メールの件名をフィルタリングする
retrieve_password_messageパスワードリセット用メールの本文をフィルタリングする
retrieve_password_notification_email(新規追加)パスワードリセット用メールのデータ全体をフィルタリングする

send_retrieve_password_email の使用例

function custom_send_retrieve_password_email( $send, $user_login, $user_data ) {
	// 特定のユーザの時はメールを送信しない
	if ( 'admin' === $user_login ) {
		return false;
	}
	return $send;
}
add_filter( 'send_retrieve_password_email', 'custom_send_retrieve_password_email', 10, 3 );

retrieve_password_notification_email の使用例

function custom_retrieve_password_notification_email( $defaults, $key, $user_login, $user_data ) {
	// メールの送信先を変更する
	$defaults['to'] = 'test@example.com';
	// 件名を変更する
	$defaults['subject'] = 'パスワードリセット用のメールです';
	// 特定のユーザの時だけ件名を変更する
	if ( 'admin' === $user_login ) {
		$defaults['subject'] = '管理者のパスワードがリセットされようとしています!';
	}
	return $defaults;
}
add_filter( 'retrieve_password_notification_email', 'custom_retrieve_password_notification_email', 10, 4 );

アクションフック

★registered_post_type_{$post_type} / registered_taxonomy_{$taxonomy}

特定の投稿タイプまたはタクソノミーが登録された後に発火します。

これまでは、registered_post_typeregistered_taxonomy アクションフックを使って、第一引数( $post_type or $taxonomy) のスラッグによって処理を切り分けていたと思いますが、アクションフック名で特定の投稿タイプ・タクソノミーをフィルタリング出来るようになりました。

function custom_registered_post_type_post( $post_type, $post_type_object ) {
	// 投稿の一般名を変更
	$post_type_object->labels->name = 'ニュース';
}
add_action( 'registered_post_type_post', 'custom_registered_post_type_post', 10, 2 );

function custom_registered_taxonomy_category( $taxonomy, $object_type, $taxonomy_object ) {
	// カテゴリーの一般名を変更
	$taxonomy_object['labels']->name = 'ジャンル';
}
add_action( 'registered_taxonomy_category', 'custom_registered_taxonomy_category', 10, 3 );

同様のフックとして、前述の register_{$post_type}_post_type_args / register_{$taxonomy}_taxonomy_args フィルターフックがありますが、これは register_post_type で指定されたパラメータを変更するためのフックです。

一方、registered_post_type_{$post_type} / registered_taxonomy_{$taxonomy} アクションフックは、登録された投稿タイプ・タクソノミーのオブジェクト(WP_Post_Type)に対して発火する、という違いがあります。

多少フックの書き方は変わるものの、どちらのフックを使っても同じようなことは出来ると思います。

クラス

クラスに関しては、一般的な開発ではほぼ使わないであろう事、また自分が詳しく解説出来る自信がありませんので、各クラスの冒頭のコメント欄を翻訳した文章のみ記載しておきます。

WP_REST_Block_Patterns_Controller

REST APIでブロックパターンにアクセスするためのコアクラス

WP_REST_Block_Pattern_Categories_Controller

REST APIでブロックパターンカテゴリーにアクセスするためのコアクラス

アップデートされた関数

影響が大きそうな関数のみをピックアップしています。

size_format

バイト数をフォーマットする関数ですが、より大きな単位(PB / EB / ZB / YB)をサポートするようになりました。

まとめると、以下の単位がサポートされます。

スラッグ名前
YBヨタバイト
ZBゼタバイト
EBエクサバイト
PBペタバイト
TBテラバイト
GBギガバイト
MBメガバイト
KBキロバイト
Bバイト

validate_current_theme

現在有効なテーマが必須ファイルを含んでいるかどうかをチェックする関数ですが、ブロックテーマでは/templates/index.html (または /block-templates/index.html ) が存在すれば、index.php が無くてもこの関数は true を返すようになりました。

つまり、ブロックテーマにおいて、index.php を含める事が必須ではなくなりました。

アップデートされたフィルタ―フック

影響が大きそうなものは特に無し

非推奨となった関数

無し