はじめに
monpy です。フロントエンドやってます。UNBA 所属
私の働いている会社では、毎クォーターのはじめに、前クォーターの振り返りを発表する。
いつものは esa.io に書いたりするけど、今回からここにまとめようかな。要するに ストック乞食
何の話か
前クォーターは WordPress を利用して、会員向けのコンテンツを含むサイトを構築したことが主だった。
その話を今回する。
実はこの話は
wordpress案件 に docker を使ってみた件 にも書いたので、興味があるなら覗いてストックしてほしい。
案件を受けるまで
私は PHP にも WordPress にも明るくなかった。
加えて 私の周りには アンチPHP が多く、大学の教授までそんな言語やるなと言っていた(大学なら言って当然だろうとは思う)。
ただ個人の所感としては、PHP はプログラミング言語としてはあまりよろしくないかもしれないが、テンプレート言語としては良いと思う。
フロントエンドしては、一旦は抑えておくべきところだろうとうことで、あえてこの案件を担当した。
これも感想だが WordPress を利用したサイトを作るためには、実はそんなに PHP のことを知っている必要はないと感じた(そこが PHP が優秀な理由かもしれない)、普段フロントエンド業務で javascript ができれば大抵が google に質問を投げれば解決するレベルの問題だと思う。
WordPress を知る + tips
重要なのは WordPress の構造や決まりごとを知ることである。
会社には WordPress に詳しい人がいなかったので、まずは自分がシステムの全容を把握する必要がある。
書籍を買う
みんな大好き oreilly から
というのが出ていたので買って流し読んだ。(https://wpdocs.osdn.jp/ に大体乗っているけどね)
この本のは、どこぞの WordPress開発本 とは違って WordPress の DB構成 や、その関係性が明記されている。これが非常に助かった。
WordPress案件で困りがちなのが、用意されている API からは整形できないデータが要求された時である。
そういう時は 自前で DB を叩いて持ってくるしかない。そうすると先の本の重要せいがわかるだろう。
あとは、テンプレートの上下関係とか基本的に知っておくべき情報が一通り揃っているので、買っておいて損はないと思う。
web の偉大な知恵を拝借
あとは、大体が先人の知恵を利用させてもらう。
以下は大抵知っておくと良さそうなリンク集として捉えといてほしい
CustomPost
自作の投稿タイプはどの案件でも必要になるでしょう。
ちなみに Custom Post Type UI なるものがあるらしいが、きちん自分で設定できる方が良い。
作ってる時にはなかったが最高のリンク集があった
ちなみに 個人では以下のようにな構成で管理した
custom_posts
├── _all.php # 下の各ファイルを読み込む
├── actions.php # 例えば 管理ページの表示をいじる時などはここで設定する
├── custom_1.php # 自作のカスタムポストの設定を書く
...
<?php
require_once( dirname(__FILE__) . '/' .'custom_1.php' );
require_once( dirname(__FILE__) . '/' .'actions.php' );
?>
Custom Permalink
記事リンクをいじるのもほぼ必須。
これはとても優秀な プラグインがあるのでこれで設定するのに限る。
ただこれだと実現できなケースもあった。
例えば
hoge/huga
のように、一階層下に潜った URL が希望だった時は上のプラグインだと難しかった。
そういう時は custom post の設定で rewrite 項目を以下のように設定し、さらに追記する プラグインの cptp_permalink_structure プロパティを指定する
"rewrite" => [
"with_front" => false,
"slug" => "hoge/huga"
],
"cptp_permalink_structure" => "/%post_id%"
こうすることで
hoge/huga/1
みたいな URL になった(気がする。すまそ、、、すまそ、、、)
query var
検索の時のパラメータはいつだって重要である。
検索プロパティをまとめた gist があるのでこれを見よう
pager
これは プラグインを使わない方が幸せだった気がする
ここに良い方法が掲載されていて
ここにあるのを partial なりでよびだせるようにしておく。
下準備としては重要なのが、ページ単位のポストの件数のデフォルトを 1件にしておく。これをしておくと、ページ毎(例えばカスタムポスト毎)に好きに１ページあたりの出力件数を制御できるようになる。
具体的には 各 archives で以下のようなことをしていた。
<?php
// query の再設定をする
$per_page = 10; # 1page あたり 10件出力する
$new_query = add_query_arg( array(
'posts_per_page' => $per_page,
'paged' => $paged,
), $query_string );
$archives = new WP_Query($new_query); # そのページの記事を取得する
// pager の設定
$pagerArgs = array(
'max_num_pages' => $archives->max_num_pages,
'paged' => ($paged ? $paged : 1),
);
#これは自作の関数だが、内容は上記リンクの
# 'total' と 'current' を変数経由で設定するようにする
<?php partial("parts/commons/pager.php", $pagerArgs); ?>
?>
こうすることで $per_page を弄れば好きなようにできた。
Custom Field
Advanced Custom Fields 一択
大抵これで肩がつくと思う。
UI 的にも優しい。
ここに素晴らしき記事がある。
DB
こればっかりは難しいが、先に紹介した本を読めばきっとできるはず。
バックエンド人がいれば、やさしく答えてくれるだろうから投げてしまうのも吉。
composer
PHP の有用なリソースを使い倒しましょう。
私は up-parser あたりを使いました。
npm と感覚は同じなのでこれも別に抵抗感は無いです。
あまりよろしく無いですが、composer 用のl フォルダを用意してそのままアップしてしまうのも選択の一つ(サーバ側でinstall できない場合の話)
あとは案件の質によって変わるでしょうが、基本を押さえさえすればきっとう大丈夫なはず。
社内環境とか
もう一つ頭を悩ませるべきなのは 構築環境である。
言葉だと難しいので図で説明する。
ざっとだがこんな感じ。
ポイントは以下
- 開発人と PM(その他)の分離
- PMは基本的に web 上の環境でしか見ずにソースコードは触らない
- DB を手元と同期させデバッグを行う、基本的に手元のDBは Preview のコピーにする
- 逆に サーバ上のソースコードは 手元のものをコピーする
- 環境は Docker に任せる
- 上記の作業を Make ファイルでコマンド一発でできるようにする。
個人的には結構やりやすかった。
Docker がもう少し軽く動いたら最高。
本番環境も基本的には Preview と同じことをするが、クライアントがいじってしまうケースなどを考慮する必要がある。
そこは間違いのないように事前に運用方針を共有することが重要である。
多人数開発だったので、ここら辺を準備するのは重要だった。
個人開発ならここまでする必要はないでしょう。
まとめ
ここら辺までが、私が主だった案件を納めるまでにしたことである。
雑に言えばなんとかなった。
WordPress は、見た目をつくるのはどうとでもなると思う。
でも重要なのは、その後の運用をクライエントさまと円滑に進めていく準備をしておくことだと思いました(なんとなくいいこと言っておこう)。
この記事が WordPress やってみたいと思う人の後押しになればこれ幸い。
仕事ほしい
お仕事ください。