WordPressデータベースを移植可能でURLに依存しないようにするにはどうすればよいですか?


9

問題

多人数チーム環境でWordPressの開発に着手しようとしています。(同時に3人以上が同じコードベースで作業し、それぞれがローカルで開発しています)

私たちが協力してきた他のCMSでは、誰もが同じデータベースでインストールを指定しました。そのCMS /データベースがどのように機能したかにより、同じコンテンツを(異なるURLにある)インストールにフィードできるようになりました。同じデータベースで多くの問題はない(アップロードフォルダーを同期する必要がある場合を除く)

私の質問は、WordPressでこれと同じアプローチを使用できない理由と、これらの問題をどのように解決できるかということです。

例えば。WordPressの3つのコピーがすべて同じデータベースで実行されています。

http://dev.local/developer-a/
http://dev.local/developer-b/
http://dev.local/developer-c/

言うまでもなく、これはリリース前の開発環境でのみ行われることになります。

主な問題

  1. データベース内の特定のURL(wp_postsおよびwp_optionsそれと思われるテーブル)への参照
  2. ある人がプラグインをインストールすると、他の人はそれを持たず、データベースで同時実行の問題を引き起こします
  3. アップロードフォルダーの同期を維持する

現在のソリューション

現在、私は最初の問題の解決策の始まりを持っています。以下をmu-pluginsフォルダーのファイルに配置します。

コードは基本的に、URLのインスタンスを一意のトークンに置き換えることにより、データベースに出入りする投稿コンテンツをフィルタリングします。

<?php

define('PORTABILITY_TOKEN', '{_portable_}');

function portability_remove_home($content)
{
    $content = str_replace(get_option('home'), PORTABILITY_TOKEN, $content);

    return $content;
}

add_filter('content_save_pre', 'portability_remove_home');

function portability_add_home($content)
{
    $content = str_replace(PORTABILITY_TOKEN, get_option('home'), $content);

    return $content;
}

add_filter('the_content', 'portability_add_home');
add_filter('the_editor_content', 'portability_add_home');

WordPressがインストールされている環境を使用して、phpを介してhomeおよびsiteurlオプションを設定しました。(これも開発専用です)つまり、個々のインストールでは、WordPressの投稿コンテンツは、クライアントに到達するまでにそのURLで実行されているように見えます。

<?php
if (!defined('WP_HOME'))
{
    // define WP_HOME (aka url of install) based on environment.
    // IF THIS ISN'T WORKING, DEFINE IT EARLIER.
    define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . str_replace($_SERVER['DOCUMENT_ROOT'], '', dirname(__FILE__) ) );
}

if (!defined('WP_SITEURL'))
{
    // Assumes WordPress is in a separate directory called 'wp', relative to WP_HOME.
    // IF IT'S DIFFERENT, DEFINE IT EARLIER.
    define('WP_SITEURL', WP_HOME . '/wp');
}

2番目と3番目の問題は、適切なシンボリックリンクで解決できるようです(すべて同じマシンで開発されています)。

実際の質問

  1. とにかく、異なるURLの処理を改善できますか?データベースにURLがハードコード化されて見逃したものはありますか?

  2. シンボリックリンクで注意すべき落とし穴はありますか?

  3. 誰かが考えることができる他の問題はありますか?

これらの質問は非常に具体的であることがわかります。不明な点がある場合は、これについてコメントしてください。修正または明確にします。

ありがとう。

回答:


2

質問2に回答します。データベースの一部の値は、シリアル化された配列に格納されています。たとえば、URL文字列の長さが変更され、それがシリアル化された配列内にある場合、その文字列のインデックスを更新する必要があります。

このPHPスクリプトを使用し、シリアル化された配列のすべての値を更新するか、独自のスクリプトのコマンドラインから実行できます。


PHPスクリプトの方向を教えてくれて、遅れてしまいました。それは私が別のワードプレス関連のタスクで抱えていたいくつかの問題を解決しました。
ナビトロニック2012年

1

質問1:投稿コンテンツだけでなく、データベースに出入りするURLがさまざまな場所にあります。私は中にURLを見つけ*_postmeta*_comments*_options(あなたが定義されているものに加えて)。これは、プラグインアクティビティとカスタムメタフィールドアクティビティをカウントしていません。

質問2:便宜上、プラグインをシンボリックリンクすることもありますが、ほとんどの場合は機能します。時々それはしません。問題の原因となる正確な状況をお伝えすることはできませんが、Javascriptが要因のようです。

質問3:*_optionsどちらかと言えば、テーブルに問題があると思います。アクティブ化されたプラグインやアクティブなテーマなどのものがそこに保持され、他の多くの情報はかなりサイト固有です。


質問3のとおりです。これは主に、このテーブルにシリアル化された形式で格納されているものが原因であると考えられます。
navitronic 2012年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.