WordPressで場数を踏んでいくと、CakePHPなどの良さも分かっていながらついつい何でもWPを使いたくなってくる。
今回、仕様の段階ではWP的なものと判断し、思わずハマってしまったことを踏まえ、敗因？を分析したい。
１・仕様が細かく、「振れ幅」が少なかった。顧客は旧サイトの仕様にこだわっていた。
このパターンはかなり危険。
WPではプラグインなどをフル活用するため、プラグインの仕様に合わせることが許されない場合、あるいは仕様の変更などをを求められた場合、開発は厄介になる。プラグインの改変も基本NGだ。
動作スピードなども厳しく指摘されてしまうと目も当てられなくなる。
２・実は肝心のプラグインが使えなかったので自作せざるを得なかった
例えば、アップロードプラグイン。フロントエンド用で、ajaxで大容量のファイルをアップできる、その他保存形式やデータチェックなど細かいカスタマイズのことを考えると、もう該当のものはなくなる。ここの部分は自作したが、相当の工数を費やした。cakePHPなどは改変が前提でGitHubなどで公開されたプラグインが多く、WPのプラグインと違い手を入れやすい。
３・オリジナルテーブルをいくつも使う羽目になり、だんだん面倒なことになってきた
WPで開発をすると、まず考えるのが投稿タイプを設定しpostsとpostmetaにデータを入れ込むという方法だろう。そうすれば入力インターフェースと管理画面はすでにおなじみのものが使えるし、何よりもWp_Queryの対象になるのでアーカイブなども自然と出来上がってくるしページ送りなども問題がない。
これはWPで開発する上での王道と言えるが、postmetaにあらゆるデータを入れるのはDBアプリとしては不自由な設計になってしまうし、データの確認もしづらい。何をするにも一手間多くかかる。もちろん負荷も多く、もっさりしたアプリになりやすい。
そこでオリジナルテーブルを複数JOINするようなアプリにしようとすると、この辺りの取り扱いはPHPフレームワークの足元に及ばず、$wpdbとSQLでガリガリやっていくハメになり、WPを使うメリットが少なくなってくる。
４・データ管理画面の作成工数が半端なかった
管理者用にちょっとしたCRUDの画面を一式作ってあげようとすると、これが大変面倒臭いし、融通も利かない。管理者用の一覧はadmin_tableなど専用のクラスがあるが、使いやすいものではない。ページ処理なども自前で実装しなければいけない。
CakePHPのbakeなどは本当に魔法のようにCRUD生成してくれる。もちろん調整は必要だが一から作るのに比べれば雲泥の差だ。
５・とにかく見通しが悪い
CMSだから仕方がないのかも知れない。MVCまでは行かないが、ある程度オレオレファイル規約を設けてファイルを整理したつもりだったが、処理が錯綜してくる。プラグインとテーマファイルにテンプレートと処理が分散する。設計次第といえばそうなるが、ある程度の機能を持たせようとするとグチャグチャになってしまう。
WP自体もそれなりにMVCらしき機構を持っているのだが、自分で独自のフロントエンドコントローラみたいなものを組み込むとさらに建て付けが悪くなってくる。
コメント