WordPress 5.5の素晴らしい新機能—新リリースの詳細

WordPress 5.5がもうすぐリリースされるため、今年の2番目のWordPressリリースでコアに追加される最も注目すべき変更点と新機能を紹介する時が来ました。

最近では、WordPressの各リリースでブロックエディターに多くの機能が追加されるのに慣れています。WordPress 5.5も例外ではありません！

一方、今回のバージョンでは、CMSの使用方法に大きな影響を与えるが、エディターに関連しない多数の変更も行われています。

WordPress 5.5ではWordPressのコアに多くの変更が加えられていますが、5.5で待ち望まれていた機能の一部は、未解決の課題のために遅延され、このバージョンから削除されました。したがって、フルサイト編集、ナビゲーションブロック、ナビゲーション画面と、ウィジェット画面はWordPress 5.5ではリリースされません。

WordPress 5.5の開発サイクルの詳細については、以下のリンクをご覧ださい。

2020年7月7日：Beta 1
2020年7月14日：Beta 2
2020年7月21日：Beta 3
2020年7月27日：Beta 4
2020年7月28日：RC 1
2020年8月4日: RC 2
2020年8月10日：WordPress 5.5のドライラン
2020年8月11日：WordPress 5.5のリリース目標日

さて、PHP 5.5の新機能をご確認ください！

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

WordPress 5.5の最終リリースでは、Gutenbergプラグインの10バージョンがコアに追加され、使いやすさから機能性、パフォーマンスに至るまで、編集エクスペリエンスのあらゆる側面に影響を与える多数のUI、機能や拡張機能の改善、またはバグ修正がリリースされるようです。

すべての変更について述べることはほぼ不可能であるため、本記事では、私たちのお気に入りの新機能と改善点のみをご紹介します。

WordPress 5.5でブロックエディターに追加された改善点と新機能のより包括的なリストについては、プラグインリリースの公式発表をご参照ください。7.5、7.6、7.7、7.8、7.9、8.0、8.1、8.2、8.3、8.4、8.5

そうは言っても、本記事ではWordPress 5.5のブロックエディターの次の変更点についてご説明します。

新しいUIデザイン
ブロックデザインツール
インライン画像編集
ブロックカテゴリと新しいブロック挿入パネル
ブロックディレクトリとブロックプラグイン
ブロックパターン

新しいUIデザイン

Gutenbergプラグインの各バージョンは、編集作業を完全に変える改善点をもたらします。中には規模の小さいものも、大きいものもあります。これらの変更点の多くは、WordPressのコアにマージされるようです。したがって、WordPress 5.5でブロックエディターを初めて起動したときは、わずかに異なるインターフェイスになります。たとえば、次の点が変わります。

簡略化されたブロックツールバー
より強い色のコントラスト
新しいアイコン
ブロックムーバー
周囲の要素
デバイスのプレビュー
ドラッグアンドドロップの改善
UI全体で改善され、統一されたブロックフォーカススタイル
一度に複数のブロックをフォーマットする機能
パフォーマンス改善

上記のものは、編集エクスペリエンスに影響を与える多くの変更のほんの一部のみです。

追加の変更には、次のものがあります。

下付き文字と上付き文字

下付き文字と上付き文字の設定は、リッチテキストコントロール（Gutenberg 8.0）で利用できるようになりました。

T再設計されたアイコン、ブロックムーバー、およびより優れた色のコントラストを備えた新しいブロックツールバー

親ブロックの選択

ブロックツールバーの左側にマウスを合わせると、新しいツールバーボタンが表示されるようになります。新しいボタンを使用すると、サブ項目として入れたコンテンツの親ブロックを選択できます（Gutenberg 8.3）。

ブロックデザインツール

過去数か月にわたって、いくつかの設計ツールがGutenbergプラグインに追加されました、今回はこれらのツールは、WordPress 5.5のコアに組み込まれるようになります。

高さ管理と背景のカラー設定

最初のツールセットは、いくつかのブロックの寸法と背景の色を管理できるツールです。（Gutenberg 7.9）。

パディングとリンクのカラー管理

さらに、2つの機能がコア（Gutenberg 8.3）に追加される予定だが、本記事の執筆時点では、両方はまだ実験段階です。

カバーブロックのパディング管理。
段落、見出し、グループ、列、メディアおよびテキストブロックのリンクカラーの管理。

ブロックエディターハンドブックで説明されているように、パディング管理とリンクカラー管理はデフォルトでオフになっており、開発者はそれらのサポートを明示的に宣言する必要があります。

カバーブロックのパディングkなりをテーマに追加するには、次の行をテーマのfunctions.phpに追加するだけです。

add_theme_support( 'experimental-custom-spacing' );

段落、見出し、グループ、列、メディアおよびテキストブロックのリンクのカラー管理を有効にするには、次の行をテーマのfunctionsファイルに追加します。

add_theme_support( 'experimental-link-color' );

カスタムユニットとカスタム行の高さ

この新機能を使用すると、カバーブロックのpx、 em、rem、vwまたはvhの高さの値を設定できます。（Gutenberg 7.9）%もサポートされていますが、高さのパーセンテージが予測できないため、省略されています。

拡張された高さ管理を使用すると、Shiftキーを押しながら「↑」や「↓」を押すことにより、値を10ずつ変更できます。

開発者は、custom-unitsサポートフラグを定義して、カスタムユニットのサポートを追加できます。

add_theme_support( 'custom-units' );

特定のカスタムユニットを設定することもできます。

add_theme_support( 'custom-units', 'rem', 'em' );

開発者は、custom-line-heightのサポートフラグを定義して、見出しと段落のカスタム行の高さを追加することもできます。

add_theme_support( 'custom-line-height' );

インライン画像編集

新しい編集機能がGutenberg 8.4のブロックエディターに追加され、ユーザーが画像ブロックで画像を編集できるようになりました。

今回は子の機能がコアに統合されるため、WordPress 5.5以降では、メディアライブラリを起動しなくても、画像の位置をトリミング、回転、ズーム、調整できるため、編集作業が高速になります。

大量の写真の公開しているユーザーは、間違いなく楽になります。

画像ツールバーの「切り抜き」ボタンをクリックするだけで、新しい編集機能にアクセスできます。変更内容に満足したら、変更を適用して完了です。

WordPressは新しい画像を添付ファイルとしてメディアライブラリに保存し、元の画像から詳細（タイトル、説明、キャプション、代替テキスト、EXIFデータ）をコピーします。これにより、画像の新しいバージョンを完全に変更できます。

ブロックカテゴリと新しいブロック挿入パネル

再設計されたブロック挿入パネルは、ブロックとパターンをカテゴリ別に表示し、編集エクスペリエンスを大幅に改善し、ブロックとパターンを見つけやすくします（Gutenberg 8.3）。

ブロックディレクトリとブロックプラグイン

ブロックディレクトリの実装により、ブロック挿入パネルから直接にサードパーティブロックを検索、インストール、追加できます。

ブロックを検索すると、まだインストールされていない場合は、プラグインディレクトリで利用可能なプラグインのリストが表示されます。これらのプラグインは「ブロックプラグイン」と呼ばれ、ワンクリックでエディターに追加できます。

この素晴らしい機能のおかげで、独自のブロックを作成してプラグインディレクトリに公開し、作成したブロックをWordPressコミュニティ全体で利用してもらうようになりました。

幸い、カスタムブロックを作成するには、PHPに精通している人でなくても結構です。一方、JavaScriptの知識が必要です。

独自のブロックの開発を始める方法がわからないですか？素晴らしいWordPressコミュニティは、簡単なステップバイステップチュートリアルを作成してくれました。

ブロックチュートリアルの最初のバージョンは、ブロック開発の基本を学ぶのに役立つ公式のブロックエディターハンドブックですでに利用可能です。ブロックディレクトリとブロックプラグインの開発の詳細についてはMake WordPress Pluginsブログをご覧ください。

ブロックパターン

2020年3月に、Gutenberg 7.7とGutenberg 7.8は、テーマとプラグイン用のブロックパターンとブロックパターンAPIを導入しました。

ブロックパターンは、ユーザーがサブ項目として入れたブロックの複雑な構造をすばやくページに追加できる、定義済みのブロックレイアウトです。彼らの意図は、コンテンツ作成者とサイト管理者をきれいでプロのレイアウトを簡単に構築できるようにすることです。

フルサイト編集でブロックパターンの姿は最高になるはずでしょう。

GutenbergプロジェクトのリードアーキテクトであるMathias Venturaが、ブロックパターンの意図されている機能を明確に説明しています。

明確にさせてください。「ブロックパターン」の設定は、テンプレートパーツ（構造的に意味のあるもの）についての機能ではなく、より小さなブロックで構成される一般的な設計要素についてです。いったん挿入すると、個別に保存されません。たとえば、ブロックパターンがないと、設定するのに時間のかかる、いくつかのブロックを組み合わせて特定の外観にした「カバー」画像のことです。テーマテンプレートの再利用可能な部分ではなく、どこにでも追加できるデザインのコレクションとして考えてください。

ブロックパターンはテンプレートパーツではなく、デザイン要素であり、サイト管理者およびコンテンツ作成者が編集作業を高速化したり改善したりするのに役立ちます。

Gutenberg 7.7で導入されたブロックパターンが、最初にサイドバープラグインに表示されました。その後、Gutenberg 8.0のリリースとともに、以下の画像に示すように、エディターの左側にある改良されたブロック挿入パネルに移動しました。

初期段階であるため、ブロックパターンには非常に限られたパターンセットしかありません。とは言え、編集エクスペリエンスに大きな強化をもたらすでしょう。そして、うまくいけば、近い将来さらに多くのパターンが追加されるでしょう。

通常のブロックと同様に、パターンは検索可能で、次のカテゴリに分類されています。

テキスト
ヒーロー
列
ボタン
ギャラリー
機能
お客様の声
未分類

組み込みのブロックパターンに加えて、WordPress開発者は、まったく新しいAPIを利用して、テーマとプラグインにカスタムパターンを提供できます。

register_block_pattern関数とカテゴリのregister_block_pattern_categoryを使用して、カスタムパターンを登録できます。

register_block_patternには2つの引数が必要です。

1. パターンの名前。

2. パターンプロパティの配列。

プロパティには次のものがあります。

title
content
description
categories
keywords
viewportWidth

register_block_pattern_categoryにも2つの引数が必要です。

パターンカテゴリーの名前。

パティの配列。

APIはまた、unregister_block_patternとunregister_block_pattern_categoryというパターンとカテゴリの登録を削除する関数も2つ提供します。

独自のブロックパターンの作成するは非常に簡単です。たとえば、次のコードをコピーしてカスタムプラグインまたは子テーマの関数ファイルに貼り付け、好みに応じてパターンの名前を変更します。

add_action( 'init', function(){

	register_block_pattern_category( 
		'kinsta', 
		array( 'label' => __( 'Kinsta stuff', 'kinsta-pattern' ) ) );

	register_block_pattern(
	'kinsta-pattern/my-custom-pattern',
	array(
		'title'			=> __( 'Two Kinsta buttons', 'kinsta-pattern' ),
		'description'	=> _x( 'Two nice buttons.', 'Kinsta Buttons', 'kinsta-pattern' ),
		'content'		=> "<!-- wp:buttons {\"align\":\"center\"} -->\n<div class=\"wp-block-buttons aligncenter\"><!-- wp:button {\"backgroundColor\":\"very-dark-gray\",\"borderRadius\":0} -->\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link has-background has-very-dark-gray-background-color no-border-radius\">" . esc_html__( 'Button One', 'kinsta-pattern' ) ."</a></div>\n<!-- /wp:button -->\n\n<!-- wp:button {\"textColor\":\"very-dark-gray\",\"borderRadius\":0,\"className\":\"is-style-outline\"} -->\n<div class=\"wp-block-button is-style-outline\"><a class=\"wp-block-button__link has-text-color has-very-dark-gray-color no-border-radius\">" . esc_html__( 'Button Two', 'kinsta-pattern' ) ."</a></div>\n<!-- /wp:button --></div>\n<!-- /wp:buttons -->",
		'categories'	=> array( 'kinsta' ),
	)
	);
});

上記のコードは、ブロックAPIのリファレンススニペットを簡単にカスタマイズしたものです。ご覧のとおり、JavaScriptは必要ありません。

WordPress 5.5のブロックパターンもご覧ください。

WordPressコアのネイティブの画像遅延読み込み

遅延読み込みは、重要でないリソースの読み込みを延期する最適化手法です。つまり、ページの読み込み時に可視コンテンツを読み込み、残りの画像のダウンロードとレンダリングを実際に必要になるまで延期するようにブラウザーに指示する機能です。

ネイティブの遅延読み込みが導入された前に、ウェブ開発者はIntersectionObserver API、または scroll、resizeとorientationchangeイベントハンドラーを使用して、JavaScriptでアセットの遅延読み込みを設定できました。

ただし、遅延読み込みが標準になったため、カスタムコードを記述したり、JavaScriptライブラリを使用したりする必要がなくなり、imgおよびiframeタグの新しいloading属性を使用して画像の遅延読み込みを設定できるようになりました。

loading属性は、ブラウザがリソースをすぐに読み込むか、条件が満たされるまで待機するかを決定します。現在、次の値をサポートしています。

lazy：条件が満たされるまで待機する
eager：リソースをすぐに読み込む

Chromeの遅延読み込み設定（chrome://flags/#enable-lazy-image-loading）

この記事の執筆時点では、ネイティブ遅延読み込みは、Microsoft Edge、Firefox、Google Chrome、Operaブラウザー、Androidブラウザー、およびChrome for Androidでサポートされています。

WordPress 5.5より前のバージョンでは、遅延読み込みをWordPressで使用するのにAutoptimizeやBJ Lazy Loadなどの最適化プラグインが必要でした。今回のリリースでは、WordPressのコアの一部になるため、追加のプラグインをインストールする必要はなくなります！

WordPressのネイティブの遅延読み込み

Felix ArntzがMake WordPress Coreブログの古いブログ投稿で述べているように、遅延読み込みJavaScriptのWordPressへの導入が最初に提案されたのは数年前でしたが、結局コアの一部にはなりませんでした。ネイティブの遅延画像読み込みの今回の導入より、互換性の懸念がなくなり、新しい機能を安全にWordPress 5.5のコアにマージできるようになりました。

Felixによると、WordPressの画像のネイティブ遅延読み込みは、遅延読み込みプラグインを利用しない多数のWordPressウェブサイトのサイトパフォーマンスとユーザーエクスペリエンスに有益な影響を与えるでしょう。

…技術的な知識も、「遅延読み込み」自体の認識さえ必要としません。新しい loading属性を採用することは、WordPressにWeb全体の高速化をリードするチャンス与えます。

レイアウトのシフトを防ぐために、loading="lazy"はwidthとheight属性と共にimgタグに自動的に追加されます。これは、画像がWordPressで添付ファイルとして利用可能で、$idクラスが含まれている場合にのみ可能です。

遅延読み込みは、画像の多いWordPressインストールおよびウェブサイトにとって不可欠な最適化です。Felix曰く、

これにより、ユーザーがスクロールしなくても、ページの下の画像がすぐに読み込まれていたサイトでは、ユーザーエージェントでもサーバーでも帯域幅が大幅に節約されます。

WordPressのネイティブ遅延読み込みは、次のような画像で利用可能です。

投稿コンテンツの画像。（the_content）
抜粋後の画像。（the_excerpt）
テキストウィジェット内の画像。（widget_text_content）
get_avatar()でレンダリングされたアバター画像。
wp_get_attachment_imageを使用したテンプレート画像。

今回導入される遅延読み込みは画像のみをサポートしますが、iframeタグの遅延読み込みへの将来の拡張が期待されます。

WordPress開発者のための遅延読み込み

開発者は、新しいフィルターを使用してデフォルトの動作を上書きできます。これらのフィルターの中で開発者にとって最も便利なのは、wp_lazy_loading_enabled とwp_img_tag_add_loading_attr でしょう。

wp_lazy_loading_enabledはloading属性をオンまたはオフにします。このフィルターは、サイト全体にもタグごとにも適用できます。
wp_img_tag_add_loading_attrはloading属性値をフィルタリングし、遅延読み込みを画像ごとに制御できるようにします。

次の例は、遅延読み込みをサイト全体で無効にした例です。

add_filter( 'wp_lazy_loading_enabled', '__return_false' );

特定のタグの遅延読み込みを無効にすることもできます。以下の例では、the_contentの画像の遅延読み込みがオフになっています。（詳細については、Make WordPress Coreをご覧ください。）

add_filter(
	'wp_lazy_loading_enabled',
	function( $default, $tag_name, $context ){
		if ( 'img' === $tag_name && 'the_content' === $context ){
			return false;
		}
		return $default;
	},
	10,
	3
);

$default：論理的属性のデフォルト値（true）。
$tag_name: 遅延読み込される要素のタグ名。
$context: 画像のコンテキストを指定するオプションのパラメーター（上記のリストを参照）。

執筆時点では、$tag_nameパラメーターはimgタグのみをサポートしています。一方、前述のように、今後はさらにタグが追加されるでしょう。

WordPressの画像の遅延読み込みをより詳細に制御するのに、コンテキストに応じて2つの異なる方法があります。

コンテンツ（つまり、the_content、 the_excerpt、widget_text_content）なら、wp_img_tag_add_loading_attrフィルターを使用できます。次の例は、特定の画像の遅延読み込みを無効にする方法を示しています。

add_filter(
	'wp_img_tag_add_loading_attr',
	function( $value, $image, $context ){
		if ( 'the_content' === $context ){
			$image_url = wp_get_attachment_image_url( 67, 'medium' );
			if ( false !== strpos( $image, ' src="' .$image_url .'"' ) ) {
				return false;
			}
		}
		return $value;
	},
	10,
	3
);

テーマ開発者は、wp_get_attachment_imageを使用して画像を制御することもできます。この場合では、画像のloading属性値をfalseに設定するだけです。

echo wp_get_attachment_image(
	67,
	'medium',
	false,
	array( 'loading' => false ),
);

WordPress 5.5が最終的にリリースされる前に画像の遅延読み込みを試してみたい場合は、公式のLazy Loading Featureプラグインをインストールするか、Githubでソースコードを確認してください。

Native lazy-loading images is coming to #WordPress 5.5, for faster sites and less waste of network resources! And it's accompanied by further image improvements which reduce those annoying layout shifts that make you accidentally click on the wrong things. https://t.co/e7g2s9uSPk

— Felix Arntz (@felixarntz) July 14, 2020

Make WordPress Coreブログで、WordPress 5.5の画像の遅延読み込みに関する詳細情報を確認できます。

プラグインとテーマの自動更新

サイト所有者の最大の懸念事項の一つはサイトのセキュリティです。ソフトウェアを最新の状態に保つことは、すべてのサイト所有者が考慮に入れるべきことです。

WordPressの自動更新機能が WordPress 3.7以降に利用可能でしたが、コアメンテナンスとセキュリティリリースの自動更新がデフォルトで有効になっていても、WordPress 5.5までは多くのサイト所有者は、プラグインとテーマの自動更新を利用していませんでした。

その理由はおそらく、この機能にはWordPress開発の基本的な知識が必要だったことでしょう。開発者は、wp-config.phpの定数を定義するか、プラグインのフィルター機能を使用することにより、更新設定を微調整できました。

WordPress 5.5では、サイト管理者はプラグインとテーマの自動更新をWordPressダッシュボードでワンクリックでオンにしたりオフにしたりできるようになります。

プラグイン画面の新しい自動更新列に表示されるリンクをクリックして、プラグインの自動更新を有効または無効にできます。

テーマの自動更新を有効にする場合は、「外観」> 「テーマ」に移動し、テーマにマウスを合わせて「テーマの詳細」をクリックします。次に、新しい「自動更新を有効にする」リンクをクリックすると完了です。

プラグインとテーマの新しい自動更新UIには、自動更新エクスペリエンスをカスタマイズするために開発者が利用できるいくつかの関数とフックが付属しています。

プラグインおよびテーマ開発者向けの自動更新機能とフィルター

新機能とそのいくつかのフィルターにより、WordPress開発者はプラグインとテーマの自動更新の多くの側面をカスタマイズできます。

自動更新UIを確認する

新しいwp_is_auto_update_enabled_for_type()WordPress関数は、特定の種類に対して自動更新UIが有効になっているかどうかをチェックします。この新しい関数には、チェックする更新の種類（'theme'または'plugin'）を決定する単一の引数（$type）があり、それに対してtrueまたはfalseを返します。

plugins_auto_update_enabledとthemes_auto_update_enabledという2つの新しいフィルターのおかげで、プラグインまたはテーマの新しい自動更新UIを無効にすることができます。以下の例をご覧ください。

// Disable plugins auto-update UI elements.
add_filter( 'plugins_auto_update_enabled', '__return_false' );

// Disable themes auto-update UI elements.
add_filter( 'themes_auto_update_enabled', '__return_false' );

上記のフィルターはwp-admin/includes/update.phpに記載されます。

自動更新リンクをカスタマイズする

プラグインとテーマの開発者は、自動更新リンクのHTML出力もカスタマイズできます。

plugin_auto_update_setting_htmlフィルターを使用すると、更新間のトグルリンクと頻度をカスタマイズできます。

コールバック関数には3つの引数があります。

$html：自動更新のアクションリンクの切り替え、更新間の頻度などを含むプラグインの自動更新列のコンテンツのHTML。
$plugin_file：プラグインディレクトリに対するプラグインファイルへのパス。
$plugin_data：プラグインデータの配列。

ここで、自動更新リンクテキストのラベルをカスタマイズするには、次のスニペットに示すように、フィルターを使用します。

add_filter( 'plugin_auto_update_setting_html', function( $html, $plugin_file, $plugin_data ){
	if ( 'kinsta-plugin/kinsta-plugin.php' === $plugin_file ) {
		$html = __( 'Custom HTML', 'kinsta-plugin' );
	}
	return $html;	
	}, 
	10, 
	3 
);

以下の画像は、画面上の結果を示しています。

このフィルターはwp-admin/includes/class-wp-plugins-list-table.phpに記載されます。

単独のサイトでは、theme_auto_update_setting_templateフィルターを使用して自動更新リンクのJSテンプレートをカスタマイズできます。プラグインとテーマの自動更新を紹介するブログ投稿では、フィルターの次の例があります。

function myplugin_auto_update_setting_template( $template ) {
    $text = __( 'Auto-updates are not available for this theme.', 'my-plugin' );
 
    return "<# if ( [ 'my-theme', 'twentytwenty' ].includes( data.id ) ) { #>
        <p>$text</p>
        <# } else { #>
        $template
        <# } #>";
}
add_filter( 'theme_auto_update_setting_template', 'myplugin_auto_update_setting_template' );

data.idパラメータを使用してターゲットテーマを確認することをお勧めします。

WordPressマルチサイトインストールの場合、theme_auto_update_setting_htmlフィルターが必要です。これにより、プラグイン画面と同様に、テーマ画面の自動更新リンクをカスタマイズできます。

最後になりますが、残りの2つのフィルターが、将来インストールされるテーマとプラグインを含む、すべてのテーマとプラグインのすべての自動更新を制御します。

WordPress 3.7以降で利用可能なこれらのフィルターは、WordPressダッシュボードのすべての自動更新設定を上書きします。詳細については、当社のWordPress自動更新の詳細記事をご参照ください。プラグインとテーマの自動更新の詳細については、こちらのブログ投稿をご覧ください。

自動更新の電子メール通知とサイトヘルス情報

WordPress 5.5以降、自動更新の試行後にメール通知が送信されます。

auto_plugin_theme_update_emailフィルターフックは、自動更新後に送信される電子メールをフィルターします。使用例については、こちらのdev-notesブログ投稿をご参照ください。

2つの新しいフィルターを使用して、自動更新の電子メール通知を無効にすることもできます。

// Disable auto-update email notifications for plugins.
add_filter( 'auto_plugin_update_send_email', '__return_false' );

// Disable auto-update email notifications for themes.
add_filter( 'auto_theme_update_send_email', '__return_false' );

プラグインとテーマの自動更新情報は、「サイトのヘルス」の「情報」タブにも表示されます。

開発者は、plugin_auto_update_debug_stringフィルターとtheme_auto_update_debug_stringフィルターを使用して、この画面に表示されるテキストをカスタマイズできます。詳細と例については、こちらをご覧ください。

拡張可能なコアサイトマップ

サイトマップは検索エンジンがウェブサイトをすばやくクロールできるための簡単なURLのリストです。

サイトマップはrobots.txtとよく似ていますが、robots.txtのコンテンツがインデックスに登録されないことに対して、サイトマップはインデックスが作成されるURLのリストを検索エンジンに提供します。

WordPress 5.5までは、サイトマップをWordPressウェブサイトに追加するのにプラグインなどのツールが必要でした。

WordPress 5.5ではWordPressコアに新しいXMLサイトマップ機能がリリースされます。

この新しい機能には、基本的な動作の他にプラグイン開発者が組み込み機能をさらに拡張できるためのフックとフィルターも数多くあります。

XMLサイトマップは（検索エンジンがウェブサイトのインデックスを作成しないよう設定していない限り）デフォルトで有効になっています。次のオブジェクトタイプを提供します。

ホームページ
投稿ページ
コア投稿タイプ（固定ページと投稿）
カスタム投稿タイプ
コア分類法（タグとカテゴリ）
カスタム分類法/li>
作成者アーカイブ

最大2,000のURLを含むサイトマップインデックスは、/wp-sitemap.xmlにあります。最大数に達すると、新しいサイトマップファイルが追加されます。

前述のように、プラグイン開発者は、多くのアクションとフィルターのいずれかを使用して、サイトマップをカスタマイズできます。サイトマップ関連のフックの包括的なリストについては、機能プラグインのドキュメントと紹介ブログ投稿をご参照ください。

たとえば、XMLサイトマップが有効かどうかをフィルタリングしたりwp_sitemaps_get_server関数が実行されないようにしたりするwp_sitemaps_enabledフィルターを使用してコアサイトマップをプログラムで無効にすることができます。

remove_action( 'init', 'wp_sitemaps_get_server' );

コアサイトマップは、ウェブサイトにインストールしたサイトマッププラグインと競合しないはずです。Make WordPress CoreのPascal Birchler曰く、

コアサイトマップ機能は、堅牢で簡単に拡張可能な方法で構築されました。何らかの理由で2つのサイトマップ（コアサイトマップとプラグインのサイトマップ）がウェブサイトで公開されていても、サイトの発見可能性に悪影響を与えることはありません。

XMLブロックの文字列をエスケープするのは、XMLサイトマップ機能の一部である新しいXMLブロックの文字列をエスケープ関数です。関数と対応するフィルターはwp-includes/formatting.phpに記載されます。

執筆時点では、新しいサイトマップ機能は画像、ビデオやニュースのサイトマップをサポートしておらず、これは将来も変更されないでしょう。一方、開発者が本機能に追加できる新しいフィルターとフックは、将来のバージョンで追加されるかもしれません。

拡張可能なサイトマップの詳細については、こちらの新しいクラス、関数、フック、およびフィルターをカバーするサイトマップの開発者向けの紹介記事をご参照ください。

テンプレートファイルに引数を渡す

WordPress 5.5までは、テンプレートファイルへのデータの受け渡しは、グローバル変数やクエリ変数などの最適化されていない対策でしかできませんでした。WordPress 5.5では、$argsパラメーターがテンプレート読み込み関数に追加されました（対応するフックもそれに応じて更新されました）。

get_header()
get_footer()
get_sidebar()
get_template_part()
locate_template()
load_template()

テーマ開発者は、引数の配列を渡すだけで、テンプレートファイルで変数を設定してすべてのテンプレートパーツをその変数にアクセスできるようにすることができます。

一方、本機能はテーマ開発者にてって新たな機会を生みますが、WP TavernのJustin Tadlockは次の賢い質問をしています。

1つの質問が残ります。この機能の登場は遅すぎませんか？WordPressがテーマシステム全体を刷新し、次のフルサイト編集機能と統合する予定ですので、この機能が役立つのは今後数か月だけでしょうか？

そこで、John Blackbourneの意見は次の通りです。

サイトを完全に編集できるようになったとしても、テンプレートパーツはまだ十分に必要です。たとえば、動的にレンダリングされるブロックタイプは、構造化されたテンプレートパーツを有効に活用できます。互いに排他的な要素ではないため、レイアウトのためにブロックのみを使用していない独断的なテーマは将来も存在するはずです。

最後になりますが、WPコアの貢献者であるEnrico Sorcinelliの意見もご覧ください。

導入が遅すぎたかどうかなら、私の観点から言えば、遅すぎることは決してありません！
将来のテーマ開発者が新しいフルサイト編集アプローチとの共生で使用できるこの機能を今後も必ず活用できると信じています。（例えば、動的レンダリングのあるブロックなど）

この機能をフルサイト編集とどのように組み合わせることができるかを判断するのは今の段階ではまだ早いかもしれませんが、今後は、ユーザーと開発者の両方にとってより良いウェブサイトを構築できるようになるでしょう。

プラグインとテーマの.zipファイルからの更新

この機能が自動更新と同時にリリースされるのは不思議に見えるかもしれませんが、本来だと、理にかなっています。

WordPress 5.5までは、ワンクリック更新機能がない場合、サイト管理者はFTP / SFTPまたはファイルマネージャーを使用することでしかプラグインやテーマの更新をアップロードできませんでした。これは主に、カスタムプラグインやテーマ、またはサードパーティのマーケットプレイスでホストされている拡張機能に当てはまりました。

WordPress 5.5以降、コンピューターから.zipファイルをWordPressダッシュボードにアップロードすることにより、プラグインやテーマを更新できるようになります。

プラグインを更新するには、「プラグイン」> 「新規追加」画面に移動し、「プラグインのアップロード」ボタンをクリックします。次に、プラグインは既にウェブサイトにインストールされている場合、新しい画面に「このプラグインはすでにインストールされています」と表示され、現在のバージョンとアップロードされたバージョンの情報が表示されます。

テーマの更新プロセスはかなり似ています。

「外観」> 「テーマ」画面に移動し、「新規追加」、「テーマのアップロード」の順にクリックします。次に、テーマは既にWordPressウェブサイトにインストールされている場合、新しい画面に「このテーマはすでにインストールされています」と表示され、現在のバージョンとアップロードされたバージョンの情報が表示されます。

WordPress 5.5のその他の開発者向けの改善点

これまで説明してきたものに加えて、開発者の注意に値する機能がまだ数多くあります。

新しいwp_get_environment_type() 関数

新しいwp_get_environment_type() 関数を使用すると、ウェブサイトの現在の環境タイプを検出し、プラグインやテーマの機能を現在の環境に適用することができます。

wp_get_environment_type()はデフォルトでproductionを返します。その他のサポートされる値はdevelopmentとstagingです。開発者はまた、必要に応じて追加の環境タイプも定義できます。

ウェブサイトの環境タイプを設定する方法は3つあります。次のものを使用できます。（優先順位）

WP_ENVIRONMENT_TYPE PHP環境変数
WP_ENVIRONMENT_TYPE 定数
wp_get_environment_typeフィルター

たとえば、環境をステージングに設定する場合は、次のようにwp-config.phpファイルでWP_ENVIRONMENT_TYPE定数を定義します。

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

環境タイプがステージングの場合、わざわざ定義していなくても、WP_DEBUG は自動的に「true」に設定されます。

WordPress 5.5のREST APIの変更点

WordPress 5.5ではREST APIにも多くの変更が加えられています。新しいエンドポイント、新しいパラメーターとJSONスキーマの変更、新しい関数、さらに機能強化が見られます。

新しいエンドポイントの簡単なリストを次に示します。

ブロックタイプ

すべての登録されているブロックタイプを取得できる新しいエンドポイント。

GET /wp/v2/block-typesは、登録されているすべてのブロックタイプを返します。
GET /wp/v2/block-types/coreは、core前空間内を含むすべてのブロックを返します。
GET /wp/v2/block-types/core/quoteは、コアのquoteブロックの定義を返します。

プラグイン

プラグインを管理できる新しいエンドポイントです。

GET /wp/v2/pluginsは、すべてのインストールされているプラグインのリストを返します。
GET /wp/v2/plugins/plugin-name/plugin-nameは、指定されたプラグインに関する情報を返します。
POST /wp/v2/plugins { slug: "plugin-name" }は、指定されたプラグインをプラグインディレクトリからインストールします。
PUT /wp/v2/plugins/plugin-name/plugin-name { status: "active" } は、指定されたプラグインを有効化します。
DELETE /wp/v2/plugins/plugin-name/plugin-nameは、無効化されたプラグインを削除します。

ブロックディレクトリ

ブロックディレクトリを検索できる新しいエンドポイント。

GET /wp/v2/block-directory/search?term=block-nameは、ブロックディレクトリでblock-nameを検索します。

画像の編集

メディアライブラリ内の画像添付ファイルを編集できる、インライン画像編集機能とペアリングされた新しいエンドポイントです。

POST /wp/v2/media/5/editはID 5の画像を編集します。

WordPress 5.5のREST APIのすべての変更点の詳細については、WordPressコアの開発メモをご参照ください。

まとめ

WordPress 5.5は単一のリリースでこれほど多く新機能と拡張機能を提供することをとても嬉しく思います。

コアの貢献者たちは一生懸命に苦労しているこたは今回こそ明らかになりました。深く感謝しております。

本記事でカバーした変更点だけでは不十分な場合は、WordPress 5.5のその他の改善点を次に示します。

WordPressコアのダッシュボードアイコンのアイコンフォントに65個の新しいアイコンが追加されました。
ウィジェットのリンクのアクセシビリティ改善リスト。
無効なボタンの新しいCSSスタイル。
オペコードキャッシュの無効化。
redirect_guess_404_permalink()の制御の向上。
PHP関連の改善点。
コードベースの変更。
カスタムロゴ関数とフィルターの変更。
ブロックAPIの更新。
アーカイブページの見出しフィルター。
Twenty Twentyへのアイコンの追加。
云々

WordPress 5.5に特化した無料のウェビナーにぜひご参加ください。（英語）

さて、あなたのWordPress 5.5で最も気に入っている機能や改善点は何ですか？また、WordPress 5.6に追加してほしい機能はありますか？下記のコメント欄で教えてください。

Carlo Daniele Kinsta

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