作ったよ – ページ 2 – シングスブログ

ブロックエディタにフル対応したWordPressテーマを作ってみた所感

公開日: 2019年11月26日 18:03 更新日: 2020年4月28日 21:09 投稿者: thingsym

ブロックエディタにフル対応したビジネス向けウェブサイト用のWordPressテーマ「Foresight」をつくりました

もともと去年2018年11月頃から、WordPressのブロックエディタ (Gutenberg) に対応した WordPressテーマ開発に取り組み始めましたが。いつの間にか方針転換をして WordPressスターターテーマ「WP Theme Boilerplate」を開発していました。テーマ開発は先延ばしになってしまいました。

今回ようやくWordPressテーマ「Foresight (フォーサイト)」がお披露目できてホッとしているところです。

タイミンク的に、ブロックエディタが WordPressに実装されてほぼ1年が経った頃で、その間ブロックエディタにも色々使いやすく改良が加えられて充実しつつあり、良かったんじゃないかと思います。

WordPressテーマ「Foresight」の特徴

WordPressテーマ「Foresight (フォーサイト)」の特徴は、

ビジネス向けウェブサイトまたはランディングページなど1ページもののウェブページが作れるように
新しいエディタであるブロックエディタをフルに活用できるように

設計したテーマです。

ビジネス向けはもちろん、ランディングページはじめ、ブランディングやマーケティングで活用することを考慮して、デフォルトレイアウトに幅広なレイアウトを採用して作ってみました。ブログ・メディア向けテーマにするとサイドバーが必須になることが大半でブロックエディタの全幅・幅広なレイアウトが活かせないところもあったり。といっても必要な方にはオプション設定やテンプレートの選択でできるように作っています。

WordPressテーマ「Foresight」の公式ディレクトリへの登録は、これから登録申請する予定です。ので管理画面経由からのインストールはまだできません。しばしお待ちを。早々に試したい方は GitHub からダウンロードできますので、是非試してみてください。

ブロックエディタにフル対応したWordPressテーマを作ってみた所感

テーマのコンセプト的なことは、とりあえずテーマのプロダクトページを用意しましたので、そちらに譲ります。またテーマの技術的なことは、GitHub のレポジトリをご覧ください。この記事では、ブロックエディタにフル対応したWordPressテーマを作ってみたときに感じたことを綴ってみたいと思います。

なぜ作ったの?

4つあります。

まずは、テーマを作るのに先立って WordPressテーマスターターキット「WP Theme Boilerplate」を作ったので、これをベースに公式ディレクトリに登録されるテーマとして実績を作ることを目指しました。

2つ目がブロックエディタにフル対応したテーマを設計するというテーマ開発の動機ができた。

WordPressの関わりは、テーマ開発がはじまりで (オープンソースで公開しているのはプラグインだけで。いくつかリリースして使われているのでプラグインの人かと思われている感がありそうですが)。当時テーマを作って公式ディレクトリに登録しようと思ったが、気合を入れすぎて機能を作ったけど、プラグインテリトリなど全く知らないこともあり、登録を断念したまま時が過ぎていきました。一時テーマ販売もしたこともありますが、どちらかというとマーケティングやメディア運営が軸に活動しているところもあり、テーマ開発は、作ったテーマの改良を続けているだけでした。新たにテーマを開発する動機がありませんでしたが。

去年末に WordPress 5.0 からブロックエディタが導入されました。開発したテーマは前エディタであるクラシックエディタに対応したものがほとんどで。今回ブロックエディタに対応したWordPressテーマを作ろうという動機が少しずつ出てきたので、手を動かし始めました。ベースにある感覚は、Gutenbergを開発段階から触っていて、完成度が高まるとコンテンツ作りに集中できるなぁという感覚でした。

ツイッターでもちょこっと所感をツイートしていた。

WordPressのブロック型エディタGutenberg、楽しみだけどなぁ。HTMLを意識しなくなって純粋にコンテンツ作りやコミュニケーションに向き合えるようになる。 / WordPressの次期エディタ「Gutenberg」、賛否両論 | スラドオープンソース https://t.co/XsLnSJ0h2z
— 水野陽介 (Yosuke Mizuno) (@thingsym) August 18, 2018

3つ目がブロックエディタへ移行してなにかか生まれる契機になりそう、特にビジネス面で。

ウェブサイト運営の現場も変わりつつありそうなのも動機の一つになりました。

公式ディレクトリを見てみると、ブロックエディタに対応したテーマがまだまだ少ないのが現状です。今はまだブロックエディタへの移行期の途中ですね。無料有料のWordPressテーマもクラシックエディタの部分を引きずっているところがあります。(現実的には継続してアップデートを繰り返してもブロックエディタへの移行も難しいですから。特に機能部分の移行や破棄はやりづらいですね。テーマ開発者にとって辛いことですが。コツコツ頑張りましょう。ボクも以前作ったテーマで苦労している最中です〜。)

実際のウェブサイト運営の現場でも今までの業務の仕方で特に支障がないためブロックエディタに変える必要性があまり見いだせないところでしょう。クラシックエディタから使い込んでいるWordPressサイトでは、ブロックエディタへの移行もなかなか進んでいかないのも現状かと思います。

テーマの設計面やウェブサイト運営の現場など広く見渡しても一筋縄でいかず、解決策を探るべく模索がまだまだ続いていくかと思います。

その中で、特にビジネス面でなにかか生まれてくることに期待しています。その期待を見据えつつ、ビジネス向けWordPressテーマとして作ってみたところがあります。

4つ目がウェブサイト設計の知見を一層深めること。

ブロックエディタになったWordPressで、いままでのウェブページの作り方がガラリと変わります。

以前のクラシックエディタは、HTMLベースのテキスト入力 (テキストモード) あるいは見出しや太字などテキストの装飾をメインにしたビジュアル編集 (ビジュアルモード) でした。

これがブロックエディタになると、見出しや太字などテキストの装飾はもちろん、コンテンツ部分の構成やレイアウトもブロックを積み重ねるようにして作ることができます。HTMLやスタイルシートを扱わなければできなかったことが、HTMLを直接扱うことなく (ブロックエディタがその部分をうまく吸収してほとんど表に出ることなく、求められる技術スキルのハードルが下がり)、文章の作成や編集修正、レイアウト作りが誰でもできる形でウェブページが作れる。つまり、コンテンツ作りに集中できる環境がブロックエディタで実現しています。

ウェブサイトを運営する方にとっては、ホームページの開設や日々の運営していくコンテンツ作成の敷居が下がる分、ビジネスチャンスを掴みやすい環境になります。コンテンツの部分でもビジネスに発展していく機会が増えていってほしいですね。

これからのWordPressテーマ設計を考えてみる

反面、テーマ開発者はじめ、ホームページ制作やウェブサイト構築に携わっている方にとってウェブサイト構築やウェブデザインのあり方まで変わる可能性を秘めているところです。面白いところでもありますが、設計と実装面で相当の技術レベルが要求されつつあります。ウェブサイトを運営する方にとってハードルが下がるということは、設計実装面ではハードルが上がることを意味します。そこについていくことがなかなかつらい現状ですが...。

WordPressのテーマ設計面を診てみると、
ブロックエディタの導入による大きな変更は、テーマの機能として実装していた部分

ウェブサイト機能 (ウェブサイト全体設計の部分)
コンテンツ機能 (本来はプラグインテリトリに該当するかなぁ)

として機能を作り込んできたかと思います。

レイアウト機能やコンテンツを構成するコンポーネント、ウィジェット、ショートコード、ビジュアルエディタの機能拡張などを独自の設定画面を作ったり、カスタマイザに設定パネルを用意してWordPress管理画面に使いやすく実装してきました。

これからは4つのレイヤーで設計を考える

いままでWordPressのテーマ設計を考える場合、3つのレイヤーで考えるところが (テリトリにもつながるところですね)

WordPress本体の機能 (標準機能)
WordPressテーマの機能 (ウェブサイト機能とコンテンツ機能)
WordPressプラグインの機能 (付加機能)

そこにブロックエディタが加わり、テーマの機能にあったコンテンツ機能に当たる部分がブロックエディタに移ることになると思います。以下のように。(コンテンツテリトリみたいになっていくのかなぁ)

WordPress本体の機能 (標準機能)
WordPressテーマの機能 (ウェブサイト機能)
WordPressプラグインの機能 (付加機能)
ブロックエディタの機能 (コンテンツ機能)

つまり、テーマあるいはプラグインのどちらに実装すればいいのか今まで曖昧で、はっきりしなかったコンテンツ機能の実装が、ブロックエディタの導入で明確になったことが大きいなぁと感じます。

ということで、いままでカスタマイザにあったコンテンツ機能がブロックエディタに移っていくように設計されることになるかと思います。プラグインもコンテンツ機能を担っていたものの一部はブロックエディタ (またはカスタムブロックとして) に移りそう。特にウィジェット系はブロックエディタに統合される将来があるのかなぁとも思いますね。全体的にもブロックエディタ上に統合する形の方向にもなりそう。

またWordPressテーマ不要論もチラホラ見受けられます。が、WordPressテーマはウェブサイト全体設計として残ります。そのテーマで出来上がるウェブサイトを規定する上位の設計思想 (コンセプトの部分にあたるところ) として。WordPressテーマ「Foresight」もそんな感じで作ってみました。

WordPressは、全体を見るとなにか複雑になっているように見えますが。
設計面をこうして見ると、うまく分かれてWordPressが進化しているのが理解できますね。

ということを考えることが楽しい今日この頃です。

次世代 WordPress テーマスターターキット「WP Theme Boilerplate」をリリースしました

公開日: 2019年5月20日 15:48 更新日: 2019年11月23日 22:22 投稿者: thingsym

WordPressスターターテーマ「WP Theme Boilerplate」を開発しました。

去年2018年11月頃。WordPress 5.0 から新しいブロックエディタ (Gutenberg) が出ることだし、それにフィットする WordPressテーマを作りたいなぁと。公式に掲載してみたいなぁと。
もともと定番スターターテーマである「_s (Underscores)」をベースにテーマを作っていましたが。
気づいたらいつのまにか方針転換をしちゃって、テーマ作りより独自のオリジナルテーマがスムーズに作れる環境を作ったほうが広がりがあって面白いなぁと思い、取り組んでみました。

WordPressテーマスターターキット「WP Theme Boilerplate」 8 つの特徴

特徴は 8 つほど。

テンプレート階層とディレクトリレイアウトを改善
WordPress Theme Autoloader を実装
テーマの機能をクラスベースで実装
Theme hooks を実装
Block Editorに最適化した WordPressテーマを目指して Block Editor (Gutenberg) をサポート
Theme Starter script で独自テーマのスターターテーマを生成
npm scripts でテーマ開発環境を整備
composer scripts でテーマテスト環境を整備

スターターキットとしてテーマ開発環境を整備

フロントエンド開発環境
WordPressテーマ開発環境
テスト環境 (ユニットテストや静的コード解析、CI/CDまで)

この辺がサクッと整備されたらいいなぁと。

ただ効率的にテーマがつくれることだけを追求してもだめで。(単にテーマを作れるだけでは価値はだんだんなくなってくる)
一番価値が生まれるところである、デザインやコンテンツにきちっと時間を割きたい。
ビジネスにスピードと柔軟性が求められている中でプロトタイプ的な、アジャイル的なアプローチで開発ができるようにしたい。
常に改善されるテーマになるよう機動性を手に入れたい。
新しい価値を生み出す今の開発環境にマッチできるような設計思想をいくつか組み入れてみました。

結果、ただテンプレートが揃っただけのスターターテーマではなく、開発環境やテスト環境など周辺環境を整えた「スターターキット」にしてみました。

テーマ設計で感じたこと

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 に引っ掛けることでメインテンプレートには手を入れずに追加要素を差し込んだり、フックした関数 (アクション) 側で複雑なロジックを組み入れることを目指してみたい。

あなただけのオリジナルWordPressテーマをつくろう

独自テーマが作れるように Theme Starter script を用意してみました。
テーマ名を引数に Theme Starter script を走らせるだけでオリジナルテーマの雛形がすぐに生成されます。
そこからあなただけのオリジナルWordPressテーマをつくっていける開発環境ができあがる。
WordPressテーマを作れる環境はすでに目の前にあります。
WordPressテーマ作りを楽しく過ごしてみてね。

素敵な、便利な、魅力的な WordPressテーマがたくさん生まれたり、
面白い、読み応えのあるコンテンツがある WordPressサイトがいっぱい出来上がったり、
テーマ開発やWordPress構築プロジェクトを成功に導いたりと。
WP Theme Boilerplate が縁の下の力持ちとして
少しでも力になれば幸いです。

リソース

Next Generation WordPress Theme Starter Kit「WP Theme Boilerplate」GitHub Repository

今後すること・したいこと

今後やることをメモ。

テストを書く
ドキュメントをつくる
WP Theme Boilerplate をベースに公式テーマを (やっと) つくる

BashテストフレームワークBatsのヘルパースクリプト「Bats Assertion」をつくりました

公開日: 2018年4月11日 16:57 更新日: 2019年11月27日 13:52 投稿者: thingsym

Bash のシェルスクリプトは、エンジニアが片手間に書いて使う DIY 的な使い捨てスクリプトになりがちぎみだけれども。
Bash のシェルスクリプトを作ってオープンソースとして公開している手前、
「きちっとテストを入れたいなぁ」と思っていろいろ Bash のテストどうやるの? というところから始まって
どんなアプローチがあるのだろうといろいろ調べたり試したり。
結果、Bashテストフレームワークとして「Bats」がシンプルすぎるぐらいに良かったので採用してみました。

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 Assertion」

今回、その Bats のヘルパースクリプト「Bats Assertion」をつくりました。

Assertion 系のヘルパースクリプトは、ほかにもありましたが、
テストを書くこと自体がテストドキュメントになる。
もっとシンプルに書けて、テストを書くことが億劫にならず、
テストを育てていく感じにならないかなぁと思って設計してみました。

使い方は、ヘルパースクリプト「Bats Assertion」をダウンロードして
テストファイル内で Bats の load コマンドで読み込むだけ。

load bats-assertion/bats-assertion

読み込むと、以下の assertion 系のコマンドが使えるようになります。

assert_success
assert_failure
assert_status
assert_equal
assert_fail_equal
assert_match
assert_fail_match
assert_lines_equal
assert_fail_lines_equal
assert_lines_match
assert_fail_lines_match

それぞれのコマンドの詳細は Assertion Reference を参照してみてください。

ヘルパースクリプト「Bats Assertion」で書き換えると

先の 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 系のコマンドを体系化することでテストが書きやすく、
一目見ただけで分かりやすいテストケースになって
そのままテストドキュメントにもなればなぁと思います。

ドキュメント

リソース

Bats: Bash Automated Testing System - 本家
BATS-core: Bash Automated Testing System (2017) - メンテナンスフォーク
bats-assert
basher-assertions

WordPressバックアップスクリプト「WP Offsite Backup」をリリースしました

公開日: 2018年1月12日 15:02 更新日: 2019年11月27日 14:32 投稿者: thingsym

仕事柄「WordPress (ワードプレス) 保守管理サービス – シングスマネジメント」でバックアップ体制をつくったり。
プラグインでバックアップを試してみたり。
そうこうしているうちに WordPress サイトをバックアップするスクリプトをつくっていました。

WordPressバックアップスクリプト「WP Offsite Backup」は、WordPressのファイルやデータベースのデータを Amazon S3 など外部ストレージに遠隔バックアップするスクリプトです。

WP Offsite Backup - GitHub

使い方は簡単

あらかじめデフォルトの設定をして

bash wp-offsite-backup

とコマンドを走らせるだけ。手動でバックアップします。

また、自動で走らせるには、Cron でスケジュールを設定するだけ。

MAILTO=hoge@example.com

20 0 * * * bash /path/to/wp-offsite-backup/wp-offsite-backup

とすると、毎日0時20分にバックアップします。

WordPressバックアップスクリプト「WP Offsite Backup」の特長

ワードプレスのファイルとデータベースをバックアップ
ストレージサービスにバックアップファイルを保存 (今のところ Amazon S3 だけに対応)
Cron で自動バックアップ
設定のカスタマイズでいろいろなバックアップができます
バックアップファイルのローテーション
ログ履歴の管理

サポートしているストレージサービスは、いまのところ Amazon S3 だけですが、
おいおい Google Cloud Storage や Microsoft Azure Storage などにも対応してみたいと思います。

基本設計は、依存関係の解決やメンテナンスを極力減らすため、
WordPress のプラグイン、WP-CLI などコマンドラインツールに依存せず、
Linux コマンドとストレージサービスのコマンドラインツールだけで済ませるようにしました。
またデータをローカルサーバに残さないようにセキュリティに配慮してみました。

使い方もデフォルトの設定をしたら、コマンドを走らせるだけでバックアップができるを目指してみました。

WordPressバックアップスクリプト「WP Offsite Backup」を導入するには、
いまのところ AWS Command Line Interface などストレージサービスのコマンドラインツールをインストールする必要があるので、
root 権限を持っている VPS やクラウドサーバーに導入に限られてしまいますが、
レンタルサーバーでも動かないかなぁと模索中です。

設定のカスタマイズでバックアップいろいろ

インストールや設定の仕方は、ドキュメントの「Getting Started」を参考にどうぞ。

もちろんバックアップのカスタマイズもできます。

カスタマイズした設定に名前を付けるだけ。

設定も保存して複数持てるので、
WordPressファイルをフィルタリングしたり、
データベースだけバックアップということも。
一つのサーバに複数の WordPress サイトがあっても、
それぞれのウェブサイト用に設定を切り替えてバックアップできます。

その場合のコマンドは、カスタマイズした設定を渡すだけ。

bash wp-offsite-backup customized-config

Cron で自動バックアップも
環境変数 WP_OFFSITE_BACKUP_CONFIG にカスタマイズした設定を渡すだけ。

MAILTO=hoge@example.com

20 0 * * * WP_OFFSITE_BACKUP_CONFIG=customized-config bash /path/to/wp-offsite-backup/wp-offsite-backup

設定のサンプルもあるので参考にしてみてください。

db-only-backup-config (データベースだけバックアップ)
full-backup-config (フルバックアップ)
partial-backup-config (wp-content とデータベースだけバックアップ)
wp-content-only-backup-config (wp-content だけバックアップ)

バックアップファイルのローテーションで費用負担を減らす

ストレージサービスをバックアップに利用すると、
いつの間にかバックアップファイルがたくさんできてしまします。
気が付かないでいると、ムダな費用を払うこともあると思います。
バックアップの性格上、何かがあったときの復旧に必要な直近のバックアップファイルだけあれば、
充分済むことが大半だと思います。

ファイルの整理をするには、Amazon S3 だと、ライフサイクルで有効期限を決めて、
その有効期限が切れたならば、ファイルを削除するということを
ストレージサービス側で設定する必要があります。

これはこれで便利なのですが、
できたらファイル数で制限してファイルのローテーションをしたいと思い、実装してみました。

ストレージサービスの課金は、ディスク使用量によって決まるところが大半なので、
ファイルサイズが大容量になりやすいバックアップファイルにとってより大切なこと。

バックアップファイルのファイル数で制限することで費用をコントロールしながらバックアップシステムが構築できます。

是非WordPressバックアップスクリプト「WP Offsite Backup」を試してみてね。

ドキュメント: wp-offsite-backup - GitHub

WordPress本体をより安全に自動更新できるWordPressプラグイン「WP Auto Updater」をリリースしました

公開日: 2017年9月29日 15:20 更新日: 2019年11月25日 22:16 投稿者: thingsym

WordPressプラグイン「WP Auto Updater」の生まれた背景とかも書いてみたので、めっちゃくちゃ長い文章になっています。
なので、WordPressプラグイン「WP Auto Updater」をサクッと知りたい方は、読み飛ばしてこちらから読んでください。
全文は暇なときに読んでもらえればと思います。

2017年2月に情報公開された WordPress 4.7.0, WordPress 4.7.1の脆弱性

2016年12月6日にリリースされたバージョン 4.7 には、容易に攻撃できる脆弱性が入り込みました。

原因元は WordPress 4.7　から追加された機能 REST API。結果、外部から REST API の脆弱性を利用して WordPress のコンテンツが改ざん被害が確認されました。WordPress の新機能はまずプラグインとして開発されます。機能として完成した段階で WordPress本体に取り込まれます。その過程で脆弱性が入り込み、典型的なメジャーバージョン特性を表すように発見されたわけです。

WordPressは、常に最新版にするべきか

WordPressサイトを運営する側として対応することはあるだろうか?

基本的なスタンスとして、脆弱性を悪用されて被害にあったからアウト。会わなかったからセーフではなく、
被害に関わらず致命的な脆弱性があるコードを晒した時点でアウト。
そういう状況に置くこと自体がアウトというスタンス。
そこを考えて WordPress をアップデートしていくことが必要になってきています。

WordPressは、管理画面を経由してボタンをクリックするだけで簡単にアップデート更新できます。WordPressに詳しくなくても、スキルがなくても、何も考えなくてもできます。便利さの反面、そこに盲点が生まれます。

致命的なことが起こった後に火消し的に対応するのではなく、100%は無理でも、避けられるものは避ける。
自動更新が機能していないから被害が広がるとか聞かれますが、関係ありません。

一番大切なことは、手動、自動かかわらず普段からアップデート方針を持っていること。
その上でサイトを運営することです。

WordPressの管理画面には、メジャーアップデート、マイナーアップデートの区別なく常に最新版に促すメッセージが流れます。スマホアプリのようにバッチで通知されます。
もちろん WordPress はスマホアプリではなく、ウェブアプリです。
さらに WordPress はオープンソースで誰でも使える。
いろんな人がいろんな目的で利用し、ウェブサイトやブログを運営しています。

WordPressのセキュリティに関してのブログ記事を目にすることもあるかと思います。
そこに最新版にするとよく書かれていますが、
メジャーアップデート、マイナーアップデートのどちらを指しているかわかりません。

はたして常に最新版にすることが安全と言えるのでしょうか。

現場でやっている WordPressアップデートの基本的な考え

実際、WordPressサイトを運営したり、
クライアントのウェブサイトの運営をお手伝いしていますが、
常に最新版にしていることはありません。

マイナーアップデートは自動でまたは手動でこまめに適用していますが、
メジャーバージョンがリリースされてもすぐにはアップデートしません。
最新のメジャーバージョンで追加された新機能をつかいたいなど特段の理由がない限り、
ある程度時間をおいてから行います。
前出のメジャーバージョン特性があるからです。

また、メジャーアップデートを止めることもしません。
必ずどこかの段階でメジャーアップデートを行います。
目安としては最新のバージョンとのバージョンナンバーが大きく離れないこと。
アップデートを止めていたり、アップデートはしていてもバージョンナンバーが大きく離れると、
検証作業が別途必要になってきます。

ということで、検証作業を行う必要がない範囲で
メジャーバージョンのアップデートをする前提で
WordPressサイトを運営しています。

これもすべて普段からアップデート方針を持っているからです。

より安全なWordPressの自動更新を目指して

上記のアップデート方針を取ろうとしてもなかなかできないのも事実です。
まず手動ですることが前提になります。
いちいち管理画面でアップデート更新するしかありません。

それも一定のスケジュールをもって行う必要があります。
どこかで忘れたり、面倒くさがってアップデートを怠ります。
場合によっては、ブログを更新するときについでにアップデートする。
けどそれは、ブログを書かなくなるとアップデートが止まることを意味します。

やはりここは自動更新でと思っても。

メジャーバージョンの自動更新を有効にしても、
リリースされるとすぐに最新版の WordPress が適用されてアップデートします。
基本的な考えに沿った形になりません。

自動更新で実現するには、「どのようにして自動更新を行うのか」
「いつメジャーアップデートをするのか」という問いに答えなければなりません。

WordPressのバージョンを固定してコントロールという発想を実装

幸い WordPress のバージョンナンバリングは、セマンティックバージョニングのように体系化がきっちりなされています。
バージョンナンバリングをうまく活用すれば、WordPress本体の更新がコントロールできるのではないかと、早速ソースコードを読み進めました。
また、WordPressの裏側には API があります。この API は、インストールされた WordPress本体と現在の最新版とのバージョンの比較をしています。WordPressの最新版やマイナーバージョンがリリースされたらアップデートを通知する仕組みでもあります。

WordPressの自動更新でメジャーバージョンのアップデートを有効にすると、常に最新のバージョンにアップデートします。
これをあるときには最新のバージョンにアップデートさせない、ある条件を満たせば、メジャーアップデートさせる。バージョンナンバリングと API を組み合わせて、バージョンを固定したり、アップデートそのものをコントロールする。というところに行き着きました。

メジャーアップデートでいかに安全な方向に倒すか、フェイルセーフ 2 つの方向性「Minor Only Version Update」「Previous Generation Version Update」

それによって可能になることは、メジャーアップデートをするけれど、より安全にできること。
メジャーバージョン特性をなくせれば、メジャーアップデートもより安全になります。
メジャーバージョン特性を無くすことの基本的な原理は単純で、メジャーバージョンのリリース直前のメジャーアップデートを辞めるに尽きます。

ではいつメジャーアップデートすればいいのか。方向性は 2つあります。

一つ目は、メジャーバージョンのリリース直前のアップデートではなく、マイナーバージョンがリリースされた段階でメジャーアップデートする「Minor Only Version Update」。これはある程度メジャーバージョンが使われて、あらかた不具合も発見されている可能性は高まった段階でメジャーアップデートをおこなう。以降はマイナーアップデートをきちっと適用してくれます。

もう一つは、最新のバージョンを使わない。ひとつバージョンを遅らせて使う「Previous Generation Version Update」。
常に前バージョンを使えば、極めて安全な運営が実現できます。
最新のメジャーバージョンがリリースされると、一つ前のバージョンにメジャーアップデートする。
この場合、大体においてマイナーアップデートが入ったバージョンで行ってくれると思います。

おまけにもう一つ可能になることが出てきました。
自動更新を常に安全な方向に持って行けば、
WordPress本体の更新は、今まで手動だったのを、これからは自動で行うことを前提として運営できる。
テーマ、プラグインも最新バージョンに対応して出揃った段階で WordPress本体をアップデートできる。

また管理面の負担が減ります。
手動で WordPressの管理画面に入って更新する、またはコマンドで操作する必要がなくなりました。
最新版を使いたいときだけ、手動でメジャーアップデートする。
でも基本的な方向性は安全な方向を保ったまま。といった運営が実現します。

そして、WordPressプラグイン「WP Auto Updater」が生まれました。

長くなりましたが、ようやく本題です。

WordPressプラグイン「WP Auto Updater」は、WordPressの本体 (コア)、テーマ、プラグイン、翻訳を自動更新するプラグインです。WordPress本体のバージョンをコントロールしてより安全に自動更新ができるようになります。

主な機能は、

WordPress 本体 (コア) の自動更新
テーマ、プラグイン、翻訳の自動更新
自動更新スケジュールの設定
個々のテーマ、プラグインの自動更新を無効化する機能
自動更新の履歴を記録 (ログ)

以上を管理画面で設定できます。

まずは、

WordPressの自動更新をする前に、重要なことがあります。
それは、バックアップをきちっと取ること。
WordPressの更新はファイルの変更が伴うため、バックアップ系プラグインを導入など必ずバックアップ体制を作ってください。

WordPressプラグイン「WP Auto Updater」をインストールして有効化すると、管理画面が用意してあります。

自動更新シナリオ (Auto Update Scenario) を作る

WordPressプラグイン「WP Auto Updater」の管理画面で、
自動更新シナリオ (Auto Update Scenario) を作って WordPressの自動更新の方針を決めます。

WordPress 本体の自動アップデートは、以下の 5 つから選択できます。

マイナーバージョンをアップデート (推奨) / Minor Version Update (Recommended)
メジャーバージョンをアップデート / Major Version Update
マイナーバージョンだけをアップデート / Minor Only Version Update
一世代前のバージョンをアップデート / Previous Generation Version Update
手動でアップデート / Manual Update

マイナーバージョンをアップデート (推奨) / Minor Version Update (Recommended)

マイナーバージョンをアップデート (推奨) は、マイナーアップデートを有効化します。
マイナーアップデートは、セキュリティのための WordPress のデフォルトの機能です。
バージョンナンバーの動きから観ると、4.8 から 4.8.1, 4.8.2… とマイナーバージョンがリリースされる度に自動更新されます。メジャーバージョンである 4.9 に自動更新はしません。
WordPressプラグイン「WP Auto Updater」では、マイナーアップデートをできるだけ有効な状態を保つようにしています。

メジャーバージョンをアップデート / Major Version Update

メジャーバージョンをアップデート はメジャーアップデートを有効化します。
WordPressのデフォルトでは、無効になっています。
バージョンナンバーの動きから観ると、4.7 から 4.8, 4.9 とメジャーバージョンがリリースされる度に自動更新されます。

マイナーバージョンだけをアップデート / Minor Only Version Update

マイナーバージョンだけをアップデート は、バージョン x.y.0 のメジャーバージョンを除くメジャーアップデートとマイナーアップデートを有効化します。

この自動更新は、セキュリティの修正が入ったバージョン x.y.1 以降の WordPress がリリースされた段階でメジャーアップデートを実施します。メジャーバージョンであるバージョン x.y.0 or x.y ではメジャーアップデートをしません。
バージョンナンバーの動きから観ると、4.7.z から 4.8.z, 4.9.z とメジャーバージョンとマイナーバージョンがリリースされる度に自動更新されます。つまり 4.7.0, 4.8.0, 4.9.0 のメジャーバージョンをスキップします。

一世代前のバージョンをアップデート / Previous Generation Version Update

一世代前のバージョンをアップデート は、最新メジャーバージョンの WordPress を除くメジャーアップデートとマイナーアップデートを有効化します。

この自動更新は、WordPress 4.6.z をインストールしているとすると。最新メジャーバージョンの WordPress 4.8.0 がリリースされるときには、メジャーバージョン 4.7.z にメジャーアップデート。
常に最新バージョンの一つ前のバージョンにメジャーアップデートします。その場合、大体においてセキュリティの修正が入ったバージョンがアップデート対象になると思います。

手動でアップデート / Manual Update

メジャーアップデートとマイナーアップデートの自動更新を無効化します。
WordPressの管理画面から手動でアップデート更新します。

テーマ、プラグイン、翻訳の自動アップデートは、

自動更新 / Auto Update
手動更新 / Manual Update

が選べます。

またテーマ、プラグインは、個々に自動アップデートの無効化ができます。
ちょっと信頼できないテーマ、プラグインは一時的に自動更新を止めて様子を見たり、
検証環境で確認してから手動でアップデートの手順を取るなど
安全に更新ができる体制が作れると思います。

自動更新のスケジュールを設定

次に自動更新のスケジュールを設定します。

更新間隔は、以下から選べます。

1日2回 (12時間間隔) / Twice Daily (12 hours interval)
毎日 / Daily
毎週 / Weekly
毎月 / Monthly

デフォルトでは、自動アップデートがいつ動くか時間を指定できないですが、
WordPressプラグイン「WP Auto Updater」では、自動アップデートを動かす日時も指定できます。

訪問者の少ない深夜帯に自動更新をしたり、
都合のいい日時時間に自動更新することも可能になります。

自動更新

自動更新のスケジュール間隔で自動更新のチェックが入ります。
アップデートできる WordPressの本体 (コア)、テーマ、プラグイン、翻訳があれば、自動的にアップデートしてくれます。
アップデートしたWordPressの本体、テーマ、プラグイン、翻訳は、アップデート履歴に記録されます。

以上が WordPressプラグイン「WP Auto Updater」での自動更新の設定と自動更新が行われるまでの流れです。

WordPressを自動更新で運営してみたい方は、WordPressプラグイン「WP Auto Updater」を是非使ってみてください。
「WordPress を活用する人を幸せする運営はあるのだろうか」に少しでも応えられたら幸いです。

ブロックエディタにフル対応したビジネス向けウェブサイト用のWordPressテーマ「Foresight」をつくりました

WordPressテーマ「Foresight」の特徴

ブロックエディタにフル対応したWordPressテーマを作ってみた所感

なぜ作ったの?

これからのWordPressテーマ設計を考えてみる

これからは4つのレイヤーで設計を考える

WordPressテーマスターターキット「WP Theme Boilerplate」 8 つの特徴

スターターキットとしてテーマ開発環境を整備

テーマ設計で感じたこと

あなただけのオリジナルWordPressテーマをつくろう

リソース

今後すること・したいこと

Bashテストフレームワーク「Bats」とは

ヘルパースクリプト「Bats Assertion」

ヘルパースクリプト「Bats Assertion」で書き換えると

ドキュメント

リソース

使い方は簡単

WordPressバックアップスクリプト「WP Offsite Backup」の特長

設定のカスタマイズでバックアップいろいろ

バックアップファイルのローテーションで費用負担を減らす

最新版メジャーアップデートは安全とは言い切れない問題がはらんでいる

2017年2月に情報公開された WordPress 4.7.0, WordPress 4.7.1の脆弱性

WordPressは、常に最新版にするべきか

現場でやっている WordPressアップデートの基本的な考え

より安全なWordPressの自動更新を目指して

WordPressのバージョンを固定してコントロールという発想を実装

メジャーアップデートでいかに安全な方向に倒すか、フェイルセーフ 2 つの方向性「Minor Only Version Update」「Previous Generation Version Update」

そして、WordPressプラグイン「WP Auto Updater」が生まれました。

まずは、

自動更新シナリオ (Auto Update Scenario) を作る

マイナーバージョンをアップデート (推奨) / Minor Version Update (Recommended)

メジャーバージョンをアップデート / Major Version Update

マイナーバージョンだけをアップデート / Minor Only Version Update

一世代前のバージョンをアップデート / Previous Generation Version Update

手動でアップデート / Manual Update

自動更新のスケジュールを設定

自動更新

最近の投稿

カテゴリー

アーカイブ

検索