サブサイトを開発マルチサイトから本番マルチサイトに移行する方法

マルチサイトを使用して多数のサブサイトをローカルで開発し、準備ができたら運用環境に移動するための最良かつ最も安全な方法を探しています。

完全なマルチサイトインストールを最初のサブサイトに移行しました。ローカルサーバーで他のサイトを開発したいので、運用サーバーはそのままにしておきますが、明らかに完全な移行を再度行うことはできません。

解決策を探しましたが、見つかったすべてのことは、単一のサイトをマルチサイトに移動すること、またはその逆であり、「サブサイトをマルチサイトからマルチサイトに移動する」ことではありません。

設定、ウィジェットなど、すべてを保持したいと思います。

これはやや退屈な作業になる可能性がありますが、うまくいけば役に立ちます。ある環境から次の環境への変更が少ないほど、このプロセスの痛みは少なくなります。特に、ドメイン、サイトID、ファイルパスが同じである場合、このプロセスの負担は少なくなります。

この投稿は、データベース管理の知識があることを前提としています。フォーラムを検索し、データベーステーブルのエクスポートでサポートが必要な場合など、問題が発生しているステップに固有のスレッドを作成する必要があるため、完全なステップバイステップではありません。

最も重要なことは、何か問題が発生した場合に備えて、ローカル開発サイトと新しい場所の両方のデータベースとファイル全体をバックアップすることです。何かがうまくいかないことを期待してください。そうでない場合はうれしい驚きです。

テーマファイルの移動は非常に簡単です。テーマファイルをwp-content / themesディレクトリにアップロードし、通常どおりアクティブにします。これはすべてのブログがアクセスできる共有テーマだと思います。

プラグインファイルを新しい場所のwp-content / pluginsにアップロードします。まだアクティブにしないでください。

移行するブログ専用のコンテンツwp-content/blogs.dir/2/filesは、2がサイトIDであるようなディレクトリに配置されることに注意してください。このサイトIDを新しい場所で維持できる場合は、新しい場所に移行した後のデータベースの競合を最小限に抑えるのに役立ちます。それ以外の場合は、新しいパスを反映するようにデータベースを更新する必要があります。

移行しようとしているブログに関連するマルチサイトテーブルをエクスポートして、新しい場所にインポートする必要があります。移行するブログに関連するデータを格納するテーブルを編集する必要があります。これらのテーブルのプレフィックスが新しい場所で同じであることを確認してください。

たとえば、ブログのwp_blogsテーブルには、ブログID、サイトID、ドメイン、およびWordPressマルチサイトがブログを認識して操作できるようにするパスが含まれています。新しい場所を反映するために正しくなくなったものを編集しますが、変更する前にこの投稿の残りの部分を読んでください。

マルチサイトテーブルの概要を参照

転送するブログのWordPressとプラグインの設定を移行するには、すべてのプラグインをローカルで無効にしてから、プラグイン用のものを含め、サイト固有のテーブル（コーデックスリファレンス）をエクスポートする必要があります。これらのテーブルを新しい場所のデータベースにインポートします。

新しい場所で、インポートするテーブルと同じデータベースプレフィックスを使用していることを確認してください。プレフィックスには、ブログのサイトIDが含まれ、のようになりwp_2_options, wp_2_posts, wp_2_postmetaます。Lisa Sabin-WilsonによるWordPressマルチサイトの探索を
参照してください

私はあなたがphpmyAdminまたはターミナルでmysqldumpコマンドを使用してインポート/エクスポートする方法を知っていると仮定しています。これはこの投稿の範囲を少し超えていますが、役立つエクスポートの例を次に示します。

どのように特定のテーブル（複数可）をmysqldumpをしますか？（構文はより明確になるように少し編集されました。）：

mydbという名前のデータベースからテーブルt1、t2、およびt3をダンプする場合

mysqldump -u <username> -p <password> mydb t1 t2 t3 > mydb_tables.sql

新しいサイトでプラグインをアクティブにする前に、admin cpのパーマリンク設定に移動し、設定を保存してデータベースファイルを新しいサイトのURLに更新します。プラグインを有効にして、問題がないか確認してください。

発生する可能性のある1つの問題は、テーブルのデータのシリアル化です。

「[...]古いドメイン名または場所への参照はデータベースに残り、リンクまたはテーマの表示で問題を引き起こす可能性があります。

データベース全体を検索して置換してURLを変更すると、一部のテーマやウィジェットにマークされたURLの長さの値が格納されるため、データのシリアル化で問題が発生する可能性があります。 " ドメイン名またはURLが変化する

データのシリアル化は、プラグインに関連するデータベーステーブルでも競合を引き起こす可能性があることに注意してください。データベースに保存されているURLで手動検索と置換を実行するのではなく、前のコーデックスリンクで推奨されているデータベース検索と置換スクリプトを使用します。データベースにシリアル化のインスタンスが数個しかない場合は、phpMyAdminを使用して手動で編集するか、データベースを管理するための設定を変更できます。

発生する可能性のあるもう1つの問題は、データベーステーブルに格納されている不正なファイルパスを更新して、新しい場所を反映させる必要があることです。これは、プラグインの設計方法に応じて、メディアディレクトリまたはプラグインによって使用されるディレクトリの場合に当てはまります。この場合も、検索と置換スクリプトを使用して、ファイルパスの更新中にシリアル化の競合が発生しないようにする必要があります。または、テーブルを確認して手動で更新することもできます。

WordPressの組み込みのエクスポート機能とインポート機能を使用できませんか？次に、テーマをFTP経由でインストールから次のインストールに移動するだけです。それはかなり迅速に進み、インストール間で5分未満でサイトを移行できます。

User Syncronizationと呼ばれる気の利いたプラグインを使用してユーザー資格情報を同期できます。

まだ使用していませんが、ManageWPにはユーザーフレンドリーなデプロイおよびクローンツールがあり、既存のサイトから新しいサイトに移動できます。調べてみる価値はあります。