警告:入ってくるテキストの壁..
@Rob、WPはチームでの作業に関しては地獄です。ただし、少しの作業 (およびいくつかのシンボリック リンク マジック) で、WP プロジェクトをセットアップして、テーマまたはプラグインの作業ファイルを WP コアとは別に配置できるようにすることができます。これの一部は WP の組み込みメカニズムを使用し、一部は SVN 外部 (ヒント) に関連しています。それはあなたの質問の範囲外なので、グーグルで検索させてください。
WP GUID に関する注意
警告: GUID を置き換えないでください。外部フィード リーダー用の WP GUID があります。フィード リーダーは GUID を使用して、コンテンツが最近のものかどうかを判断します。これを変更すると、基本的に、フィード内のすべてのエントリが新しいものであることを読者に伝えます (特に投稿の場合)。これにより、不要なレガシー コンテンツに多くの余分なオーバーヘッドが発生します。GUID は、ずっと前に UUID に変更されるべきだった従来の機能です。技術的には、GUID フィールドには何でも使用できますが、WP はパーマリンクを使用してそのフィールド (レガシー) に入力します。
GUID の変更が許容されるのは、コンテンツがまったく新しい wp プロジェクトの場合のみです。
あなたの質問に答えるには：
WP は、現在のドメインへの明示的な参照を DB の数十か所に保存します。これらの場所を追跡して変更するのは面倒です。本番環境にインポートする予定の *.sql ダンプ ファイルを手動で編集することは、最も避けたいことです。悪い開発慣行の匂いがするだけです。
これを回避するにはいくつかの方法がありますが、開発ライフサイクルがすでに進んでいる場合は、少し手間がかかります。最初のケースについて説明します。
ケース 1: プロジェクトの開始
プロジェクトを開始するときには、開発サンドボックスと DB が準備されている可能性があります。WP は既にインストールされている可能性が高いため、すべての意図と目的に対して本質的にクリーンです。
最初にやりたいことは、構成ファイルの動作を変更することです。ほとんどの人は標準wp-config.phpファイルを使用しています (チームの運用プロジェクトを超えて、それを編集する理由は実際にはありません)。ただし、開発者固有または環境固有の構成ファイルを含めるように、いくつかのロジックを使用してセットアップできます。例えば：
wp-config.php
switch( $current_environment )
{
case 'jack.local' : include( 'wp-config-jack.php' ) break; // Jack's sandbox
case 'jill.local' : include( 'wp-config-jill.php' ) break; // Jill's sandbox
default : ... break; // Staging & Production
}
次にやりたいことは、wp-config.phpファイルの通常の内容をwp-config-remote.phpステージング/プロダクションで使用するためにファイルに含めることです。次に、ファイルを編集して、wp-config-remote.php複数の環境 (ステージング、本番) で 1 つの構成ファイルを使用できるようにします。必要なのは or ブロックだけですif(...)。switch(...)
if( (strpos( $_SERVER[ "HTTP_HOST" ], "localhost" ) !== false) || (strpos( $_SERVER[ "HTTP_HOST" ], "local" ) !== false) )
(その条件を記述するより良い方法があります...これは単なる大雑把な例です。)
各リモート環境に固有のすべての WP 設定を構成します。願わくば、これをソース管理リポジトリにチェックインしてください。
これにより、基本的には、チームが環境に固有の構成設定を行えるようになり、各リモート環境の設定を 1回チェックインできるようになります。
2 番目に行うことは、ドメイン固有のリンクを傍受してフィルター処理するメカニズムを構築することです。このメカニズムの背後にある意図は、現在のドメインへの参照をトークン/プレースホルダーに置き換えることです。ここでこれを行う手法の概要を説明しました: http://www.farfromfearless.com/2010/09/07/url-token-replacement-techniques-for-wordpress-3-0/
基本的には、コンテンツが DB に送信される前、およびコンテンツがページにレンダリングされる前に、コンテンツに作用するフィルターを作成することになります。この手法は透過的で、通常の編集作業には影響しません。エディターでコンテンツを作成したり、他のページ、投稿、画像などを参照したりでき、さまざまな環境で編集しているときに問題なく表示されます。
最近のプロジェクトでは、このすべてと他のいくつかの WP の「正規化」機能を、設定して忘れる単一のブートストラップ プラグインにラップしました。
ケース 2: プロジェクト進行中
さて、あなたの場合、開発ライフサイクルはさらに進んでいます。これらのドメイン参照を置き換えるには多少の作業が必要ですが、上記で概説した手順に従えば、これを行う必要があるのは 1 回だけです。上記のリンクは、そのジョブを実行するために必要な SQL を提供します。マルチサイト環境では、作成したすべての「サブサイト」に対してこれを行う必要があることに注意することが重要です。
DB を更新したら、CASE 1の手順を実装することをお勧めします。これにより、手順を再度繰り返す必要がなくなります。
おまけ: コンテンツの同期
コンテンツの同期は面倒です。私が最近のプロジェクトで行ったことは、クライアントがステージング サーバーで動作し、変更を本番環境に昇格させることです。そのため、ダウンストリームをサンドボックスに同期する必要があります。ステージング DB から特定のコンテンツ テーブルのコピーをダンプし、それらをサンドボックス DB にインポートするシェル スクリプトを記述します (実質的にコンテンツ テーブルを置き換えます)。ドメイン トークン置換手法の利点を確認できるはずです。
ソース管理にチェックインされていないイメージ (クライアント イメージなど) は、S3 バケットなどの共通の場所にプッシュする必要があります。それを支援する WP プラグインがあります。これにより、環境間でアセットを同期する時間を大幅に節約できます。
これがお役に立てば幸いです。そうでない場合は、常に SilverStripe があります ;)