WordPress のデータベース入れ替えの備忘録
まえがき・・・どうでもいいこと
放置状態の WordPress サイトの正常化をお願いされた。
そのサイト、アクセスしてみると、永遠に表示されないのではないかと思うぐらい、極遅。
ふつうならまず、これほど待つことはない。ソースを見てみると膨大な数のスタイルシートと Javascript ファイルの数。そしてぱっと見でわかる、ほとんどが無駄なものばかり列挙された HTML 文。
相当な数のプラグインを使っているのであろう、とは想像にやさしい。実際に、ログインしてみるとそれはもう驚くべき数だった。しかも放置してあったので、これもまたすごい数のバージョンアップと何かしらの警告。とにかく一度すべて消し去ってまっさらにしたくなる衝動に駆られてしまう。
ちょっと前にもてはやされた視覚ギミックをいくつか装備していたページだったが、そのすべてをプラグインに頼って実現していた。エディタにおいても、(このサイトを作らせたのはブロックエディタ以前とのこと)HTML を知らなくても投稿が書ける、旧世代のビジュアルエディタのようなプラグインを使っていて、バージョンが古くなってしまっているそれは、すでに機能しなくなってしまっていた。
サイトのデザイン的には問題無いとのことなので、そのデザインを踏襲しつつ、視覚ギミックをもっと凝ったものにすればそれでいいかと。ただ、サイトのソース自体は、そのすべてがほぼプラグインによって構成されているものなので、余計な部分を消去して解読するだけでうんざりしてしまうだろう。手間がかかるだけのことなので、まっさらから自作したほうがよほど早いし信頼性もあるし気持ちも良い。
ただ、各投稿のタイトルや本文、画像などは再利用するので、データベースはそのまま使えればよかったのだけれど。が、コンテンツの本文もプラグインによって汚染されていたし、膨大な数のプラグインのせいなのだろう、余計なデーブルもたくさんあって、もう、何がなにやら、という具合でこれもまたうんざりしてしまう。いらぬゴミが残るのも気分が悪いし、いっそデータベースも新調することにした。
再利用するデータは、HTML からパースして抜き出し、php から呼び出して使えるように、それぞれ各項目ごとに規則的に分別して配列にし、保存するようにした。と、いうことで、そんな感じでローカルにて制作したものを、いよいよサーバーにあるものと入れ替えるという時となる。これはそのときの、WordPress のデータベース入れ替え(サイトの入れ替え)の備忘録。
データベースの入れ替え
普通は、データベースにある投稿データはそれがそのまま使えたりする。なので、データベースからして入れ替えて使うというのは、そういわれてみれば、やったことがなかったりした。これ、違うデータベースを使用する設定をして、テーマを入れれば、それで使えるようになるのだろうか。まぁ、ちょっと考えてみると、各所にちらばっている url の指定などを変更さえすれば、それですんなりいけそうではあるけれど。
とりあえず、ローカルネットワークにつながっている別の PC にて試してみることにした。そちらの WordPress はただインストールしてあるだけで、全く使用していない。入っているデータベースは MariaDB となる。移動元、移動先の各環境はというと下のようになっている。
移動元:
Windows10
Apache 2.4.48
php 8.1
MySQL 5.7
WordPress 6.1
フォルダ:/wptr/
移動先:
Windows10
Apache 2.4.48
php 8.1
MariaDB 10.9.2
WordPress 6.0
フォルダ:/wp/
まぁ、最初の疑問は、たぶん問題なくできるとは思いつつも果たしてやってみないとわからないところで、MySQL のデータがすんなり MariaDB へとインポートできるか、というところ。
このサイトはたいして大きなサイトではなく、元データベースからすべてのテーブルをエクスポートしたファイルのサイズは圧縮なしで 2.9MB といったところ。我がサイトにおいては、130MB ほどもあったので、それに比べればかわいいものである。
データベースのデータのエクスポート、インポートは phpMyAdmin にて行った。そして問題の MariaDB へのインポートであるが、一度はエラーで止まってしまったが、それを対策した二度目は実にあっけなく問題なく完了してくれた。そのエラーというのはよくあることで、php の設定で post_max_size の設定値が少なすぎたためのこと。あほらしいというかなんということはない。php.ini の設定を変更するだけで解決する。
後は、テーマとか使っているプラグイン、画像などをコピーしていく。プラグインは一つ二つだし、画像はサーバーにあるものを参照していたので、そのあたりの作業もわずかなものだった。
各設定の変更
つづいて、データベースを WordPress とひもづけるために、wp-config.php の設定値を変更する。データベースのデータベース名、ユーザー名、パスワードとホスト名の4つ。あと、WordPress 用のテーブルの接頭辞を デフォルトの wp_ ではなくて変更している場合はそれの指定も必須。
そしていくつか、url の設定値で変更しておかないといけないところがあり、wp_options テーブルの siteurl と home の値。これはまぁ、たとえば同じローカルホストで WordPress がインストールしてあるフォルダも同じなら変更する必要はないけれど、ローカルからサーバーということになると変更は必須となる。
あと、データベースの入れ替えということで、データを元のデータベースからエクスポートして使用する場合、新しい方のデータベースにおいて、WP のテーブルの接頭辞を変更している場合は、他にもいくつか変更しなくてはいけないところがあった。この件も実際にやってみたことになるが、教えてくれているサイトを見つつ、自分でも探しながらやっていったので、どれを変更していったのかあまり覚えていない。変更箇所はそんなに多くはなかった。
移動元と移動先でフォルダの名前が異なる場合で、パーマリンクを設定していると、WordPress のルートフォルダにある .htaccess も変更が必要となる。WordPress によって生成されているデフォルトの内容は以下のような感じだと思う。下はルートフォルダにインストールされていた場合。/wptr/ のフォルダにインストールされていれば、4行目と8行目は /wptr/ と /wptr/index.php になる。移動先は /wp/ なので、その部分を変更しないと、ありもしないフォルダにリダイレクトされてしまうことになる。
これが WordPress の .htaccess におけるデフォルトのようなので、忘れてしまった時のために意味を書いておこう。
5行目の RewriteRule ^index\.php$ – [L] において、^ と $ は正規表現であり、文字列の最初と最後を指定するもので、これらにはさまれた文字列がすべてということになる。[L] はこの条件にマッチした場合、この記号でもって終わりで、後の行は無視するという意味。よって、リクエストが index.php であれば、リダイレクトせずに、そのままアクセスさせる、ということ。
6行目の最後の -f はファイルを示すもので、その前についている ! は否定であり、よってリクエストされたものがファイルとして存在しない場合、となる。7行目の最後の -d はディレクトリを示すもので、よって、6行目、7行目において、リクエストされたものがファイルでもディレクトリでも存在しない場合は、ということになる。%{REQUEST_FILENAME} の %{} はこういう書式なんだと思う。
そして、-f でも -d でも存在しない場合は、いかなるリクエストであろうとも、/index.php へリダイレクトしろ、というのが8行目の RewriteRule である。まぁ、これは忘れようもないか、とは思うけれど。あと、.htaccess は最後に空行が必要とのことなので、それも忘れないようにしないといけない。
あとは、投稿の本文中に、自url を直書きしているところなどがあったので、それらを変更して、入れ替えたデータベースによる、新 WordPress サイトを起動させることができた。
元のデータベースにあったデータをインポートなどせず、全く新たに作ったサイトのデータであれば、データベースを入れ替えれば、当然のことではあるけれど、ユーザーを含め全くべつの内容のサイトとなる。
見捨てられたサーバー
ずっと放置されていたサーバーの方は、大量のプラグインを Akismet 以外、すべて消去してから、WordPress を現行バージョンにアップデートさせた。随分古かったので、離れすぎていてエラーになるかと恐れていたが、案の定、終わったんだかよくわからない状況で、もどってくること無く、止まってしまっているような状況になってしまった。
少しの間、「現在メンテナンス中のため、しばらくの間ご利用いただけません」が出ていてアクセスできなかったが、じきにログイン画面が出て、なんとかログインすることができた。ログインすると、なんら問題などなかったようにアップデートできていたようでひと安心。その後のデータベース入れ替えも、一度やっていたことなので、難なくあっさりとおわり、サイトをリニューアルさせることができた。
ただ、そのレンタルサーバー、あれこれやっていると色々とわかってくるが、やはりとても遅い。最初のサーバーレスポンスが極めて遅いよう。で、見ていくと php は 7.4。MySQL は 5.6 だった。これは放置されていたからバージョンアップしていないのだろうと、サーバーのユーザーページにアクセスしてみたが、なんと、それぞれそれ以上新しくはできなかった。で、サーバーの Apache にしても、アクセス制限を書いていて Require を使うとエラーとなってしまうので、どうやらこれも 2.4 ではないようだった。
なんだか契約していたプランは、もう無くなってしまっているようで、サーバーの機能はバージョンアップされることなく、契約者がいなくなるのを待っているかのようだった。見捨てられちゃったんだな~、と思いつつ。他のプランに移行して欲しいとか、通知があったでしょ!と聞いてみたが、そんなものは全く無かったとのこと。それが本当だとしたら、ちょっと酷いレンタルサーバー屋じゃないか。さっさと違うところに移ったほうがいい!と提言しておいた。老舗で有名なところだけど、酷いところだ。
と、いうことで後になって気が付いたことではあるけれど、データベースのデータは、MySQL 5.7 から 5.6 へのインポートだったということになる。移行自体は何ら問題なくできたわけではあるが、 少し問題が生じているようではある。WordPress の自動更新のときのようで以下のエラーが出ている。
「WordPress database error Lost connection to MySQL server during query for query UPDATE `wptr_options` SET `option_value` ・・・」
ちなみに WordPress は、6.1-RC3 であり、RC2 でも同じものが排出されていた。まぁ、データベースのバージョンの件もあるし、この件は 6.1 の正規版がリリースされてからやろうと思っている。
Post : 2022/10/24 23:18
Comments feed
Trackback URL : https://strix.main.jp/wp-trackback.php?p=172798