Xfreeからcloudfreeへのサーバー移行 (8/8)
2023-10-26 記載
概要：Xfreeからcloudfreeへのサーバー移行
前後の記事：1/8, 2/8, 3/8, 4/8, 5/8, 6/8, 7/8
Keyword : cloudfree, Xfree, サーバー移行,
[Step番外編:A]WordPressにログインできない場合
WordPressのログインアカウントをブラウザの記憶まかせにして、WordPressの移動などをしていると、いままで使えていたブラウザのパスワード●●●●●が使えなくなったりすることがあります。
これはwp-config.phpを書き換えたときに、クッキーのKEYが変わって使えなくなるからです。
ただデータベースアカウントがわかっているなら(wp-config.phpに書いてあるからわかるはず)、phpMyAdminからWordPressのパスワードはいつでもリセットできます。wp_users テーブルの user_pass がそれです。
ただしプレーンテキストではなくMD5の関数を通した値なので、現状が何かは逆変換できません。ちなみに数学的には逆変換できないのだけれど、皆がよく使ってるようなありふれたパスワードなら、変換実績のビッグデータから一瞬で逆変換されてしまうみたいです。
# user"admin"のパスワードを"1234"にする
UPDATE wp_users SET user_pass=MD5('1234') WHERE user_login='admin';上のSQLでいつでもリセットができます。
[Step番外編:B]ドメイン直下にあったWordPressをサブフォルダに配置する場合
★xfsid.wp.xdomain.jp にあったWordPressを、★cfsid.cloudfree.jp/subfolder に配置する場合、★cfsid.cloudfree.jp/subfolderにドメインを割り当てるなら別ですが、初期ドメインだけでやりくりするなら、index.phpのフォルダの.htaccessは書き換える必要があります。
以下はsubfolder に配置する場合。パスを記述すれば階層は深くなってもOKです。
# BEGIN WordPress
# "BEGIN WordPress" から "END WordPress" までのディレクティブ (行) は
# 動的に生成され、WordPress フィルターによってのみ修正が可能です。
# これらのマーカー間にあるディレクティブへのいかなる変更も上書きされてしまいます。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /subfolder/
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /subfolder/index.php [L]
</IfModule>
# END WordPressトップページはちゃんと表示されるのに、リンクを開いたらまったく表示されない、URLは正しい、という場合はこの.htaccessの設定が疑われます。
[Step番外編:C]table_prefixをwp_以外に編集してデプロイする場合
wp-config.phpの以下の一行で、そのWordPresssのテーブル名が決まります。
$table_prefix = ‘wp_’;
１つのデータベース内に複数のWordPressを同居させたい場合は、ここを変えることで可能です。たとえば『cloudfreeでは簡単インストールでwp_*のテーブルがすでに作られてるなぁ。でもデータベースが増えるとバックアップとかも増えて面倒だから、wpsub1_*でいれちゃおう』とか。
インポート前に.sqlファイルをテキストエディタで開いて、`wp_ を `wpsub1_ に一括置換してから、インポートさせます。
wp-config.phpのこの一行を書き換えます。
$table_prefix = ‘wpsub1_’;
まだあります。これだけだと管理者でログインしても、ログインはできるのに、管理バーだけが表示されて、ダッシュボードのメニュー項目が何も表示されない、という状態になります。
あわせて wpsub1_usermetaテーブル の修正が必要です。
UPDATE `wpsub1_usermeta` SET `meta_key`='wpsub1_capabilities'
WHERE `meta_key`='wp_capabilities';
UPDATE `wpsub1_usermeta` SET `meta_key`='wpsub1_user_level'
WHERE `meta_key`='wp_user_level';
UPDATE `wpsub1_usermeta` SET `meta_key`='wpsub1_dashboard_quick_press_last_post_id'
WHERE `meta_key`='wp_dashboard_quick_press_last_post_id';使い方次第でここは修正すべきレコードが増えるかもしれませんが、
wp_capabilities, wp_user_level
とあとは同様にmeta_keyがwp_で始まるレコードに注目すれば対処できるでしょう。
以上で Xfree→cloudfreeの移行シリーズは完結です。
最後になりましたが、一般的な注意点など。
cloudfreeではほとんど制限がないので、WordPressに関してはかなり自由な配置ができます。
しかしあまりこみいったことをするとメンテナンス的にもSEO的にも不利ですから、よほどの理由がない限りシンプルかつオーソドックスな配置がベターです。
また移行にあたってはどう配置するにせよ、まずはpublic_html直下に置いて正常動作を確認してからcloudfree内部での移動に挑む、と二段階で進めるのが無難です。
cloudfreeのサーバーパネルから簡単インストールしたWordPressなどを削除した場合、すぐには処理されず５分ほどのちに反映されます。ユーザーインターフェースから同期で処理はされずに、バッチジョブにタスクが投入されて数分後に実行、という感じでしょうか。
作成と削除を激しく繰り返すサーバーへのDOS攻撃もありえることを考えると、そうなるんでしょうね。
あれ？と思わされるもどかしい一面はありますが、サーバー側の都合で即時反映されないのは一部のケースのみ。
修正が反映されない悩みは、たいていブラウザやネットワークのキャッシュです。移行作業中の画面更新は、Ctrl＋F5のスーパーリロードをデフォルトで使うように心掛けてください。
では皆さんの移行の成功を祈っております。(^_^)/~
