WordPressテーマTwenty Twenty-Threeの子テーマにグローバルカスタムメニューを追加する

近年のブログやネットショップなどに於けるシステムの傾向にwebサイトを構築する際のブロック・エディター化が有ります。ブロック単位でのレイアウト変更がweb上の管理画面にて容易に行えるシステムで、ネットショップでは勃興著しい「Shopify」が代表として挙げられるでしょう。世界で最も利用されるブログシステムのWordPressも此の傾向に無縁ではいられません。2018年師走に鳴り物入りで登場した「Gutenberg
グーテンベルグ
」に先鞭を告げ、先のデフォルト・テーマ「Twenty Twenty-Two」にて端的に導入されたWordPressのブロック・エディター化[※1]は最新のデフォルト・テーマ「Twenty Twenty-Three」で更に顕著なものとなりました。

此の傾向に於いてはITに其れ程馴染みの無い向きには便宜が図られるも、所与のデザインでは満足されない場合に此のカスタマイズを依頼されるIT屋に取っては、勿論、「Gutenberg
グーテンベルグ
」から既に五年を閲しようと言うものの、未だ先のテーマで明確な潮流となってからよりは長い時間を経ぬ上での状況も有って、なかなかの難物となる様で、近しい時期に引き継いだWordPressサイトの構築がブロック化を忌避するように全くデフォルト・テーマから切り離して昔ながらの手法で独自テーマを以て成されているなど見るに付け感じられる所ですが、流石に其の旧態依然さに驚かされも呆れさせられもし、此の如くブロック・エディター化を執拗に避けるのも限界があるでしょう、以て反面教師とし、他山の石としたく思い、少しく「Twenty Twenty-Three」に取り組み標題の知見をシェアするものです。

Twenty Twenty-Threeに見られる著しい変化

最新のWordPressデフォルト・テーマのフォルダ内を見て先ず驚かされるのは、カスタマイズする際にはお馴染みの「functions.php」ファイルが見当たらないことです。此れについては情報が錯綜してもおり、バージョンに仍っては付与されるケースも見られる様ですが、2023年5月現在には見当たりません。

スポンサーリンク

次に驚かされることにスタイルシートが見当たりません。正確に言えば「twentytwentythree」直下に「style.css」ファイルは用意されているのですが、内容を見ればプロパティの記述は一つも有りません。又其れらしき「styles」フォルダ内にはスタイルシートらしきファイルが幾ファイルか用意されているのですが、此れ等は「.json」ファイルです。但し内容を見ればスタイルを指定しているらしき節が見られます。此の見当で行くと「twentytwentythree」直下に見られる「theme.json」がスタイルを指定している様です。恐らくはブロック・エディターで管理者がレイアウトやデザインを編集した結果がDBに保存されてwebサイトとして表示される、其の操作以前のデフォルトの「Twenty Twenty-Three」テーマの見た目の設定が此れ等「.json」ファイルに記述されている様です。

もう一つ驚かされるのは管理者画面に於いて、左側のサイドバーの「外観」を辿るに「テーマ」と「エディター」しか見えず、見慣れた「メニュー」が見えません。此処で無理矢理従来のメニュー編集画面のアドレス「https://hoge.co.jp/wp-admin/nav-menus.php」にアクセスしようものなら「お使いのテーマはナビゲーションメニューやウィジェットに対応していません。」なるメッセージが表示される始末です。そして此の「エディター」項目こそが「ブロック・エディター」への道筋であるのでした。従ってデフォルトでは「ブロック・エディター」からしかメニューの恣意的な操作は出来なくなっているのです。

WordPressシステムの警告画面「お使いのテーマはナビゲーションメニューやウィジェットに対応していません。」
WordPressシステムの警告画面「お使いのテーマはナビゲーションメニューやウィジェットに対応していません。」

此の制限されたメニューはIT屋ならぬ、一般の利用者に取っては妥当な配慮と言えるでしょうが、しかし独自のカスタマイズを施したメニューの追加も、従来馴染んだ「外観」から「メニュー」を辿り、システムから容易にメニュー項目を追加する方法が取れなくなってしまったWordPressの改定ではあり、カスタマイズを依頼された際には戸惑いを伴うものでもあるでしょう。

カスタムメニューを追加する

前段にWordPressのシステムが限られているとすれば、何某かの新手法を用いてコードで以てメニュー・ブロックを追加してブロック・エディターに反映せしめるしか、独自のカスタマイズは不能となり、テーマお仕着せのメニューにCSSでスタイルを適宜適用するしかないでしょう。処で実際には、流石にWordPress開発陣も其処迄の急変に限定はしておらず、大体が其の様な急変にシステムが制限されていれば、以前のブロック・エディターに対応していないテーマは全てWordPressのバージョンアップと共に破綻してしまいます。畢竟、「twentytwentythree」フォルダに「functions.php」は見られませんが、其処に当該ファイルを置けば其の記述は従来通り真っ当に動作します。

すると従来のWordPressの関数も大凡が「functions.php」内で動作するでしょう、では世の中に溢れ返ったカスタムメニュー追加の以下の関数をファイル内の記述に追加してみます。

/* カスタムメニュー */
function register_my_menus() {
	register_nav_menus(
			array(
			"g-menu" => "グローバルメニュー",
		)
	);
}
add_action( "after_setup_theme", "register_my_menus" );

此の追記を施した「functions.php」ファイルを子テーマのフォルダ直下にアップロードすれば、「テーマ」と「エディター」しか見えなかった「外観」の下階層には「メニュー」が追加され、リンク先は「https://hoge.co.jp/wp-admin/nav-menus.php」であり、此の画面を開けば馴染み深い「メニューを編集」「位置を管理」のタブで仕切られたメニュー編集画面にお目に掛かれるでしょう。

ヘッダーファイル

前段で独自にカスタマイズ・メニューの追加が可能となりました。しかし、此処で追加したメニューは、上で言えば「グローバルメニュー」として扱われるべき「g-menu」は、ブロック・エディターには表示されません。では、どの様にしてカスタマイズしたい子テーマに追加したら良いでしょうか。先ずは従来通りヘッダーファイルに「<?php wp_nav_menu( $args ); ?>」関数を記述すれば良かろうと思い「header.php」ファイルを「twentytwentythree」フォルダ内に探してみます、が、見付かりません。

ではどの様にして「Twenty Twenty-Three」テーマはヘッダーを表示しているのでしょうか。其れと思しきファイルを「twentytwentythree」フォルダ内に探せば、如何やら「parts/header.html」が該当する様です。しかしHTMLファイルにてPHPコマンドを記述出来ません。如何なるファイルかとファイルを覗いてみれば以下の如くものされています。

<!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group">
	<!-- wp:group {"align":"wide","style":{"spacing":{"padding":{"bottom":"var:preset|spacing|40"}}},"layout":{"type":"flex","justifyContent":"space-between"}} -->
	<div class="wp-block-group alignwide" style="padding-bottom:var(--wp--preset--spacing--40)">
		<!-- wp:site-title {"level":0} /-->
		<!-- wp:navigation {"layout":{"type":"flex","setCascadingProperties":true,"justifyContent":"right"}} /-->
	</div>
	<!-- /wp:group -->
</div>
<!-- /wp:group -->

此れを見ればWordPressのHTMLテンプレートタグとして機能していると思われるHTMLコメントアウト内の記述で以てwebサイトに出力せしめているのであろう仕様が窺われ、此処には以下の三つが使用されています。

  • wp:group
  • wp:site-title
  • wp:navigation

「site-title」と言い、「navigation」と言い、如何にもヘッダーファイルらしき様相を呈しているのが分かります。又「group」がブロック・エディターの編集単位になってもいるだろうのが推測出来ます。しかし、此処に前段でシステムに追加したカスタム・メニューを記述する様式が分かりません。大体が「Twenty Twenty-Three」テーマ自体がカスタム・メニューを拒んでいるのですから其の様な都合の宜しい書式「<!-- wp:*** -->」などは期待しない方が、今の処は良い様です。

ブロックの元コードの在り処

書式が用意されてないとなれば、「site-title」や「navigation」を書き換えれば良いと思われます。では、此れ等の元コードは何処に用意されているかとWordPressのフォルダ内を繰って見れば、如何やら其れ等はWordPressシステムの「/wp-includes/blocks/」に有りました。「site-title」も「navigation」も、共に当該PHPファイルが存り、又同名フォルダも在って、其の内にはPHPファイルやスタイルシートやJavaScriptファイルなど当該PHPファイルに用いられるアセット・ファイルが用意されています。

従って此処を編集すればwebサイト出力に反映はされるでしょうが、如何しても、短期的に、と言った条件付きでなければ実行すべき手法ではないでしょう。システム・ファイル群の恣意的変更は、セキュリティ・ホール抔思わぬ不具合をwebサイトに齎しますし、システム・バージョンアップも不能となれば、古いバージョンのWordPressの儘の運営を余儀無くされ、全く現実的では有りません。其の為にこそ、WordPressにはテーマが用意され、親テーマを継承する子テーマ機能さえ用意されているのでした。

当該ファイルの上書きが不能となれば、若しや此の「blocks」フォルダを子テーマの中に複製すれば良いのではないか、とも思われますが、勿論親テーマならぬシステムフォルダの「/wp-includes/blocks/」を子テーマに複製しても、親テーマの構成に子テーマの追記が上書きされてwebサイトに出力されるようなことは有りません。

親テーマの「patterns」フォルダ

何とか子テーマフォルダ内で事を収めたいのでしたが、果たして如何にすべきかを考えるに、此処は矢張り親テーマを参考するしかなさそうです。親テーマの「twentytwentythree」フォルダ内を見れば、以下のフォルダ、ファイルが用意されています。

Twenty Twenty-Threeテーマ・スクリーンショット
  • assets
  • parts
  • patterns
  • styles
  • templates
  • readme.txt
  • style.css
  • theme.json
  • screenshot.png

「parts」フォルダが前述した「header.html」の収められるフォルダで有り、同フォルダには「footer.html」も置かれ、此れを「templates」フォルダ内の各テンプレートファイルが条件に応じてシステムに呼び出され、其の際に「parts」フォルダのヘッダー、フッターを読み込む仕様の様ですが、「parts」フォルダも「templates」フォルダも共にHTMLファイルが収められ、PHPコードを書き込むのは穏やかでは有りません。其処でPHPファイルの収められたフォルダを探すに「patterns」フォルダが該当しました。此処には以下PHPファイルが置かれています。

  • call-to-action.php
  • footer-default.php
  • hidden-404.php
  • hidden-comments.php
  • hidden-no-results.php
  • post-meta.php

此れ等ならばPHPコードを書き込んでも問題ないでしょう。

header-default.phpファイルの追加

其処で子テーマフォルダ直下に親テーマフォルダを真似て「patterns」フォルダを拵えますが、困ったことに「twentytwentythree/patterns」フォルダにはフッターの構成ファイルらしき「footer-default.php」ファイルは見付かるものの、フッターが斯く有るとすればヘッダーコードの書かれるには「header-default.php」とも命名されるべき妥当なファイルが見付かりません。確かに「parts/footer.html」ファイルの中身を見れば以下の如く記述され、確かに「footer-default.php」を読み込んでいるらしくあります。

<!-- wp:pattern {"slug":"twentytwentythree/footer-default"} /-->

それならばと、子テーマの「patterns」フォルダ内に「header-default.php」を新たに作成し、「parts/header.html」に上のコードの「footer」部分を「header」に書き換えて記述して見れば如何でしょうか。残念ながら此れは機能しません。大方パスの問題だろうと、「twentytwentythree/footer-default」部分を子テーマを「fuga」とすれば「fuga/header-default」としても、「../fuga/header-default」としても残念ながら機能しません。

header-default.phpファイルの読み込み方法

さて、では如何すれば小テーマ・フォルダ内の「fuga/patterns/header-default.php」は読み込むことが出来るのか、此の方法こそが本記事の肝にて何某かで本ページに辿り着いた向きには此処だけ読めば目的の達せられる場合が多いものでしょう。

フッターに於いてはきっちり読み込まれているに仍って「footer.html」を参考にするのが妥当とは思われるものの、実は此方には読み込むファイルを所与の書式に従ってをものす而已なのは先程見た通りで、幾ら「header.html」に細工しようとヘッダーには「header-default.php」の内容は反映されません。正解は読み込まれる方の「header-default.php」にこそ有りました。参考に「footer-default.php」を覗いてみましょう。

<?php
/**
 * Title: Default Footer
 * Slug: twentytwentythree/footer-default
 * Categories: footer
 * Block Types: core/template-part/footer
 */
?>
<!-- wp:group {"layout":{"type":"constrained"}} -->
<div class="wp-block-group">
	…(ry…
</div>
<!-- /wp:group -->

冒頭のPHPコメントアウト部分こそが求めるものでした。題目を「Default Footer」とし「footer」カテゴリーに分類されるに仍ってシステム・プログラムとしては「core/template-part/footer」が適用されるもので、此れを用いるには「Slug」を「twentytwentythree/footer-default」とせよ、と読み解けば、「footer.html」の記述と整合性が取れます。此れをヘッダーに適用試行するに先ず「twentytwentythree/patterns/footer-default.php」を「fuga/patterns/header-default.php」に複製し、上の肝部分を以下の如く書き換えてみます。

<?php
/**
 * Title: Default Header
 * Slug: fuga/header-default
 * Categories: header
 * Block Types: core/template-part/header
 */
?>

以て「fuga/parts/header.html」に以下の如く記述してみます。

<!-- wp:pattern {"slug":"fuga/header-default"} /-->

然るべき后に、オンラインにてWordPressの出力するwebサイトを閲覧してみれば思惑通り、ヘッダー部分にはフッターと同じきものが出力されました。後はPHPコードの記述可能な「fuga/patterns/header-default.php」に上で追加したカスタムメニューのコードを「<?php wp_nav_menu( $args ); ?>」関数を以て各自自由に追記すれば、見事思う所のカスタムメニューは追加され、其れはWordPressの管理画面の外観の下階層のメニュー項目で自由に編集が可能なものとなっている筈です。

サイト全体に拡張されたGutenberg
グーテンベルグ

扨「ヘッダーファイル」の章で挙げた「WordPressのHTMLテンプレートタグとして機能していると思われるHTMLコメントアウト内の記述」を此処でもう少し詳しく見てみましょう。この書式への見覚えもWordPressのカスタマイズに携わった向きには多い筈です。其れも其の筈、WordPress投稿画面にて「コードエディター」に切り替えれば見られる例の書式であったのでした。「<!-- wp:site-title -->」や「<!-- wp:navigation -->」は投稿記事の中ではなかなか見ないかも知れませんが「<!-- wp:group -->」は複数のブロックを選択して「グループ化」すれば見られる書式です。一般に最も見られるのは段落として機能する「<!-- wp:paragraph -->」でしょうし、見出しとして機能する「level」を引数に伴った「<!-- wp:heading -->」もあるでしょう、又、ブログ記事に書かせぬ画像は「<!-- wp:image -->」が「id」や「sizeSlug」を引数に伴い見られている筈です。

此れ等正しく「Gutenberg
グーテンベルグ
」にて登場した書式にて、即ち如何いう事かと言えば、投稿記事に適用されていたブロック・エディターと同じき仕様がサイトの構造を管理編集する「外観」から辿る「エディター」にも適用されたと言う事であり、Gutenberg
グーテンベルグ
」の仕様のWordPressのサイト全体のレイアウトへの拡張
を意味します。

改めて此の視点で以て上で挙げた「twentytwentythree/parts/header.html」ファイルを見て見れば、全体的にブロック・エディターでの編集単位となる「<!-- wp:*** -->」で記述、即ち「Gutenberg
グーテンベルグ
」の仕様で記述されているのが分かります。又「twentytwentythree/patterns/footer-default.php」を見てみれば、使用されているものが「<!-- wp:navigation -->」から「<!-- wp:paragraph -->」に変わるだけで、此方もPHPファイルでありながらHTMLファイルと同じき書式に従って書かれているのが分かります。

次善の対策

では果たしてサイト全体に拡張された「Gutenberg
グーテンベルグ
」の仕様を無視して「fuga/patterns/header-default.php」を記述すれば如何なる事態を招くでしょうか。無視したファイルをアップロードして「外観」から「エディター」を検見すれば以下の如きメッセージが表示されるでしょう。

「ブロックのリカバリーを試行」ボタンを含むWordPressシステムの警告画面
「ブロックのリカバリーを試行」ボタンを含むWordPressシステムの警告画面

此れもWordPressを多く扱う向きには見慣れた警告で有るかも知れません。投稿ページでコードで記述した際にWordPressのお気に召さない書式であれば、間違ったHTMLとしてシステムに認識されてしまう為に表示される例の警告です。カスタマイズする者に取っては如何でも宜しいでしょうが、カスタマイズを依頼した者が若し此処にアクセスして「ブロックのリカバリーを試行」しようものなら、折角構築したレイアウトが瞬時に破綻し兼ねません。多少なりとも此の状況への対策は取っておいた方が良いでしょう。

此れを防止するにも投稿画面の「Gutenberg
グーテンベルグ
」エディターに於いてコードエディターで見た書式が参考になります。此の時参考すべきは「カスタムHTML」でしょう。何となれば此のブロック内にはWordPressからは認められないHTMLが許容されるからです。本記事に於いては追加した「header-default.php」ファイルに於いてカスタムメニューを表示させる任意の場所に記述した「<?php wp_nav_menu( $args ); ?>」関数を「<!-- wp:html -->〜<!-- /wp:html -->」で括れば宜しいでしょう。然すれば「エディター」画面に生のHTMLコードは表示されてしまうものの其れは枠で囲まれ一体となり何やら不可侵の雰囲気を漂わせ、余り詳しくは無い一般の方に「ブロックのリカバリーを試行」ボタンをいきなり押されてのっぴきならない事態が招かれるのを防げるものと思います。

但し此れは次善の策にて、本来はWordPressに独自にブロックを追加した上で「ref」を引数に伴う「<!-- wp:navigation -->」を以て記述する様にするのが最善だとは思われます。しかし最善策はWordPressに新規独自ブロックを追加すると言う些か難易度の高い処理を事前に実施する必要がある為、可成りハイ・コストではあります。WordPress運営としては、新規テーマの作成には最善策を以て当たって欲しい姿勢では有るのでしょうけれども、「外観」下の「エディター」から「ヘッダー」下の「ナビゲーション」を操作してみましたが、まだまだ決して操作性の宜しいものとはお世辞にも言えません。可成り練られた感の有る従来の「外観」下の「メニュー」の方が遥かに操作性は宜しく、今の状態では「外観」下の「エディター」に於けるナビゲーションには「外観」下の「メニュー」と、如何しても関連付けたくなってしまいます。但し、此れの実現を新規追加の独自のナビゲーション・ブロックに施そうとでも目論むものなら、更なる高いコストが要求されるのは言う迄も有りません。此の方面については今後の動静を見守りたく、展開次第で対処を考えたく思います。

結言

動画全盛の世の中となれば、無料ブログはオワコン化してしまい、ほぼ機能向上の変化も見られない中で、独り気を吐くブログ・システムがWordPressです。Eコマースサイトなどの動静を見てもブロック・エディター化が棹をさすべき潮流なのでしょう。今後、WordPressに関しては当該知見の要請が多くなるものと思われますが、現時点ではGoogle検索エンジンの錯綜も有って、検索するもオリジナルのWordPress情報を捻り出せる筈もないアフィリエイターなどの検索結果をコピペで継ぎ接ぎしたページが上位に表示される始末にて、未だ一つ前の「Twenty Twenty-Two」テーマに於いてさえ、ブロック・エディター化に関する情報は貧弱な儘に見受けられます。又候人格者面して日本語を捻じ曲げようと目論むNHK[※2]的常識を押し付けているのを忌避して「正鵠を得る」から援用して敢えて「的を得た」と言いますが、願わくば、斯くの如き情報が溢れるネット状況の一助になればと思い、本記事をものしたものです。

A.「ピッタリと要点をとらえる」場合などの表現で、「的を射る」と「的を得る」の二とおりの言い方を耳にします。どちらでもよいのでしょうか。

Q.本来の言い方は「的を射る」です。

解説
「的(まと)」は、弓や銃砲の発射練習の際の目標のことです。「的を射る」は、「矢や弾を的に向かって放つ。また、放った矢、弾が的に命中する。」(日本国語大辞典・小学館)ことから、「的確に要点をとらえる」ことを意味するようになりました。「的を得る」という言い方も慣用的に使われるようになっていますが、「的を射る」が本来の言い方です。放送では「的を射る」を使っています。
「道理にかなっている」ことを意味する「当を得る」との混同から使われるようになったのでしょうか。

  1. WordPressでTwenty Twenty-Twoを親テーマにした時に独自ブロックパターンを子テーマに追加する(2022年2月26日)
  2. 「的」は「射る」?「得る」?(NHK放送文化研究所:2003年6月1日)