このサイトは現時点では静的サイトジェネレータの hugo で書いているが、別件で、WordPress ブログのリニューアルを行うことになった。
このプロジェクトでは、僕がデザインと実装を行い、クライアントが辛口のフィードバックやダメ出しをくれる形式。

このプロジェクトで僕は無給で働いた。

クライアントとは奥さんのことだ。


WordPressから他のプラットフォームへの移住も考えたが、やっぱりWordPressを選んでしまった。

webデザイン

ボタニカルや手芸がテーマだけど、クライアントの人柄を表すイエローや五芒星をモチーフに取り入れた。

アイデンティティを考え・・・
(ちょっと稚拙な図案だけど)

イメージを考え・・・

レイアウトを考え・・・

クライアントに、雰囲気でオッケーをもらえたので、途中から実装に移る。

サーバ構成

apacheやPHPを直接扱うのは辛いので、Dockerを使う。

WordPressは、置くだけで、動く。だが、Dockerを使うときは、いつ壊れても良いように万全の守りをしなければいけない。
この危機感・制約があるため、逆に、怠けずにコード化、バージョン管理、バックアップをしっかり考える必要にせまられる。

小さな個人ブログなので、スケールアウトは考慮しないし、もし必要になったら CDNを前に置ける前提で設計する。
また、SuperCacheプラグインを使い、静的ファイルを吐き出すようにしておくだけで、相当に早くなるし、そうそうCPUが燃えることは無い。
PHPに動的な仕事はさせない。必要ならJavaScriptでやれば良い。

サービス 説明
nginx バーチャルホストとSSL終端
php Dockerコンテナで動かす。
PHP のオフィシャルイメージをベースにする。
mysql これもDockerコンテナ。貧乏性のため、別サービスと共有。


PHPで書かれたWordPressのコード一式は、Dockerではなく、ホストマシンに置いて、コンテナの/var/www/html にバインドマウントすることにした。
WordPressのオフィシャルイメージは使わない。WordPress自体のコードを永続化したいからだ。

WordPressは、ファイルシステムへのアクセスを平然と行うアプリケーションなので、コンテナに管理させるよりも、ホスト側でバージョン管理やバックアップを受け持つことにした。
それと、マウント先への書き込み権限を与える必要がある。

参考にした記事:
ホストディレクトリに入れたwordPressをdockerで構築したApache+PHP+MySQLで動かす
http://qiita.com/tubone/items/1edf2d3639089a1837ea

このPHPオフィシャルイメージは、apacheの子プロセスをwww-dataというユーザー権限で動かすようだ。なので、apacheを、ホストに実在する、WordPressコード一式の所有者のユーザー権限で動くようにした。

他、imagemagickやmod_rewriteを突っ込み、Dockerfileはこんな感じに。

FROM php:7.1-apache

RUN useradd -M -u $YOUR_USER_ID $USER_USER_NAME
ENV APACHE_RUN_USER $USER_USER_NAME
ENV APACHE_RUN_GROUP $USER_USER_NAME

RUN apt-get update && \
  docker-php-ext-install pdo_mysql mysqli mbstring && \
  apt install -y imagemagick

RUN a2enmod rewrite

ソースコード管理やバックアップについて考える

公開されるディレクトリ、いわゆる/var/www/html 配下は全てgitで管理し、バックアップ体制が整ったリモートリポジトリにpushしておく。
しかし、ファイルサイズがやけに大きいことに気づく。リニューアル時点で、不要な画像も含めて、アップロード画像が500MBくらいあったからだ。アップロードコンテンツwp-content/uploadsだけはgit管理から除外し、別の道を模索。

アップロードコンテンツは、aws s3 sync コマンドをcronで走らせてAWS S3にバックアップするようにした。syncコマンドなら、変更が無いファイルは転送されない。

aws s3 sync $WP_ROOT/wp-content/uploads s3://$S3_BUCKET/wp-content/uploads

WordPressテーマを開発する

順番が逆になってしまったが、端末でWordPressが動く環境を整え、テーマ開発をしていく。

この時点ですでにテーマフォルダ wp-content/themes もgitリポジトリに入っているので、ローカルにcloneして、テーマを作って、pushすれば良さそうだ。

今は、単にテーマだけ作れれば良いので、本番サーバと同じ環境を再現することは重要ではない。ローカル開発用にDockerComposeを使ってサーバを立てる。docker-compose.ymlはこんな感じになった。

version: "2"
services:
    wordpress:
        image: wordpress:latest
        ports:
            - "9000:80"
        depends_on:
            - db
        environment:
            WORDPRESS_DB_HOST: "db:3306"
        env_file: dev.env
        volumes:
            - ./public/wp-content/themes:/var/www/html/wp-content/themes
    db:
        image: mysql:latest
        env_file: dev.env
        volumes:
            - ./db:/var/lib/mysql

標準のテーマ(2017年時点では、twentyseventeen)をコピーして作ろうとしたが、あまりにコードが長く、ファイルが多いため、すべてフルスクラッチで書き直すことにした。

標準テーマは過度にファイル分割しているが、正直、ファイルが多すぎて辛い。小さいブログならindex.phparchive.phpだけ使っていれば十分ではなかろうか。
今回は、シンプルなフラット構造を意識して、index.phpにあらゆる分岐を詰め込むスタイルを採った。最終的に、ファイルはこんな感じ。(汚いので中身の公開はしない)

CSSは、プリプロセッサ Stylus と、ポストプロセッサ kouto-swiss を使い、package.jsonにワンラインで、watchしてbuildするスクリプトを書く。

Stylus と kouto-swiss の組み合わせが気に入っており、よく使っている。StylusはSassよりも柔軟性が高いし、Sassのような分裂(.sassか.scssか、Node版のSassかRuby版のSassか)も無い。
また、Stylusは、最近では、SCSSに近い文法(CSS Style Syntax)にも対応していて、しかも、1ファイル内でCSS文法とインデント文法を混在させられる。うーん、強い。

クライアントにテストサイトを見せながら開発を進めていくが、プロトタイプ段階よりも多くのフィードバックをもらった。
クライアントは普段、Windowsを使っているので、だんだんWindowsみたいなデザインに近づいていく。これを、押しとどめることに苦労した。


できた

まだ肝心のコンテンツが投稿できていないが、執筆して公開できる状態になった。

フライング・スター・サボテン
http://plants.snkz.org/

まだ使えないコンポーネントがあったり、ページを増やしたい需要があるから、暇なときに作っていく。
WordPressのテーマをフルスクラッチ開発するのは辛かったが、一度やってしまえば、どんなカスタマイズでも出来そうな気がしてくる。