WordPress 本体のアップデートプロセスチャート

WordPress 本体のアップデートプロセスチャートを作ってみました。

WordPress 3.7 から実装された自動更新で WordPress がアップデートされると、WordPress 本体が自動でアップデートできます。

自動更新は、いくつかのアップデート方式 (マイナーバージョンだけ、メジャーバージョン・マイナーバージョン両方) があり、それぞれが WordPress 本体がどのようにアップデートするか図解してみました。

加えて、開発したプラグイン「WP Auto Updater」で実装したアップデート方式

  • Minor Only Version Update
  • Previous Generation Version Update

を追加してみました。

安定的な WordPress サイトの運用に参考にどうぞ。

WordPress Update Process Chart
WordPress Update Process Chart

参考

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

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 が縁の下の力持ちとして 少しでも力になれば幸いです。

リソース

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

今後やることをメモ。

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

WordPress運用保守チェックリスト

WordPressでウェブサイトやブログを立ち上げるのは、手軽でツールとして便利な一方。
運用しつづけるには、メンテナンスをする手間やセキュリティ上のリスクを自分で対応する必要があります。

保守管理レベルで対応できる範囲はそれぞれですが。
個人でWordPressサイトを運営する方から、ビジネスでWordPressを使ってウェブサイトを開設している方、ウェブ制作会社などクライアントのウェブサイトをサポートしている方に参考になるようできるだけ幅広い視点から「WordPress運用保守チェックリスト」を作成してみました。

WordPress運用保守の底上げに繋がれば幸いです。

WordPress運用保守チェックリスト (2019.06.26更新)

WordPress保守・保全

  • WordPress本体・テーマ・プラグインがアップデートできる環境になっている
  • 自動アップデートが機能している環境になっている
  • WordPress本体はこまめにアップデートしている
    1. 手動
    2. 自動
  • テーマ・プラグイン・翻訳はこまめにアップデートしている
    1. 手動
    2. 自動
  • データのバックアップを定期的にしている (ファイルとデータベース両方)
    1. 手動
    2. 自動
  • バックアップデータの格納先
    1. サイトと同一サーバー上
    2. 別のサーバー・ストレージサービスなど遠隔スペース
  • バックアップ先は、セキュリティを施してアクセスは制限されている
  • データベースの肥大化を防いでいる
    • 投稿履歴の件数を制限している
    • データベースの​​最適化を定期的に行っている
  • リストアなど復旧作業のシミュレーションを検証環境上で行っている

WordPressセキュリティ

アプリケーションレイヤー

  • テーマ・プラグインは出所 (開発元) を確認して適切に管理している
    • 公式ディレクトリ掲載 (審査レビューチェック済み)
    • 有料テーマ・プラグイン
    • 野良テーマ・プラグイン (配布先ダウンロードが特定サイトのみ、GitHubなどレポジトリのみ)
  • 使っていないテーマ・プラグインは削除している
  • セキュリティ系のプラグインを少なくとも一つは導入している
    • ログイン試行防御 (総当たり攻撃・ブルートフォースアタック、パスワードリスト攻撃)
    • DDoS 攻撃防御
    • メールフォームスパム対策
    • セキュリティ監視
  • wp-config.php の salt を wordpress.org salt generator で生成して設定している
  • wp-config.php をアクセスできないルートディレクトリ外に配置している
  • ファイル編集機能を停止している

ミドルウエアレイヤー

  • ファイルパーミッションを適切に設定している
  • PHPの実行を拒否、ファイルアクセス拒否制御を行っている
    • wp-config.php
    • /wp-admin/includes/
    • /wp-includes
    • /wp-includes/js/tinymce/langs/
    • /wp-includes/theme-compat/
    • /wp-content/themes/
    • /wp-content/plugins/
    • /wp-content/uploads/
  • 管理画面ログイン・アクセスを強化している
    • 2段階認証・2ファクタ認証を導入している
    • CAPTCHAを導入している
    • Basic認証を導入している
    • 管理画面のアクセスをIPアドレスホワイトリストで限定している
  • サイトへの特定のアクセスをIPアドレスブラックリストで制限している
  • 国外IPアドレスフィルタを有効にしている
  • WAFを導入している、またはWAF機能を有効にしている
  • マルウェア混入チェックを定期的に行っている
  • 脆弱性診断を定期的に行っている

ヒューマンファクター

  • ユーザ名 admin は削除している、または存在していない
  • ユーザ名 admin のログインを禁止している
  • ユーザーのパスワードを適切に設定している
    • 8文字以上
    • 小文字・大文字・数字が最低1つずつ含まれている
    • できれば記号も含める
    • パスワード自動生成なら尚よし
  • 複数のユーザアカウントには、適切な権限を付与している
  • 使われていないユーザアカウントは定期的に削除している
  • セキュリティ系のプラグインでログインアクセスを履歴記録している

サーバ・システムインフラ基盤

  • サーバーの保守管理担当者がいる
  • レンタルサーバーまたはVPS・クラウドサーバーで運用している
  • 独自ドメインで運用している
  • SSL/TLS (サーバ証明書) を導入して暗号化通信している
    1. http と https 両方でサーバー接続している
    2. 常時SSL (https のみ限定サーバー接続、http はリダイレクト処理)
    3. 常時SSL (https のみ限定サーバー接続、http は80番ポート閉鎖)
  • サーバー・データベースやPHPなどミドルウエアを定期的にアップデートしている
  • 定期的にサービスプランを変更してサーバーを刷新している、またはサーバ・システム基盤をリプレイスしている
  • システムパフォーマンスを定期的に計測している、またはモニタリングしている

運用体制・障害対応

  • WordPressの保守担当者がいる
  • 死活監視を導入している
    1. 人的監視
    2. リモート自動監視
  • アラート通知など障害発生にすぐに気づく体制がある
  • 24時間以内に一次対応 (応急処置) で障害の復旧ができる
  • 障害の原因調査ができる体制がある
  • WordPressサイトの再現検証、テスト環境がある
  • 再発防止策の実施など根本的な解決を行える体制がある
  • 障害報告・対応作業報告・作業予定など情報を共有している
  • 運用保守体制を定期的にチェックして改善している

参考

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

仕事柄「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」をリリースしました

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

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

WordPressは、2013年10月にリリースされたバージョン 3.7 から自動更新 (Automatic Background Updates) ができるようになっています。
デフォルトで有効になっている自動更新の対象は、マイナーバージョン。バージョンナンバー x.y.z の数字 z の部分が対象。おもにセキュリティ関連の問題の修正やメジャーバージョンがリリースされた以降に発見されたバグを修正しています。
自動更新が機能していれば、1日に2回自動更新のチェックが入ります。マイナーバージョンがリリースされると、自動でマイナーアップデートが適用されて常に安全な形でWordPressサイトを運営できます。

メジャーバージョンにも自動更新ができますが、デフォルトでは、無効になっています。
WordPressは、開発を続けて常に最新版としてメジャーバージョンがリリースされます。
メジャーアップデートは、新しい機能の追加やファイル構成の変更、抜本的なコードの変更など設計見直しが反映されます。

ソフトウエアの本質から観てみると、そこにはどんなソフトウエアにも不具合というバグは入り込む余地があります。
ソフトウエアの本質としてバグはつきもの。それは避けて通れないもの。

加えてメジャーバージョン特性として、バグの発見が困難な状況に陥ることがあります。
いくらベータ段階で検証しても見つからない。ユースケースの粒度、検証の範囲や頻度が少なく捉えきれない。
リリース前に見つけられず、それが初期不具合として現れるのが、メジャーバージョンでもあります。

これは、ソフトウエアだけでなく、一般的な製品でも新製品として販売された直前に製造された初期ロットでは、初期不良という形で不具合が多く出ることと似ています。自動車や家電製品の分野ではリコールという形で知ることも多いのではないでしょうか。

メジャーバージョンには、「予測ができない」という不確実性の高い、真空状態が生じる期間が必ず生まれます。その真空状態を事前に少なくすることが試作品、テスト、ベータリリースなど。事後では真空状態から空気を入れて不確実性を無くしていくことがリコールだったり、マイナーバージョンのリリースです。

WordPressも常に最新版に更新すれば安全ということを考え直す時期に来ているといえるかもしれません。

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」をインストールして有効化すると、管理画面が用意してあります。

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 を活用する人を幸せする運営はあるのだろうか」に少しでも応えられたら幸いです。

最近の投稿

カテゴリー

アーカイブ