WordPressのサイトヘルスステータスでPHPバージョンが指摘される

　そもそもなぜ PHP のバージョンを上げるかと言うと、WordPressのサイトヘルスステータスで下記のようにPHPのバージョンが古いことが指摘されるようになったからです。

サイトがPHPの古いバージョン（7.2.13）を実行しており、更新をおすすめします

　また、たとえここで指摘されなかったとしても、PHP7.2系は2020年11月30日でセキュリティサポートが停止されますから、アップデートしておくに越したことはありません。

bitnami でインストールされた WordPress のPHPバージョンアップは難しい

　PHPやMySQLのバージョンアップであれば、Lightsailのインスタンスのディストリビューション（ubuntu）に合わせて所定のアップデート作業を行えばよいと考えていましたが、bitnamiでインストールされた PHP は、通常の構成ではなくbitnami用のディレクトリ構成となっており、アップデートするのであれば bitnami 丸ごと最新バージョンに上げる必要がありそうでした。それはそれで面白そうではあるので検証環境で試してみたいのですが、今回は確実な方法を取ることとしました。

Lightsailの新インスタンスを立ち上げ、WordPressのバックアップを復元する

　今回実施するのは、現行のインスタンスでコンテンツとDBのバックアップを取得しておき、それを新しいLightsailのインスタンスで復元する、という方法です。bitnamiの最新バージョンインストールを試すにせよ、検証環境の立ち上げは必要となるので、それならば別インスタンスへのバックアップによる移行を検証しつつ、バージョンアップ（新しいインスタンスでは各種ツールのバージョンが更新されている）を狙っています。

現行インスタンスでWordPressのコンテンツとDBをバックアップ

　まずは現行のインスタンスにSSHログインし、コンテンツとDBをバックアップします。

　なお、MySQLのrootユーザーのパスワードは

$ cat ~/bitnami_application_password

で確認できますので、確認しておきます。こちらのパスワードを使用してMySQLサーバーへログイン後、DB名を確認してDBをバックアップします。

バックアップのためのコマンドは

$ mysqldump --single-transaction -u root -p bitnami_wordpress > ~/bitnami_wordpress.dump

です。

なお、WordPressのコンテンツ側のバックアップは

$ tar acvf wp.tar.gz /opt/bitnami/apps/wordpress/htdocs/

で可能です。作成された wp.tar.gz と bitnami_wordpress.dump は、SCPなどでローカルに保存しておきます。続いて新しいインスタンスを立ち上げます。

新しいインスタンスにSSHログインして、PHPバージョンを確認してみましょう。

PHPが7.3に更新されていることが分かります。

バックアップからWordPressを復元する

　WordPressをバックアップから復元しますが、DBユーザーとして既に存在するWordPressのデフォルトユーザーをそのまま使用するため、予めWordPressのユーザーパスワードを控えておきます。

$ cat /opt/bitnami/apps/wordpress/htdocs/wp-config.php | grep DB_PASSWORD

　wp.tar.gz と bitnami_wordpress.dump を任意の場所（今回はホームディレクトリ）にSCPなどで格納しておき、展開とDBリストアを行います。

$ cd /
$ sudo tar ~/xvf wp.tar.gz
$ mysql -u root -p bitnami_wordpress < ~/bitnami_wordpress.dump

　上記コマンドでwp-config.php が上書きされてしまっていますので、控えておいたDBユーザーのパスワードを再度記載しておきます。

$ vim /opt/bitnami/apps/wordpress/htdocs/wp-config.php

　ここまで実行すれば、新しいインスタンス上でWordPressが動作するはずです。あとはDNSのAレコードなどを書き換えて、新インスタンスとドメインを紐づければ移行が完了します。なお、Aレコード変更前に直接新インスタンスのIPを指定するなどしてアクセスすると、Jetpackがセーフモードで実行されてしまいますが、これは別ドメインでJetpackが実行されているためで、Aレコードの書き換えが反映され、移行前のURLで新インスタンスへアクセスすれば解消されます。

　また、コンテンツかDBどちらかのバックアップ、復元が失敗するなどしてDBとWordPressが不整合となっていると、下記のような画像が表示されることがあるので注意してください。この場合は、復元手順にミスがないか確認し、ミスが無いのであればバックアップの作成からやり直すのが良いです。

まとめ

　いかがでしたでしょうか？このほか、bitnamiのロゴを消したり、証明書を旧インスタンスからコピーしたり、証明書更新用のLet’s Encrypt用cronタブを再設定したりと、面倒なこともありますので、次回はスナップショットからの検証環境立ち上げと、bitnamiの最新バージョンインストールによるバージョンアップが可能か、を検証していきたいと思います。

作業はWebターミナルで行う

　今回は簡単に進めるため、LightsailのダッシュボードからWebターミナルを起動します。オレンジ色の「>_」と表示されているボタンをクリックすればWebのターミナルが起動します。

　Webターミナルが起動しました。

　それでは証明書を更新していきましょう。Let’s Encrypt のインストールディレクトリに移動した後に、こちらのコマンドを実行すれば証明書の更新が確認できます。

$ sudo certbot-auto renew

　証明書が更新され、次回の有効期限は 2020/07/30 であることがわかります。（画像は更新後に再度実行したため、実際の更新ログが表示されていません）また、「./certbot-auto has insecure permissions!」という警告メッセージが表示されていますので続いてこれを解消していきます。

certbot-auto has insecure permissions を解消する

　「./certbot-auto has insecure permissions!」については、こちらの記事に解消方法が載っています
https://community.letsencrypt.org/t/certbot-auto-deployment-best-practices/91979/

1. 一般ユーザーに書き込み権限がないディレクトリに certbot-auto を配置すること（例えば /usr/local/bin など）
2. 所有者を root ユーザーにすること
3. パーミッションを 0755 （所有者のみが書き込み可能）に設定すること

まとめると、下記の一連のコマンドで解消できそうです。

$ sudo chown root:root certbot-auto
$ sudo chmod 755 certbot-auto
$ mv certbot-auto /usr/local/bin

上記を実施した結果、エラーが解消されました。

dry-run について

　なお、certbot-auto renew には –-dry-run のオプションが設定可能です。サーバーの設定を変更した後、事前にcertbot-auto renewで正しく証明書が取得、更新されるか確認したい場合は –-dry-run のオプション付きで実行しましょう。

　実際に–dry-runオプション付きで実行したところ、「Congratulations, all renewals succeeded. The following certs have been renewed:」と出力されているので、証明書の更新処理には成功することがわかります。

　さらに「DRY RUN: simulating」や「(The test certificates above have not been saved.)」という出力から、実際には証明書更新が行われないことがわかります。

　ここまでが、Lightsail上でLet’s Encryptの証明書を更新した際の作業記録でした。もちろん、Lightsail や WordPress に限定した話ではないので、他のVPSなどでも同様の手順で更新できると思います。次回は機会があれば、cron（クロン）による証明書の自動更新設定を解説します。

• 日本語化されている
• 有料会員、無料会員を作成することができる
• ログインページやプロフィールページを固定ページで用意できる

などです。早速インストールから見ていきましょう。

Simple Membership プラグインのインストール

　プラグインのインストールに関しては特に難しいことはなく、WordPressの管理画面より「プラグイン＞新規追加」を選択後、プラグイン名を入れてインストール、有効化を行ってください。

設定について公式サイトの
Basic setup and configuration documentation (Read This First) を読んでみると、まず会員レベルの作成を行う必要があるようです。
https://simple-membership-plugin.com/simple-membership-plugin-basic-setup-documentation/

無料会員の作成

左サイドメニューから「会員レベル」「レベルの追加」の順に選択し、会員レベル名に「無料会員」と入力した後「新規メンバーシップレベルの追加」をクリックして、無料会員を作成します。

　無料会員が作成されました。

　この状態でサイトにアクセスすると、ログインや登録といったアイテムがヘッダーメニューに追加されているので、まずは登録を行います。

　こちらが登録ページです。

　上記は固定ページの「登録」です。他にもパスワードリセットやメンバーログイン用のページが固定ページで作成されています。

　ユーザーを登録後、ログインしてみます。

　プロフィールが編集、確認可能となりました。

　ログイン状態で、ダッシュボードを表示しようとするとメッセージが出て表示できないようになっています。（設定でダッシュボードの表示を禁止した場合）

　また、ページ編集時に会員レベルごとに表示する、しないを設定できるようになります（閲覧権限を設定）。

　閲覧が許可されていないレベルのメンバーがコンテンツを表示しようとするとこのようなメッセージが表示されます。

Simple MembershipプラグインのDBへの影響を調査する

SimpleMembership プラグインをインストールすると、下記のようにDBに

• wp_swpm_members_tbl
• wp_swpm_membership_meta_tbl
• wp_swpm_membership_tbl
• wp_swpm_payments_tbl

が追加されます。

これらの具体的な挙動や、プラグインの拡張、カスタマイズについて引き続き調査を進めていきます。

きっかけはプラグインのエラー表示から

　早速 Theme My Login プラグインを有効化し、登録ページを表示してみると「現在、ユーザー登録はできません」というメッセージが表示されまして。
原因を調査すると、WordPress のダッシュボードの『設定 ＞ 一般』から『メンバーシップ』の『だれでもユーザー登録ができるようにする』をチェックする必要があるようです。このチェックボックスのオンオフが内部的にどのような挙動をするのか興味があって調べてみました。

users_can_register とは？

　まず、この設定画面のソースコードである options-general.php を確認すると
get_option( ‘users_can_register’ ) した値を表示していることがわかりました。get_option は WordPress Codex によれば options テーブルからの値の取得です。
https://wpdocs.osdn.jp/関数リファレンス/get_option

　つまりこのチェックボックスは users_can_register というキーでDBにデータを書き込みそれをもとに処理や表示を切り替えるためのフラグだとわかります。

users_can_register から会員登録（ユーザー登録）まで処理を追う

　では実際に users_can_register を利用して処理や表示を切り替えている箇所を調べてみます。該当箇所は何か所かあるのですが、最も該当数が多いのは wp-login.php でした。どうやら users_can_register が有効の状態ではログイン画面に登録用のリンクが表示され、それをクリックするとユーザー登録用のページ wp-login.php?action=register へと遷移するようになっているようです。

register アクションの調査

　register action については wp-login.php 内に
switch ( $action ) で処理を分岐させている箇所があり、その switch 節の中の case ラベルとして
confirm_admin_email
lostpassword
など様々なアクションごとの処理が定義されています。

アクションごとの処理はさらにGETの場合（テンプレートの表示処理）と、POSTの場合（『登録』などのフォームボタンクリック時の処理）に分かれており、if ( $http_post ) から始まる if 節の中身が POST の場合の処理です。

　POST の場合の処理を確認すると、register_new_user というメソッドがWordPress標準の会員登録処理の実処理であることがわかります。

register_new_user の処理から、会員情報（ユーザー情報）の登録処理と管理しているDBを調べる

　register_new_user については残念ながら日本語サイトで解説はないのですが（2020/05/06 現在）下記WordPressの開発者向けサイトから概要や、ソースコードそのものの確認が可能です。
https://developer.wordpress.org/reference/functions/register_new_user/
ソースコードを読む限りでは、パスワードを自動生成し、DBへのユーザーの登録処理は wp_create_user に任せているようです。

　wp_create_user も user_login, user_email, user_pass で compact した Array を生成して wp_insert_user に処理を任せています。

wp_insert_user まで読み進むと、ようやく $wpdb->users に対して $wpdb->update または $wpdb->insert していることがわかります。
　つまり、 WordPress 標準機能で追加されたユーザーは users テーブルに挿入されます。なお、ここで気になるのがユーザー生成時のロールですが、wp_insert_user 呼び出し時の引数オブジェクトに role というプロパティが設定されていればそれが設定されますし、設定されていなければデフォルトのロールが用いられます。

　ただしロールについては users テーブルには格納されていません。というのも users テーブルに格納されているのは認証に必要な情報のみで、それ以外のデータはすべて usermeta テーブルに格納されているからです。
　usermeta テーブルには meta_key = wp_capabilities のレコードがあり、meta_value にシリアライズされた ロール情報が格納されています。
ここまでで、WordPress のデフォルト機能がユーザー情報をどのように格納しているかがわかりました。

実際のプラグインではどのようにユーザー情報を登録しているか？

　それでは、その他のプラグインではどのようにユーザー情報を登録、管理しているのでしょうか？あるプラグインを例にとって調べてみると、まず wp-login.php をそのまま使用するのではなく、add_action によるフックを行い、ログインページや登録ページを別に用意しているようです。また、ユーザーの登録には wp_create_user を利用していました。

　この場合、ユーザー情報自体はusersテーブルに登録されてしまいますから、
wp-login.php からログインできてしまいます。その結果、プロフィールの編集はともかくとして、ダッシュボードも閲覧できてしまいます。

　調べてみると、このプラグインでは Profiles など各種機能は有償の別エクステンションとなっているようでした。そのため、有償エクステンションなしではそれほど凝った管理方法になっていない可能性があります。次回は Simple Membership など、プロフィール登録機能がついているといわれているプラグインなどを参考 WordPressプラグインによる会員サイト構築のやりかたについて考察を進めていきます。