WordPressテーマはコードで選ぶ
WordPressのテーマを選ぶとき、デモ画面だけ見て決めると後で困ることがある。
見た目は良い。でも、いざカスタマイズするとPHPファイルが追いにくい。プラグインを1つ外したらレイアウトが崩れる。CSSを少し変えただけなのに、別のページまで影響する。
開発者が見るべきなのは、スクリーンショットよりも中で何が動いているかだと思う。
まず見るのは依存関係
WordPressテーマでは、テーマ本体だけで全部を処理しているケースは少ない。
Elementor、WooCommerce、WPML、Contact Form 7など、外部プラグインとの組み合わせでサイトを作ることが多い。BrickoxもElementor、WooCommerce、WPML、Contact Form 7などとの互換性を持つ構成になっている。
ここで大事なのは「対応しているか」だけではない。
functions.php
wp_enqueue_scripts
template hierarchy
hooks / filters
shortcode
custom widget
このあたりを追えば、テーマがWordPressの標準的な流れに乗っているかが分かる。
独自処理が多すぎるテーマは、最初は便利でも、半年後の修正で苦労しやすい。
CSSより先にHTMLを見る
デザインを変えたいとき、いきなりCSSを書き始めるのも危ない。
まずブラウザのDevToolsでDOMを見る。
例えば、
<div class="project-item">
<a href="#">
<img src="...">
<h3>Project Name</h3>
</a>
</div>
のように、同じ役割のコンポーネントが同じ構造になっていれば変更しやすい。
逆にページごとにHTML構造が違うと、同じ見た目を作るだけでもCSSが増える。
テーマ開発では「きれいなCSS」より、同じものを同じ構造で出せるかのほうが長期的には重要だ。
Page Builderを使うなら境界を決める
ElementorのようなPage Builderは便利だ。
ただし、全部をBuilder側に入れると、後からコードを追いにくくなる。
例えば会社概要やお問い合わせページはBuilderで作る。一方、投稿、商品、施工実績など、データとして管理したいものはWordPress側で構造を決める。
この境界を最初に決めておくと、サイトが大きくなっても管理しやすい。
BrickoxはElementorを中心にレイアウトを組めるため、施工会社や工業系サイトのように「ページの見た目を頻繁に変えたい」ケースでは、この考え方と相性がいい。
Bootstrapがあるから速い、とは限らない
Bootstrapを使っているテーマを見ると、すぐ使えそうに感じる。
BrickoxもBootstrap 5.xをベースにしている。
ただ、重要なのはBootstrapを使っていることではなく、どこまで依存しているかだ。
使っていないCSSまで大量に読み込めば、単純にファイルサイズは増える。
開発時には、
Network
↓
CSS / JS
↓
Coverage
↓
実際に使っているコード
まで確認しておくといい。
特に企業サイトでは、派手なJavaScriptより「必要なものだけ読み込む」ほうが後々効いてくる。
テーマ交換を考えたコードにする
WordPressでは、テーマを永久に使い続けるとは限らない。
だから、
「テーマを変えたら全部消える」
という作りにはしないほうがいい。
会社情報、施工実績、製品情報などのデータと、見た目をできるだけ分離する。
テーマには表示を担当させ、データはWordPressの標準機能や適切なカスタム投稿タイプ側に置く。
この考え方なら、将来テーマを変更するときも移行範囲を小さくできる。
開発者なら「デモ」より「変更しやすさ」を見る
建設・製造・エンジニアリング系のサイトは、施工実績、サービス、会社情報、スタッフ、問い合わせなど、似たページが増えやすい。
だから重要なのは、最初の見た目だけではない。
追加したときに楽か。
修正したときに壊れないか。
プラグインを更新しても追えるか。
この3つを見るだけでも、テーマ選びはかなり変わる。
Brickox – Construction and Industry WordPress Themeも、Elementor、Bootstrap 5.x、WPML、WooCommerceなどを前提にした構成なので、実案件に入れる前に自分の環境でプラグインとの依存関係を確認しておくといい。
なお、こうしたWordPressテーマや開発用リソースを探す場合は、GPLPALでもBrickoxを確認できる。GPLPal — Premium WordPress Resources Hub
結局、良いテーマは「デモがきれいなテーマ」ではない。
自分でコードを読める。
必要な場所だけ変更できる。
半年後にも修正できる。
開発者なら、この3つを基準に選んだほうがいい。