ローカルからライブにWordPressサイトを移行する際に何がうまくいかなくなるか

ラップトップ上ではサイトは完璧です。すべてのページがロードされ、すべての画像が鮮明で、チェックアウトも機能します。次に、ライブサーバーにプッシュしてブラウザで開くと、何かがおかしくなっています。

ローカルとライブの環境は、見た目よりもはるかに異なります。そのギャップがほとんどの問題を引き起こします。

Duplicatorは、150万以上のサイトで動作するWordPressのバックアップおよび移行プラグインです。Duplicator Proを実行しているサイトの重要な割合は、ローカルまたは開発環境であり、約10件に1件です。これは、ラップトップで構築し、ライブサーバーにプッシュする人が多いことを意味します。

ローカルからライブサーバーにサイトをプッシュしているユーザーからのサポートチケットを調べました。失敗は一貫しており、そのうちの1つは、他のどのデータよりもここで圧倒的に多く現れています。

これらの数値は、サポートチケットのボリュームと匿名化されたインストールデータを反映したものであり、顧客数や売上ではありません。

目次

主な発見事項

ここでは、ローカル開発からライブサーバーにWordPressサイトを移動することに関するチケットの内容を示します。すべての数値はDuplicator独自の記録に基づいています。

• Duplicator Proを実行しているサイトの約10件に1件は、ローカルまたは開発環境です。まずローカルで構築することは、一般的なプラクティスであり、例外的なケースではありません。
• ローカルからライブへの問題は、すべての移行サポートチケットの約8件に1件を占めています。単一のシナリオとしては、これは大きな割合です。
• SSLはこの引き継ぎの代表的な失敗です。ローカルからライブへのチケットの約5件に1件に現れ、一般的な移行チケットよりも約15倍多く見られます。
• PHPバージョンの不一致は、ローカルツールが最新のPHPを出荷し、多くのライブホストが遅れているため、他の移行よりも約3倍多く発生しています。
• 最も一般的な単一の問題は、インストールを停止するホスト制限であり、移動自体の欠陥ではありません。
• ほぼすべての失敗は、転送ではなく、2つの環境間の違いに起因します。

TLDR:通常、ラップトップとライブサーバーは、PHPバージョン、SSL、ファイルパーミッション、サイトのドメインの4つの点で意見が異なります。移動前にそれらを解決すれば、引き継ぎはスムーズに進みます。

これを読み解く上で考慮すべき注意点が1つあります。これらはサポートチケットであり、ローカルからライブへの引き継ぎがどこで壊れるかを示していますが、それがどれくらいの頻度で壊れるかは示していません。

これらの移行の多くは問題なく完了し、チケットが生成されることはありません。また、10件に1件という数字は、WordPress全体ではなく、Duplicator Proを実行しているサイトを表しています。

ローカルとライブが思っているより離れている理由

ローカルWordPress環境は、プライベートテスト用に構築されます。ライブサーバーは、パブリックインターネット用に構築されます。これらは異なるジョブであり、セットアップもそれを反映しています。

このレポートのほぼすべてを引き起こす4つの違いがあります：

• PHPバージョン。ローカルツールとライブウェブホストは、異なるデフォルトPHPバージョンで実行されている可能性があります。
• SSL。ローカルはプレーンなhttp://または自己署名証明書で実行されます。ライブは実際のものを期待します。
• ファイルパーミッション。ローカルはあなたが唯一のユーザーであるため、寛容です。ライブはよりロックダウンされています。
• ドメイン。あなたのサイトは、mysite.localのような名前で自身を認識します。移動後、その名前は存在しません。

Local、MAMP、XAMPP、Docker、またはプレーンなlocalhostセットアップのいずれを使用しても、失敗モードは同じです。なぜなら、ギャップはツール間ではなく、環境間に存在するからです。

誰も警告しないSSLの問題

サイトがライブサーバーに表示される際に鍵マークが表示されない、またはスタイルシートの半分が読み込まれずにレイアウトが崩れる。あるいは、ブラウザが混合コンテンツの警告を表示し、それが何を指しているのか分からない状態になる。

これはデータセット全体で最も顕著な障害です。SSLの問題は、ローカルからライブへの移行チケットの約5枚に1枚で発生するのに対し、一般的な移行チケットでは約70枚に1枚程度です。これは通常の15倍の割合であり、その理由は移行自体よりもタイミングに起因します。

移行ツールは、インストールの際にサイトのドメインを書き換えます。mysite.local は、シリアライズされたデータ内を含め、データベース全体で yoursite.com になります。その部分は処理済みです。

プロトコルは別の問題です。移行時にライブホストでSSLがアクティブでない場合、その時点でのサイトの正しいアドレスは http://yoursite.com になります。そのため、データベースに書き込まれるのはそのアドレスです。

その後証明書を有効にすると、サイトはHTTPSで配信されるようになりますが、データベースにはまだ http:// と記録されています。ローカル開発中に保存されたすべての資産は、HTTPSを必要としなかったため、同じ問題を継承します。

何も失敗しませんでした。サイトは当時のアドレスに移動されました。

修正は、主に正しい順序で作業を行うことです。

• 移行する前に、ライブホストでSSLを有効にしてください。ほとんどのホストでは、通常、ホスティングコントロールパネルのSSL、SSL/TLS、またはセキュリティというセクションの下に無料証明書が発行されます。これを最初に行うと、インストール時に最初から https:// が書き込まれます。
• すでに移行済みの場合は、サイトのURLを更新してください。これはWordPressダッシュボードの設定 » 一般の下にあるWordPressアドレスとサイトアドレスのフィールドで見つけることができます。
• ローカル開発で残った http:// への参照を検索して置換して、古いアセットリンクを新しいプロトコルに一致させます。
• 混合コンテンツを確認してください。ライブサイトを読み込み、ブラウザの開発者コンソールを開き、安全でないリソースに関する警告を探してください。 http:// で読み込まれ続けている正確なファイル名が表示されます。

移行前にSSLを処理すれば、驚くほど多くの問題が発生しなくなります。

ローカルからライブへの移行で壊れるもの

SSLはローカルからライブへの移行が失敗する際立った理由ですが、それだけではありません。その他のエラー、その原因、およびそれらを解決する方法を以下に示します。

何が問題になるか	おおよその頻度	その背後にあるもの	どのように解決されるか
ホストの制限によりインストールが停止する	最も一般的	ライブサーバーのPHPタイムアウトまたはメモリキャップが抽出を中断し、ラップトップでは強制されなかったもの	ホストで max_execution_time と memory_limit を引き上げる
移行後にサイトが安全でない	約5分の1	移行時にホストでSSLがアクティブでなかったため、保存されたアドレスはまだ http:// のままです	移行前にホストでSSLを有効にし、サイトのURLが https:// を使用していることを確認してください
データベースのインポートが失敗する	約7分の1	ライブデータベースの認証情報がホストが作成したものと一致しない	インストール中に正しいデータベース名、ユーザー、パスワードを入力してください
ファイルパーミッションが書き込みをブロックしています	約8分の1	ローカル環境は寛容ですが、本番環境はそうではないため、所有権と書き込みアクセスが突然重要になります	フォルダを755に、ファイルを644に設定してください
本番環境に移行するとログインできなくなります	約9分の1	保存されたサイトURLが本番環境のアドレスと一致しないため、リダイレクトループが発生しています	WordPressアドレスとサイトアドレスを修正し、Cookieをクリアしてください
PHPエラーが本番サイトに表示されます	約11分の1	ローカルツールはホストが実行しているPHPよりも新しいPHPを出荷するため、関数が非推奨または欠落しています	移行前に両方の環境でPHPバージョンを一致させてください
いくつかのローカル参照が残っています	約16分の1	データベース外のテーマファイル、カスタムコード、キャッシュ、またはサードパーティサービスにハードコードされたURL	テーマとカスタムコードでローカルドメインを検索し、すべてのキャッシュをクリアしてください

3列目を読み進めると、パターンは一目瞭然です。ここでの問題のほとんどは転送によるものではありません。ラップトップとは異なる設定の本番サーバーによって引き起こされています。

ホストの制限がインストールを停止するとき

本番サーバーでインストールを開始しますが、しばらく処理された後、停止します。

これはローカルから本番への移行チケットで最も一般的な単一の問題であり、壊れた移行ではなくホストの制限です。サーバーのPHPタイムアウトまたはメモリキャップが、最も重いステップである抽出中にプロセスをカットします。ローカルマシンにはそのような上限がないため、ラップトップで正常に実行されたビルドが共有ホスティングで壁にぶつかる可能性があります。

宛先サーバーでmax_execution_timeとmemory_limitを上げてください。これらはホストのコントロールパネル（PHPオプションまたはMultiPHP INIエディタの下にあることが多い）にあり、見つけられない場合はホストのサポートが迅速に引き上げてくれます。

これは、使用するツールによっても違いが生じる点です。

標準のzipアーカイブは、1回の連続実行で展開する必要があります。実行時間が短いサーバーでは、これは問題となります。

展開にホストが許可する時間を超えると、プロセスは途中で終了し、サイトは部分的に展開されたままエラーが明確になりません。

DupArchiveはDuplicatorのカスタムバックアップアーカイブ形式で、代わりに小さなピースで展開できるように設計されています。サイトをチャンクごとに処理するため、単一の実行でホストの制限を超える必要はありません。

これにより、Duplicatorは、従来のアーカイブでは問題が発生するサーバーで、400GBの実際の移行を含む大規模なサイトを処理できます。

スタンドアロンインストーラーは、反対側の関連問題を解決します。宛先にWordPressが既に存在する必要がないため、何も設定せずにローカルビルドを完全に空のサーバーに移動できます。

PHPはラップトップの方がホストよりも新しい

ローカルではすべて正常に動作しますが、本番サイトでは特定のプラグインまたはテーマ機能を使用するページでエラーが発生します。

これは、他の移行よりもローカルから本番への移行で約3倍多く発生し、ツールのパッケージ化の方法によるものです。

ローカル開発環境は最新のPHPバージョンで出荷されます。多くの本番ホストはまだ古いバージョンをデフォルトとしているため、ラップトップで機能した関数がサーバーでは非推奨または欠落しています。

両方を確認してから移動してください。ローカルツールでは、通常、サイトの設定パネルにPHPバージョンが表示されます。

ホストでは、PHPバージョン、PHPバージョンの選択、またはMultiPHPマネージャーの下を確認してください。それらを一致させ、実際にデプロイするバージョンに対してビルドしてください。

データベースのインポートが失敗する

ライブサイトでは、データベース接続の確立に関するエラーが表示されるか、インストールがデータベースのステップで停止します。

移動後、これは壊れたデータベースではなく、ほぼ常に認証情報の問題です。名前、ユーザー、またはパスワードがライブホストが作成したものと一致しません。

ライブホスティングアカウントからデータベース名、ユーザー名、パスワード、およびホスト値を取得し、インストールステップ中に注意深く入力してください。サイトがすでに稼働していて失敗している場合、それらの値はサイトのルートフォルダにあるwp-config.phpにあり、ホストのファイルマネージャーまたはFTPクライアントからアクセスできます。

ファイルパーミッションが引き継がれない

ファイルを書き込めない、またはフォルダを作成できないというエラーでインストールが停止します。

ローカル環境は、あなただけが使用しているため、寛容です。ライブサーバーはより厳格です。ラップトップでは重要でなかった所有権と書き込みアクセスが、ここで重要になります。

宛先のフォルダを755に、ファイルを644に設定してください。フォルダを右クリックするとパーミッションまたはCHMODオプションが表示されるFTPクライアントまたはホストのファイルマネージャーを通じてファイルパーミッションを変更できます。不明な場合は、ホストのドキュメントで正しいWebサーバーユーザーを確認してください。

ライブになるとログインできなくなる

移動が完了し、ログインしようとすると、ログインページがあなたをリダイレクトバックするか、ループします。

これは、それが必要とする以上のパニックを引き起こします。移動が失敗したことを意味することはほとんどありません。データベースに保存されているサイトURLが、サイトが現在存在する場所と一致しないため、WordPressは存在しないアドレスにリダイレクトし続けます。

設定 » 一般の下にあるWordPressアドレスとサイトアドレスフィールドを修正し、Cookieをクリアしてください。

ダッシュボードにまったくアクセスできない場合は、wp-config.phpで両方の値を一時的に設定できます。

移動後も残るローカル参照

ほとんどのリンクは機能しますが、まだmysite.localを指しているものがあります。

データベース参照はインストール中に書き直されます。残るのは、データベースの外にあるすべてです。テーマまたは子テーマファイルにハードコードされたURL、カスタムコードに書き込まれたパス、キャッシュされたページ、または開発アドレスを指しているサードパーティサービスです。

テーマとカスタムコードでローカルドメインを検索し、キャッシュプラグインとホストのサーバーキャッシュをクリアしてから再読み込みしてください。CDNや外部フォームなどのサービスが関与している場合は、そのサービスでもサイトアドレスを更新してください。

ローカルをライブにプッシュする前の事前チェック

約5分間の準備で、ほとんどのローカルからライブへのWordPressエラーを回避できます。

• ライブホストでSSLを有効にしてください。これはリストの中で最も価値の高い項目であり、最初に行うことが機能させる鍵です。
• ローカルツールとライブホストのPHPバージョンを比較し、一致させてください。
• インストールを開始する前に、ライブデータベースの認証情報を手元に用意してください。
• ライブURLを把握しておきましょう。サイトのアドレスはURLに合わせて変更されることを想定してください。
• 管理者ログイン情報を準備しておけば、リダイレクトループでサイトに入れなくなることを防げます。

移行自体の詳細な手順については、ローカルWordPressサイトをライブサーバーに移行する方法に関するガイドでプロセスを説明しています。この記事では、2つの環境の違いと、事前にそれらを解消する方法について説明します。

Duplicator Proは、ここで発生する問題の多くを解決するのに役立ちます。スタンドアロンインストーラーは、WordPressがインストールされていないサーバーにもサイトを移行でき、DupArchiveは抽出プロセスで問題を起こすことなく、大規模なローカルビルドを処理します。

よくある質問（FAQ）

ラップトップとサーバーの間のギャップ

この記事のすべての問題は同じ場所から来ています。ローカル環境とライブサーバーは、PHP、SSL、権限、またはサイト自体の名前について意見が異なります。移行は、それらの意見の相違が一斉に表面化する場所です。

これは、準備方法を変えるため、はっきりと繰り返す価値があります。移行は危険な部分ではありません。不一致が危険な部分です。

ローカルサイトをビルドする前に、ライブホストのPHPバージョンを確認し、SSL証明書を有効にしてください。デプロイする環境で開発すれば、この記事のほとんどはあなたには関係なくなります。

次のローンチの前に、戻る方法を用意しておく

公開初日に壊れるサイトは、午後の残念な出来事です。復旧できるクリーンなコピーがないまま壊れるサイトは、さらに悪いことです。

Duplicator Proは、150万以上のWordPressのプロフェッショナルに利用されており、サイトのバックアップ、移行、復元に使用されています。スタンドアロンインストーラーは、ローカルのビルドを空のサーバーに移動し、リカバリツールを使用すると、ローンチがうまくいかなかった場合でも復旧できます。

ついでに、これらの他のWordPressリソースも一見の価値があります。

• 8,000件以上のサポートチケットが明らかにするWordPress移行が失敗する理由
• WordPressのバックアップを破損させるもの：1,400件以上のサポートチケットから学ぶ教訓
• WordPress の移行チェックリスト完全版（開始から終了まで）
• WordPressウェブサイトを新しいホストに移動する方法
• バックアップからWordPressサイトを復元する方法