【WordPress】本番マルチサイトをローカル開発環境で表示・確認する方法

WordPress

開発環境でマルチサイト環境の本番WordPress表示させたい

通常のシングルサイト状態なら確認できる。

WordPress開発環境と本番環境にて、完全に同じファイルを使う方法
開発環境で本番環境を再現したいのだ開発していて、めんどくさいのは、ローカルの開発環境と本番環境で、同じソースで動くか確認することである。環境は勿論のこと、完全同じソースが使えないと面白くない。本番公開中サイトのソースを、完全にそのままローカ...
qooga.jb-jk.net

でもマルチサイトになると偽造しきれなくて、延々ループする。

「でも何とか、データ変更することなく、開発環境で見たい！」
て人のための対応方法

  1. 開発環境でマルチサイト環境の本番WordPress表示させたい
    1. マルチサイトネットワーク内の情報が欲しいだけの場合
    2. 昔の記事で設定した方へ「すいません」
    3. 完全偽造する方法はない可能性が高い
      1. 設定では、どうにもならなそう
  2. 本番環境を開発環境で見る方法
    1. 基本設定
    2. マルチサイト用の基本設定
    3. 別のブログIDを見る設定
    4. 管理画面を使う場合
    5. 注意事項
      1. プラグインはネットワークより個別

マルチサイトネットワーク内の情報が欲しいだけの場合

もし、ここまでの書き換えが必要なのではなく、
同じマルチサイトネットワーク内の情報が欲しいだけて場合はコチラ⇩

【WordPressマルチサイト攻略】別サイトの情報をスマートに呼び出す「横断取得」完全ガイド
せっかくWordPressをマルチサイトにしたのだから、情報リンク使いしないともったいない！WordPressマルチサイトの最大の利点は、単にサイトを複数持てることではない。「サイト間の壁を越えて、情報を自由に流通させられること」にある。「...
qooga.jb-jk.net

この記事の目的はあくまで、ローカル開発環境で本番WordPressを確認したい人向けなのですよ。

昔の記事で設定した方へ「すいません」

⇩昔も対応する記事書いたんですよ

WordPressマルチサイトでも、開発環境と本番環境にて、完全に同じファイルを使う方法
マルチサイト機能を使ってても、ローカル開発環境で本番WordPressを確認したい開発環境と本番環境で、rsyncしても問題ない環境を作る方法を、『WordPress開発環境と本番環境にて、完全に同じファイルを使う方法』にて、公開していた。...
qooga.jb-jk.net

でもね…
『WordPress MU Domain Mapping』なんて、もはや使いやしないのだ
現在はデフォルトであるからね、マルチサイト機能。

てか、旧やりかた記事、今読んだら、全然タイトルと内容が合ってなさすぎて、何が言いたいんだ感がすごい。
直したいけど、直したとこでもう使えないから良しとする。

完全偽造する方法はない可能性が高い

公式の機能で、マルチサイトの偽造は想定していない様子。

だから
開発環境のURLに偽造はできているけど
「そんなURLはwp_blogsにない！」
と延々新規サイトを作ろうとして、延々redirectをするわけです。

設定では、どうにもならなそう

DOMAIN_CURRENT_SITEやらBLOG_ID_CURRENT_SITEやら$wpなんつらやら
色々設定できるパラメータは変更してみたけど、全然できない。

「これもうWordPressのコアやDBアクセス部分を変えないと、無理じゃない？」状態

やろうとしてる人は他にもいるけど、コアやデータいじっとる⇩

Override WP_SITEURL and WP_HOME for WordPress Multisite
For doing local development on a WordPress site ( I was previously overriding the WP_SITEURL and WP_HOME values in wp-co...
stackoverflow.com

でもそんなリスクは犯したくないですよね？

マルチサイト状態で確認したいことがあるならどうしようもないんですけど
デザインやデータ、実際のプラグインの動き状況を見たりできればいい。
それだけなら別にシングルサイト状態で確認しても問題ないわけです。

というわけで、
シングルサイト偽造して確認する方法＝本番環境を開発環境で見る方法
として解説していきます。

本番環境を開発環境で見る方法

書き換える場所は wp-config.php のみ。

基本設定

シングルサイトと同じで

define('WP_HOME', 【WordPress アドレス (URL)】);
define('WP_SITEURL', 【サイトアドレス (URL)】);

をローカルのURLに書き換えます。

マルチサイト用の基本設定

『マルチサイト作るのに設定したdefine系』を消します。
⇩コレ系

define('WP_ALLOW_MULTISITE', true);
define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', false);
define('DOMAIN_CURRENT_SITE', 'wordpress.ne.jp');
define('PATH_CURRENT_SITE', '/');
define('SITE_ID_CURRENT_SITE', 1);
define('BLOG_ID_CURRENT_SITE', 1);

消さないでもfalseにはします。

define('WP_ALLOW_MULTISITE', false);
define('MULTISITE', false);

見ているドメインあたりで、if文作って分けたらよろしいかと。

データベースが開発環境からでもアクセスできるようになっていれば、これだけで読めるようになります。
SQLiteならファイル名を書き換えるとかね。

別のブログIDを見る設定

ブログIDに合わせて、プレフィックス(DBテーブルの頭に付ける文字)を書き換えます。

書き換える内容はこんな感じ。

$table_prefix = "【元々の$table_prefix】_【ブログID】_";

例えば、元々のプレフィックスがデフォルトの

$table_prefix = "wp_";

だった場合に、ブログID『2』に書き換えるとするなら

$table_prefix = "wp_2_";

管理画面を使う場合

プレフィックスとブログIDにあわせて、wp_usersとwp_usermetaのコピーを作る

プレフィックスが『wp_』、ブログIDが『2』の場合、

  • wp_usersをコピーしてwp_2_users
  • wp_usermetaをコピーしてwp_2_usermeta
ここが残念ポイントなんだけど、これらのテーブルが増えたとしても、マルチサイト状態の本番WordPressには影響しないので、ご容赦。

注意事項

滅多に起きないけど、開発によっては困るからメモ程度に。

プラグインはネットワークより個別

開発サイトで確認予定であるなら、ブログ毎にプラグインを有効にすること。

シングルサイト偽造した状態では、個別のプラグイン状態しか、理解しない。
ネットワークの有効状態は、無視することになる。

サイト毎にプラグインを有効＋ネットワークでプラグインを有効の『W有効』状態は、
通常の使用は問題ないが、
シングルサイト偽造した状態では、
プラグインは有効でありながら、isPluginActive()の判定にかからない謎現象もある。
マジ謎。

問題を起こさないためにも、ローカル偽造するなら『ブログ毎』にプラグインを有効にしてください。
逆にローカルで使いたくないプラグインは『ネットワークで有効』にしておくといいかも。

自分

ムダに深夜まで作業したうえに、2日かけちゃったい

コメント

タイトルとURLをコピーしました