MU移行でWordPressマルチサイト移行を合理化する方法

公開: 2022-03-10

クイックサマリー↬開発者がマルチサイトインスタンス間でサイトを移行するのに役立つWP-CLIコマンドであるMU-Migrationツールの紹介。マルチサイトの移行にはさまざまな技術的な複雑さがあり、このツールはそれらを軽減するのに役立ちます。

スタンドアロンのWordPressサイトをサイトネットワーク（または「マルチサイト」）環境に移行することは、退屈でトリッキーな作業ですが、その逆も当てはまります。 WordPress Importerは、小規模で単純なサイトでは十分に機能しますが、改善の余地があります。コンテンツはエクスポートされますが、ウィジェットとカスタマイザーの構成、プラグイン、サイト設定などのサイト構成データはエクスポートされません。インポーターはまた、大量のコンテンツを処理するのに苦労しています。この記事では、WP-CLIプラグインであるMU-Migrationを使用して、このタイプの移行を合理化する方法を学習します。

マルチサイトを理解する

WordPressマルチサイトを使用すると、同じWordPressインストール内で複数のWebサイトを実行できます。多くの場合、「マルチサイトネットワーク」と呼ばれます。 WordPress.comは、おそらくマルチサイトネットワークの最大の例であり、同じWordPressインスタンス内で数千のサイトを実行しています。

WordPressマルチサイトは、いくつかのユースケースに最適です。その一部には次のものが含まれます。

クライアントには複数のプロパティがある場合があり、すべてのサイトを一意のWordPressインストールに統合して、単一のドメインを共有することが理にかなっている場合がありますが、これに限定されません。
セットアップが完了すると、新しいサイトを立ち上げ、ネットワークですでに利用可能なテーマとプラグインを活用するためのシンプルで簡単なプロセスです。

マルチサイトがどのように機能するかを深く理解することはこの記事の範囲を超えていますが、次のリンクを確認できます。

「CreateANetwork」、Codex、WordPress.org
「WordPressマルチサイト：実用的な機能と方法」、Kevin Leary、Smashing Magazine

ジャンプした後もっと！以下を読み続けてください↓

課題を理解する

シングルサイトとWordPressマルチサイトの構造の違いは非常に合理的です。マルチサイトでは、すべてのサイトで共有されるユーザーのテーブル（ wp_user ）を除いて、各サブサイトは独自のデータベーステーブルのセットを取得します。これがWordPressで機能する方法は、テーブルの各サブサイトセットに、各テーブル名にサイトのIDが追加されることです（ wp_X_posts 、 wp_X_postmeta 、 wp_X_options ）。

このデータベース構造自体は、すでにいくつかの複雑さをもたらしています。たとえば、サブサイトをマルチサイトからシングルインストールにどのように移行しますか？もちろん、データベースを単一のインストールにエクスポートおよびインポートするだけでは不十分です。テーブル名は異なります。エクスポートされた.sqlファイルのテーブルの名前を変更するか、 ALTER TABLE SQLクエリを使用してインポート後にテーブルの名前を変更する必要があります。反対の方法でも同じことが言えます。単一のサイトをマルチサイトにインポートする場合は、テーブルプレフィックスも更新する必要があります。仕事が多すぎるようですね。

マルチサイトのユーザーテーブルはグローバルです。つまり、マルチサイトグローバルユーザーテーブルを完全に上書きするため、単一サイトからユーザーテーブルをインポートすることはできません。逆の場合、WordPressからサブサイトを抽出して単一のサイトにインポートすると、移行対象のサブサイトに属していないユーザーも含め、ネットワークのすべてのユーザーを引き継ぐことになります。さらに、サブサイトをあるマルチサイトから別のマルチサイトに移行する場合、ユーザーのテーブルのエクスポートは完全にテーブルから外れます。

最善の解決策は、ユーザーを個別にエクスポートすることですが、別の問題が発生します。ユーザーがインポートされると、異なるIDが取得されます。この問題を解決するには、新しいユーザーのIDを追跡し、マッピングテーブルを作成し、マッピングテーブルを使用してWordPressのユーザーIDへのすべての参照を更新する必要があります。繰り返しますが、作業が多すぎますよね？

これらは、このような移行を処理するときに直面する可能性のある課題の2つの例にすぎません。アップロードフォルダを適切な場所に移動したり、サイトIDを参照するデータベース内のレコードを移行したりするなど、他にも注意が必要な小さなことがたくさんあります。

MUに会う-移行

MU-Migrationは、いくつかのクライアント移行に取り組んでいる間に作成したWP-CLIプラグインであり、後で10upによってオープンソース化されています。サイトを単一のWordPressサイトからマルチサイトインスタンスに（またはその逆に）移動するプロセスを合理化するために考案されました。基本的にすべてをZIPパッケージにエクスポートし、これを使用して目的のWordPressインストールでサイトをインポートできます。

これは、サイトのコンテンツとオプションでテーマ、プラグインをエクスポートし、別のWordPressインストールに簡単にインポートできるzipパッケージにフォルダーをアップロードすることで機能します。 MU-Migrationを使用する場合、移行の基本的な技術的詳細について心配する必要はありません。それはあなたのためにそれらすべてを単に処理するので、あなたは重要なことに集中することができます：あなたのクライアントに成功した移行を提供すること。

WP-CLIとMU-Migrationのインストール

MU-Migrationを使用するには、最初に公式のWordPressコマンドラインツールであるWP-CLIをインストールする必要があります。 WP-CLIのインストールは、サーバーで以下のコマンドを実行するのと同じくらい簡単です。

 $ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar $ chmod +x wp-cli.phar $ sudo mv wp-cli.phar /usr/local/bin/wp

これらの手順を実行した後、WordPressルートディレクトリ内にいる限り、WordPressインストールからwpと入力するだけでWP-CLIを実行できるようになります。

たとえば、WordPressインストールフォルダーで、次のコマンドを実行してみてください。

 $ wp theme status

これは単純なコマンドであり、使用可能なすべてのテーマを一覧表示し、現在アクティブなテーマを強調表示します。

最後に、MU-Migrationをインストールするには、 package installコマンドを利用できます。次のコマンドを使用して、MU-MigrationをWP-CLIプラグインとしてダウンロードしてインストールします。

 $ wp package install 10up/mu-migration

単純な移行の実行

MU-Migrationの使用法は非常に簡単です。最初のシナリオでは、単一のWordPressサイトをWordPressマルチサイトインストールに移動します。

単一サイトのエクスポート

まず、単一のサイトをエクスポートすることから始めます。そのためには、 exportallコマンドを使用する必要があります。

 $ wp mu-migration export all single-site.zip --themes --plugins --uploads

上記のコマンドは、サイト全体をZIPパッケージにエクスポートします。フラグ--themes 、 --plugins 、および--uploadsはオプションであり、現在のテーマ、すべてのプラグイン、およびアップロードフォルダーがそれぞれエクスポートに含まれます。サイトのサイズによっては、プロセスが完了するまでに時間がかかる場合がありますが、ほとんどのサイトでは、エクスポートプロセスに数分以上かかることはありません。

完了すると、サイトのすべてのデータ、テーマ、プラグイン、およびアップロードディレクトリを含むsingle-site.zipというファイルが作成されます。次のステップは、WordPressマルチサイトが存在するサーバーに移動することです。お好みのSFTPクライアントまたはrsyncなどのより堅牢なソリューションを使用できます。

シングルサイトのマルチサイトへのインポート

マルチサイトサーバーにエクスポートされたファイルを使用する場合は、WordPressマルチサイトディレクトリからimportコマンドを使用するだけです。言うまでもなく、WP-CLIとMU-Migrationの両方を移行先サーバーにもインストールする必要があります。

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site

上記のコマンドは、 single-site.zipファイルを取得して抽出し、すべてをマルチサイトにインポートします。ネットワークに新しいサブサイトが作成されます。 --new_urlパラメーターはオプションです。 MU-Migrationに検索を実行するように指示し、エクスポートされたサイトのサイトURLのすべてのオカレンスを指定されたものに置き換えるために置き換えます。このパラメーターは、移行にURLの変更が含まれる場合、ローカルにインポートする場合、またはステージング環境でさえも便利です。

インポートプロセスは通常時間がかかり、インポートするサイトのサイズによって異なりますが、心配しないでください。MU-Migrationは、移行の実行中に最新の状態を維持します。プロセスが終了すると、MU-Migrationはインポートされたサイトの最終的なURLを通知します。サーバーで実行されているすべてのキャッシュレイヤー、特にMemcacheまたはRedisをフラッシュすることを強くお勧めします。

移行の再実行

移行を行う場合、最終的な移行を実行する前にテストを行う目的で最初にドライランを実行するのが一般的です。これは通常、別のエクスポートを実行し、移行先のマルチサイトインストールで再インポートすることを意味します。ただし、最初の移行の例では、MU-Migrationは、その上に単一のサイトをインポートするために、ネットワーク内に新しいサブサイトを作成したことに注意してください。まったく同じコマンドを再度実行すると、別のサブサイトが作成されますが、これは私たちが期待するものとはまったく異なります。

幸い、 blog_idを指定することは可能です。これは、MU-Migrationに指定されたblog_idでサブサイトをオーバーライドするように指示します。たとえば、前のインポートコマンドでIDが2のサブサイトが作成され、移行を再実行するとします。次のことができます。

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site --blog_id=2

blog_idがわからない場合は、ネットワーク管理者設定から、または$ wp site listを実行して取得できます。

マルチサイトインストールからのサブサイトの抽出

MU-Migrationは、マルチサイトインストールからサブサイトを抽出し、それを別のマルチサイトまたは単一サイトにインポートすることもサポートしています。

これらの2つのシナリオでは、単一サイトからではなく、マルチサイトインストールからexportコマンドを実行します。これは、エクスポートするサブサイトを指定する方法が必要であることを意味します。これを行うには、 --blog_idパラメーターをexportコマンドに渡す必要があります。

 $ wp mu-migration export all subsite-3.zip --themes --plugins --uploads --blog_id=3

この例では、IDが3に等しいサブサイトをエクスポートしています。これにより、別のマルチサイトまたは単一サイトにインポートする準備ができているZIPファイルが作成されます。シングルサイトとマルチサイトにインポートするコマンドはまったく同じです。MU-Migrationは、マルチサイトで実行されているかどうかを検出し、それに合わせて自動的に調整します。ちなみに、別のマルチサイトインスタンスにインポートする場合は、 --blog_idパラメーターを指定して既存のサブサイトをオーバーライドすることもできます。

 $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ]

大規模な移行を実行するためのヒント

前の例は小規模から中規模の移行では非常にうまく機能しますが、大規模なサイトをマルチサイトに移行したり、マルチサイトから移行したりするには、かなりの時間がかかる場合があります。このセクションでは、エンタープライズのような移行を行う際に学んだ教訓をいくつか紹介します。

移行計画を作成する

多くの場合、データの移行が必要ですが、多くのプロジェクトでは無視されています。移行は面倒で複雑になる可能性がありますが、適切に計画すれば痛みはありません。移行計画の作成は、移行プロジェクトの最初のステップである必要があります。

一般的な移行計画には、次のようなものが含まれます。

移行が本番編集プロセスに与える影響（つまり、コンテンツのフリーズ、移行要件の違い）。
移行はどのくらいの期間実行されると予想されますか？
バックアップはどのように復元されますか？失敗した移行はどのように処理されますか？
エクスポートプロセスはサイトのパフォーマンスにどのように影響しますか？多くのサイトでは、ピーク時にデータベースをエクスポートする余裕がありません。

一般的な経験則として、移行は可能な限りシームレスである必要があります。理想的には、起動時にすべての重労働がすでに完了しているはずであり、厳密に必要な手順のみを実行する必要があります。つまり、間違いやQAを修正する余地があるため、実際のリリース日の前にできる限りすべてを移行する必要があります。これが新しいサイトビルドであり、データを移行する場合、コンテンツのフリーズウィンドウを利用して、コンテンツを事前に移動できることがよくあります。可能であれば、戦略を使用してコンテンツを段階的に移動することもできます。この手法の例については、次のセクションを確認してください。

何度も無視されていますが、適切な移行計画により、移行に関するさまざまな問題を回避できます。予期しない状況によって移行が失敗することのないように、事前に計画してください。移行の計画に関するより詳細な議論については、10upのベストプラクティスの移行セクションを確認することをお勧めします。

Rsyncを使用してアップロードを段階的にコピーする

大規模なサイトのアップロードフォルダは非常に大きくなる可能性があり、後で抽出するためにそれをZIPファイルに圧縮することが常に最良かつ最速のソリューションであるとは限りません。アップロードフォルダを宛先サーバーにコピーする方法は他にもいくつかあります。企業のような移行に一般的に使用されるツールはrsyncです。これは、標準のSFTPソリューションを使用するよりも高速にサーバー間でファイルを転送でき、さらに、転送を一時停止および復元できます。すでに転送されたものを追跡します。つまり、ファイルを段階的に同期できます。たとえば、実際の移行の数日前にファイルの同期を開始して、時間を購入することができます。次に、移行日に、ファイルを同期して、最後の同期以降に追加されたすべてのものが移行先サーバーに転送されることを確認するだけです。

このアプローチの唯一の注意点は、マルチサイトのアップロードフォルダの構造がわずかに異なるため、アップロードのサブディレクトリを手動で適切な場所に移動する必要があることです。各サイトには、名前がサイトのIDである独自のサブフォルダがあります。。

最後の例として、大規模な単一サイトをマルチサイトインスタンスに移行する方法を見てみましょう。まず、単一のサイトをZIPパッケージにエクスポートし、宛先サーバーでドライランテストを実行します。その時点では、ドメインはまだ古いサーバーを指しているため、サイトには誰もアクセスできません。つまり、移行をテストするために、ホストのファイルを新しいサーバーに安全に向けることができます。また、宛先サイトで[サイトアクセスの制限]などのプラグインを有効にして、パブリックにアクセスできないようにすることもできます。

ドライランテストでは、移行予定日の数日前または数週間前にサイトをエクスポートしてテストし、プロセスにかかる時間を把握します。アップロードフォルダは含まれていないことに注意してください。

最初にドライランを行う

常に最初にドライランを実行してください。理想的には、ドライランは実際のサーバーまたは同様のサーバースタックを備えたステージング環境で実行する必要があります。

--mysql-single-transactionフラグの使用を検討してください

importコマンドは、SQLエクスポートを単一のトランザクションにラップしてインポートからのすべての変更を一度にコミットする--mysql-single-transactionフラグもサポートし、特にクラスター化されたMySQL環境で書き込みがデータベースサーバーを圧倒するのを防ぎます。

 $ cd /path/to/wordpress $ wp mu-migration export all site.zip --themes --plugins

rsyncを使用すると、生成されたエクスポートファイルを簡単に転送できます。

 $ rsync -aP site.zip [email protected]:/var/www/multisite/

次に、宛先サーバーでimportコマンドを実行します。

 $ ssh [email protected] $ cd /var/www/multisite $ wp mu-migration import all site.zip

ここで、新しく作成されたサブサイトのblog_idが何であるかを知る必要があります。次のコマンドを実行して、その情報を取得できます。

$ wpサイトリスト
blog_id	url	最終更新	登録済み
1	https://multisite.com/	2017-09-09 20:59:31	2016-11-23 21:59:34
2	https://siglesite.com/	2017-06-21 18:30:09	2017-04-25 13:07:46

上記のコマンドの出力から、サイトがID 2でインポートされていることがわかりますrsyncを使用してuploadsフォルダーを適切に移動するには、これが必要です。シングルサイトサーバーから、次のコマンドを実行します。

 $ rsync -azP wp-content/uploads/ [email protected]:/var/www/multisite/wp-content/uploads/sites/2/

上記のコマンドは、アップロードフォルダー全体をマルチサイトインストールの適切な場所にコピーします。この場所は、sitesフォルダーの下にあり、名前がサイトのID（この場合は2）であるフォルダー内にあります。この時点で、ホストのファイルを編集して、シングルサイトドメインがマルチサイトサーバーを指すようにすることができます。次に、移行が期待どおりに機能することを確認するために、いくつかのテストを実行できます。

最終的な移行では、 --blog_id=2をimportコマンドに渡すことを除いて、すべてが同じになります。

 $ wp mu-migration import all site.zip --blog_id=2

また、利点として、 rsyncは最後の同期以降に変更または追加されたファイルのみを転送するため、アップロードの同期がはるかに高速に行われます。

結論

マルチサイトへの移行またはマルチサイトからの移行は困難であり、この記事で紹介するツールは、いくつかのCLIコマンドの実行を減らすことで、移行プロセス全体を簡素化します。 MU-Migrationは、1年以上にわたって本番環境で積極的に使用されており、完全にオープンソースのプロジェクトです。プラグインはGithubで開発されており、プルリクエストは大歓迎です！