エンジニアがWordPressの自作テーマを作る時に考えていること
この記事を書いてる人
せっかくWordPressでブログやサイトを作るなら、自作テーマを作るのは楽しみの一つだと思っています。
データの構造から見た目に関わる部分まで、考え始めたらあっという間に時間が溶けます笑
でも長年WordPressを触ってきて、作り方そのものに迷うことはほとんどなくなりました。
最新バージョンならこの機能はどう作るのがいいんだろう、みたいなバージョン依存の話くらい。
それでも毎回ちゃんと考えることが一つだけあります。
それは、どういう風に作っておけば、長年使いやすい形で維持できるか。
今回の話は全部ここに繋がっています。
データベース、プラグイン、管理画面、見た目、サーバー反映、全部「長く使えるか」という一つの問いへの、僕なりの答えです。
これはWordPressというよりシステム開発の話に近くて、仕事だろうが趣味だろうが根っこは変わりません。
プラグインは何をしているか分かって使う
WordPressをカスタマイズするなら一番触れる機会があるのがプラグイン。
ボタンをポチポチやるだけで本当に色んな機能が作れて、便利です。
ただ、何でもかんでも入れると、どの機能をどのプラグインで作っているか分からなくなったり、設定が干渉したりは起こり得ます。
しかもプラグインは、裏でデータベースにデータを追加しているものもある。
たとえばカスタム投稿タイプ。
プラグインで簡単に設定できるけど、あれも内部ではプラグインがDBを操作して実現している機能です。
カスタム投稿タイプは、プラグインを使わずDBを操作して自分で作ることもできる。
自分で理解して操作するのと、プラグインに任せて「よく分からないけど動いてる」のとでは、まったく話が変わります。
誰でも気軽に機能を作れるものとして必要なのは分かるけど、エンジニアの観点だと「中で何が起きてるか分からないけど動いてる」状態は、長く使うならちょっと避けたい。
じゃあ使わないのかというと、仕事なら時間やお金の都合で変わります。
趣味で時間を気にしなくていいなら、自分一人でやる前提だと使わないかな、という感じ。
管理画面は使い心地は「良い」より「悪くない」
データをどういう構造で作るかと合わせて、管理画面の使い心地も考えています。
自作テーマというとサイトの見た目にフォーカスされがちだけど、管理画面もPHPやJavaScriptでカスタマイズできる。
運営者以外には表しか見えないけど、運営する側は管理画面を触っている時間も結構長いんですよね。
「この操作どこからやるんだっけ」とか「登録すれば動くけど操作がしんどいな」みたいなのは、サイトを運営するモチベーションに地味に効いてきます。
そうならないために、データ構造をどうするかは結構重要。
そしてそのデータをどう操作させるかが、管理画面の使い心地に直結する。
なので僕は「常に使い心地が良い」を目指すというより、「使い心地が悪くない」を意識します。
だからプラグインで一瞬でできることでも、無料版だと広告がちらついたり、SEO系だとコンテンツをスコアリングされて嫌だな、というケースではあえて使わない選択もする。
機能が作れることと、その管理画面を使いたいことは別だから。
BestよりもBetter。
全部をBestにできるならそれがいい。
でもシステムの都合も物理的な時間の都合もある。
BestとBadが混在するくらいなら、Betterで揃えたほうが多分長く使えます。
見た目の土台は設計、表現は自由でいい
ここまでDBと管理画面の話をしてきたけど、一番多くの人が触れるサイトやブログの見た目はどうなのか。
ここは少し考え方を分けています。
土台、つまりPHPでどうデータを取得してCSSでどう制御するか、という構造の部分はちゃんと設計する。
ここを雑にやると確かに破綻しやすい。
でもその上に乗る表現の部分は、個人のサイトなら難しいことを考えず、やりたいようにやっていいと思っています。
なぜかというと、本質はカスタマイズじゃなくてコンテンツを作ることだから。
しっかり設計を意識しないといけないのは、ページや機能が多い業務サイトくらい。
それにWordPressはコンテンツ入稿という性質上、ページ数が多くてもプログラムの量が多いとは限らない。
だから個人でやる分には、ある程度自由に作って、おかしいなと思ったら直す、で全然いいと思う。
テーマ反映の理想は事前検討、でも後追いでもいい
最後に、テーマをどうやってサーバーに反映するか。これはエンジニア的に結構気になるテーマです。
ファイルを変更するたびにFTPで1ファイルずつアップしてもいいけど、それは仕事だろうが趣味だろうがしんどい。なので僕は、GitHubでコードを管理して、変更したら自動でサーバーに反映される仕組みを前提に考えます。
自作テーマの運用で意外としんどくなるのが、この反映の部分だったりする。
だから「その仕組みが作れるか」も含めて、どんなサーバーを契約するかをサイトを作る前に検討します。
というのが理想です。
ただ正直、これをやるにはWordPressの機能追加や見た目の変更とはまったく別の知識が、最初の段階から必要になります。
なので現実的には、運用するなかで反映がしんどいと限界が来てから考える、でも全然いい。
理想を知っておいて、必要になったら手を打つ、くらいの温度感です。
まとめ
今回書いてきたことをまとめると、こんな感じ。
- データベースがどうなっているかはちゃんと理解しておきたい
- プラグインを使うなら、そのプラグインが何をするのか理解しておく
- 管理画面の使い心地が「悪くない」か
- 大規模サイトでなければ見た目の表現は割と自由でいい(特に個人の趣味なら)
- 自作テーマをどうやってサーバーに反映するか
エンジニアとして自作テーマを作る時に考えているのは、結局「どういう見た目をどう作るか」ではなく「どう作っておけば長く使えるものになるか」です。
これらができなくても個人のサイトやブログなら大きな問題になることはほとんどない。
でも、エンジニアってこんなことを考えてWordPress開発してるよ、という話でした。
このサイトもバリバリ自作テーマでカスタマイズしているので、自分がワクワクする空間にしていきたいと思ってます。
コメントを残す