Snow Monkey カスタマイズをはじめよう – 準備・入門編

本記事は、Snow Monkey カスタマイズをこれからはじめようとする初心者向けの準備や基礎を解説している入門編です。

Snow Monkey テーマの大きな特徴

Snow Monkey テーマの大きな特徴の1つとして、子テーマではなく、プラグインで自由にカスタマイズをできると言う仕組みがあります。しかし、テーマのカスタマイズをプラグインで自由に行えると言う仕組みは、他のテーマと違う Snow Monkey のオリジナルな特徴ですので「何が出来るのか、そして、どうやるのか」については、実際に Snow Mokey を知っていかなければ不明となる部分も多々あります。

プラグインでテーマをカスタマイズ?

Snow Monkey 以外のテーマでは、テーマで表示している部分的なデザインの変更などをしたい場合、そのテーマを親とした子テーマを使って、そのテーマが表示している部分に対してまるごと上書きをするなどで対応する必要があります。

しかし、Snow Monkey テーマでは、子テーマを使用せずに、またテーマのファイル自身にも一切手を加えることなく、プラグインを使ってテーマで表示している部分をほぼすべて変更できる仕組みがあります。その仕組みにより、その他のテーマとは違って、プラグインのみでもテーマを自由にカスタマイズすることが可能になっています。実際に、当ウェブサイトではすべてオリジナルなプラグインを使ったのみで表示のカスタマイズを実現しています。子テーマは一切使用しておりません。

プラグインでテーマカスタマイズするのは大きなメリット

Snow Monkey 以外のテーマでは、カスタマイズする場合には子テーマなどを使って、表示を上書きする事が手順として指定されている場合が多いです。しかし、子テーマでテーマカスタマイズを行うのは、問題やデメリットも存在しています。

子テーマでテーマをカスタマイズをすることは、デメリットと問題を多くする

Snow Monkey 公式サイトではデメリットについて次のように書かれています。

例えば子テーマを使わず Snow Monkey そのまま使ってたとしたら、子テーマをつくって切り替えますよね。ただ、ウィジェットの設定とか、カスタマイザーの設定ってテーマに紐づいているので、テーマを切り替えるとリセットされちゃうんですよね。

テンプレートの上書きは意図せず古いコードを残したままにしてしまうので、無くなった関数などがかかれているとサイト真っ白状態になっちゃうんですよね。

Snow Monkey 公式サイトの記事より、説明の一部を引用
テネーブル

子テーマで行うカスタマイズの問題には、主に1ファイルに対して多々の修正を掛ける事が多い為に、多人数での制作に環境対応するのが難しいと言うこともあります。

ケミ

例えば、ヘッダーを変更したいとします。その場合、通常のテーマの場合では header.php を変更してヘッダーの表示を変更しなければなりません。そこで、複数人が header.php を修正しようとした場合はどうでしょうか。WordPress テーマの構成上、通常の場合などではテーマ内ファイルはカスタマイズ対象によって同じ形になっていますので、ソースコードの記述に競合が起こってしまうケースが多いです。チーム内の競合だけではなく、テーマ開発者のテーマのアップデート更新にも対応が必要です。その為に、古いバージョンのままテーマを使い続けていると言う問題のケースもあります。

プラグインでテーマカスタマイズは、制作環境の大幅な改善にも

プラグインでテーマカスタマイズをする場合は、元のテーマのファイルに手を加える必要がありません。それを理由に、テーマファイルに対するソースコードの競合と言うことも起こりません。

また、それぞれが別のプラグインを作るなどの体制を取るので、制作は別になっているカタチになります。なので、複数人が同じファイルを扱うと言うケースもほぼ起こらないでしょう。マージを取る手間も大幅に改善されるでしょう。

テーマカスタマイズの基本手順を知る前に

ここから、本記事では入門編として「カスタマイズの初歩の手順」を紹介します。本記事で紹介するカスタマイズ方法を実際に試してみてください。プラグインでカスタマイズするメリットを少し理解できるでしょう。
その入門編の知識は、他の Snow Monkey カスタマイズでも役に立つことです。是非覚えてください。

テネーブル

もちろん、プラグインでテーマカスタマイズをする際には、フック処理の優先度や細かな部分や仕様と言った情報共有を制作チーム内で行う方が良いです。

それらのルールを決定すれば、後はそれぞれの担当者が自分のカスタマイズに専念して制作できるようになります。子テーマでテーマカスタマイズをするより、スムーズな制作環境になるでしょう。

プラグインでテーマカスタマイズ前に

本記事の入門として体験するテーマカスタマイズは、実用性の無い機能です。しかし、このテーマカスタマイズから多くのことを体験することで、カスタマイズ方法の初歩を理解できます。是非、記事を読みながら実際にお試しください。

テーマカスタマイズをプラグインでするための準備

ルミェール

実際に Snow Monkey を使ってテーマカスタマイズを行う前に準備しておくと、カスタマイズがしやすくなることを紹介するよ!
既にテーマカスタマイズをしている人も、設定すればカスタマイズしやすくなることかも?

1. 制作環境の WordPress のデバッグ設定を、有効にする

WordPress のインストールされたディレクトリ内に、wp-config.php と言ったファイルがあります。
このファイルは WordPress の設定を行うファイルなのですが、そこにデバッグ設定を追加で記述することで、WordPress をデバッグモードで動作させることが可能になります。

wp-config.php に下記の1行を追加します。

define('WP_DEBUG', true);

$table_prefix = 'wp_'; と書いてある行の下あたりから if ( ! defined( 'ABSPATH' ) ) と書かれている行の間に、上記の define 文を追加しましょう。

テネーブル

本番(実際に運営している)環境では、デバッグ設定は無効にした方が良いので、制作が完了した本番環境では、デバッグ設定は無効にするようにしましょう。

デバッグ設定を無効にする方法は、追加した記述を削除するだけです。

この WordPress のデバッグモードを有効にすると、Snow Monkey では Google Chrome や Safari などのブラウザで閲覧して、デベロッパーツール や Webインスペクタ で HTML構造を見ると、何のテンプレートを読み込んでいるのかをコメントアウトで表示されるようになります。

テネーブル

コメントアウト表記で、その HTML を表示する為に読み込まれているテンプレート名が Start から始まり End で終わるように記載されているので、どの HTML領域が、どのテンプレートで表示されるようになっているのか解るようになります。

ケミ

補足:

もし、デバッグモードを有効にしても上記のようにコメントアウトで表示されない場合は snow_monkey_debug と言うフィルターフックの返却値が false になってるかもしれません。使用していないか、ウェブ担当者の方などに確認してみてね。

2. 「My Snow Monkey プラグイン」をインストールする

プラグインでテーマカスタマイズをする場合でも、子テーマ同様にテーマカスタマイズ用のプラグインを用意・インストールしている必要があります。

プラグインに対して function や処理を加えていくので、自分でテーマカスタマイズ用のプラグインを作っていない場合は、Snow Monkey 公式でテーマカスタマイズ用に用意された雛形プラグイン「My Snow Monkey」が配布されていますので、そちらを開発環境にインストールし、有効化しておきましょう。

My Snow Monkey プラグインの入手方法は、Snow Monkey 公式サイトのマイアカウントからダウンロード可能です。※ Snow Monkeyのサブスクリプションが必要です

Snow Monkey 公式サイトのマイアカウント
葉月

My Snow Monkey プラグインについての紹介は、Snow Monkey 公式サイトの次の記事を参考にしてください。

My Snow Monkey プラグインについて

テーマカスタマイズの手順を整理

準備が完了したので、実際にテーマカスタマイズの手順を整理しましょう。

1. どのようなテーマカスタマイズをしたいか考える

まず、テーマカスタマイズを行う場合、どのようなテーマカスタマイズをしたいのか整理するところからはじめましょう。

テネーブル

闇雲に何でもテーマカスタマイズをしだすと、構成がメチャクチャになってしまいます。子テーマと同じようにカスタマイズしたい箇所だけを整理しましょう。

2. どうすればテーマカスタマイズが実現可能か考える

次に、テーマカスタマイズを行う場合、どうすれば実現が可能なのかを考えましょう。

テネーブル

料理を完成させようとする場合でも、完成させる為にはどうすれば可能なのかをレシピを計画しなければなりません。どう言った手順で調理を行うのか。失敗か成功かは手順を実行した後に解ることです。この工程ではまず手順を自由に考えるのが大事です!

3. トライ&エラー

最後に、実現可能かどうかを実際に試し、失敗すれば成功まで何度も改善すると言うこと(トライ&エラー)をしていく流れとなります。

実際に、テーマのカスタマイズを試そう

まず、どのようなテーマカスタマイズをしたいか考えることにしましょう。

本記事では、解説の例として「この記事を書いた人」と言う文言を「この記事の筆者」にすることをテーマのカスタマイズの目標にしてみました。

その為にはどうすればよいでしょうか?

考えられる1つの案としては

  1. 記事の下に出ている「この記事を書いた人」の文字列がある部分を見つける。
  2. 見つけた「この記事を書いた人」を「この記事の筆者」に文字列を置換する。

と言うのが挙げられます。今回は、この方法でやってみましょう。

置換する為に、表示している該当テンプレートパーツ名を確認

最初に「この記事を書いた人」が表示されている HTML 要素は、テーマに存在しているどのテンプレートパーツが表示を処理しているのか調べる必要があります。

テネーブル

「この記事を書いた人」と言う部分は、プロフィールボックスを表示する設定が有効でなければ表示されません。もし、カスタマイザーの「記事にプロフィールボックスを表示する」設定をオフにしている場合は、オンにしてください。

上記の準備を正しくしてデバッグモードを有効化されている場合は、Safari や Google Chrome などのブラウザで、デベロッパーツール や Webインスペクタなどで HTML 要素の表示を行えば、「この記事を書いた人」の HTML 要素を表示している部分が <!-- Start : template-parts/common/profile-box --><!-- End : template-parts/common/profile-box --> で囲まれていることが確認できます。

この記述から template-parts/common/profile-box.php と言うテンプレートパーツのファイルが「この記事を書いた人」の HTML 要素を表示する為に読まれているテンプレートパーツのファイルだと言うことが解ったと思います。

しかし、このテンプレートパーツは何処にあるファイルなのでしょうか?
それは、テンプレートルートディレクトリからの相対パスになっています。

テンプレートルートディレクトリの解説は

をご覧ください。

このテンプレートパーツのファイル (template-parts/common/profile-box.php) を開いて確認してみると [wp_profile_box] のショートコードを実行する記述しかありません。

その為、「この記事を書いた人の記述を直接置換してしまえば良い」と考えていたのに、その記述がないことから文字列の置換は考え通りではできない可能性が出てしまいました。

「この記事を書いた人」の HTML 記述は [wp_profile_box] のショートコードが実行された後の文字列です。なので、テンプレートパーツを読込みされた後の文字列を取得すれば文字列の置換ができるはずです。

Snow Monkey の独自フックを調べよう

テンプレートパーツを読込みされた後の文字列を取得する為に、テンプレートパーツを読込みしている動作で発生するフックについて調べれば何らかの手掛かりが掴めそうです。フックについて調べることにしましょう。

(※ フックとは何か、フィルタフックとアクションフックの違いなどについては、別記事「Snow Monkey をカスタマイズするためにも、フックについて覚えよう」を参照してください)

Snow Monkey テーマの処理に対して何かの動作を追加や変更する場合のフックは、Snow Monkeyテーマが用意している Snow Monkey テーマ独自のフックを使用する必要があります。
そのような Snow Monkey テーマ独自のフックの一覧は、公式の GitHub リポジトリ内の Wiki に記載されています。参照しましょう。

Snow Monkeyの GitHub リポジトリの Wiki のページには、 Action HookアクションフックFilter Hookフィルタフック で、それぞれページが別にあります。

目的は「テンプレートパーツを読込みされた時のフック」ですのですが、どうやら見つかりません。しかしアクションフックの方で「該当のテンプレートパーツの出力を変更する」とある snow_monkey_get_template_part_<slug> フックが見つかりました。

テネーブル

フック一覧ではサンプルコードや説明が記載されているのですが、こう言ったリファレンスや一覧を読むのに慣れている人でなければ、フック一覧から目的の機能や代わりとなる可能性があるフックを見つけることが難しいかもしれません。

もし、迷った場合や困った場合でも、Snow Monkey 公式ウェブサイトには、カスタマイズについて質問可能なサポートフォーラムが用意されています。どのフックを使ったら良いのか迷ったりした場合や、Snow Monkey 独自のフックの使い方などについても Snow Monkey 公式サポートフォーラムでは聞いて大丈夫だそうです。(Snow Monkey 公式サポートフォーラムを利用するには、Snow Monkey のサブスクリプションをしている必要があります)

フックを使って、テンプレートの出力を変更(置換)する

使用するフックを整理できたので、HTML 記述の置換をしてみましょう。
しかし、どのような処理を記述すればテンプレートパーツの出力を変更出来るのでしょうか?

フック一覧のサンプルコードの記述を一度見てみましょう。

/**
 * @param $name テンプレート名
 * @param $vars テンプレートへのリクエスト配列
 */
add_action(
	'snow_monkey_get_template_part_templates/view/404',
	function( $name, $vars ) {
?>
		表示したい HTML 文字列
<?php
	},
	10,
	2
);

とサンプルコードでは記述されています。

ケミ

もし、add_action 関数や add_filter 関数について不明であれば、別記事「Snow Monkey をカスタマイズするためにも、フックについて覚えよう」も参照してください。そちらで解説をしています。

そのうちの templates/view/404 部分は slug となり、フックを掛けるテンプレートパーツ名が記述されます。今回は templates/view/404 ではなく、template-parts/common/profile-box のテンプレートパーツの出力を変更したいので、フック名を変更しなければなりません。
今回の変更対象となるのは template-parts/common/profile-box ですので、slug のみです。name となる部分はありません。function の引数の $name には、値が代入されません。$vars も今回はテンプレートを読み込む際にリクエスト配列を渡されないので、空の配列となります。

テネーブル

slugname が別になっているテンプレートパーツ(例:templates/view/content-post など)の場合は、templates/view/content までが slug で、post の部分は引数の $name で渡されます。ちょっとややこしいですね。

上記の slugname に関する部分は、Snow Monkey v6 から、別のフックとして snow_monkey_get_template_part_<slug>-<name> が用意されています。そちらでは snow_monkey_get_template_part_templates/view/content-post と記述して大丈夫になりました。

Snow Monkey v6 から template-parts/common/profile-box などの slug のみのテンプレートファイルの場合は

add_action(
	'snow_monkey_get_template_part_template-parts/common/profile-box',
	function( $name, $vars ) {
?>
		表示したい HTML 文字列
<?php
	},
	10,
	2
);

または

add_action(
	'snow_monkey_get_template_part_template-parts/common/profile-box',
	function( $vars ) {
?>
		表示したい HTML 文字列
<?php
	},
	10,
	1
);

と、どちらで記述しても問題ありません。

このコードを記述し、該当のプラグインを有効化している状態で記事ページを確認すると、記事下の「この記事を書いた人」の部分が「表示したい HTML 文字列」と言う記述に置換されているはずです。その場合は、置換は正しく動作しています。
しかし、目標としている「この記事を書いた人」の文字列のみを変更することはまだです。それを行う為に次へ進みましょう。

テンプレートパーツを読込んで、文字列を置換してみよう【失敗パターン】

テンプレートパーツの文字列を置換する為には、その置換を行う出力済みの HTML 文字列を取得する必要があります。
Snow Monkey のテンプレートパーツを見ていくと、 \Framework\Helper クラスに用意されている get_template_part 関数がテンプレートパーツを取得すると言うのが解ると思います。もしかすれば、それを使えばできるかもしれません。やってみましょう。

ルミェール

これが、可能性を考えることと、トライだよ。

get_template_part 関数は、引数にテンプレート対象のテンプレートパーツを処理した後に出力される HTML 文字列が返却される関数です。

HTML 文字列を取得したいのは template-parts/common/profile-box ですので、
\Framework\Helper::get_template_part( 'template-parts/common/profile-box', null, $vars ); と記述すれば、template-parts/common/profile-box のテンプレートパーツを読み込んだ後の HTML 文字列が返却値として取得できるはずです。

ルミェール

過去の \Framework\Helper::get_template_part の関数を調べると、テンプレートパーツのslugname を別々に引数で渡されていたけど、Snow Monkey v6 からは\Framework\Helper::get_template_part( 'templates/view/content-post', $vars );などで記述できるようにもなってるよ!その場合、 name は渡しては駄目なので $vars だけ渡すようにしよう。

実際に \Framework\Helper::get_template_part 関数を使用したコードを記述してみましょう。
次のようなソースコードが記述できそうな感じです。

add_action(
  'snow_monkey_get_template_part_template-parts/common/profile-box',
  function( $vars ) {
    $html = ob_get_clean();
    ob_start();
    \Framework\Helper::get_template_part( 'template-parts/common/profile-box', $vars );
    $html = mb_ereg_replace(
      'この記事を書いた人',
      'この記事の筆者',
      $html
    );
    echo $html;
  },
  10,
  1
);

このソースコードは、正しく動作しそうな感じがしますが、実際に記事ページを読込みしてみると、記事ページが表示されなくなる、または記事部分が真っ白になるなど動作できないことを確認できます。失敗パターンです。

ルミェール

失敗するのはトライ&エラーエラーに当たるよ。

何故、失敗したのか考えよう

何故、上記のケースでは失敗してしまうのでしょうか?

まず、PHP のエラーを見てみましょう。

Fatal error: Uncaught Error: Maximum function nesting level of '256' reached, aborting! 

と言うエラーで表示されています。

ブリエ

致命的なエラー:キャッチされていないエラー:関数のネストレベルが「256」に達し、中止されました!」ってどう言うことだろう?

ルミェール

関数のネストレベルと言うのが怪しそう。ネストレベルって何かを知ってみよう。

ネスト / ネスティング(nesting) とは、入れ子のことです。プログラムの場合は処理の中に処理が重ねられていく状態や構造を指します。データ構造の場合、構造の内部に同じような構造が含まれている状態のことを指します。

ITデジタル用語・プログラミング用語詳細リファレンスより引用
ブリエ

つまり、処理の中に処理が重なっているってこと?そんな処理をしている記述ってあるのかな?

実際にネストしているとエラーが指している箇所を調べると \Framework\Helper::get_template_part( 'template-parts/common/profile-box', $vars ); の部分にエラーの原因があるのが判明します。

\Framework\Helper::get_template_part 関数は、テンプレートパーツの出力結果を返却する関数ですが、一方で Snow Monkey に用意されている snow_monkey_get_template_part_<slug> フックは、テンプレートパーツの出力結果を変更するフックです。

ブリエ

それって…テンプレートパーツの出力結果を正しく返却する為に、\Framework\Helper::get_template_part関数を実行したら、出力結果を返却する前にテンプレートパーツの出力を変更する為の snow_monkey_get_template_part_<slug> フック処理があれば、そのフック処理を apply(適用) するってことだよね?

ルミェール

そうなるよね。 snow_monkey_get_template_part_<slug> フックの中で \Framework\Helper::get_template_part 関数が同じテンプレートパーツの出力結果を取得しようとした場合、また同じフック処理を実行しちゃう。実行されたフック処理が、また\Framework\Helper::get_template_part 関数を実行してテンプレートパーツの出力結果を取得しようとして…再帰的に処理を実行されちゃうから処理に処理が重なっていくんだね。結果的にネストレベルが上がり続けるだけで、出力結果も取得できなくなっちゃってエラーになってるんだ。それで真っ白になったり、記事ページが表示されなかったんだね。

テンプレートパーツを読込んだら、フックを削除してみよう【仮成功パターン】

ブリエ

どうやって成功させれば良いんだろう?

考えられる手段として「この無限に適用されるフック処理をしないようにすれば良い」のが1つの解となります。

フック処理を適用しないようにするには、追加したフックを削除すれば良いです。
WordPress には追加されたフック処理を適用しないように、フックを削除する為に、remove_action 関数や remove_filter 関数が用意されています。

ケミ

もし、remove_action 関数や remove_filter 関数について不明であれば、別記事「Snow Monkey をカスタマイズするためにも、フックについて覚えよう」も参照してください。そちらで解説しています。

しかし、remove_action 関数や remove_filter 関数は無名関数に対して使用することができません。
なので、まずはフック処理に無名関数で記述しているfunction 処理を正しく関数名をつけて別の関数で動作させるように変更します。そして、remove_action 関数を処理できるようにします。

結果は、次のコードになりました。

add_action(
  'snow_monkey_get_template_part_template-parts/common/profile-box',
  '_template_parts_common_profile_box',
  10,
  1
);
 
function _template_parts_common_profile_box( $vars ) {
  $_is_removed = remove_action(
    'snow_monkey_get_template_part_template-parts/common/profile-box',
    '_template_parts_common_profile_box',
    10,
    1
  );
  if ( $_is_removed ) {
    \Framework\Helper::get_template_part( 'template-parts/common/profile-box', $vars );
    $html = ob_get_clean();
    ob_start();
    $html = mb_ereg_replace(
      'この記事を書いた人',
      'この記事の筆者',
      $html
    );
    echo $html;
  }
}

記述を確認をしてみると「この記事を書いた人」と表示されていた HTML 部分は、「この記事の筆者」と言う表示に変更しているでしょう。

上記のコードでは、まず _template_parts_common_profile_box 関数を作成し、フック処理の動作をその関数で処理するように変更しました。この変更の理由は remove_action 関数が無名関数では動作できないからです。そして、関数内では remove_action 関数で該当の関数のフックを削除するようにしました。それを行うことで、1度実行された後に該当のフック処理を再実行されないようにします。しかし、正しくフックが削除されていない場合は、失敗パターン同様の再起的な無限ループになる為、$_is_removed でフックが削除されたかどうかを条件判定し、成功している場合のみ表示処理をするようにしました。

テネーブル

フック削除に失敗した場合は、HTML 要素が表示されなくなってしまいます。しかし、フック処理の削除が失敗したと言う場合は、正しい処理ができていないと言う場合でもあります。その場合のことは、ほとんど気にする必要がないでしょう。

そして、テンプレートパーツの HTML 文字列の取得を \Framework\Helper::get_template_part 関数を用いて行っています。今回はフックを事前に remove_action 関数を用いて削除しているので、無限ループに陥る事なく結果を取得できます。
$html として取得する際には、Snow Monkey 公式サイトでも推奨されているob_get_clean 関数などを使用する方法で、HTML 記述を取得しましょう。(※ 何故、ob_get_clean 関数が必要なのか後述で説明しています)

ob_get_clean 関数を使用する理由

\Framework\Helper::get_template_part 関数は、実際には HTML 結果の出力を行う関数です。その為、実行した際に実際には HTML を取得ではなく出力します。

その出力される処理を Snow Monkey 公式でも、ob_get_clean 関数などを使用して実際の出力を行わない形で変数へ代入する方法を行っています。前述していたob_get_clean 関数などを使用している理由です。

何故、さっきのは仮成功パターンなの?

ブリエ

一応できたみたいだけど、フックを消したり、テンプレートを読み込んだりちょっと大変。

テネーブル

そうですね。また、特定の場合では、正しくこのようにフックを削除を行えないケースも存在します。なので、現在の Snow Monkey ではこのような形で snow_monkey_get_template_part_<slug> フックを使用することを推奨していません。

ブリエ

いや、それ先に言ってよー…。このカスタマイズじゃ駄目ってこと?

テネーブル

失敗パターンや仮成功パターンからテンプレートの読み込みを学習する解説上、仕方なかったんですよー。ここまで解説したカスタマイズ方法は Snow Monkey v6.0 前後までの古い方法で、駄目ってわけではないですが、現在の Snow Monkey では推奨されていません。

現在の Snow Monkey にカスタマイズ方法も合わせよう【成功パターン】

ブリエ

現在の Snow Monkey だと別のカスタマイズ方法があるってことだよね?

テネーブル

そうです。ちょっと Snow Monkey のフィルターフックの一覧をもう一度ゆっくりみていきましょうか。

ブリエ

えーっと…。snow_monkey_template_part_render フック…説明が「テンプレートパーツの最終出力を変更」…あれ?

テネーブル

そうです。何となくイメージがついたかもしれません。そのフックを使えば \Framework\Helper::get_template_part 関数などで読込んだテンプレートパーツの最終出力される結果の HTML を変更できるんです。

ブリエ

……ということは、このフックを使うのが正しいってことだよね。なんで最初からこれを…(ぶつぶつ)

テネーブル

はい、このフックを使用するのが、現在の Snow Monkey の正しいカスタマイズ方法になります。こうしたフックの整理も最初から有った訳ではなく、このフックが登場した Snow Monkey v6の後にテーマのアップデートを含めて、フックの意図も整理されたんです。

ルミェール

Snow Monkeyは、フックも使いやすいように進化してるってことだよ。

Snow Monkey 開発者のキタジマタカシ氏が設計したフックの意図については、別記事「テンプレート系フックの意図と最適解の考案 – Snow Monkey カスタマイズ」で紹介しています。興味がある方は、そちらもご参考ください。

テネーブル

それでは、実際に現在の Snow Monkey のカスタマイズの記述にしたコードを見てみましょう。

add_filter(
	'snow_monkey_template_part_render',
	'_sm_template_part_render',
	10,
	4
);

function _sm_template_part_render( $html, $slug, $name, $vars ) {
	if ( 'template-parts/common/profile-box' === $slug ) {
		$html = preg_replace(
			'/<h2 class="wp-profile-box__title">この記事を書いた人<\/h2>/i',
			'<h2 class="wp-profile-box__title">この記事の筆者</h2>',
			$html
		);
	}
	return $html;
}
テネーブル

まず最初に、add_filter 関数で、フィルターフックの追加です。

snow_monkey_template_part_render フックを定義しています。コールバック関数名は _sm_template_part_render です。優先度は標準の 10 で良いでしょう。渡される引数の数は 4 です。

渡される引数ですが、

  • 第1引数の $html には、処理された後の HTML 文字列が渡されます。
  • 第2引数の $slug には、テンプレートパーツの slug が渡されます。
  • 第3引数の $name には、テンプレートパーツの name が渡されます。
  • 第4引数の $vars には、テンプレートパーツの リクエスト配列 が渡されます。
テネーブル

今回は、template-parts/common/profile-boxslug に持つテンプレートパーツの HTML を変更したいので $slug を判定して条件分岐しています。その後に preg_replace 関数を用いて h2 タグで見出しとなっている部分を正規表現で置換しています。そうしないと、本文で この記事を書いた人 と書いた文章の部分も文字列置換されてしまうからです。

ブリエ

随分スッキリしましたね。仮正解パターンのコードの長さや分かり難さが嘘みたい。

最後に

どうだったでしょうか?難しかったでしょうか?
過去に「フックの削除とか追加とか難しい」と挫折された方向けにも、現在の Snow Monkey のカスタマイズ方法までの基礎を、早足で解説したのですが「できそう」と思われたのであれば嬉しいです。

今回のテーマカスタマイズは、実用性もないので「簡単そうだけど、あまり意味がないことでは?」と言う気持ちもあるでしょう。しかし、プラグインでテーマのカスタマイズを行う一連の手順や方法の基礎を大きく体験・理解していただけたと思っています。

本記事で体験・理解できたことを、Snow Monkey テーマを使用したウェブサイト制作で活かしてみてください。上手く応用すれば自由にテーマのカスタマイズも可能になります。今後も別記事の解説と合わせながら色々とカスタマイズを楽しんでいただければと思います。

この記事の筆者

Kmix39(ケミ)

電子の妖精。当ウェブサイトの記事制作などを行なっています。
金融・不動産・医療・教育などの数々の業種のシステム開発を経験を積み、スマートフォンアプリケーションと WordPress などのウェブアプリケーションを日々勉強中。