WordFes 開催まで後5日! WordPress のコーディングフローについて考えてみる

こんにちは。本日のリレーブログ を努めます、石原です。

 

日々、GrowGroup株式会社という Web制作会社でエンジニアをしております。

業務的に、バックエンドを開発したり、フロントエンドをコーディングしたりと忙しい日々です。

WordPress を業務として利用する会社ではバックエンドとフロントエンドで専業で担当するよりも、構築をすべて引き受ける方も多いのではないでしょうか?

WordPress のコーディングについて

WordPress においてのフロントエンド実装というと、「テーマ」作成業務にあたりますね。

しかし、WordPress のテーマ作業においては、PHP で記事を取得したり、中には複雑な条件分岐や、大量のカスタムフィールドを埋め込む必要があったりします。

皆さんは、テーマを作成してデザインをコードで表現し、サイトとして構築を終えるまで、どのような作業フローで行うのでしょうか?

主な作業フローとしては、2択となるかと思います。


 

1. テーマとしてコーディングを始める

デザインデータをスライス後、ベースとなるテーマを利用するか( underscoreなど )、一からテーマを作成し、HTMLをテンプレートファイルに記述していく方法です。

 

2. 静的HTMLコーディングから始め、テーマテンプレートとして埋め込む

まずは 静的HTMLを書いて、それを WordPress に変換する方法です。


 

以上の二択です。(他にもあったらすみません)

この方法をめぐり、今まで悩んでいました。

一体、どっちの方法の方が早く性格にコーディングができるのでしょうか?

私の完全な独自の意見ですが、考えてみました。

1. テーマとしてコーディングを始める場合

テーマとしてコーディングを始める場合、静的HTMLコーディングと比べ一体何がメリットとしてありえるのでしょうか?

メリット

・静的なHTMLテンプレートを書かないですむため、作業時間の短縮になる

・テーマとして必要な PHP のコードを一緒の流れの中で書けるため、作業時間の短縮となる

こんなもんでしょうかね。主に作業時間の短縮となる といったことが理由の一つとなりえますね。

私自身、このフローで作業を行う際に効率化できるように、ボイラープレートになりえるようなテーマを作成しています。

次にデメリットを考えてみます。

デメリット

  • HTMLマークアップを書きつつ、ファイル分割や、必要なPHPを書くため、作業が煩雑になる。

HTMLマークアップを書きつつ、カスタム投稿タイプを作り、サンプル記事を登録したり、カスタムフィールドを作成して、呼び出す処理を書いたり、作業はフロントエンドとバックエンドを行き来することになります。

  • タスクランナー等利用した際、BrowserSync でのリロードが遅い。

Gulp や Grunt 等のタスクランナーを利用する際に BrowserSync を入れる人がほとんどだと思いますが、プロキシで立ち上げるため、リロードがかなり遅くなります。

2. 静的HTMLコーディングから行う場合

さて、静的HTMLコーディングから行う場合についてですが、まずはメリットから見て行きましょう。

メリット

  • HTMLマークアップ、CSS 設計に集中できるため、作業はやりやすい

これはあたりまえですが一応。
特に、レスポンシブ Web デザインでコーディングする場合には CSS の設計がかなり大切になるため、作業に集中したいところです。

  • 作業効率化のための資産が結構ある

昨今の静的HTMLコーディングといっても、生のHTMLをそのまま書くことはほとんどありません。

Jekyll や Middleman といた静的サイトジェネレーターを利用したり、jade や ejs といった テンプレートエンジンを利用することが多いです。

CSS は Sass や Less, Stylus …etc といった メタ言語 を利用しますね。

いくらEmmet やエディタのパワーに頼ろうとも、WordPress テンプレートをコーディングするよりもこちらの方が早いかと思います。

特に Yeoman の generator-gulp-webapp 当たりを利用し、 + jade あたりのテンプレートエンジンを導入すれば、かなり早くコーディングに取り掛かれるのではないでしょうか。

※ jade + WordPress テーマ作成をこなす荒業もみかけますが、僕は やめときます。僕の脳みそでは訳の分からないことになりそうです。

デメリット

  • コーディング後、WordPress に移行するので最終的にはいらないかわいそうなファイルに変身する

まぁ…そういうことになります。

  • コーディングする際に、WordPress で吐き出される class や id 、マークアップに関する知識を持っていなければならない。

WordPress では、ウィジェットやメニュー、その他独自に出力されるマークアップがあるので、その知識がないと
WordPress に変換する時に CSS を書きなおしたり、マークアップを変更したり、、、といった自体に陥ります。

どっちがいいの?

ここまで、2つのワークフローについて考えてきましたが、
どちらの方がいいのでしょうか?

(まぁ、人それぞれ、千差万別ではありますが。)

 

僕の中で現在出した答えがこちらです….!!

 


 

・小規模なサイト ( 4,5ページ ) は WordPress テンプレートとして構築

 

レスポンシブ Web デザイン、もしくは大規模なサイト は 静的HTMLコーディングから作業


 

 

 

ここまで引き伸ばしてこれかよ…って感じるかもしれませんがw 現状これがベストかと考えてます。

レスポンシブ Webデザインなどを実装する必要があったり、大規模だったりすると、
いきなり WordPress テーマから開発を行うと結果的に作業時間がかかる場合が多いんです。個人的に。

特に、CSS の設計当たりが時間がかかり、コンポーネントベースのマークアップって、難しいです… ほんとに。
レスポンシブ Web デザインも、複数デバイスで確認しながら、自動リロードばんばんかけて随時確認しながら進めないと全然進みません。
Jade といったHTMLテンプレートエンジンも非常に便利で、生のHTMLを書く気力がなくなります。

また、バックエンドとフロントエンドを分けて考えることで、非常にやりやすくなります。

逆に、小規模なサイトだとそこら辺を考える必要がないので、いきなり WordPress テーマとして実装した方が作業時間はかからないですね。

これが、これまで、HTMLコーディングからWordPress テーマへ → WordPress テーマをいきなり実装 → HTMLコーディングからWordPress テーマへ という作業フローに変更してきて、現状出している答えです。

以上、一介のWordPress エンジニアの意見として参考に、してもらえれば幸いです。