WordPress, テーマ作成の環境づくりと方針

連載

WordPressテーマを作ってみよう Vol.2

テーマ作成の環境はNode.jsやwebpackなどで自動化できるところはどんどん使っていきます。

3つのコマンドを実行すれば環境ができるところまで準備しました。

（そのためにNode.jsのインストールが必要です。）

テーマ作成の環境

ここではくわしい説明はしません。GitHubに完成したソースコードと説明をアップしました。

そちらからダウンロードしてコマンドを実行してください。

ただし、ツールにはNode.jsを使うのでインストールが必要です。

CSS, JavaScriptの編集

CSS, JavaScriptの環境はWebpackを使います。WordPressでもバージョン5からブロックエディタが採用され、中身はJavaScript。

しかも、NextJSで書くほうがかんたんなので、JavaScriptのトランスパイルは必須。

また、ブロックエディタの開発環境まわりはNode.jsのパッケージを使います。

（パッケージはWordPress.orgが提供している。）

webpackを使わない理由がありません。

（ほかの代替ツールを使うならそれでもいい。）

CSSファイルは直接編集しません。SASS（SCSS）を編集してwebpackにcssファイルを自動生成してもらいます。

いまのWeb開発では基本的な方法になっているので積極的に採用しましょう。

PHPの編集

PHPは、WordPressが提供しているテンプレートファイル、functions.php、自作のテンプレートファイル以外はクラス（オブジェクト指向）ベースで作成します。

phpファイルにfunctionは定義しません。たとえばこんな感じの。

function wpdocs_theme_name_scripts() {
	wp_enqueue_style( 'style-name', get_stylesheet_uri() );
}
add_action( 'wp_enqueue_scripts', 'wpdocs_theme_name_scripts' );

.phpに直接functionを定義する問題点

これのどこが問題か分かるでしょうか？

この関数はどこからでも使えるグローバルの定義です。

WordPressはテーマやプラグインなど多くの人が作ったコードをまとめて動かすので、関数名が被ることがありPHPエラーになります。

（関数名のバリエーションなんてたかが知れてる。）

個人商店を営んでて、自分の持ち物と他人の持ち物、販売する商品が店内に陳列されていたらどうなるか...

カオスです。

普通のコーディングをする

いまどき、オブジェクト指向が使えるのに使わないプログラミングはありません。でも、WordPressではクラスを使わないプログラミングをする人も多いです。

だから、『WordPressやってます。』をエンジニアの実績として認めない人が多いんじゃないかな？

（カオスを作る人は迷惑でしかない。）

WordPressが悪いんじゃなくて、カオスのプログラムを書く人がそれを直そうとせず『俺、プログラマー』っていうからダメなんです。

ボクは、『普通』のプログラミングをしさえすれば、WordPress使いを低く見る必要はないと思ってます。

（システムとしても悪くない。）

だから普通のプログラミングを目指します。

WordPress.orgもカオスを放置していない

WordPressのコーディング規約でもカオスのコードを書かないようにアナウンスしてます。

さっきのコードはこんな風に。

add_action( 'wp_enqueue_scripts', function () {
	wp_enqueue_style( 'style-name', get_stylesheet_uri() );
} );

WordPressで困ったことがあったとき、

『これをfunctions.phpに追加。かんたんでしょ？』

という情報がたくさん出てきますが、それを集めた知識はプログラマーの知識ではありません。

ITエンジニアはカオスが大嫌いですから。

これを考えながら書くのがプログラマーの仕事です。

デザインパターンの一部を採用

LaravelやRuby on Railsなどのフレームワークを使うと、必ず出てくるデザインパターンがWordPressでは見えません。

（デザインパターンをアーキテクチャともいう。）

MVC, MVP, MMVMなどでいうView以外の部分はWordPressが内部でやってくれるからです。

（Viewの表示以外やってくれるところはありがたいが。）

しかし、Viewに処理が集まりメンテが大変になるので、構成だけはMVC（やそれに似たもの）にします。

厳密なデザインパターンの機能は実装しません。その必要性がないので。

サイトの公開ページはテンプレート（View）以外さわることがないので、コントローラー（C）の入る余地はありません。

MVPになると思います。管理画面はMVCになるかな？

『テーマの機能』以外は排除

テーマは本来、見てくれを定義するところです。デザインパターンではView。JSON-LDの追加や、SNSボタン、OGPの設置などはテーマの仕事ではありません。

（機能はViewじゃない。）

WordPress.orgもプラグインで作るように言っています。

（公式テーマの申請を出したとき、余計な機能があると通らないらしい。）

テーマの変更で、いままで使ってた機能が使えなくなるのを防ぐためです。

今回はそれらの機能を排除します。あとでテーマ拡張プラグインとして作っていくつもりです。

今回はここまで。次回より実際にコードの実装を始めます。