【WordPress】1からテーマ作成案件の受注〜納品までの流れ

WordPress

今日は、WordPressのテーマ作成案件の受注〜納品までの流れをご紹介します。

こんにちは。Webコーダーのharuです。

*わたしについて*
2歳0歳の育児をしながら、22時〜2時にプログラミングを独学しています。
2020.5.11~学習スタート
2020.8.10~実務でコーディングしています
HTML/CSS(SCSS)/jQuery/WordPress
これからもっと知識をつけていきたく、インプット・アウトプットを続けています。
このような方に向けた記事です
・案件の具体的な流れを知りたい
・受注してから納品するまでの過程があまり想像できない
・案件に挑戦するまでにやっておくと良いことを知りたい

これらは、わたしが案件のお話をいただいたときに思っていたことです。

WordPressコーディング案件の流れや進め方って、詳しく説明している記事が全然ないのですよね..。

WordPressの案件と言っても

・1からテーマ作成
・既存テーマのカスタマイズ
・静的サイトをWordPress化( 以下WP化 )
などいろいろあります。さらに、お仕事をさせていただくクライアントさんによってもお仕事の進め方は様々だと思います。

今回は、わたしが経験した「制作会社さんとの1からテーマ作成案件」を一つの例としてご紹介します!
お仕事の一例として、どなたか1人でもお役に立てたら嬉しいです。
※認識の間違っている箇所があれば、ご教授いただけると喜びます!

【WordPress】テーマ作成案件の受注〜納品までの流れ

1からテーマ作成のお仕事受注〜納品までの流れをご紹介します。

【受注】いただいた情報やファイル

今回は、ありがたいことに制作会社の社長さん(@ficus_at_osaka)からTwitter経由でお話をいただきました。

受注してから、いただいた情報やファイルは以下です。

・XDカンプ
・imagesファイル(一部の画像)
・サーバー接続時の鍵ファイル
・アニメーションや細かい実装の指示書
・メタタグの内容が書いてあるテキストファイル
・WP構築/テスト・本番環境/ベーシック認証 のIDやパス
・下層ページ内容が書かれた.pptxファイル(PowerPoint)

ちなみに、今回の案件は

✔︎ TOPページ + 下層9P のコーポレートサイトです。

上記が入ったフォルダをギガファイル便でいただきました。(いただいたURLをクリックして、圧縮されたファイルをダウンロードすることができます)

静的サイトとしてコーディング

まず、静的サイトとしてHTML/CSS/JSでコーディングを行いました。計9P。

不慣れなため、クライアントさんに確認してみたところ

①HTML/CSS/JSでコーディングを行ってからWP化
②ローカル環境構築して、真っ白のテンプレートを作成してからWP上でコーディング

の2パターンがあり、どちらを選ぶかは人によって好き好きだと教えてくださいました。

一度①で案件をやってみて思ったのは、②の方が絶対早くて効率的!ということですw

WP化をすれば、ヘッダー・フッターはファイル分割で使いまわせたり、記事一覧はループ1つで何記事でも表示できるからです。
次にWordPress案件をいただく機会があったら、わたしは②でやると思います!

ローカル環境の構築

次にWP化のためにローカル環境を構築します。
わたしは「local by Fly Wheel」を使いました。アプリから簡単に環境構築ができるのでとても楽です。

クライアントさんもこちらを使用されているとおっしゃっていました!

今回は全くの1から新規作成だったので、設定も全てデフォルトです。(Preferred)

ログインのためのIDとパスワードは、クライアントさんからいただいたものを使用して構築しました。

ADD SITEをクリックすれば構築は完了です!

これでWordPressのダッシュボードにログインできる状態になります。

新規テーマの用意

次に、1からテーマ作成案件なので、テーマ用のフォルダ・ファイルを用意します。

ファイルを用意する場所は、以下から

app > public > wp-content > themes

の中に、任意のテーマ名でフォルダを作成します。

今回は、このあと案件のアウトプットをするために環境構築したので「test2」という適当な名前をつけました。(実際は、案件のサイト名にしました!)

このフォルダの中に、index.php、style.phpなどを入れてテーマを作成します。

htmlコーディングの時に使用していたCSS/JS/imagesファイルもそのまま移動しておきます。

 

詳しくはこちらにアウトプットしていたので、過去記事を貼らせていただきます。

phpファイル構成

先ほどのフォルダにphpファイルを作成していきます。

まずは、空の状態でphpファイルを作成→HTMLコーディングした内容をコピー&ペーストします。

ファイル分けの一例として、今回の案件のファイル分けをご紹介します。

①TOP(カスタム投稿一覧ページ) //front-page.php
②記事ページ //single-$posttype.php
③タグカテゴリー検索結果 //taxonomy.php
④固定ページそれぞれ //page.php
⑤検索バー //searchform.php
⑥検索結果ページ //search.php
⑦テンプレ必須ファイル //index.php(中身は空),functions.php
⑧ヘッダー //header.php
⑨フッター //footer.php
⑩サイドバー //sidebar.php

こんな感じです。

実際には、404.phpや別種のカスタム投稿なども作成しました。

わたしは初めてのWordPress案件で不安だったため、上記のようなファイル分けを一度クライアントさんに確認してもらいました(見事に間違っていたので、ぜひ確認した方が良いと思いますw)

階層を調べるときは、こちらの図を保存して使用させていただいています。

(引用:WordPress codex テンプレート階層)

 

今回のファイル分けのポイントは、デフォルトの投稿ページを使わず(ダッシュボードからも削除する)、カスタム投稿を使用した点です。

デフォルトの投稿(post)を使用すると、詳細をsingle.phpで表示したときにパーマリンクが「/記事名/」のようになってしまい、親ディレクトリを挟むことができないと教えていただきました。
「news/記事名/」「blog/記事名/」のようにしたかったので、カスタム投稿を用意しました。カテゴリー検索結果のページも、デフォルトの場合はcategory.phpですが、カスタム投稿なのでtaxonomy.phpで作成します。

具体的なカスタム投稿の作成方法などは、別途アウトプット記事を用意しようと思います。

ファイル分割

以下のパーツファイルに、コードを分けていきます。
・header.php
・footer.php
・sidebar.php
(・searchform.php)
index.htmlに書いたヘッダー部分をまるっと切り取って、header.phpへ。
フッダー部分はfooter.phpへ…

この辺りは、世にたくさん記事があるので省略します

 

たとえばheader.phpの場合…

どこまでheader.phpなどのパーツに含めるかどうかは、デザインカンプによって汎用的な部分を入れたら良いのかなと思います。

わたしは今回、<head>に加えて<header>も入れました。これは、ヘッダーデザインがどの下層ページも同じだったからです。<header>がページによって違う場合は、<header>を別パーツに分けた方が使いやすいと思います。

→作成したheader.phpは、それぞれの下層ページのhead部分に<?php get_header(); ?>と記述することで、呼び出せます。

読み込むファイルのパスを変更する

htmlコーディングの時のパスのままだと、画像やCSS/JSの読み込みができません。

WordPressで表示できるようにパスを変更していきます。

画像のパスを変更

<img src=”/common/images/image01.png”>の部分を変更します。

<img src="<?php echo get_template_directory_uri(); ?>/common/images/image01.png">

このように、<?php echo get_template_directory_uri(); ?>を階層前に付ければOKです。

CSS/JSファイルのパスを変更

CSSとJSのファイルの読み込みは、header.phpに書いても機能はしますが、functions.phpで一括管理するのが一般的です。以下に例を載せます。

//functions.php
<?php
function my_enqueue_scripts(){
  //JS
  wp_enqueue_script('theme-jquery', get_theme_file_uri().'/common/js/jquery.min-3.5.1.js', array(), '3.5.1', true);
  wp_enqueue_script('my_js', get_theme_file_uri(). '/common/js/script.js', array(), false, true );
 
  //CSS
  wp_enqueue_style('my_common', get_theme_file_uri(). '/common/css/common.css', array() );
  wp_enqueue_style('reset', get_theme_file_uri(). '/common/css/reset.css', array() );

}
add_action('wp_enqueue_scripts','my_enqueue_scripts');

 

‘theme-jquery’, ‘my_js’など書かれている部分は、任意の記述で大丈夫です。

slickなどのライブラリを使用する場合もこちらに書きます。

common.cssに読み込んでいるもの

上記のcommon.cssに読み込んでいるscssも、一例としてご紹介します。

【Foundation】

①variable・・・変数
②mixin・・・mixin
③base・・・各scss共通の記述

【Layout】

①header・・・header.phpのscss
②footer・・・footer.phpのscss

こちらは制作会社の社長さんに教わった書き方です。

一つのファイルに一元化しておくことで管理しやすく、common.cssをfunctions.phpに読み込むだけで全て呼び出せます。

個別ページのCSS読み込み

個別ページのCSSは、その固定ページでのみCSSが読み込まれるように以下の形式で追記します。

//専用css

  //固定ページ
  if ( is_page('スラッグ名') ){wp_enqueue_style( 'page-company', get_theme_file_uri(). '/common/css/page-company.css', array() );}

 //タクソノミー
  if ( is_tax()){wp_enqueue_style( 'taxonomy', get_theme_file_uri(). '/common/css/taxonomy.css', array() );}

  //カスタム投稿
  if ( is_singular(array('スラッグ名','スラッグ名')) ){wp_enqueue_style( 'single-column', get_theme_file_uri(). '/common/css/single-column.css', array() );}

  //カスタムアーカイブ
  if ( is_archive('スラッグ名') ){wp_enqueue_style( 'archive-news', get_theme_file_uri(). '/common/css/archive-news.css', array() );}

・カスタム投稿のように、2つのページで同じCSSを読み込む場合は、array(スラッグ名,スラッグ名)というように書きます。

ざっくり書いてしまったので、参考URLを貼ります。

テーマの宣言

必須のテーマの宣言です。

style.cssに以下を記述します。ちなみに、style.cssだけは必ずphpファイルと同階層におきます。そのほかのCSSファイルはcommon > css内にあっても大丈夫です。

//style.css

/*
Theme Name: ◯◯
Author: ◯◯
Version:1.0
*/

Theme Nameだけあればテーマとして成り立ちますが、わたしは上記の記述を入れました。

Authorには制作会社さんの会社名を入れました。

 

また、テーマ必須の記述として以下も記述します。

//header.php
//</head>の直前に記述

  <?php wp_head(); ?>
</head>

 

//footer.php
//</body>の直前に記述

  <?php wp_footer(); ?>
</body>

実装

ここまでで、WP化の準備が整いました。

ここからはひたすら実装していきます。

詳しい実装についてのアウトプットは個別に記事を作りたいと思うので、ここでは割愛します。

テスト環境にアップロード

実装が終わったらテスト環境にアップをしていきます。

 

本番環境にアップロードする前に、テスト環境を挟むのは名の通り本番環境できちんと動作するのかをテストするためです。変更や修正はサイト全体に影響を及ぼすこともあり高リスクです。本リリースとなる際に本番環境にアップします。

PHPやサーバーの環境設定は、なるべく本番と合わせます。

参考リンク

今回は、クライアントさんからテスト環境を事前にいただいていました。

・新規サイト

・ローカル環境とテスト環境でID・パスが同じ

ことから、プラグイン「All in One WP Migration」でテスト環境のWordPressに上書きする形で移動をしました。

「All in One WP Migration」での移行は、とっても簡単でした!

【All in oneの移行方法】
①開発中のlocal WordPressで、プラグイン「All in One WP Migration」をインストール。
②プラグインを有効にして、エクスポート > エクスポート先を「ファイル」にする。
③移行先のWordPressの管理画面を開き、「All in One WP Migration」をインストール 。
④移行先でプラグインを有効 >インポート > インポート先を「ファイル」にする。
⑤インポート完了したらリロードするとログアウトされているので、localで使っていたID・パスでログイン(ユーザー情報も移行されて、古いユーザーは上書き削除される)

 

また、All in One WP Migrationはインポート制限があってかなり小さいですが、「All-in-One WP Migration File Extension」という無料プラグインを移行先で有効化すると、上限がかなり上がるのだそうです!クライアントさんに教えていただきました!

 

テスト環境アップ後の編集

テスト環境アップ後に編集したファイルは、「Filezilla」などのFTPツールを使って、サーバーにアップロードします。

Filezillaは無料のFTPツールで、初心者のわたしでも簡単に使えたのでおすすめです。

 

今回の案件ではSFTPという少し特殊な設定でサーバーと接続をしました。(FTP接続より簡単な模様)

SFTP接続
①Filezillaを起動し、ファイル > インポート。
②クライアントさんからいただいていた.xmlファイル(接続の設定が入ったもの)を選択。
③編集 > 設定 >鍵ファイルの追加 でいただいていた鍵ファイル.pemを選択。
左上のボタンからインポートしたファイルを選択 > 接続。

⑤接続が完了したら右側にもディレクトリ一覧が表示されます(下画像は表示されていませんが…)
左がローカル。右がリモートのディレクトリ一覧です。左と右、どちらも自分で作成したテーマ名のフォルダに選択を合わせます。その状態で、左から右にドラッグすればアップロード完了です。
ちなみにFTP接続の場合は、クライアントさんからいただく(自分でテスト環境を用意する場合は、自分の)サーバーのFTP情報が必要になります。
それらを ファイル > サイトマネージャー から登録していきます。
詳しくは参考サイトをどうぞ!

本番環境アップ

修正作業等が終わったら、おそらく本番環境にアップするのだと思いますが、わたしはテスト環境アップ〜編集まででクライアントさんに提出となりました。

今後、経験しましたら追記させていただきます><

 

おまけ:ディレクトリ構造

今回の案件で作成したディレクトリの構造です。

mainの階層には、各php / style.css /commonディレクトリ があります。

commonディレクトリには、css / scss / images / js / lib。

libはLibralyです。今回は、スライダーでslickを使用したので、そちらのライブラリが入っています。

 

また、CSSファイルについてですが、下層ページが多いサイトでSassをコンパイルすると

.css
.scss
.map

が一つのフォルダ内に入ってしまい、管理しづらくなります。

そこで、VSCodeの設定からコンパイル先を分けることができるので、設定するのがおすすめです。

X

参考リンク貼っておきます。

画像では/css/となっていますが、今回の案件のディレクトリ構造だと、 /common/css/が正解です。

案件までにやっておくとよかったこと

わたしがテーマ作成案件をやってみて、事前にやっておけばよかったなと思うことを書いてみます。

ツイートしたとおりですが、一番はカスタム投稿・カスタムフィールドの知識です。

かなりゴリゴリ使う案件だったので、少しでも知識つけておくべきだったなと思いました。

案件では、こちらのサイトにとってもお世話になりました。

サイト内で「カスタム投稿」と検索したページを貼っておきます!

 

あとは、今回はじめてgitで共同開発をおこないました。

制作会社さんやクライアントさんによっては、ファイルの共有をgitで行うこともあるかと思います。

gitを複数人で使うときに起こることとして「コンフリクト」は薄い知識としてあったのですが、実際に体験してうまく対処することができませんでした。

gitを使う予定があり、複数人での使用がはじめての場合は調べておくと良いと思います(´・ω・`)

また、わたしは案件挑戦までに書籍1冊、Udemyの講座を1つやりました。

しかし今振り返ってみて、Udemyをひととおりやったあとは、別冊を辞書がわりに見るのが良いなと思いました。

x.com

Udemyは、たにぐちまことさんの「WordPress開発マスターコース」がとてもおすすめです♪下のではない書籍やった後にUdemyやってみたら、こっちだけでよかったじゃんとなりました(´;ω;`)実務に使うところわんさかです!

わたしが辞書がわりに使っている本↓

ご参考になれば幸いです。

 

あとがき

だいぶ割愛してしまいましたが、今回の案件の流れは以上です。

どなたかのご参考になれば幸いです!

最後に、お話をくださった制作会社 株式会社Fics の(@ficus_at_osaka)さんに感謝いたします!今後も勉強させていただきます!

 

今日は以上です。

★Thanks:もりけんさん(@terrace_tec)

もりけんさんのHPはこちら