WordPress 6.1の新機能（Fluid Typography、テンプレートシステムの改良や新サイトヘルスチェックなど）

2022年11月1日に、待望のWordPress 6.1 Mishaがリリースされました。5月24日リリースのWordPress 6.0 Arturo、1月25日登場のWordPress 5.9 Josephineに続き、2022年3度目のメジャーリリースです。

WordPressの最新版には、Gutenberg最新バージョンの新機能、改善、バグ修正がコアに導入されるのが通例。WordPress 6.1も例に漏れず、13.1から14.1まで11バージョンのGutenbergプラグインが統合されています。

この記事では、WordPress最新バージョンの裏側を覗きつつ、さまざまな新機能を一挙にご紹介していきます。

Matias Ventura氏は、6.1へのロードマップで、6.1の目的は5.9と6.0で導入された機能をさらに磨き上げ、Gutenbergロードマップのフェーズ3に向けて改善してくことであると述べ、以下の詳細を発表していました。

1. テンプレートエディターの改善─WordPress 6.1の主要新機能。サイトの構造を閲覧、視覚化、編集する機能を導入する。

2. テンプレートパターン─テンプレートや固定ページの作成においてブロックパターンに中心的な役割を与えて、カスタム投稿タイプやブロックタイプへの適応、ロック機能の強化、保存されたパターン管理の改善などを目指す。

3. グローバルスタイル、ブロック、デザインツール─ウェブフォントの管理、レスポンシブタイポグラフィの実装、ブロックで利用可能なツールセットの拡張を可能に。

以上を踏まえ、早速WordPress 6.1の注目の新機能に迫っていきます。

流動的なタイポグラフィと余白

WordPress 6.1では、calc/clampCSS 関数でFluid Typography（以下「流動的なタイポグラフィ」とも）がサポートされています。

「Fluid（流動的な）」という表現の通り、テキストがビューポートの幅に適応し、フォントサイズが画面サイズに応じて滑らかに拡大・縮小されるようになります。

メディアクエリでは、テーマが特定のビューポートサイズに応じて、テキストのサイズを変更することはできますが、あくまで同じ値の間でのみ有効です。そのため、メディアクエリの機能とは異なります。

いくつかのテーマでは、すでにFluid Typographyをサポートしており、例えば「Twenty Twenty-Two」は、以下のようにいくつかのフォントサイズにCSSclamp()関数を採用しています。

"settings": {
	...
	"custom": {
		"spacing": {
			"small": "max(1.25rem, 5vw)",
			"medium": "clamp(2rem, 8vw, calc(4 * var(--wp--style--block-gap)))",
			"large": "clamp(4rem, 10vw, 8rem)",
			"outer": "var(--wp--custom--spacing--small, 1.25rem)"
		},
		"typography": {
			"font-size": {
				"huge": "clamp(2.25rem, 4vw, 2.75rem)",
				"gigantic": "clamp(2.75rem, 6vw, 3.25rem)",
				"colossal": "clamp(3.25rem, 8vw, 6.25rem)"
			}
		}
	}
}

上記コードでわかる通り、このフォントサイズの値は、すべてのフォントサイズに対して適用されます。

typography.fluidプロパティを以下のように宣言することで、テーマが自動的にフォントサイズを定義することができます。

"settings": {
	....
	"typography": {
		"fluid": true,
		"fontSizes": [
			{
				"size": "2rem",
				"fluid": {
					"min": "2rem",
					"max": "2.5rem"
				},
				"slug": "medium",
				"name": "Medium"
			}
		]
}

すべてのフォントサイズの値は、typography.fluidとtypography.fontSizes[].fluidを使用して、以下の式で自動で計算されます。

--wp--preset--font-size--{slug}: clamp({fluid.min}, {fluid.min} + ((1vw - 0.48rem) * 1.592), {fluid.max});

例えば、以下のようになります。

--wp--preset--font-size--large: clamp(2rem, 2rem + ((1vw - 0.48rem) * 1.592), {2.5rem});

なお、この記事の執筆時点では、Fluid Typographyは未だ実験的な機能です。技術的な詳細はこちらをご覧ください。

Fluid typography is a significant improvement for building modern #WordPress websites. We just updated @frostwp to include this feature. Here’s a great read from @richard_tabor into what it is and why it matters. https://t.co/Bq5YuHX3wi

— Brian Gardner (@bgardner) August 8, 2022

併せて、Rich Tabor氏によるWordPressのブロックテーマにFluid Typographyを挿入する方法とCarolina Nymark氏によるGutenbergにおけるFluid Typographyも参照してください。

また、流動的なタイポグラフィに加えて、流動的な余白（Fluid Spacing）もサポートされます。

以前は、エディターで余白の値を設定することしかできず、padding、margin、gapそれぞれに固定値を指定することはできませんでした。これにより、あるテーマから別のテーマに余白関連の設定を移したり、異なるサイト間でコンテンツをコピー＆ペーストする際に値を維持したりすることも不可能でした。

6.1では、spacing.spacingScaleとspacing.spacingSizes[]を使用し、Fluid Spacingのサポートを宣言することができます（詳しくは、Theme.json: 余白サイズのプリセットとtheme.jsonを拡張して余白サイズをプリセットを参照）。

"settings": {
	"spacing": {
		"spacingScale": 
		{
			"steps": 0
		},
		"spacingSizes": [
			{
				"size": "clamp(1.5rem, 5vw, 2rem)",
				"slug": "30",
				"name": "1"
			},
			{
				"size": "clamp(1.8rem, 1.8rem + ((1vw - 0.48rem) * 2.885), 3rem)",
				"slug": "40",
				"name": "2"
			},
			{
				"size": "clamp(2.5rem, 8vw, 6.5rem)",
				"slug": "50",
				"name": "3"
			},
			{
				"size": "clamp(3.75rem, 10vw, 7rem)",
				"slug": "60",
				"name": "4"
			},
			{
				"size": "clamp(5rem, 5.25rem + ((1vw - 0.48rem) * 9.096), 8rem)",
				"slug": "70",
				"name": "5"
			},
			{
				"size": "clamp(7rem, 14vw, 11rem)",
				"slug": "80",
				"name": "6"
			}
		],
	...
	}
}

Fluid TypographyとFluid Spacingのプロパティは、グローバル設定とスタイルプリセットとtheme.json API V2に関してに記載されています。

コンテンツのみのブロック編集

ブロック、パターン、テンプレートでコンテンツのみの編集が行えるようになりました。この機能を有効にすると、ブロックやパターンのコンテンツのみを編集できるようになり、誤ってレイアウトを崩してしまったり、スタイルを変更してしまったりすることを回避できます。

現在、ビジュアルエディターのインターフェースからこの機能を有効化することはできません。有効にするには、コードエディターでtemplateLock属性をcontentOnlyに設定します。

以下は簡単な例です。

ブロックやパターンでコンテンツのみの編集機能を有効化すると、通常の設定メニューは非表示になり、そのグループに含まれるブロックの一覧が表示されます。エディターキャンバスでブロックをクリックするか、サイドバーの対応する項目をクリックして、ブロックを選択します。

また、ツールバーの「Modify」をクリックすると、コンテンツのみを編集する機能を無効化できます。

編集後は、「Done」をクリックすると、再びコンテンツのみの編集を行うことができます。

コンテンツのないブロックは、リストビューから非表示になり、ブロック一覧で選択することができなくなります。

この機能に関する詳細は、開発者によるこちらの投稿、またはRich Tabor氏のブログ記事をご覧ください。

Gutenbergブロックの改良

今回のメジャーリリースでは、数々のGutenbergバージョンが統合されており、既存のブロックタイプにさまざまな変更と改良が導入されています。

カラムブロックの枠線

カラムブロックでBorderBoxControlコンポーネントを活用し、カラムに任意の枠線を指定して、各枠線にスタイルを設定できるようになりました（詳しくはこちら）。

枠線、以下のように個別にtheme.jsonファイルで設定することも可能です。

"core/column": {
	"border": {
		"top": {
			"color": "#CA2315",
			"style": "dashed",
			"width": "6px"
		},
		"right": {
			"color": "#FCB900",
			"style": "solid",
			"width": "6px"
		}
	}
}

この新機能ついてはこちらを参照してください。

画像ブロックの枠線

Gutenberg 13.8では、画像ブロックの枠線も編集可能になっており、この改良がWordPress 6.1のコアにも追加されています。ウェブクリエイターの表現の幅を広げてくれる嬉しい変更点です。

コメントブロックの改良

また、コメントブロックもパワーアップしており、より高度な編集機能が使用できるようになっています。

コメントブロックの設定サイドバーは以下のようになり、例えばコメントタイトルに以下のような変更を加えることができます。

投稿タグブロックのカスタムタクソノミーの改良

カスタムタクソノミー（カスタム分類）のバリエーションが増えたことで、投稿タグブロックの機能も強化されています。例えば、「Actors」の投稿タイプを登録すると、以下のように現在の投稿またはカスタム投稿タイプで、タクソノミーの一覧に表示されるようになります。

以下の例では、投稿タイプ「Movie」の俳優名が一覧が表示されています。

クエリループブロックの親フィルター

クエリループブロックに新たな親フィルターが追加され、同じ親を持つ投稿や固定ページを階層的に表示することができます。

見出しブロックのフォントファミリー

見出しブロックにフォントファミリーを制御する機能が追加されています。

ギャラリーブロックの水平・垂直方向の余白

新たな軸方向の余白管理機能により、ギャラリーブロック内の画像に異なる水平・垂直方向の余白を指定することができるようになりました。

これによって、画像ギャラリーのレイアウトの幅が広がります。

カバーブロックのアイキャッチ画像

また、人気の高いアイキャッチ画像の使用範囲が広がりました。以下のように、カバーブロックでアイキャッチ画像を直接選択できるようになりました。

この変更点によって、一貫したユーザー体験を実現でき、作業中の編集内容もよりわかりやすくなります。

また、ツールバーの「置換」でアイキャッチ画像が選択できるようになっています。

投稿ナビゲーションリンクの外観

appearanceTools設定プロパティにもいくつかの機能が増えています（デフォルトでは無効）。

appearanceTools設定プロパティをサポートするテーマでは、投稿ナビゲーションリンクのリンクの色とフォントファミリーを指定することができます。

appearanceTools設定プロパティについては、Twenty Twenty-Twoテーマに関する記事で詳しくご説明しています。

ワンクリックでコンテナブロック内をロック

新たに追加されたトグルを使って、ブロックコンテナ内のブロックをワンクリックでロックすることができます。このロック機能は、グループ、カバー、カラムブロックに適用可能です。

リストブロックの改良

リストブロックで、インナーブロックを活用できるようになりました。

これによって、リストアイテムの整理やインデントが容易になり、ユーザー体験を向上させることができます。

ブロックテーマにおける擬似要素

ブロックテーマは、要素やブロックの状態（active/focus/hover）に応じて外観を変更することができるようになっています。

以下は、Twenty Twenty-Threeのtheme.jsonで定義されている、リンクで疑似セレクタを使用する例です。

"styles": {
	...
	"elements": {
		"link": {
			"color": {
				"text": "var(--wp--preset--color--contrast)"
			},
			":hover": {
				"typography": {
					"textDecoration": "none"
				}
			},
			":focus": {
				"typography": {
					"textDecoration": "underline dashed"
				}
			},
			":active": {
				"color": {
					"text": "var(--wp--preset--color--secondary)"
				},
				"typography": {
					"textDecoration": "none"
				}
			},
			"typography": {
				"textDecoration": "underline"
			}
		}
	}
}

以下は、ボタンのスタイルを定義するコードです。

"styles": {
	...
	"elements": {
		"button": {
			"border": {
				"radius": "0"
			},
			"color": {
				"background": "var(--wp--preset--color--primary)",
				"text": "var(--wp--preset--color--contrast)"
			},
			":hover": {
				"color": {
					"background": "var(--wp--preset--color--contrast)",
					"text": "var(--wp--preset--color--base)"
				}
			},
			":focus": {
				"color": {
					"background": "var(--wp--preset--color--contrast)",
					"text": "var(--wp--preset--color--base)"
				}
			},
			":active": {
				"color": {
					"background": "var(--wp--preset--color--secondary)",
					"text": "var(--wp--preset--color--base)"
				}
			}
		}
	}
}

このコードを実行すると、以下のように表示されます。

また、ブロック単位で要素にスタイルを設定することも可能です。唯一の違いとして、この場合はブロック内でスタイルを定義します。例として、Twenty Twenty-Threeのtheme.jsonの以下のコードには、コアナビゲーションブロックのリンクにスタイルを適用した例です。

"styles": {
	"blocks": {
		"core/navigation": {
			"elements": {
				"link": {
					":hover": {
						"typography": {
							"textDecoration": "underline"
						}
					},
					":focus": {
						"typography": {
							"textDecoration": "underline dashed"
						}
					},
					":active": {
						"typography": {
							"textDecoration": "none"
						}
					},
					"typography": {
						"textDecoration": "none"
					}
				}
			},
			"typography": {
				"fontSize": "var(--wp--preset--font-size--small)"
			}
		}
	}
}

ブロックエディターへの追加機能と改善点

統合バージョンとはいえ、WordPress 6.1には変更点と改善点が満載です。そのため、今回の記事ではすべてをご紹介し尽くすことはできませんが、いくつか厳選してご紹介していきます（ブロックごとのデザインツールに関する包括的な情報は、Anne McCarty氏によるこちらの記事をご覧ください）。

ブロックインサータのテンプレートパーツ

ブロックインサータでテンプレートパーツが選べるようになり、サイトへのテンプレートパーツの挿入が容易になりました。

この変更により編集作業が効率化され、数回のクリックだけで、テンプレートパーツの種類を一括表示することができます。

余白の可視化

これは小さな改良点ですが、調整中の余白（marginとpadding）が強調表示されるようになりました。これによって、要素の内側と外側の余白をより明確に把握することができます。

設定サイドバーの改善

WordPress 6.1では、設定サイドバーのインターフェースもいくつか改善されています。

まず、投稿の設定サイドバーのデザインが若干変わっています（以下スクリーンショット参照）。投稿フォーマット、スラッグ、テンプレート、作成者のフィールドが整頓され、等間隔で配置されています。投稿スケジュールの項目も簡略化され、より見やすくなりました。テンプレートセクションもポップオーバー（要素をクリックすると小さく展開される要素）に移動し、スペースを有効活用することで、インターフェースがすっきりしました。

さらに、テンプレートパネルがテンプレートリンクに変更されています。テンプレートリンクをクリックすると、デフォルトのテンプレートがポップオーバーで表示される仕様です。

投稿ポップオーバーの外観

右側の投稿メニューの日付選択部分のデザインが変更され、既存のWordPressコンポーネントとEmotionスタイルが採用されています。

技術的な詳細（DateTimePicker）についてはこちらをご覧ください。

情報パネルに読了の所要時間

上部ツールバーにある情報パネルも改良され、単語、文字、見出し、段落、ブロックに加えて、記事読了までの所要時間が表示されるようになりました。

なお、推定所要時間は、1分間に189語（英単語）の平均値で計算されるようになっています。@wordpress/editorの「エディターで目次に読了時間を追加する方法」をご覧ください。

インターフェースでブロックの間隔変更

この機能をサポートしているブロックでは、ユーザーインターフェースからブロックの垂直・水平方向の余白を変更できるようになっています。

サイトビルダーの改善点

WordPress 6.1では、サイトビルダーの機能も拡張されています。ブロックパターンの使用範囲の拡大や、テンプレートタイプの豊富な選択肢は、テンプレートエディターでの編集体験の質を高めること間違いなしです。

投稿タイプの作成パターン

一つ前のWordPress 6.0では、新規固定ページの作成時に複数のブロックのセットから好きなパターンを選択することができる、ページ作成パターンが導入されました。これによって、ページをゼロから構築する手間が省け、好きなパターンを選んで作成するだけで、コンテンツを公開することができます。

この機能を使用するには、少なくとも1つのブロックパターンがcore/post-contentのブロックタイプのサポートを宣言していなければなりません。

WordPress 6.1では、この機能がすべての投稿タイプに拡張されています。使用するにはパターンのblockTypesにcore/post-contentを含め、関連するpostTypesを設定するだけでOKです。

ここで例を見てみます。「Movie」という投稿タイプがあるとします。

まずはこのページにある通り、ブロックパターンを登録します。

または、暗黙のパターン登録を使用するとより簡単です（今回の例ではこの暗黙のパターン登録を使用します）。

テーマのフォルダ内の/patternsディレクトリに、ブロックパターン用のPHPファイルを作成します（この例ではTwenty Twenty-Two）。それから、以下の見出しを貼り付けます。

<?php
/**
 * Title: Pattern with columns
 * Slug: twentytwentytwo/pattern-with-columns
 * Block Types: core/post-content
 * Post Types: movie
 * Categories: text
 */
?>
<!-- wp:heading -->
<h2>Hello there!</h2>
<!-- /wp:heading -->

以上です。これで、「Movie」投稿タイプを作成するたびに、パターン選択のポップアップ画面が表示されるようになります。

複数の投稿タイプを表示させたい場合（以下の例では「book」）、以下のように対応するスラッグをカンマで区切って追加してください。

<?php
/**
 * Title: Pattern with columns
 * Slug: twentytwentytwo/pattern-with-columns
 * Block Types: core/post-content
 * Post Types: movie, book
 * Categories: text
 */
?>
<!-- wp:heading -->
<h2>Hello there!</h2>
<!-- /wp:heading -->

作成パターンに関する詳しい情報はこちらをご覧ください。

サイトエディターのテンプレートタイプ

WordPress 6.0では、サイトエディターで作成可能なテンプレートには制限がありました。

WordPress 6.0で新規テンプレートをの追加 — WordPress 6.0で新規テンプレートを追加

WordPress 6.1では、個々の投稿タイプごとに異なるテンプレートを作成することができます。

また、コアやカスタムタクソノミー、さらには単一のカテゴリやタグに対してもテンプレートを追加・編集することができます。

カスタム投稿タイプやカスタムタクソノミーを作成すると、サイトエディターのテンプレート一覧に自動的に表示されるようになります。

さらに、テンプレートの投稿タイプを選択すると、そのタイプのすべての投稿、または特定の投稿に対してテンプレートを作成するかどうかを確認するポップアップが表示されます。

次の画面でその投稿タイプで使用可能な投稿一覧が表示されます。

WordPress 6.1をローカル開発環境にインストールする方法

まずは開発版を試したいという方は、以下の手順で実行してください。

DevKinstaを開き、ローカルにWordPressサイトを新規作成する。
作成後、WordPressの管理画面で「プラグイン」＞「新規追加」に移動する。
WordPress Beta Testerプラグインを検索してインストール。
プラグインを有効化し、「ツール」＞「Beta Testing」に移動する。
WP Beta Testerの「Settings」タブで「Bleeding edge」を選択して設定を保存する。
WordPressの管理画面に戻って「更新」に移動し、最新のベータ版に更新する。

これでWordPressのローカル開発環境が整い、自由にテストを実行することができます。WordPress 6.1の新機能について、本記事の最後にあるコメント欄でぜひご感想をお聞かせください。

DevKinstaを使用すると、数回のクリックで、ローカルマシンにWordPressの最新の開発環境を立ち上げることができます🖥

DevKinstaを無料でダウンロード👈

新テーマ「Twenty Twenty-Three」とその他のテーマの変更点

WordPress 6.1には、新たなデフォルトテーマ「Twenty Twenty-Three」が付帯しています。画像や過剰な機能を取り除いた、ミニマムなテーマになっています。

最新のサイト編集機能を一箇所に集約し、テンプレートやテンプレートパーツ、スタイル、柔軟なフォントや余白など、WordPress 6.1で導入されたすべての機能をテストするには、打ってつけのテーマです。

また、テーマ、テンプレート、ブロックパターンの開発方法を実際に操作しながら習得することができます。

Twenty Twenty-Threeについてはこちらの記事でご紹介しています。

また、Twenty Twenty-Three以外にも、いくつかのテーマが改良されています。

テーマのURIヘッダー

以前は、テーマディレクトリで利用可能なテーマと同じ名前のテーマがある場合は、更新可能メッセージが表示されていました。

今後は、Update URIヘッダーの導入により、サードパーティのテーマファイルを誤って上書きするのを防ぐことができます。この機能は、テーマディレクトリにあるテーマと同じ名前の自社開発テーマを所有しているもののコミュニティで共有したくない、といった場合に便利です。

現在、Update URIテーマヘッダーの値がhttps://wordpress.org/themes/{$slug}/、またはw.org/theme/{$slug}と一致しない場合、更新されることはありません。

この機能を有効にするには、Update URIはhttps://wordpress.org/themes/my-theme/やhttps://example.com/my-theme/のような独自のホスト名を持つURIでなければなりません。

Update URIの詳細についてはこちらをご覧ください（テーマ開発者向け）。

テーマ追加画面でのブロックテーマのフィルタリング

「テーマを追加」画面で新たにテーマをインストールする際、ショートカットでブロックテーマをフィルタリングすることができるようになりました。

また、同じ画面にブロックテーマのヘルプタブも追加されています。

開発者向け変更点

WordPress 6.1では、新たなAPIも使用することができ、開発者向け機能や変更点も多数追加されています。

新しい設定永続化API

ローカルストレージではなく、WordPressデータベースにエディター設定を保存する、まったく新しい設定永続化APIが導入されています。

これによって、すべてのブラウザとデバイスで設定を保存することができます。

このAPIの導入により、@wordpress/dataパッケージの以前の永続化システムは非推奨となり、preferences-persistenceパッケージが新たに導入されています。このパッケージでは、Rest APIを介してユーザーメタにデータが保存されます。また、データは、オフラインになったり、リクエストが中断されたりした際のフォールバックとして、ローカルストレージに保存されます（#39795参照）。

theme.jsonのボタン

theme.jsonを使ってボタンスタイルを定義し、テーマに追加することができます。これによって、ブロック間でボタンに一貫性を持たせることができます。例えば検索ブロック、また、サードパーティのブロックにも有用です。

ボタン要素にwp-element-buttonクラスを追加することで、同じスタイルを共有できるようになります。

この変更は、開発環境でtheme.jsonに以下のコードを挿入してテストすることができます。

{
	"styles": {
		"elements": {
			"button": {
				"color": {
					"background": "blue"
				}
			}
		}
	}
}

クエリバーに対応する検索ブロック

また、クエリバーに基づく検索ブロックにバリエーションが登場しています。これによって、訪問者に向けて、あらゆる種類のコンテンツを高度に検索できる検索ボックスを設置することができます。

以下の例では、投稿タイプ「Movies」にブロックバリエーションを設定しています。なお、以下の例は、Carolina Nymar氏のブロックバリエーションに関する解説をもとにしています。

子テーマのfunctionsファイルに、以下のコードを貼り付けます。

function movies_editor_assets() {
	wp_enqueue_script(
		'movies-block-variations',
		get_template_directory_uri() . '/assets/block-variations.js',
		array( 'wp-blocks' )
	);
}
add_action( 'enqueue_block_editor_assets', 'movies_editor_assets' );

次に、以下のblock-variations.jsファイル子テーマのassetsフォルダに作成します。

wp.blocks.registerBlockVariation( 
	'core/search', 
	{
		name: 'movie-search',
		title: 'Movie Search Block',
		attributes: {
			query: {
				post_type: 'movies'
			}
		}
	} 
);

WordPressの管理画面を再読み込みし、ブロックインサータで「Movies」検索ブロックを検索します。

ブロックバリエーションについては、公式ドキュメントをご覧ください。

グローバルスタイルに新たなボタン要素

WordPress 5.9では、グローバルスタイルが導入され、ウェブサイトのスタイルプリセットを、全体またはブロックレベルで編集できるようになりました。

当初は、背景、テキスト、リンクの色が変更可能でしたが、6.1では、カラーパネルにボタン要素も追加されており、ウェブサイト全体のボタンの外観を制御できるようになっています。

ボタンブロックから検索ブロック、ボタンを使用するサードパーティブロックまで、サイト全体のすべてのボタンのデザインを変更可能です。

どのテーマでも使用できる外観ツール

WordPress 6.1以前は、外観ツールはブロックテーマでのみ利用可能でしたが、functionsファイルに以下を挿入するだけで、テーマを問わずこの機能を使用できます。

add_theme_support( 'appearance-tools' );

すると、以下の設定が一括で有効化されます。

枠：色、半径、スタイル、幅
色：リンク
余白：blockGap、margin、padding
タイポグラフィ：行間

is_login_screen()関数

is_login_screen()関数の導入によって、現在のページがログイン画面であるかどうかを判断できるようになります。また、独自に設定したログイン画面にも対応しています。

条件タグは、例えば以下の通り。

function add_text_to_login() {
	if ( is_login_screen() ) {
		echo( "<h1>Welcome to Kinsta!</h1>" );
	}
}
add_action( 'init', 'add_text_to_login' );

フロントエンドでは、以下のように表示されます。

現在のページがログイン画面であるかどうかを検証するis_login_screen()関数

永続化対応オブジェクトキャッシュとフルページキャッシュのサイトヘルスチェック

WordPress 6.1には、永続化対応オブジェクトキャッシュ（以後「永続オブジェクトキャッシュ」）とフルページキャッシュの2つのサイトヘルスチェックが組み込まれており、どちらも本番環境のみで実行されます。

サイトヘルスチェックの結果は、「サイトヘルス」画面の「ステータス」タブで確認できます。

永続オブジェクトキャッシュテストは、サイトが永続オブジェクトキャッシュを使用しているかどうかを判断し、（使用していない場合）必要に応じて使用が推奨されます。

これに加えて、ホスティングプロバイダーが各環境で使用できるフィルターもいくつか導入されています。

site_status_persistent_object_cache_urlで、永続オブジェクトキャッシュのデフォルトの「Learn more（続きを読む）」リンクを編集することができます。以下はその例です。

add_filter( 'site_status_persistent_object_cache_url', function() {
	return 'https://example.com/persistent-object-cache';
} );

site_status_persistent_object_cache_notesを使用すると、ホスティング側でデフォルトのメモを置き換えて、例えば以下のように、任意のオブジェクトキャッシュソリューションを推奨することができます。

add_filter( 'site_status_persistent_object_cache_notes', function( $notes ) {
	$notes = __( 'Custom notes.', 'text-domain' );
	return $notes;
} );

site_status_persistent_object_cache_thresholdsは、永続的なオブジェクトキャッシュの使用を推奨するか否かを判定するためのしきい値を指定できます。初期値は以下の通り。

$thresholds = apply_filters(
	'site_status_persistent_object_cache_thresholds',
	array(
		'alloptions_count' => 500,
		'alloptions_bytes' => 100000,
		'comments_count'   => 1000,
		'options_count'    => 1000,
		'posts_count'      => 1000,
		'terms_count'      => 1000,
		'users_count'      => 1000,
	)
);

例えば、以下のように使用します。

add_filter( 'site_status_persistent_object_cache_thresholds', function( $thresholds ) {
	$thresholds = array(
		'alloptions_count' => 700,
		'alloptions_bytes' => 150000,
		'comments_count'   => 1500,
		'options_count'    => 1500,
		'posts_count'      => 2000,
		'terms_count'      => 1000,
		'users_count'      => 2000,
	);
	return $thresholds;
} );

site_status_should_suggest_persistent_object_cacheは簡易的なフィルターで、永続オブジェクトキャッシュの使用を提案し、デフォルトのしきい値チェックをバイパスするかどうかを判断します。例えば以下の通りです。

add_filter( 'site_status_should_suggest_persistent_object_cache', '__return_true' );

フルページキャッシュテストは、サイトがフルページキャッシュを使用しているかどうか、また応答時間に問題がないかを確認します。

この2つのフィルターにより、サーバーはレスポンスのしきい値を独自に設定し、検出する独自のキャッシュヘッダーを追加することができます。

site_status_good_response_time_thresholdは、応答時間が良好とみなすしきい値をフィルタリングします。初期値は600ミリ秒です（サーバー応答時間はパフォーマンスに影響します。詳しくはこちら）。

site_status_page_cache_supported_cache_headersは、サーバー側で独自のキャッシュヘッダーとそれに対応する検証コールバックを追加するためのものです。開発者向けメモでは、以下のような使用事例が紹介されています。

add_filter( 'site_status_page_cache_supported_cache_headers', function( $cache_headers  ) {
	// Add new header to the existing list.
	$cache_headers['cf-cache-status'] = static function ( $header_value ) {
		return false !== strpos( strtolower( $header_value ), 'hit' );
	};
	return $cache_headers;
});

サイトヘルスチェックについては、以下のリソースも参照してみてください（開発者向け）。

Create Blockの改良

新規ブロックタイプのひな形を作成する@wordpress/create-blockパッケージにも、新機能と改善点が追加されています。

ブロックのひな形は、WordPressがブロックを認識するためのサポートディレクトリ構造です。

新たに加わった–variantフラグにより、ひな形となるブロックのバリアントを選択することができます。Create Blockの内部テンプレートは、dynamic（動的）とstatic（静的）をサポートしており、それぞれ動的ブロックと静的ブロックをひな形にすることができます（デフォルトではstatic）。

このフラグは、以下のように使用します。

npx @wordpress/create-block my-first-block -variant=dynamic

テンプレートの定義にvariantsオブジェクトを追加し、独自のvariantを定義することもできます。

また、--no-pluginフラグによって、既存のプラグインに新規ブロックを追加できるようになりました。

npx @wordpress/create-block custom-block --no-plugin

上記のコマンドを実行すると、カレントディレクトリのサブディレクトリにブロックファイルのセットが新規生成されます。

なお、スクリプトでは場所が認識されていません。

「npx @wordpress/create-block block-name --no-pluginを呼び出すと、呼び出されたfolderNamedirectoryの中にブロックが生成される」

Create Blockの改良についてはこちらをご覧ください。

WP_Queryでクエリ結果をキャッシュ

WP_Queryクラスでデータベースクエリを実行する方法が変更されました。6.1では、クエリがキャッシュされ、クエリが複数回実行された場合、キャッシュから結果が読み込まれます。

これは、永続オブジェクトキャッシュを使用しているサイトと、インメモリキャッシュを使用しているサイトにとっては朗報で、特に前者にとっては嬉しい変更点です。

デフォルトでは、WP_Queryのすべての呼び出しがキャッシュされますが、cache_resultsパラメータを使用して、クエリのキャッシュを無効にすることも可能です。

$args = array(
	'posts_per_page' => 20,
	'cache_results'  => false
);
$query = new WP_Query( $args );

また、disable_cachingフックを使用して、クエリキャッシュを全体で無効にすることもできますが、推奨されていません。

なお、fieldパラメータなど、いくつかのクエリパラメータは、クエリキャッシュの対象外になります。これは、fieldsを含めると、同じデータのサブセットに対して複数のキャッシュが生成され、パフォーマンスが低下する恐れがあるためです。

WP_Queryキャッシュの詳細についてはこちらをご覧ください。

クラシックテーマのテンプレートパーツ

クラシックテーマでブロックベースのテンプレートパーツが使用できるようになりました。この機能を有効にするには、テーマに以下のようにblock-template-partsのサポートを追加します。

function add_block_template_part_support() {
	add_theme_support( 'block-template-parts' );
}
 
add_action( 'after_setup_theme', 'add_block_template_part_support' );

また、block_template_part関数を使って、クラシックテーマのPHPテンプレートにテンプレートパーツを挿入することができます。この機能についてはこちらのページで詳しく説明されています。

JPEGからWebPへの画像変換に関する注意事項

リリース発表当初、JPEGからWebPへの自動画像変換の導入が囁かれていました。

しかしこれに対して、WordPressコミュニティで多くのユーザーが意見を寄せました。例えば、以下のような指摘があります。

「画像アップロード時の画像生成のリソースは大幅に増えるけど、画像配信のリソースは減ることになる。前者は後者に比べれば滅多に実行されることはないから、わざわざ画像を圧縮して保存する価値がないといけない」（英語原文の日本語訳）

また、以下のような意見も。

「画像アップロード時のリソース使用量を大幅に増やすデメリットはかなり大きい。アップロードの失敗が増えて、ユーザーを足止めしてしまうことになるし、WordPressとサーバー会社の両方に対するサポートの依頼も劇的に増える。WordPressで画像のmulti-mimeサポートが必要になることを加味しても、これが良いアイデアとは到底思えない」（英語原文の日本語訳）

そして、WordPress.orgのMatt Mullenweg氏の投稿が決定打となり、WordPress 6.1でのJPEGからWEBPへの自動画像変換の導入が取りやめになりました。

「新しいフォーマットのサポートやパフォーマンスの向上はもちろん興味深いが、懸念が残るwebp（とHEIC）ファイルに対するOSのサポートを含め、今デフォルトでこの機能を組み込むのは、現実的じゃない。

どのような機能を受け入れて、どのような機能を使用するのかは自由であるべきなので、webpとHEICファイルの作業がサポートされているのは有難いが、JPEGがアップロード時にすべてwebpに変換されるのには反対。

とは言え、canonicalプラグインにとり画期的な機能なので、Make WordPressチームは実験と機能性を追求する機会として、捉えていきたいところ」（英語原文の日本語訳）

WordPressのパフォーマンスチームによるPerformance Labプラグインを使用すれば、JPEGからWebPへの自動画像変換を試すことができます。

開発者向けの追加変更点

今回の記事でご紹介した機能や改善点のほかにも、まだ追加的変更が多数あります。これについては、以下の開発者向けメモ（英語のみ）を参照してください。

まとめ

WordPress 6.1では、WordPressサイト編集機能の統合が行われています。Gutenbergの長期ロードマップは、未だフェーズ2にありますが、ツールと機能の信頼性と堅牢性が強化されています。今回のメジャーリリースでは、Fluid Typographyやサイトビルダーの新機能、そしてGutenbergブロックの改良が多数導入されました。

またこれに留まらず、パフォーマンスも大幅に改善されています。新たな2つのサイトヘルスチェックは、フルページキャッシュと永続オブジェクトキャッシュの使用を検出し、クエリキャッシュによってWP_Queryのパフォーマンスが向上、さらにコアブロックのPHPパフォーマンスも向上しています。

したがって、WordPressユーザーやウェブデザイナーにとってはもちろん、CMSの複数の領域において、開発者にとっても多数のメリットがあります。

あなたのお気に入りの新しい機能や改善点はなんですか？また、開発環境でのテストはお済みですか？以下のコメント欄でぜひご意見をお聞かせください。

Carlo Daniele Kinsta

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