WordPress 6.5に変更後、ダッシュボードが表示不能となりましたが、SQLiteが生成したDBファイルの特定のパラメータを書き換えることで復旧できました。
注：今回の記事は鉄道・旅行には無関係ですが、備忘録を兼ねて記事化しました。
WordPress 6.5に変更後、ダッシュボードが表示不能に
本サイトはWordPressを使って構築していますが、WordPressは原則としてMySQLなどのRDB（文字情報のみを蓄積するサーバのようなもの）が必要です。しかし、筆者が契約しているレンタルサーバは格安ゆえMySQLが使えません。
そこで、MySQLの機能をSQLiteというフリーのプログラムに代行させることで、ある意味強引にWordPressを動作させています。その場合、本来MySQLに格納されるデータはレンタルサーバ上にファイルとして保持されます。詳しい説明は、例えば以下のサイトに記載されています。
筆者の環境では、WordPressのバージョンアップを自動で行うよう設定していました。4月頭のある日、WordPressのバージョンが6.5に上がったようで、管理用のダッシュボードを開こうとすると「DBの更新が必要です」という画面が出てきました。
しかし、「更新」ボタンを押すと「WordPress 6.5 には MySQL 5.5.5 以上が必要です」のメッセージが出ました。どうやらWordPress 6.5 以降のバージョンでは、「MySQLのバージョンが5.5.5以上でないと動かない」という制約が加わったようです。
上記の通り筆者の環境ではMySQLは使っていませんが、WordPress側からはMySQL 5.5.5以前のバージョンと認識されてしまっているようです。SQLiteのパラメータを色々いじってみたりしたものの、解消せずでした。
SQLiteのパラメータ書き換えでDB更新が発生しなくなった
色々と試行錯誤しているうちに、上記のサイトに行き当たりました。曰く、
/docroot/wordpress/wp-includes/version.phpに記述されている「$wp_db_version」の値を確認します。
WP本体の更新に伴い、この値と上記DB内のoption_valueの値が不一致になると、前述の「DBの更新が必要」画面で本事象が発生するようです。
とのこと。調べてみると、筆者の環境ではwp_db_versionの値は 57155 でした。
SQLiteのDBファイルは/wp-content/database/.ht.sqliteという場所にできています。ところが、DBファイルは通常のテキストファイルなどではなくバイナリファイルとして保存されているので、DB Browser for SQLiteのような専用の編集ツールを用いないと値の書き換えができません。
そこで、DBファイルをftpでダウンロードし(約5GBと大きいので大変でしたが)、DB編集ツールを使って、以下のようなSQL文によりoption_valueの値を書き換えます。
UPDATE wp_options SET option_value = 57155 WHERE option_name = 'db_version';これで、DB内のoption_valueの値と、wp_db_versionの値が同じになりました。
書き換えたDBファイルをまたftpでアップロードし、既存のものと置き換えると、DB更新のメッセージは出なくなり、無事管理用ダッシュボードが表示されるようになりました。めでたしめでたし。
WordPress＋SQLiteは運用が難しい？
という訳で、今回は何とか自力で問題を解決できましたが、そもそもWordPressとSQLiteを組み合わせて使うことは非公認である(WordPressでSQLiteを正式サポートする話もあるようですが、まだ実現していないようです)ため、何かあった場合の問題解決は自己責任となります。
上記のようにftpなどを使ってファイル操作をする場合、ミスすればWordPressが動かなくなったり、最悪過去記事のデータが無くなってしまうこともあり得ます。レンタルサーバによってはWordPress環境の構築・管理を行ってくれるサービスもあるはずですので、自信が無い場合はそちらを使う方がいいでしょう。
また、WordPressとSQLiteの組み合わせだと、ページの表示性能が悪いのも課題です(本サイトもページの表示に数秒を要し、ご迷惑をおかけします)。そのうち、レンタルサーバのプランを変更し、SQLiteからMySQLに移行して性能向上したいと思っているのですが、移行もなかなか面倒なようでまだ踏み切れずにいます。
【2024/11追記】WordPressのソースコード修正でも対応可
その後WordPressのバージョンが上がり、同じ症状が再発したため改めて調べたところ、上記サイトにある通りWordPressのテーマ内にある”functions.php”というファイルを修正してやれば、バージョン不整合が起きなくなるとのこと。
例えば、本サイトはWordPressのCocoonというテーマを使っているのですが、その場合は”/wp-content/themes/cocoon-master”というフォルダにあるfunctions.phpを更新し、上記サイトに記載のソースコードをファイル末尾に付け足してやると不具合が解消しました。
このやり方の方が、SQLでDBファイルを書き換えるよりずっと楽なので、同じ問題で悩まれている方は上記サイトの方法を試されることを推奨します。
(ちなみに上記サイトでは本記事を参考にして頂いたようで、どうもありがとうございます。)
コメント