今日、ローカル（自分のPC内）で制作したWordPressサイトデータをサーバ(ロリポップ！
)へそのまま移行したんですけど、トラブル2連発でちょいとドタバタしました（汗）
一応解決したけど、昨日の食事をまるで思い出せない脳みそ記憶領域が少ない自分なので、備忘録がてら書き残しておこうと思いますよ。
WordPressサイトデータのローカル→サーバ（ロリポップ）への基本移行手順
本題のトラブルシューティングの前に、WordPressサイトデータのローカル→サーバ（ロリポップ）への基本移行手順についても簡単にだけ紹介しておきます。
サーバ（ロリポップ！）への移行でのトラブル解決方法だけ知りたいという人はココは読み飛ばして頂いて構いませんので。
データをFTPでサーバ（ロリポップ）の公開ディレクトリにアップロード
ローカルに作成したWordPresデータ一式（WordPress本体、テーマ、プラグイン、アップロード画像など）をサーバ（ロリポップ）にFTPソフトでサーバの公開ディレクトリーに直接アップロード。
アップロードする際には、後で使うことになる「Search-Replace-DB-master」のようなデータベース内のレコード文字列を一括置換するツールも公開ディレクトリ直下に一時的にアップ。
データベース情報をphpMyAdminよりエクスポート＆インポート
ローカルPCのXAMPPのコントロールパネルよりphpMyAdminを起動
↓
サーバへ移行したいWordPressサイトに紐づいている該当データベースを選択後、「エクスポート」をクリック。
↓
Exportメソッドは「簡易」「詳細」のどちらか選べるけど、どちらでもOK。
基本的には何も設定変更せずに「実行」ボタンをクリック。
↓
サーバ（ロリポップ）のユーザ専用ページにログイン後、サーバで利用予定の該当データベースをphpMyAdminで開く（無ければデータベース新規作成）。
↓
該当データベースを選択後に、「インポート」をクリックし、先ほどエクスポートして書き出したsqlファイルを選択して「実行」をクリック。
↓
先にFTPでアップロードした「Search-Replace-DB-master」のサーバURLを開いて、該当データベースの文字列を一括置換を実行。
具体的には、WordPressのローカルURLをサーバ用URLに変換する。（例．http://localhost/yossy-style.net → https://yossy-style.net）
↓
最後に念のため、WordPress管理画面にログインして「設定」→「パーマリンク設定」を開いて、「変更を保存」を押しておく。
↓
サーバ（ロリポップ）にアップしたサイトとその管理画面を確認して、正常に動作しているかどうかを確認する。
↓
問題なければ、最後に「Search-Replace-DB-master」をサーバから削除。
こんな感じでたいていの場合は、上記の手順でローカルのWordPressサイトデータをサーバ（ロリポップ）にそのままスムーズに移行することができます。
そう、たいていの場合はですけども。。
サーバ（ロリポップ）へのデータ移行で発生したトラブル
(1)WEBページが文字化けした場合の解決方法
上記手順で終えて、今回も無事サーバへの移行が完了したと思っていたら、予期せぬトラブルがここで発生。
WordPressサイトのWEBページの文字（正確にはデータベースから取得している日本語データの文字列）が全部？？？に文字化けを起こしとりますがな(‘Д’)
でもphpMyAdmin上で見るテーブルレコードは文字化けしていない。。
ん~、なんで？
いろいろと調べた結果、このエラーの原因はWordPressディレクトリ直下のwp-config.php内にあるデータベースの文字セットの設定によるものでした。
いつもは、define(‘DB_CHARSET’, ‘utf8’)となっているのが、今回はどうやらdefine(‘DB_CHARSET’, ‘utf8mb4’)になっていた模様。
ローカルではutf8mb4のままでも動いていたけど、サーバではutf8mb4が文字化けするということは、utf8mb4という文字コードにロリポップのサーバが対応していない可能性が高いのかもしれない。。
とりあえず記述を下記のようにdefine(‘DB_CHARSET’, ‘utf8’)に修正して、FTPでwp-config.phpをサーバに上書きしたら、文字化けトラブルは無事解決しました(^^)/
てか、ローカルにダウンロードしてZIP解凍して使ったwordpress本体（バージョン4.5.1）のwp-config.phpの初期設定のDB_CHARSETはutf8なので、もしかしたらWordPress本体のバージョンアップデートでこのwp-config.phpの文字コードがutf8mb4に書き換わってしまっていたのかもしれない（推測の話だけど）。
(2)WordPressプラグインの更新ボタンを押すと403エラーが出る場合の解決方法
とりあえず文字化け解決して一件落着かと思いきや、またまた問題が(‘Д’)
今度はWordPress管理画面でWordPressプラグインの更新ボタンを押すと403エラーが出て、プラグインの操作ができないわけです。
なんでーーー((+_+))
こちらもいろいろと調べた結果、エラーの原因はサーバーのロリポップ！の「WAF設定という機能が有効」になってしまっていたことが原因のようで。
WAFとはWeb Application Firewall（ウェブアプリケーションファイアウォール）の略で、不正アクセスによるサイトの改ざんや情報漏えいを防ぐ機能です。
機能だけ聞くとありがたい機能なんですけど、このWAFがWordPressで利用する各種プラグインの設定画面にある保存ボタンで押されるプログラム実行を不正なアクセスと判断して実行を妨害してしまうわけです。なんつーありがた迷惑な機能なことで。。
正直、WordPressで利用頻度が多い人気プラグインでも普通にエラーが出ます。
自分の場合、Contact Form7とWP-pollsでエラーになっていたぐらいなので。
ロリポップユーザー専用ページよりWAF設定のログを見ると（ログ参照）、管理画面内の各プラグイン設定ページで押したボタン操作がSQLインジェクションやらクロスサイトスクリプティングという不正扱いされて、phpプログラム実行できずにエラーになっているのが確認できます。
というわけで、解決方法はWAF設定をオフにするのみです。
ユーザ専用ページにログイン後に、WEBツール→WAF設定をクリック。
ロリポップのサーバー契約後に初期設定のままだと、このWAF設定は「有効」になっているので、「無効にする」ボタンをクリックして、設定状態を「無効」にします。
下記画面を見て頂けばわかる通り、各ドメインごとにWAF設定の有効/無効を選べますが、自分にはこのWAFは必要ない機能なので全ドメインでWAF設定を無効にしておきました。てか、WordPressのプラグインの動作を邪魔する機能は要らないだろうって話で。
今回の自分みたいにロリポップでのWAF設定の初期設定がオンになっている事が原因で、WordPressプラグインがエラーになって困る人って結構多そうな気がしますね。ロリポップ！は利用ユーザ多いし、サイト・ブログにWordPressを利用する人も多いので。
てか、ロリポップはこのWAF設定の初期値は無効にしてほしいなぁ。。
とりあえず、ロリポップでWordPressサイト・ブログを運用したい人は、このWAF設定はトラブルの原因になりうるのでお気をつけを(>_<)
以上、WordPress備忘録でした。
