前回の続き。
全面的にWordPressのテーマ構成を見直しで、具体的にやった（やる）ことについてです。

具体的にやった（やる）こと

1. 作成するテーマは全案件共通の親テーマとする
2. デザインカスタマイズは子テーマで行う
3. 案件別独自機能は子テーマにて作成
4. データベースに保存して使用する項目はプラグイン化

作成した親テーマは全案件共通の親テーマとする

例えばAというテーマとBというテーマを作成したとします。
AとBはそれぞれ違うものなのですが、Aのstyle.cssやfunctions.phpをBのテーマにそのままコピーしても利用可能なデータにできるようししたいと思っています。
案件ごとに制作するので、デザインや個別の機能に違いはあります。
しかし共通して使用できるコードを幾つか作ってfunctions.phpに記入しているので、それほど特別な事をするわけではありません。
制作したテーマを確認してみるとfunctions.phpに記入しているコードの8割は共通化できると考えています。
要するに「共通する部分はで親テーマを作成してしまおう」というわけですね。
何か不具合が発生した場合の一蓮托生感はありますが、個別に作成していても結局は同じ事。違うのは・・・
　
【個別にバラバラ作成】
● 個別にチクチク直して対応＝いくつも修正が必要
　
【親テーマで対応】
● 親テーマを修正＝一回の修正と配布で完了
　
・・・とても合理的ですね。
まあ、この方法は私が考えたわけではなく、すでに何人もの先人たちが試みている方法ですので、その知恵にあやかりましょうw。

デザインカスタマイズは子テーマで行う

前項の話と同じ事になりますが、問題の切り分けです。
何か問題が発生した場合、親テーマに問題がなければ、子テーマに問題があるといえるでしょう。逆に親テーマを適用させて不具合がでるのであれば、親テーマに問題であると言えます。このように作り変え、問題の箇所を発見しやすいつくりにしたいと思います。単純な話ですね。

案件別独自機能は子テーマにて作成

作成する親テーマはWordPressの基本ルールに則ったつくりにします。
そうすることで、Wordpressのバージョンアップ時に不具合を発見しやすくなると考えています。
しかし、案件別にみるとWordPressの基本的な出力方法だけでは対応できない場合もあると思います。
ほとんどは、独自に1から作成するというよりは、WordPressの基本機能を利用してカスタマイズするという感じですが、
そういった案件別の機能は子テーマに記述するものとします。
そうすることで、修正の内容が個別に必要なのか、全体に必要なのか、問題の切り分けができるようになります。

データベースに保存して使用する項目はプラグイン化

さて個別のテーマごとに対応するものと共通するものを分けましたが、もう一つ問題が残っています。
それは「共通する独自機能」に関する内容です。
functions.phpには、効率良くテーマに出力させるためのfunctionを記述しています。
しかし、先述の「プラグインの重複問題」にもあるように、WordPressにない独自に作成した機能のうち、データベースに保存して利用するようなものはfunctions.phpに記入すべきではないと考えています。
重複した場合に機能をOFFできるようにプラグイン化して、独自機能の不具合対応に備えらればと思っています。
　
WordPressは自由度が高いですし、コードが書きやすいというのは良いのですが、その反面、油断してるとコードが散らかってしまうといったマイナス面もあると思います。
散らかるのはスキルの問題だ！というものもあるでしょうけど、まあ一度納めてしまったら、自分が全てを修正できるわけではないと思いますので、放置してると散らかってしまう可能性もあるんではないかということですね。
割と他人が作ったテーマは触りたくないとなりがちなので、せめてこれから作るテーマは変更やメンテのし易さも考えてつくっていければと思うんです。今まで怠っていたわけではないのですが、まあ昔よりはスキルが向上してると思って期待して頂ければ幸いです。
　
詳しくはnoreply365のSpecificationsに順次開示していくので、コードについてはそちらを参照してもらえればと。
まあそんな感じです。