page-***.php はなぜ叩かれるのか?


  1. Staff Blog
  2. WordPress
  3. page-***.php はなぜ叩かれるのか?

みなさんこんにちは。ベクトルのいしかわでございます。

今回はWordPress界隈で定期的に話題となる「まだ page-***.php なんて使ってるの?」という件について、僕なりの見解を述べたいと思います。

まぁ…AIの養分になるだけの記事の空気も感じますが、それでもきっとアクセスが増えて弊社製品の売上に繋がると信じて…。

page-***.phpが叩かれる理由

WordPress界隈で『page-***.php を作る手法は良くない』と言われる大きな理由は以下の2つ(主に最初の一つ)だと思います。

page-***.php にコンテンツ自体を直書きしているケース

WordPress最大の利点を潰している

最も良くないとされるのがページ毎にテンプレートを量産してコンテンツをテンプレートに書き込んでいるケース。

例)
page-service.php … サービス案内用
page-company.php … 会社案内用
page-faq.php … FAQページ用
など

これらのテンプレートに the_content() を書かず、そのかわりにコンテンツをHTMLで直接書き込む手法です。

<?php get_header(); ?>
<main>
<h1>サービス案内</h1>
<p>私たちはWordPressのテーマやプラグインを販売してます。</p>
</main>
<aside class="sidebar">
<?php get_sidebar('page'); ?>
</aside>
<?php get_footer(); ?>

こういった手法が生まれる背景には

  • クライアントが触って壊されたくない
  • 手元のコードエディタで直接編集した方が作業がしやすい
  • Gitでバージョン管理しやすい

という理由が考えられます。

けれども、言うまでもなくこの手法は コードを触らずにコンテンツを編集できるというWordPress最大の利点を潰している ため、WordPress原理主義者から

「は?何のためにWordPress入れてるの?それWordPressじゃなくてよくない?」

としばしばネタにされます。

本来クラッシックテーマであれば以下のように the_content() を入れて、管理画面からコンテンツを登録するのがセオリーとされているからです。

<?php get_header(); ?>
<main class="entry-container">
<?php if ( have_posts() ) while ( have_posts() ) : the_post(); ?>
<?php the_title(); ?>
<?php the_content(); ?>
<?php endwhile; ?>
</main>
<aside class="sidebar">
<?php get_sidebar('page'); ?>
</aside>
<?php get_footer(); ?>

※意図だけ伝えるために極限まで簡略化しています。

サイト内検索にひっかからない

また、WordPress標準の検索機能は、データベースの中から合致するキーワードで検索するため、テンプレートに直書きされている内容は検索対象になりません。

よって、WordPressの検索ブロックやウィジェットを配置したとして、ユーザーがその検索を使ってもそのページは検索結果に出てきません。

せっかく標準で検索機能があるのに使えなくしちゃってるという状態はナンセンスですよね?
となるわけです。

大人の事情があるんだよ!?

だがしかし、上記のような指摘を受けて

「だーかーら!!

『お知らせ』や『イベント情報』みたいな特定のコンテンツ以外は更新できるようにする必要がそもそもねーんだよ!

『お知らせ』や『お問い合わせフォーム』が無料で使えるからWordPress使ってるだけなの!

それ以外はうっかり編集できたりしちゃだめなの!

少し誤字があっても始末書を書かされたりする世界もあるんだよ!

だから全部Git管理で変更履歴を残していかないといけないの!

まったく…

これだから零細企業のウェブサイトしか作ってない人間や、顧客とやりとりしない頭でっかちなエンジニアどもは…。

ドゥー!

ユー!

アンダスタァァン!?」

と感じた事がある人も中にはいるだろう。

これに関しては一理ありそうで…

実はない。

それならコンテンツ部分だけテンプレートパーツ化した方がよくね?

page-***.php は一番外側のテンプレートなんですよね。なので、先ほどのサンプルコードで言えば、例えば main タグのクラス名を変更するとなった時に、全ての page-***.php を変更しないといけなくなるため、作業が手間とか更新漏れが発生する可能性があります(最近はAIがやったりするから手間も漏れもそんな気にしないだろうけど)。

ページ毎のコンテンツをコードで書きたいなら、その部分だけを切り出して get_template_parts() などで呼べば良い。

例としては、とりあえず以下のような page.php を作った上で…

<?php get_header(); ?>
<main class="entry-container">
<?php
if ( have_posts() ) :
	while ( have_posts() ) :
		the_post();

		$post = get_post();
		$slug = $post->post_name;

		// content-{slug}.php のパスを確認
		$template_file = locate_template( 'content-' . $slug . '.php' );

		if ( $template_file ) {
			// 例: スラッグが service なら content-service.php を読み込む
			get_template_part( 'content', $slug );
		} else {
			// 該当テンプレートがなければ本文を表示
			the_content();
		}

	endwhile;
endif;
?>
</main>
<aside class="sidebar">
<?php get_sidebar('page'); ?>
</aside>
<?php get_footer(); ?>

content-service.php … サービス案内用
content-company.php … 会社案内用
content-faq.php … FAQページ用

を作ってそれでGitでバージョン管理するとか。

こうする事で、外側の変更があった時に全ての page-***.php を変更しなくても、page.php だけで対応できる。

やはりコンテンツは WordPress から書こう

とは言え、やっぱりコンテンツをPHPファイルで書いてしまうと

  • 管理画面から変更できない。
  • サイト内検索にひっかからない。

これは致命的。クライアントのためになってない。
(とか言いつつ「編集できる≠クライアントのためになる」ではない世界線もあるので全否定は僕もできない)

なので、普通に管理画面からブロックエディタで作ったり、細かいレイアウトをしたかったら、なんならHTMLブロックを使ってHTML流し込めばいいじゃないですか。

編集ロックしたい

固定ページまるごと編集させないなら、User Role Editor みたいなプラグインで編集者権限のユーザーから固定ページの編集権限を外しちゃうとかもできますし、ブロック単位なら…

あら…ブロックの編集権限をロックするプラグインって意外と少ないのかな…。

Snow Monkey Editor とかそんな機能があったような…。
ちょっと VK Blocks にも実装検討するわ。待ってね。

そもそもウチは顧客サイトの編集ロックする事がなかったし、するべきじゃないと思ってたので作ってなかったのよ。

page-***.php でレイアウトを変更しているケース

“コンテンツを直書き”という理由ではなくて、単純に1カラム用とかLP用のバージョンのテンプレートみたいに、レイアウトのバリエーションとして page-onecolumn.php や page-lp.php みたいに作る場合があると思います。

これについては WordPress の作法としては正しいかなと思いますが、共通部分の変更となった時に、先述のように同じ変更を各ファイル全てしないといけなくなってしまうので、手間とか、変更漏れが発生する可能性があります。
なので、僕の場合は固定ページ用としては page.php は一つだけれどレイアウトのバリエーション情報をカスタムフィールドで持たせて、その値によって page.php 内の条件分岐で部分的にレイアウトを切り替える処理をします。

<?php get_header(); ?>

<?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?>

<?php
	// カスタムフィールド page_layout の値を取得
	// 例: one-column / two-column
	$page_layout = get_post_meta( get_the_ID(), 'page_layout', true );

	// 未設定時は two-column にしておく例
	if ( empty( $page_layout ) ) {
		$page_layout = 'two-column';
	}
?>

<div class="page-wrapper <?php echo esc_attr( $page_layout ); ?>">

	<main class="entry-container">
		<?php the_title( '<h1 class="entry-title">', '</h1>' ); ?>
		<?php the_content(); ?>
	</main>

	<?php if ( 'two-column' === $page_layout ) : ?>
	<aside class="sidebar">
		<?php get_sidebar( 'page' ); ?>
	</aside>
	<?php endif; ?>

</div>

<?php endwhile; endif; ?>

<?php get_footer(); ?>


そういう意味で page-***.php は使わないです。

でもこれもブロックテーマ使えばフルサイト編集でノーコードでできますよ。

ブロックテーマ使おうよ

まぁあれこれ書きましたが…サイト全体がエディタから編集できるブロックテーマの方が楽よ。
デザインカンプからやる場合は…いやそれもそれなりに凝ったものじゃなければ別にブロックエディタで再現できるで。それでええやん。

で、どうしても従来のPHPで処理したい部分はPHPでブロックつくれるプラグイン使うとか、WordPress 7.0 からはそのあたりも標準でできるので、必要に応じてPHPでブロック作ってそのブロックをエディタで配置すればいいんだし。

ブロックエディタと一緒で、フルサイト編集のブロックテーマに慣れると、ヘッダーやフッターをコード編集したりしないといけないPHPのクラシックテーマ使うのダルく感じる今日この頃です。

[ 動画・スライドあり ] VWSオンライン勉強会 #047 ゼロから覚えたくない WordPress の最新フルサイト編集 を開催しました

「ゼロから覚えたくない WordPress の最新フルサイト編集」を開催しましたオンライン勉強会を開催しました!動画とスライドを共有しますので、振り返りや、参加できなかった方はご確認ください!

余談 : なぜいろいろうるさい発言が出るのか?

最近のSNSでの論争の中で

「ベストプラクティスじゃないやり方をうっかり投稿すると、WordPressコミュニティの人からフルボッコにされるからWordPress怖い」

という意見もあり、それがよくないという事も同時に言われたわけですが、個人的に思うのは、WordPressコミュニティのみんなは、より多くの人がWordPressを有効に使えるように、ボランディアで開発に参加したり、勉強会( WordCamp や WordPress MeetUp )を運営したり使い方のノウハウを発信したり、サポートフォーラムで無償で回答したりしてるんですよ。

すごく膨大な時間を使ってくれている。

で、僕も含めて、はじめはみんな初心者だし、間違った事を投稿する事によってはじめて指摘してくれるから知見が広がるので、恐れずにどんどん投稿・登壇して欲しい。基本的には優しく指摘してくれると思う。

ただし…

そんな先人の貢献を目にする一方で『WordPressの発展に貢献してこなかったあまり詳しくない人が、あたかも詳しい感じの振る舞いで、本来推奨されるやり方じゃないやり方をSNSで広めたり情報商材を売ってひよこ食いで利益を上げる』みたいな…

そういうWordPressコミュニティーの人達の無償の貢献が彼らの養分になってしまうというケースを見ると、モヤっとしたりもしますよ…僕はそこまで聖人ではないので…。

page-***.php の使用はケースバイケースなので “本来推奨されるやり方じゃない” とは僕も言えないけど少なくともコンテンツを直書きする手法は推奨されない。

つまり何が言いたいのかというと、最近中学生の息子用に英単語学習Webアプリ作ったので使ってみてね!

じゃなかった、WordPress用のサロンやスクール向け予約管理プラグイン作ったのでそっちもよろしくやでって事です。

この記事を書いた人

石川栄和代表取締役
名古屋のウェブ制作会社数社に10年程度務めた後、株式会社ベクトル設立。
企画・運営・コンサルティング〜WordPressを中心としたシステム開発まで幅広く携わる。
[ 著書 ]
・いちばんやさしいWordPressの教本(共著)
・現場でかならず使われているWordPressデザインのメソッド(共著)
[ 最近のWordPressコミュニティでの活動 ]
WordCamp Tokoy 2023 セッションスピーカー
WordCamp Asia 2023 セッションスピーカー(LT)
WordCamp Niigata 2019 セッションスピーカー
WordCamp Haneda 2019 セッションスピーカー
WordCamp Osaka 2018 セッションスピーカー
WordCamp Kyoto 2017 セッションスピーカー
 Vektor Passport

を購入して

特典をゲットしよう!

X-T9 工務店
( ナチュラル )

19,800円 (税込)

0に!

Lightning ビジネス(Evergreen)

9,900円 (税込)

0に!

Lightning 工務店
( ナチュラル )

19,800円 (税込)

0に!

今なら!

Vektor Passport の
有効期間中、上記の
デモサイトデータを
何度でも素早くまるごと
インポートできます!

爆速!!1分デモサイトと同じ
ホームページができる

VK FullSite Installer のロゴ

選んだデモサイトと同じ状態の WordPress サイトを、わずか数ステップで再現できるインポート専用プラグインです。数クリックで、プロ品質のサイトがすぐに起動します。

フルサイト編集に対応したブロックテーマ X-T9

フルサイト編集対応ブロックテーマ

WordPress テーマ X-T9 は、WordPress 5.9 から実装されたフルサイト編集機能に対応した「ブロックテーマ」と呼ばれる新しい形式のテーマです。
ヘッダーやフッターなど、今までのテーマではカスタマイズが難しかったエリアもノーコードで簡単・柔軟にカスタマイズする事ができます。

パターンを使って

よりクオリティの高いサイトに

パターンとは、WordPressのブロックを組み合わせて作ったデザインテンプレートのようなもの。プロのデザイナーが制作したパターンを300以上公開中!コピペしながら高品質なサイトを簡単に作れます。

VK AB Testing は、ABテストを実施するための WordPress 用プラグインです。ブロックエディターでテストパターンを自由に作成でき、ランダム表示とクリック計測が可能です。Webサイトや広告などの施策の改善にぜひご活用ください。


このデモサイトは Vektor,Inc. のテーマとプラグインで構築されています。ご購入や詳細情報は下記のリンクもご参考ください。

PAGE TOP