サードレベルドメインでワードプレスネットワークを設定する


11

WordPressネットワークインストールのセットアップを検討してきました。目的のドメインレイアウトがうまく収まらないところまで、すべてが順調に進んでいます。

次のようなレイアウトにしたいと思います。

blog。*。stackexchange.com

たとえば、ネットワーク内に次のような複数のサイトを配置したいとします。

blog.wordpress.stackexchange.com
blog.apple.stackexchange.com
blog。$ site.stackexchange.com

これをいくつかの創造的な書き換えルールと手動のDNS介入で機能させることができると思いますが、DNS以外のすべての作成を他の誰かに引き渡すことができる設定が欲しいです(私たちはすでに自動的にプロセスを持っています) DNSで必要なすべてのサブドメインを作成する)

私が遊んだり読んだりすると、WPは本当にサイトを次のレベルのドメインにしたいので、上の例では、メインのWPブログをstackexchange.comに置き、ネットワークブログをwordpress.stackexchange.comに置きます。

私の望ましい効果を達成する方法はありますか、それともblog.stackexchange.com/$siteを実行するルートに進むべきですか?


2
創造的な書き換えルールと手動のDNS介入を使用する必要があると確信しています。また、これは仕様によるものであるため、DNS以外のすべての作成を引き渡すことができないので、<del>私</ del> <ins>他の誰か</ ins> ... ホイッスル </皮肉>(:
レベッカチェルノフ2011年

ZypherがSEを維持することについて心配する時間を増やし、コミュニティブログを探す時間を短縮できるように、誰かがステップバイステップガイドを手に入れてくれることを期待して、賞金を追加しました。
2011年

回答:


3

これにはドメインマッパープラグインを使用できます。欠点は、各サブブログを手動で構成する必要があることです。


興味深いことに、リダイレクトを行うのか、それとも単にコンテンツを提供するのか?私が尋ねようとしていることは、エンドユーザーのアドレスバーが変更されることでしょうか。
Zypher 2011年

@Zypherいいえ、コンテンツを提供するだけです。
誰も

1
プラグインを使用するためのチュートリアル:ottopress.com/2010/…重要:WPをインストールしてプラグインをアクティブにした後、このインポートデータまたはシステムを移行した後、問題はありません。ブログがドメインマッピングの前に存続した後で、このプラグインを追加するのはそれほど簡単ではありません。また、WPバックエンドでの作業を少し簡単にする他のプラグインも提供します。wordpress.org/extend/plugins/networks-for-wordpress
bueltge

選択肢がないため、+ 150担当者がいます。
2011年

1

これは、カスタマイズされたsunrise.phpファイルを使用して行うことができます。これは基本的にドメインマッピングプラグインの動作方法ですが、かなりフロントエンドを配置します。カスタムの場合、基本的に同じことを行う単純なPHPを作成できます。

マルチサイトの本質は、どのサイトにサービスを提供するかを理解することです。ドメインマッピングプラグインは、wp_domain_mappingテーブルを作成し、そこに情報を格納することでこれを行います。したがって、xxx​​.comに対する要求を受け取ると、そのテーブルを調べて、それがblog_id 123に対応していることを確認します。

まず、WordPressセットアップを作成し、マルチサイトにします。それが実際にどこにあるかは関係ありません。なぜならすべてを変更するからです。簡単にするために、blog.stackexchange.comに配置して、サブディレクトリタイプのサイトにします(これらの方が簡単です)。作成されるサブディレクトリはおそらくスラッグです。/ wordpress、/ apple、/ whatever。

つまり、最初に、blog.stackexchange.com / wordpressで実際に公開しています。これをステージング環境と考えてください。各サイトを作成するとき、マッピングをオンにすることを決定するまで、ここで何かを行うことができます。

プラグインなしで自分でドメインマッピングを行うには、次のようにします。

ステップ1:define( 'SUNRISE', 'on' );wp-config.phpファイルの先頭に追加します。

ステップ2:wp-contentディレクトリにsunrise.phpファイルを作成します。<?phpまずは上部に置きます。

ステップ3:sunrise.phpファイルで、ロードするサイトを決定するためのロジックになります。

$_SERVER[ 'HTTP_HOST' ]変数に基づいてこれを行います。その方法は簡単です。ただし、やりたいことはあります。検索する正規表現を作成'/blog\.(.*)\.stackexchange\.com/'し、データベースでそのビットを検索するだけの場合は、それを行うことができます。

ここでは「サブディレクトリ」と同じスラッグを使用しているため、個別のテーブルは必要ありません。メインのwp_blogsテーブルを調べるだけで、必要なサイトを見つけることができます。これに似たもの:

$current_blog = $wpdb->get_var( "SELECT blog_id FROM {$wpdb->blogs} WHERE path = '/wordpress/' LIMIT 1" );

$ current_blogを取得したら、次のコードが必要です。

$current_blog->domain = $_SERVER[ 'HTTP_HOST' ];
$current_blog->path = '/';
$blog_id = $current_blog->blog_id;
$site_id = $current_blog->site_id;
$current_site = $wpdb->get_row( "SELECT * from {$wpdb->site} WHERE id = '{$current_blog->site_id}' LIMIT 0,1" );
$current_site->blog_id = $current_blog->blog_id;

これにより、WordPressのMU関数でグローバル変数を実行する代わりに、$ current_blogおよび$ current_siteグローバル変数が事前定義されます。

これは、サイトを起動して機能させるには十分です(DNSにポイントさせ、仮想ホスティングのものを整理した後)。ただし、HTMLコードで使用されるほとんどの静的URLは、依然としてblog.stackexchange.comをポイントします。 / wordpress、それがサイトが実際にある場所だからです。また、Canonical URL関数はおそらくURLを気に入らず、リダイレクトします。

これらの問題を解決するには、サイトに関連付けられているURLのいくつかを事前に定義することもできます。WP_SITEURLやWP_HOMEなど。また、WP_CONTENT_URL、WP_PLUGIN_URL、およびWPMU_PLUGIN_URL。これにより、調整されるURLのほとんどのケースがカバーされます。

最後に、「COOKIE_DOMAIN」を設定します。ログインを全体で共有したいと思うので、それをstackexchange.comに設定できます。共有ログインにしたくない場合はさらに高く設定できます。

通常のstackexchangeログインシステムをWordPressに統合することについて話したい場合は、私もその質問に答えることができますが、答えについてはもう少し詳しく説明します。:)

これについてさらにサポートが必要な場合は、遠慮なくメールでお問い合わせください。喜んでお手伝いします:wordpress.orgのオットー。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.