本サイトではアフィリエイト広告を利用しています
WordPress 致命的エラー

Cygwin PC-UNIX Windows WordPress ソフトウェア データベース 設定

[WP]プラグインの Fatal error をデータベース直アクセスで切り抜ける

2020年4月25日

WordPress 関係の小ネタです。WordPress のテーマなどをローカル環境でテストするときなど、直接データベースの中身を触ってパラメーターを書き換えたり、ちょっとしたことをさっさと済ませたいことがあります。
そんなときは、以前紹介した phpMyAdmin をインストールして直接データベースに繋げるのが定番ですが、時々出くわす細かいエラーや深刻に見える Fatal error に速攻で対処していきます。

今回のミッション

  • データベースに WordPress を通さずに(phpMyAdmin で)アクセスする
  • WordPress のユーザー名を変更する
  • Fatal error 時のWordPress のプラグインを変更する(できればエラー解消)

設定環境


CYGWIN_NT-10.0 PC 3.1.4(0.340/5/3) 2020-02-19 08:49 x86_64 Cygwin
Apache/2.4.39 (Unix) May 1 2019 19:37:31
Server version: 10.3.14-MariaDB Source distribution
PHP 7.3.7 (cli) (built: Jul 21 2019 18:10:35) ( NTS )
phpMyAdmin-5.0.2-all-languages

WordPress のデータベースにアクセスする下準備

WordPress でユーザーを登録した場合ユーザー名(ログインID)は変更できません。ただし、ユーザー表示名は自由に変えることができますので、問題ないと思う人も多いと思いますが、今問題にしたいのは「ログインID」を変更したいときはどうするかということです。
新しくユーザーを作成するというような、小馬鹿にしたような解決策は無視して、「ログインID」をデータベースを触って直接変更します。

WordPress は PHP が対応している限り、多くのデータベースを扱えますが、MySQL 系がメジャー今も昔もメジャーです。MySQL そのものはそれほど複雑なデータベースではありませんが、SQL コマンドで操ることになれていない方は、phpMyAdmin などの補助ツールを活用して GUI でアクセスすると楽です。

phpMyAdmin でクッキーエラーが出たときの対処

まず、phpMyAdmin がしっかり使える状態になっているか確認します。
phpMyAdmin セッション・クッキー・エラー
どのバージョンからか記憶にないのですが、最近のバージョンではいい加減な設定を放置していると、いざ phpMyAdmin にアクセスするときに図のようなセッション・クッキーエラーが出ることがあります。エラーメッセージでは HTTPS 接続すれば治るかもよ、みたいなメッセージが出ています。
この手のエラーの場合、HTTPS 接続に切り替えてもとすぐに直らないことが多々あります。また、HTTPS 接続はパケットをチェックしたいテスト環境としては不本意なこともありますので、ここは管理者権限を有効活用し、セキュリティを大アマにして HTTP のまま繋げる方法で進みます。

以前の当サイトの速攻インストールと同様の環境を作った人は、"/srv/www/htdocs/phpmyadmin" デイレクリ以下に "config.inc.php" というファイルがあると思います。
もし、存在していない場合は、代わりに "config.sample.inc.php" という名前のファイルがあるはずですので、これをリネームして使います。

 cygwin
$ cd /srv/www/htdocs/phpmyadmin
$ mv config.sample.inc.php config.inc.php

Windows 版のエディタで直接触りたい場合は "C:\Cygwin64\srv\www\htdocs\phpmyadmin\config.inc.php" を開きます。その場合の保存時の改行コードは LF になっていることに注意しておきましょう(CR+LFでも実際は問題なく動きますが、マナー的に LF 保存をお勧めします)。

次に、約29行目以降に

 
/* Authentication type */
$cfg['Servers'][$i]['auth_type'] = 'cookie';
/* Server parameters */
$cfg['Servers'][$i]['host'] = 'localhost';
$cfg['Servers'][$i]['compress'] = false;
$cfg['Servers'][$i]['AllowNoPassword'] = false;

という記述がありますので、認証方法をクッキー以外に切り替える設定に変えます。

 
/* Authentication type */
$cfg['Servers'][$i]['auth_type'] = 'config';
/* Server parameters */
$cfg['Servers'][$i]['host'] = 'localhost';
$cfg['Servers'][$i]['compress'] = false;
$cfg['Servers'][$i]['AllowNoPassword'] = true;
$cfg['Servers'][$i]['user'] = 'root';
$cfg['Servers'][$i]['password'] = '12345678';

図の赤字の部分を書き換え、追加すればこのファイルにアクセスできる人は誰でもデータベースにアクセスでるようになります。赤字のユーザーとパスワードは、アクセスするユーザーIDとそのデータベースのパスワードです。

この設定は開発用に便宜セキュリティを緩めているだけですので、レンタルサーバーなどでこの方法を使うのはやめましょう。
多くのレンタルサーバーでは、phpMyAdmin などはサーバー管理者が適宜、セキュリティを考慮して設定してくれていますので、自分で設定を触る必要はレアです。

とりあえず、普通にアクセスできた人も、できるようにした人もここまででミッション1は完了です。

手始めに WordPress のメアドと ID を phpMyAdmin から書き換えてみる

ルールとしては「一度設定したら WordPress のログイン ID は変更できず、メールアドレスも変更の時はそのアドレスの存在確認が必要」になっています。WordPress をテストしているときはバカな ID を設定し、メアドも適当に設定していることが普通にあるものです。これを、正常なモノにする、あるいは逆にまともなメアドをでたらめなメアドに変更することは、普通によくあるケースですので、早速実行してしきましょう。

以前の速攻セットアップで MySQL を入れたときのデータベース名 "testdb" を WordPress のデータベースとして使用しているケースで考えます。WordPress 関係のテーブルはすべて接頭語 "wp_" をつけるようデフォルトにしていましたので、これを目安に関係テーブルをチェックできます。

WordPress のユーザーテーブルを書き換える

WP ユーザーID変更
WordPress のユーザー情報は "wp_users" というテーブルに保存されています。このテーブルを直接触ることで、ユーザー名やログイン ID、メールアドレス等が存在確認等の手順を踏まず書き換えることができます。
phpMyAdmin で扱うときは、「WordPress で使うデータベース」につなげて「wp_users」テーブルにアクセスするという手順ですが、テーブルがたくさんあるとスクロールやページ送りが必要ですので、テーブルが見つからなかったからテーブルは存在しないなど早とちりせずにしっかりチェックしておきましょう。

上図のようにユーザーテーブル(マル1)にアクセスし、該当箇所(マル2)を書き換えるだけでミッション2は完了です。

WordPress の重大なエラーに対処する

WordPress 深刻エラー
WordPress で一番困るのが、ウェブサイトにはアクセスできてページも表示される。しかし、管理画面に入るといきなりエラーが出てそれっきりというケースです(上図)。
このケースでは、デバッグ機能をオンしていてもろくにエラー情報を吐かず、原因が突き止めにくいものですが、経験上「プラグイン」がエラー原因となっているケースが多いです。

つまり、プラグインをとりあえず無効にすれば動くケースが大半なので、その方法でをデータベースを直接触ることで処理します。

WordPress の wp_options テーブルから plugins を探す

WP オプション検索

WordPress の設定事項の大半は wp_options テーブルに記録されています。どのプラグインが有効になっているかを知るには、option_name カラム 'active_plugins' をチェックします。
マル1をクリック、次にマル2の「検索」タブをクリック、マル3の検索に「active_plugins」を入れ、演算子を「=」にセットして、マル4の「実行」をクリックします。

phpMyAdmin で直感的にオプション値(option_value)の変更を行うには以下のようにします。
WP オプション値

図のマル2をダブルクリックして値 'a:0:{}' を入力して確定します(データを書き換えます)。

SQL に親しみがある人は、

 cygwin
UPDATE wp_options SET option_value = 'a:0:{}'
WHERE option_name = 'active_plugins';

を実行するだけです。

書き込む値の 'a:0:{}' プラグインすべてオフという意味になります。一部のプラグインだけをオフにすることも同様にできるのですが、コロンやセミコロンの打ち方を間違えると、今度はデータベースが壊れたなどと WordPress に叱られかねませんので、注意しながら書き換えてください。

今回のような深刻なエラーの場合は、とりあえずすべてのプラグインをオフにして、順次オンにしていくのが最も容易で安全です。プラグインそのものにはエラーがなくても、サーバーのスペックが弱すぎて、思いプラグインがメモリ消費関係のエラーを引き起こしているケースも、この方法で対処できます。

wp_options テーブルの 'active_plugins' を詳しく見る

値に 'a:0:{}' を書き込んでプラグインすべてオフというのも、ネタとしては弱すぎるので、もう少し中身を見てみましょう。
'active_plugins' の中身は、

 
a:使用中のプラグイン数:{i:インディックス値;s:プラグインパス文字列長:"プラグインパス";
i:インディックス値;s:プラグインパス文字列長:"プラグインパス";}

となっています。実際には改行は含まず、長い一行で一気に記述しますので注意してください。インディックス値は0から始まる重複できない連番です。

具体例で見てみます。

 
a:4:{i:0;s:27:"addquicktag/addquicktag.php";
i:1;s:33:"classic-editor/classic-editor.php";
i:2;s:25:"jet-engine/jet-engine.php";
i:3;s:24:"wpforms-lite/wpforms.php";}

上の例では、使用中のプラグイン数は4つ、インディックス0番目は "addquicktag/addquicktag.php" プラグイン、そのパスの長さは27文字となっています。
インディックス2番目は "jet-engine/jet-engine.php" プラグイン、そのパスの長さは25文字となっています。
(なお、説明のために改行を入れただけで、実際には改行は含まず、長い一行記述します。)

試しに上のプラグインだけを使用する(アクティブにする)と、次のようなエラーが出ました。
WordPress 致命的エラー

エラー表示の通り、"jet-engine" プラグインが致命的とのことですので、これを省いたプラグインだけを登録します。

 
a:3:{i:0;s:27:"addquicktag/addquicktag.php";
i:1;s:33:"classic-editor/classic-editor.php";
i:2;s:24:"wpforms-lite/wpforms.php";}

(説明のために改行を入れただけで、実際には改行は含まず、長い一行になっています。)

間の "jet-engine" プラグインが抜けたので、インディックス値を振り直したうえの値を登録します。
phpMyAdmin で行うときは、値だけを更新すれば十分です。
SQL で直接処理するには、

 cygwin
UPDATE wp_options SET option_value = 'a:3:{i:0;s:27:"addquicktag/addquicktag.php";
i:1;s:33:"classic-editor/classic-editor.php";
i:2;s:24:"wpforms-lite/wpforms.php";}' WHERE option_name = 'active_plugins';

(「'~'」の「'」で挟まれた部分は実際には改行は含まず、長い一行で入力します。)
とするだけです。
例では4つ程度のプラグイン数ですのでたいしたことありませんが、数が増えると面倒になります。そのため、いったなプラグインをすべて無効 'a:0:{}' にして、WordPress の管理画面から少しずつ有効にして動作を確認、エラーになったら、次のような SQL を打つか phpMyAdmin でプラグイン数を(0に戻して)戻して再度試すなどのデバッグが確実です。
 cygwin
UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins';

WP 最終的な使用プラグイン

今回のエラーは大したこともなく、データベースを UPDATE してミッション3は完了です。

〔オマケ〕データベースの用語を Excel 的に言い換えると

DB と Excel な対応
データベース用語に慣れていない人が、テーブルやカラムやら言葉をごちゃまぜにして、作業をミスってしまうことがよくあるので、簡単な対応表を頭に入れておきましょう。
テーブルとカラムだけ瞬間的にイメージできれば、エンジニアが何を話しているか簡単にイメージできます。

なお、今回の例は phpMyAdmin で試しましたが、Windows クライアントから直接アクセスしてデータベースを書き換えり、MySQL でなくて PostgreSQL を利用している場合でも同様にトラブルを打破することができます。以下のリンクも参考にして試してみてください。


関連記事
phpPgAdmin
Cygwin に phpPgAdmin を速攻セットアップする

Cygwin を使って phpPgAdmin を速攻セットアップする手順です。 Cygwin に Apache プラス ...

続きを見る


関連記事
WordPress 設定
Cygwin に WordPress を速攻セットアップする

Cygwin を使って WordPress を速攻セットアップする手順です。 Cygwin に Apache プラス P ...

続きを見る

-Cygwin, PC-UNIX, Windows, WordPress, ソフトウェア, データベース, 設定
-, , , , , ,