https://h2ham.net/wordpress-coding-flow-02
なんかハムさんと会うたびにこの話をしている気がします。とろゆにです。というわけで便乗エントリーします。
基本的にはいきなりテーマを作り始める派でした。既存のテーマをベースにすると言うことはほとんどやってきませんでした。ですが今年1年を振り返ってみると案件によってまちまちで、WordPress のスターターテーマ _s をベースにした開発もやりましたし、 HTMLを作成してから WordPress というフローもありました。それを踏まえてそれぞれに思うことをつらつらと。まぁ思うところや結論はハムさんとだいたい一緒ですが、プラスアルファということで。
いきなりテーマを作る？ or 静的HTML作る ？
いきなりテーマを作る場合
僕の WordPress テーマ制作のワークフロー ( 仕事編 ) – Habakiri でもキタジマさんが言っていることですが、静的 HTML と WordPress テーマのテンプレートが同じようなコードになります。それならば最初から WordPress テーマを作った方が WordPress と矛盾したモノを作りづらくなる、ソースコードの管理が煩雑にならないというのは大きなメリットです。
テーマユニットテストを突っ込んだ状態の WordPress を用意してそこからスクラッチで書いていくというのが僕の基本的なフローです。基本的には ビジュアルエディタで完結できるような作りを目指して実装していくという格好です。自動挿入される p タグや、ビジュアルエディタで消えてしまうHTMLの書き方などもあるので、そこら辺への対応を最初の段階でケアできるのは楽だったりします。
静的HTMLを作った方が良さそうな場合
運用する人があまり固定ページを編集することが想定されていない or HTML や CSS を固定ページごとに書くような運用を想定しているケース等は静的HTMLを作った方が良いのかなと思いました。HTMLのサイトがあってそこにニュースなどの一部コンテンツのみ更新したいという要件ですかね。
そもそもそんなモノを WordPress の固定ページになぜ載せるのかというのはあるのですが、サイト内検索、お問い合わせフォーム等、WordPress の一部機能を使いたいなど理由は様々。ただその場合は WordPress を無理矢理使っている感も否めないなというのもあって悩みどころです。
「WordPress のテーマの実装に入ってからの手戻りとかがあった場合どうするの？」ってWCT2016のセッションのときに聞いたんですが、「そんな手戻り無い」って言われたのは結構大きな衝撃でした。ワークフロー次第だとは思いますが、HTMLをちゃんと作りきってしまえばそんなモノなのかもしれないです。
比較して思うこと
結論としてはどっちも有るなぁと言う感じです。「WordPress のテーマを作ること」と「デザインをコーディングすること」のどちらの比重が高いのかで最適なやり方は違うのかなと思いました。特にテーマとしての運用性よりもデザインの再現が重視されるような場合は、HTML作った方が良いのかなとも。
また普通に静的なHTMLとして作成して、サイト内検索は Google のカスタム検索などで実現するというほうが有用なケースも多々ありそうです。
既存のテーマをベースしたテーマ作成
- とりあえず、最初からある程度の機能がそろってる。Jetpackの無限スクロールなどもサクッと対応できた。（_sの場合）
- ベースにするテーマそのものへの理解が必要。（主に独自のテンプレートタグとはき出すHTMLへの理解）
というのがやってみて感じたことです。ブログなどががっつりメインコンテンツになるケースなどは _s 等をベースにすると割と便利な気がしました。
ただ、ベースにする以上はあまりPHPやHTML部分に関しては弄りたくないなというのがありました。というよりそこを弄りまくるならまっさらな状態から作った方が楽というか、ベースにするテーマに対する学習コストが無駄になるなという感じです。テーマごとにカスタマイズの流儀みたいなモノもだいぶ違うので基本的に HTML の構造への編集は最小限に抑えたいなという印象です。この学習コストというのが結構馬鹿にならないとは思っています。
そうなっていくと結構CSS力などが問われる場面も多かったような記憶があります。テーマには当然リセットやHTMLタグに対するベースのスタイルなども含まれているのでそこら辺をちゃんと踏まえないといけない部分は多い気がします。そういう意味では habakiri や lightning 等は Bootstrap ベースなのでそこら辺の知見が役に立ちやすいのかなと。
ハムさんの疑問への解答
Web上の投稿エディタでマークアップを入れなければ再現できないような場合…みなさんどうしています？
僕はショートコードを作成して対処することが比較的多いです。Shortcake を使うとビジュアルエディタへの対応もそこそこ簡単なのでそれが一番スムーズなのかなと思っています。
functions.phpでできることでもプラグインだけでできることはプラグイン優先で構築するべきかどうか
functions.php できることというよりは functions.php でやって良いことかどうかは基準です。自分で書く場合もテーマに乗せるべきモノはそっちに書きますが、カスタム投稿タイプやショートコード、アクセス解析のコードなど、テーマが変わっても機能するべきところはテーマでは無くプラグインで実装します。
ここら辺は、WordCamp Tokyo 2016 で Mignon Style さんがお話しされていた、「ノンプログラマーのためのWordPressテーマ作成ステップアップ術」が詳しいです。
サイト用のプラグインを作ったり、mu-plugins にそのサイト用のコードを置いておくのが多いです。3行とかのコードでも別々のプラグインにしたりとかもやったりします。
ただ、全ての機能を自分で作るなんて言うことは無く、公式ディレクトリにあるプラグインで済むモノは積極的に利用しています。自分で作ったからといって、それが積極的にメンテナンスされるという保証も無いですし。
プラグインの選定基準は機能が要求に合っているかどうかは当然ですが、作者の人が積極的にメンテナンスやサポートをしているかどうかを割と重視して選んでます。コミットメントがあまり活発でないものはあまり使わないですね。
またテストとかがないものや、あまりにもコードが読みづらいモノは避けたいとも。バグを踏んだり足りない機能があったらそれはプルリクエストなりパッチを送ろうぜ！と思っているので、それがやりづらいプロダクトは避けたいなという感じです。
さいごに
去年のハムさんの記事を読んで便乗エントリーをしようと思っていたら1年経ってしまいました。WCT2015で初めてハムさんとお会いしてからと言うもの、毎度毎度この話をしてる気がします。（主に懇親会で飲みながら延々と）
https://h2ham.net/wordpress-coding-flow
仕事の進め方、チーム、仕様など様々な理由で最適解は違うなぁというのがこの1年の僕の感想です。ただそれによって設計や求められるスキルも変わってくるのでどう対応していこうかなというのは悩みどころです。REST API も 4.7 で本体にマージされたので、ここら辺の話はますます変わっていくのかなというところです。そうはいってもテーマをいきなり作る派であることは変わらないので、またハムさんとお酒を飲んだときにでも決着を付けようと思っていますのでよろしくお願いします！
