中小企業のマーケティングやブランディングのコンサルティング。事業開発 (ビジネスモデルの開発)、デジタルマーケティングやウェブサイト改善など事業の持続的・長期的な成長・発展に貢献できるサービスを提供しています。
WordPress 本体のアップデートプロセスチャートを作ってみました。
WordPress 3.7 から実装された自動更新で WordPress がアップデートされると、WordPress 本体が自動でアップデートできます。
自動更新は、いくつかのアップデート方式 (マイナーバージョンだけ、メジャーバージョン・マイナーバージョン両方) があり、それぞれが WordPress 本体がどのようにアップデートするか図解してみました。
加えて、開発したプラグイン「WP Auto Updater」で実装したアップデート方式
を追加してみました。
安定的な WordPress サイトの運用に参考にどうぞ。
WordPressスターターテーマ「WP Theme Boilerplate」を開発しました。
去年2018年11月頃。WordPress 5.0 から新しいブロックエディタ (Gutenberg) が出ることだし、それにフィットする WordPressテーマを作りたいなぁと。公式に掲載してみたいなぁと。
もともと定番スターターテーマである「_s (Underscores)」をベースにテーマを作っていましたが。
気づいたらいつのまにか方針転換をしちゃって、テーマ作りより独自のオリジナルテーマがスムーズに作れる環境を作ったほうが広がりがあって面白いなぁと思い、取り組んでみました。
特徴は 8 つほど。
この辺がサクッと整備されたらいいなぁと。
ただ効率的にテーマがつくれることだけを追求してもだめで。(単にテーマを作れるだけでは価値はだんだんなくなってくる)
一番価値が生まれるところである、デザインやコンテンツにきちっと時間を割きたい。
ビジネスにスピードと柔軟性が求められている中でプロトタイプ的な、アジャイル的なアプローチで開発ができるようにしたい。
常に改善されるテーマになるよう機動性を手に入れたい。
新しい価値を生み出す今の開発環境にマッチできるような設計思想をいくつか組み入れてみました。
結果、ただテンプレートが揃っただけのスターターテーマではなく、開発環境やテスト環境など周辺環境を整えた「スターターキット」にしてみました。
WordPressテーマは、ディレクトリ直下にテンプレートファイルが置かれる (WordPress 全体から見るとテーマフォルダ自体が View って感じな、テーマ開発者にとって View がディレクトリ直下にある感じな) ので、
ディレクトリ構成上フラットになりやすく、いろんな種類や役割がファイルが混ざってくる。
シンプルなテーマなら気にならないが、開発しているとファイルが散らばり複雑になってくる。
のちのち開発効率や開発意欲の低下がボディブローのように効いてくるので手を入れて整理してみた。
シンプルにテンプレートファイルを一つ下のディレクトリにまとめるアプローチで解決する。
テンプレート階層にも関わってくるので、複雑なことはしないようにする。
WordPressは、テンプレートの選ばれ方を把握していないとそう簡単に動かすことはできないけど。
これでディレクトリレイアウトが少しばかり整理される。
次にテーマの機能を関数からクラスベースに変える。
従来だと、関数名がWordPressコアの関数や他のテーマ・プラグインの関数とかぶらないように
関数名を「テーマ名のプリフィックス_関数名」みたいに先頭に namespace をつける。ので関数が必然的に長くなる。
また開発を続けていると、どの機能に関係している関数か、この関数はどこに影響や副作用を及ぼすのか、
functions.php が肥大したり、次第にまとまりがわからなくなってくる。
方向性としてテーマの機能は、クラスベース (クラスファイル) で namespace をつかってそれぞれの機能が分離するように再設計した。
そのクラスファイルは、composer autoloader のように自動的に読み込んでくれるように
WordPressのファイル命名規則に基づいて WordPress Theme Autoloader を実装してみた。
必要ならば composer autoloader を使って外部のライブラリにある機能を取り込めることもできるし。
大掛かりにならない程度の実装で機能を取り込めるように、開発が楽しくなるように目指してみた。
メインテンプレートには、複雑なロジックを入れないようにベースとなるレイアウトだけ定義する形がよさそう。
そしてパーツとして切り分けたファイルをメインテンプレートに読み込むのが基本線。
また wp_head, wp_footer などテンプレートタグにフックする。(最近 v5.2 だと wp_body_open が出てさらに便利になったね)
フックは WordPressの大きな特徴で醍醐味な部分なので。(フックを覚えたらWordPressの開発が楽しくなると思うなぁ)
テーマ専用のフックがあってもいいのではなかろうか。(将来共通化したものが出てくれたらうれしい)
ということで Theme hooks を実装してみた。
メインテンプレートのレイアウトの所々にいくつか設けた Theme hooks に引っ掛けることでメインテンプレートには手を入れずに追加要素を差し込んだり、フックした関数 (アクション) 側で複雑なロジックを組み入れることを目指してみたい。
独自テーマが作れるように Theme Starter script を用意してみました。
テーマ名を引数に Theme Starter script を走らせるだけでオリジナルテーマの雛形がすぐに生成されます。
そこからあなただけのオリジナルWordPressテーマをつくっていける開発環境ができあがる。
WordPressテーマを作れる環境はすでに目の前にあります。
WordPressテーマ作りを楽しく過ごしてみてね。
素敵な、便利な、魅力的な WordPressテーマがたくさん生まれたり、
面白い、読み応えのあるコンテンツがある WordPressサイトがいっぱい出来上がったり、
テーマ開発やWordPress構築プロジェクトを成功に導いたりと。
WP Theme Boilerplate が縁の下の力持ちとして
少しでも力になれば幸いです。
今後やることをメモ。
WordPressでウェブサイトやブログを立ち上げるのは、手軽でツールとして便利な一方。
WordPressサイトを運用しつづけるには、メンテナンスをする手間やセキュリティ上のリスクを自分で対応する必要があります。
保守管理をするレベルで対応できる範囲はそれぞれですが。
個人でWordPressサイトを運営する方から、ビジネスでWordPressを使ってウェブサイトを開設している方、ウェブ制作会社などクライアントのウェブサイトをサポートしている方に参考になるようできるだけ幅広い視点から「WordPress保守運用チェックリスト」を作成してみました。
WordPress保守運用の底上げに繋がれば幸いです。
2020.10.05更新
最近各 Linux ディストリビューションがリリースしている Vagrant Box を使うようになりました。
以前は、Bento project など良さそうな Vagrant Box を採用していましたが、
Linux ディストリビューションの Vagrant Box が整備されつつあるので、もっぱら使っています。
ただ Virtualbox Guest Additions がインスールされていない状態の Vagrant Box なので、
プロビジョニングの時にプラグイン vagrant-vbguest で入れるようにしています。
Vagrant では、いくつかフォルダ共有のタイプがあるのですが、
VirtualBox の共有フォルダ機能を使う場合は、Virtualbox Guest Additions が必須になります。
今回その時に遭遇した不具合対処メモ。
vagrant up すると、共有フォルダが同期できない現象。
==> default: Mounting shared folders...
default: /vagrant => /Users/thingsym/vaw
Vagrant was unable to mount VirtualBox shared folders. This is usually
because the filesystem "vboxsf" is not available. This filesystem is
made available via the VirtualBox Guest Additions and kernel module.
Please verify that these guest additions are properly installed in the
guest. This is not a bug in Vagrant and is usually caused by a faulty
Vagrant box. For context, the command attempted was:
mount -t vboxsf -o uid=1000,gid=1000 vagrant /vagrant
The error output from the command was:
/sbin/mount.vboxsf: mounting failed with the error: No such device遡って調べて診てみる。
Virtualbox Guest Additions はインストール完了したが、
vboxadd.service が立ち上がっていない。
結果、共有フォルダがマウンドできない。
Installing Virtualbox Guest Additions 5.2.12
Redirecting to /bin/systemctl start vboxadd.service
Job for vboxadd.service failed because the control process exited with error code. See "systemctl status vboxadd.service" and "journalctl -xe" for details.カーネルのバージョンが不一致になっている。
Please install the Linux kernel "header" files matching the current kernel
for adding new hardware support to the system.Virtualbox Guest Additions をインストールするときに
必要なパッケージをインストールするのですが、
そのなかに kernel-headers が含まれていて
kernelのアップデートのタイミングの問題? なのか
アップデートしてしまう。
ゲスト側でカーネルを調べると、
カーネルのバージョンが不一致になっている。
今回は、パッチ番号 (693と862) が不一致に。
rpm -qa kernel\* | sort
kernel-3.10.0-693.21.1.el7.x86_64
kernel-headers-3.10.0-862.2.3.el7.x86_64
kernel-tools-3.10.0-693.21.1.el7.x86_64
kernel-tools-libs-3.10.0-693.21.1.el7.x86_64kernel-headers が kernel のバージョンに対応していない状態。
vagrant sshゲスト側に入り、kernelをアップデート
sudo yum -y update kernel
sudo yum -y install kernel-devel kernel-headers kernel-tools kernel-tools-libsカーネルのバージョン (パッチ番号862) を揃える
rpm -qa kernel\* | sort
kernel-3.10.0-693.21.1.el7.x86_64
kernel-3.10.0-862.2.3.el7.x86_64
kernel-devel-3.10.0-862.2.3.el7.x86_64
kernel-headers-3.10.0-862.2.3.el7.x86_64
kernel-tools-3.10.0-862.2.3.el7.x86_64
kernel-tools-libs-3.10.0-862.2.3.el7.x86_64再度プロビジョニング
vagrant reloadBash のシェルスクリプトは、エンジニアが片手間に書いて使う DIY 的な使い捨てスクリプトになりがちぎみだけれども。
Bash のシェルスクリプトを作ってオープンソースとして公開している手前、
「きちっとテストを入れたいなぁ」と思っていろいろ Bash のテストどうやるの? というところから始まって
どんなアプローチがあるのだろうといろいろ調べたり試したり。
結果、Bashテストフレームワークとして「Bats」がシンプルすぎるぐらいに良かったので採用してみました。
Bats の正式名称は、Bash Automated Testing System。
ドキュメントには、
Bats is a TAP-compliant testing framework for Bash.
(訳: BatsはBash用のTAP準拠のテストフレームワークです。)
とある。
使い方は、.bats 拡張子を付けたファイルにテストケースを書いていくだけ。
例えば、example.bats に以下を書いて
#!/usr/bin/env bats
@test "status - return 0 exit code" {
run bash -c 'exit 0'
[ "$status" -eq 0 ]
}
@test "output" {
run bash -c 'echo -e "abc"'
[ "$output" = "abc" ]
}
@test "lines" {
run bash -c 'echo -e "abc\ndef\nghi"'
[ "${lines[0]}" = "abc" ]
[ "${lines[1]}" = "def" ]
[ "${lines[2]}" = "ghi" ]
}テストを走らせると、
bats --tap example.batsテスト結果が得られます。
1..3
ok 1 status - return 0 exit code
ok 2 output
ok 3 linesテストケースのプロセスは、run でコマンドを実行し、
その結果が 3つの変数に保存されます。
$status - exit status を保存$output - 標準出力またはエラー出力を保存$lines - 標準出力またはエラー出力を行単位で配列で保存それら変数を確かめたり、アサーションしたりする。
setup, teardown もあるので、
いろんな設定を想定したテストケースが作れると思います。
Bash だけでなくいろんな言語のコマンドラインツールで使えて
シンプルなテストには、もってこいのテストフレームワークです。
今回、その Bats のヘルパースクリプト「Bats Assertion」をつくりました。
Assertion 系のヘルパースクリプトは、ほかにもありましたが、
テストを書くこと自体がテストドキュメントになる。
もっとシンプルに書けて、テストを書くことが億劫にならず、
テストを育てていく感じにならないかなぁと思って設計してみました。
使い方は、ヘルパースクリプト「Bats Assertion」をダウンロードして
テストファイル内で Bats の load コマンドで読み込むだけ。
load bats-assertion/bats-assertion読み込むと、以下の assertion 系のコマンドが使えるようになります。
それぞれのコマンドの詳細は Assertion Reference を参照してみてください。
先の example.bats をヘルパースクリプト「Bats Assertion」で書き換えると、
こんな感じになります。
#!/usr/bin/env bats
load bats-assertion/bats-assertion
@test "status - return 0 exit code" {
run bash -c 'exit 0'
assert_success
}
@test "output" {
run bash -c 'echo -e "abc"'
assert_equal "abc"
}
@test "lines" {
run bash -c 'echo -e "abc\ndef\nghi"'
assert_lines_equal "abc" 0
assert_lines_equal "def" 1
assert_lines_equal "ghi" 2
}assertion 系のコマンドを体系化することでテストが書きやすく、
一目見ただけで分かりやすいテストケースになって
そのままテストドキュメントにもなればなぁと思います。