【SWELL】さくらインターネットのレンタルサーバーからConoHa WINGにWordPressを使用したWebサイトを引っ越しするときの注意事項

準備編

後述の事情で「All-in-One WP Migration」等のバックアップ・複製プラグインが使えないので、WordPressの標準エクスポート/インポートとデータベースで部分的にテーブルをエクスポート/インポートするやり方で対応します。

ぼくが人柱になって色々試してみたけど、万が一のことを考えると、ホームページ（Webサイト）の引っ越し時は、WordPressアドレス（URL）・サイトアドレス（URL）を別なものに変えて、いつでもログインができて見ることができる状態（情報を拾える状態）にしておくことを強くオススメします。というより、SWELLのテーマに限った話じゃなくて、

SWELLのテーマ以外と「さくらインターネットからエックスサーバー」は今回は試していないけど、万が一のことがあっても復旧しやすいので、テーマやサーバーに限らず、ホームページ（Webサイト）の引っ越しの際は、そのようにした方がいいです。

留意事項（1）

WAF有効＆SiteGuardに問題があったせいで、サイトヘルスの「おすすめの改善」が消えなかったので、引越し元のSiteGuardは引き継がないことを強く推奨します。削除しても削除しなくてもどっちでもいいけど、ずっと残そうとするなら入れておく方が良いかもしれない。
（このプラグインを削除してから「All-in-One WP Migration」のプラグインで引っ越ししようと試みても駄目だったので、SWELLでの引っ越し時の不具合は別の理由かもしれない）

留意事項（2）

SWELL設定のリセット内にあるキャッシュのクリアで「キャッシュクリアに失敗しました。」というエラーメッセージが出たので、下記のやり方で対応しています。
逐一、SWELL設定のリセット内にあるキャッシュのクリアを試して問題が発生しないことを確認しながら作業していますが、実際に対応を進めるときはやりながら、問題が出ないようにチェックすることをオススメします。

留意事項（3）

ConoHa WINGは結構コンテンツキャッシュがかかるようなので、動作がおかしいと思ったら、サーバーの管理画面からキャッシュをクリアしてください。

引っ越し編

以降、引越し元サーバーからいつでも情報を拾えることを前提に進めています。
作業中はWAFを一時的にOFFにしてください（特定のプラグインの設定が反映されなかったりします）

（手順1）ConoHaの管理画面からWordPressをインストールする

【注意事項1】手動でインストールしようとすると失敗します。

【注意事項2】作成したデータベースを削除にして移行元のデータベースをインポートしようとすると失敗します。

【注意事項3】WordPress引っ越しプラグイン「All-in-One WP Migration」を使うと、うまくいきません。

【注意事項4】データベースを引っ越すと、うまくいきません。（注意事項3と同じ）

（手順2）ローカルのファイル（メディアライブラリ用のフォルダ、テーマフォルダ）をアップロードしておく

【留意事項1】「Simple Custom CSS and JS」はメディアライブラリ用のフォルダにデータ（フォルダ）が入っているので、該当するデータ（フォルダ）をFTPでファイルをダウンロード/アップロードで設定のエクスポート/インポートが可能です。

【留意事項2】引越し前にメディアライブラリの容量をできる限り最適化（不要なものは削除）しておくと失敗しにくいです。

<?php
// zipファイル名
$fileName = 'backup-data';
// サーバールートのフルパス
$target_Path_root = __DIR__ . '/';
// 対象パス（サーバールート「/」から始まり、「/」で終わります）
// ルートディレクトリの場合は''の中は何も入力しなくてOKです。
$target_Path = $target_Path_root . '';
// 圧縮対象フォルダ（最初に「/」はつきません。最後の「/」はつきます）
$compressDir = $target_Path . ''; ← ここにルートフォルダからのメディアライブラリまでのパスを書く
// zipファイル保存先（最初に「/」はつきません。最後の「/」はつきます）
$zipFileSavePath = $target_Path . '/'; ← ルートフォルダ上に作るなら、そのままで良い

// コマンド
// cd：ディレクトリの移動
// zip:zipファイルの作成
$command =  'cd ' . $compressDir . ';' . 'zip -r ' . $zipFileSavePath . $fileName . '.zip .';

// Linuxコマンドの実行
exec($command);

<?php

$zip = new ZipArchive();
// 解凍先フォルダーを作成
$unzip_folder = "./";
//$unzip_folder = "../";
//$unzip_folder = "./" + $_SERVER['REQUEST_TIME'];
//if (!mkdir($unzip_folder, 0777, true)) {
//    die('フォルダー作成が失敗しました...');
//}
// ZIPファイルをオープン
$zip_file = './backup-data.zip';
$res = $zip->open($zip_file);

if ($res === true) {
    // 解凍先フォルダーに解凍する。
    $zip->extractTo($unzip_folder);
    $zip->close();
} else {
    exit('ご指定したzipファイル存在しないか、操作できません。');
}

（手順3）インポートする前に設定しておいた方がいい設定をする（変なエラーが出たりするから）

【やること1】WordPress管理画面内の設定を設定し直す（一般、投稿設定、表示設定、ディスカッション、パーマリンク）

【やること2】ユーザーの設定を設定し直す

【やること3】（wp-config.phpで何か設定している人）引越し先のwp-config.phpに引越し元で必要な設定を反映する

（手順4）「All-In-One Security＜All-In-One Security (AIOS) – Security and Firewall＞」をインストールしてデータベースの接頭辞を合わせる形で変更する

【注意事項】引越し元でデータベースの接頭辞を変更していた人やレンタルサーバーの仕様で「wp_」以外になっている人は、ここでデータベースの接頭辞を引越し元と合わせておいた方が良いです。

データベースの接頭辞がデフォルトの「wp_」になっている人は、引っ越しが終わった後に、このやり方でデータベースの接頭辞を変えておくことを強く推奨します。

（手順5）「All-In-One Security」を削除する

【留意事項】デフォルトで入っている「SiteGuard」プラグインを使わないなら、そのまま使用しても良いのだが、消せない（無効化はできるけど、プラグイン一覧から削除しようとしても消せなかった）ので、「All-In-One Security」の方を消した方が良い。（両方が有効の状態で重複しないように設定できる場合はこの限りではない）

（手順6）WordPress標準のエクスポート/インポートでエクスポート/インポートする

【留意事項】「すべてのコンテンツ」を選択してエクスポートファイルをダウンロードする

【注意事項】「添付ファイルをダウンロードしてインポート」はチェックをつけない

（手順7）phpMyAdminを使って、以前のデータベースから「wp_posts」「wp_postmeta」のテーブルをエクスポート/インポートする

【留意事項1】エクスポート時は簡易でデフォルトのまま実行してOK

【留意事項2】インポート時はデフォルトのままインポートしてOK

インポートするときは前のテーブルを削除しないと失敗します。間違えて他のを消したら、潔く最初からやり直し！

【留意事項3】残念ながら、このやり方だとメディアライブラリのデータがエクスポート/インポートされないので、二度手間になろうとも、データベースの該当するテーブルデータをエクスポート/インポートした方が分かりやすくて失敗がしにくいのでオススメ。

「じゃあ、はじめからタクソノミーも含めてデータベースの該当するテーブルデータをエクスポート/インポートしたらいいじゃないか」としたところ、今度はタクソノミーの反映が中途半端（子カテゴリーがあるはずなのに管理画面のカテゴリー一覧に表示されない）になってしまう。どうして。（この段階で「はぁ！？」って正直思った。深夜だし、声には出さなかったけど）

【留意事項4】もし、メディアライブラリ等のサムネイルが表示されなかったら、プラグイン「Regenerate Thumbnails」を使って再生成する（最終更新日が年単位で前なので、使ったらすぐに削除か、同様のプラグインで対応しても良い）

【留意事項5】色々対応が終わったら、下記2点のやることを対応する

1. 投稿設定でカテゴリー周りの設定を整える
2. （ホームページの表示を「固定ページ」にしている人）表示設定でホームページの表示を「固定ページ」に変更する

SWELLで「投稿リスト」ブロックを使っている場合、カテゴリーの設定が初期化される（またはズレる）ようです。
このあたりも確認するようにすると良いかと！

（手順8）引越し元のサイトと見比べながら、改めて設定し直す

【やること1】メニューを設定し直す

【やること2】ウィジェットを設定し直す

以降は、順不同で問題なし。
見た目重視で動作に問題がないのなら、やること4→やること5→やること3でも良いと思う。

【やること3】新しく必要なプラグインを導入し、設定し直す

【やること4】カスタマイズを設定し直す

さすがに面倒になってきたので、カスタマイズだけなら、プラグイン「Customizer Export/Import」でエクスポート/インポートができるので活用すると便利ですよ！（一部設定が反映されていないものがあったら、手動で設定してね！）

【やること5】テーマの設定（SWELL）をする

（手順9）動作確認をして完了！

これで引越し作業は終わりとなります。お疲れ様でした！

引っ越し作業想定所要時間

4時間

WordPressに慣れていて何度か引っ越しや新規でインストールや設定等を対応したことがある人は、設定ボリューム次第だけど、2時間くらいでいけるかも。

今回の総作業時間は8時間でした。（この記事を書く時間と、その際にできる限り読みやすいように配慮しながら、まとめた時間は除く）
試行錯誤をしている時間、本記事（まとめ）を並行で作成していた分の時間、カラーの微調整をした時間も含むことと、せっかく終わったのに「バックアップを取らないまま、変なデータを消した」という馬鹿なことをしたため、再トライすることになった2時間分が含めているため、実際のところは6時間くらいだと考えられます。
投稿・メディアライブラリまで完了してからサイトの見た目も整えて完了するまでは1時間半くらいでしょうか。
再トライ時の時間は2時間くらいだったので、初めて作業する方や不慣れな方が本記事を見ながら作業するなら4時間くらいと見ていただけると良いかと思います。

困ったら相談してください！

本記事を読みながらの作業でも不安がある場合のレクチャー、WordPressの引越し作業の代行も承りますので、
お困りの方はご相談くださいね！

SNSのDM

ココナラのDM

経緯編1「さくらインターネットのレンタルサーバーの問題点【WAF有効時はgzip圧縮が使えない】」

以前は、DKIM・DMARCが未対応というのも問題点としてあったのですが、
Googleの送信者ガイドラインが更新されるときの影響もあって、2024年1月末日に提供開始されています。
そのため、この問題点は消失したのですが、
ページ表示速度の向上に努めたはずのさくらインターネットのレンタルサーバーの致命的な弱点とも言えるのが、この仕様。

よくページ表示速度を改善する解説ページで出てくる「gzip圧縮」
gzip圧縮は、HTML・CSS・JavaScriptなどのファイルを圧縮することで、ブラウザからのデータ転送量を減らして表示速度を高めるための手法なのですが、この圧縮率が結構優れているので、ページ表示速度をなるべく速くするためには欠かせない手法の一つでもあります。
なかったら、Googleが提供するツール「PageSpeed Insights」の診断で改善できる項目の一番上に「テキスト圧縮の有効化」が表示されるくらいには影響があります。実際にページ表示速度も3秒未満の実現はかなり厳しくなります。サーバーのスペックを上げたり、他にもできることはあるので、それでなんとか……なるのか？ というより、同じ仕様のさくらインターネットのサービスを使う時点で厳しい（一部は対応しているっぽいんだけど）と考えるし、別のレンタルサーバーで「ページ表示速度、ウチのサーバーは結構速いよ！」と言っているサーバーだったら、まず、この問題は発生していないのでは……？

ob_start("ob_gzhandler")

zlib.output_compression = On

経緯編2「さくらインターネットのレンタルサーバーの問題点【WAF有効時はgzip圧縮が使えない】」

自分のサイトのメンテナンス（構造化データの自動出力とパンくずリストをSWELL標準にする作業）をしていて、サイトのパフォーマンスチェック（たまにしています）のために「PageSpeed Insights」を使って確認していたら、「First Contentful Paint」はまだしも「Speed Index」が平均でも2秒以上に（3秒未満ではありましたが…）なっていたことに気づきました。

今更気づいたのかって話ですが、元々も3秒以内（2秒以上の結果が出ても前半の数値）だから、あんまり遅いって感じにくいですし。それに、いつもはWi-Fi接続の状態で作業しながら見ていたしなぁ……。

現状、「さくらインターネットのレンタルサーバーではWAFを有効にしているとgzip圧縮はできない」から、「じゃあ、ページ表示速度を速くするのを諦めますね」というのは違うと、ぼく自身は考えています。

自分がやりたいことが実現できるレンタルサーバーに乗り換えた方が良いです。もちろん、ランニングコスト次第なんだけど。

どのレンタルサーバーに乗り換えるか（引っ越すか）の話に戻りまして。

夜空きりが所有しているのは、

• さくらインターネット（メインで使っているサーバー…だった）
• ConoHa WING（アフィリエイト用のブログのために契約している）
• エックスサーバー（創作系のウェブサーバーは別にしておきたかったのと、とにかく利用者が多いので挙動確認などの仕事でも使うと判断して契約している）

の3つです。

正直な話をすると、引っ越し先はエックスサーバーでも良かったのですが、「創作系のウェブサーバーは仕事のウェブサーバーとは別にしておきたかった」時点で嫌だったので、ConoHa WINGにしました。（メールはまぁ、同じでもいいかな。便利な方で対応で良いと思っています）

ConoHa WINGは、さくらインターネットがまだDKIMに対応していなかったために迷惑メールに入るようになってしまって困ったことや「メールとサイトでサーバー（レンタルサーバー）を分けておきたい」と思ったことから、事業用メール等で使っているメールのためにも使っていました。（その時の話）

そこで、メールとサイトのデータ（または設定）を再引っ越しして、使用用途を逆にすることにしました。
自分で言っていて、分からなくなってきたので、下記表を見てください。

ConoHa WINGのWordPressインストールでは、セキュリティ対策をしながらインストールと設定をしようと思うと、気をつけないといけない点があるのですが、アフィリエイト用のブログをセットアップしていたときに対応したから平気だと思っていたら、
WAF有効と「SiteGuard」の組み合わせで起きた不具合のあれこれと、SWELL側で複製コピーしたときに何らかの問題が発生したのか、まさか、あんなに試行錯誤するとは思いませんでした……。
おかげで、クライアントから依頼を受けたときにも対応できるようになったと思うので、前向きに捉えるなら良い経験になったとは思うのですが、まぁ、エックスサーバーでいいかな……（苦笑）

「サーバーを引っ越せないけど、なんとかWAFを有効にしたままページ表示速度の向上を目指したい！」という人向け情報

SWELLの標準機能だけでも最低限のページ表示速度の向上はできているのですが、それでも満足できない方は、独自で対応するしかないです。
ページ圧縮ができない以上、物理的に圧縮するしかないのですが、gzip圧縮したファイルを用意して送信をして……と、どうやればいいのかが分からなかったので、「なるべく無駄を省く」のが一番手軽で確実かなと思います。

静的ファイルに出力してからgzip圧縮して、圧縮したgzipファイルを展開する形になるとは思うけど、WordPressは動的なので、個人的には動的で対応したいと思うところ。

HTML等のコードをできる限り軽量化することをMinify（ミニファイ）といいます。
対応しているのはページ表示速度の改善の解説ページでよく出てくるプラグイン「Autoptimize」ですが、実はSWELLとあまり相性が良くないというか、SWELLに干渉しないように設定したら、あんまり効果が出ないんですよね。効果を出そうと設定をすると逆に遅くなってしまうという……。

ぼくが対応したときは、正直あまり効果が出なかったので断念したのですが、改めて「さくらインターネットから引っ越ししにくいWordPressを使用したWebサイト（SWELLで制作）」で試してみたところ、まぁまぁの効果が出た（ページ表示速度が3秒以上でパフォーマンススコアが70点そこそこが、3秒前後でパフォーマンススコアが80点そこそこまで改善した）のが、独自で圧縮したものでした。

下記のページをほぼそのまま使って対応したら、実現ができたので、困っている人はお試しください。

Qiita

PHPでHTML圧縮 – WordPress対応かも？ – Qiita はじめにWordpressプラグインでHTML圧縮ができるかもしれませんが、過剰に圧縮するためにうまく動かない場合が存在します。簡単なコードで HTML圧縮をしてみるのも良いでし…

なるべくSWELLやWordPressコアと干渉しないよう、ログインしていないときに実行するようにして、プラグイン化させて、いつでも無効化・削除できるようにしました。全ソースを共有します。

作成したプラグインを使用している環境で、SWELL設定の「コンテンツに合わせて必要なCSSだけを読み込む」が使えなかったことが判明したので、外部CSSファイルの非同期読み込み処理を追加しました。（2024年2月9日）

<?php
add_action('template_redirect', function () {
    if (!is_user_logged_in()) {
        /*
        * 外部CSSファイルを非同期で読み込むようにする
        *
        * 元となったプログラムソース先は失念したため、なし。
        * 結構前にオリジナルテーマを作ったとき、ページ表示速度のできる限りの向上を目指して作成したときに調べて作成したもの。
        *
        */
        add_filter('style_loader_tag', function ($block_css_html, $block_css_handle, $block_css_href, $block_css_media) {
            // ログインしていないときに実行する
            // HTML を変更
            $block_css_html = '<link rel="stylesheet" id="' . $block_css_handle . '-css" ';
            $block_css_html .= 'href="' . $block_css_href . '" media="print" onload="this.media=\'screen\'">' . "\n";
            return $block_css_html;
        }, 10, 4);
        // ログインしていないときに実行する
        // ob_startでMinify化し、出力用バッファを有効にする
        function minify_html_code($code_minify_content)
        {

            $code_minify_search = array(
                '/\s\/\>/s', // XMLの /> を圧縮
                '/\>[^\S ]+/s', // タグの後の空白を削除
                '/[^\S ]+\</s', // タグの前の空白を削除
                '/(\s)+/s', // 連続した空白を削除
                '/(\t)+/s', // 連続したタブを削除
                '/<!--[\s\S]*?-->/s', // コメントを削除
                '/type=\"text\/javascript\"/s' // 今は不要なものを削除
            );
            $code_minify_replace = array(
                '>',
                '>',
                '<',
                '\\1'
            );
            $code_minify_content = preg_replace($code_minify_search, $code_minify_replace, $code_minify_content);
            return $code_minify_content;
        }
        ob_start('minify_html_code');
    }
});
// ob_end_flushでMinify化する出力用バッファを送信してオフにする
add_action('shutdown', function () {
    if (!is_user_logged_in()) {
        // ログインしていないときに実行する
        ob_end_flush();
    }
}, 0);

「ob_end_flush」もいるよねと思ったので、HTMLの最後に実行できるアクションフックを探していたら「shutdown」というフックの存在を知りました。早速取り入れています。
（試行錯誤をしていたときに見ていたページがどれだったか忘れたので、改めて「shutdown」で探した）

WordPressのための便利帳

WordPressですべての処理が終わった後にコンテンツを置換する方法（アクションフック） WordPressで投稿本文のコンテンツを置換したいときは、「the_content」にフックさせます。function change_the_content($the_content) { $the_content = str_repla…

自己責任だけど、プラグイン化したから、使ってね。
公式配布はしません。
ほぼソース丸パクリのようなものだから、そんな状態で作ったプラグインを公式配布する度胸は、ぼくにはない。

プラグインファイル配布先

制作プラグイン クリエイトアコードが制作したプラグイン紹介 本ページでは、クリエイトアコードが実際に開発しているプラグインの紹介と今後の展開について紹介しています。 今後の展…

参考サイト集

調査中にメモするのを忘れたページもいくつかあるので、そういったページは省略せざるを得ず……。
メモとして残っているものだけをまとめています。

引越し作業前に参考にしていたページ

事の発端の内容は、さっくりとまとめているんだけど、さくらインターネットのヘルプページのことを失念していたせいで、実際はもっと原因調査に時間がかかっています。（Xにその証拠が残っているけど、わざわざ投稿リンクを貼ることでもないかなーと思って省略しています）

Qiita

SiteGuardを導入するとHTTP_ACCEPT_ENCODINGなどのHTTPヘッダが削除されてしまう件 – Qiita 「SiteGuard」を導入にすると一部のHTTPヘッダーがとれなくなります。意外と気付かず条件設定などにおいてハマってしまうことがあります。※ これは2016-09-28に個人ブログ…

さくらのサポート情報

Webアプリケーションファイアウォール(WAF)を設定したい | さくらのサポート情報 このマニュアルでは、Webアプリケーションファイアウォール（WAF）についてご案内しています。前提条件シグネチャ検査・セッション管理などの検査を実施しており、攻撃にあ…

(注)「WAF機能を利用の際は、mod_deflateを利用することができません。」とヘルプページ内に書いています。

Simple Tools

Gzip/Brotli圧縮を確認してください この無料のGZIP/Brotli圧縮ツールをお試しください。 Webサイトが完全にGZIPまたはBrotliで圧縮されているかどうかを確認します。

引っ越し中に参考にしたページ

「プラグインがないかなー」と調べていたときに見たページが色々あるんだけど、どれがどれだか分からなくなったので、ここではデータベースの情報ページ以外は載せないことにしました。記事中で出てくるプラグイン名が気になったら調べてみてね！

Proぐらし（プロぐらし）

【WordPress】生成されるデータベースの中身の詳細。情報・データがどのテーブルに保存されるか？場所と内… WordPressでサイトを生成すると自動でデータベースと必要なテーブルが生成される。 テーブルは複数ありそれぞれ決められたデータが保存されている。これらを確認する方法に…