WordPressでマルチドメインサイトを運営する

WordPress 6.1.1環境でマルチドメインサイト運営するまでの設定備忘録である。

経緯

WordPressにはマルチサイトモードがあり、公式機能で複数のサイトを運営できる。

デフォルトでは1つのサイトを運営するのみだが、マルチサイトモードを有効化すると「ネットワーク」を作成出来る。そのネットワークの下に管理・運営したいサイト一つ一つを作成して運営していこうという流れになるのだが、この運営方法の解説が曲者。

マルチサイトモードで『サブサイトやサブディレクトリでの複数ドメイン利用は可能』とあるが、『マルチドメインサイトの運営は可能』との記載は見つからないのだ。

運営方法種別URLの例判断
サブドメインhttps://example.com/
https://sub.example.com/
実現可能
サブディレクトリhttps://example.com/apple/
https://example.com/orange/
実現可能
マルチドメインサイトhttps://example.com/
https://example.jp/
記載なし
表1.運営方法別サポート状況一覧

具体的なURL例を挙げれば上記「表1」の通り。

実際にマルチドメインサイトで利用を試みても、サブドメイン情報が固定で載るため『やはりマルチドメインサイトには対応していないな』で諦めがちだ。しかし編集すればなんとかなる。

設定フロー

  1. マルチサイトモード有効化
  2. ネットワーク作成
  3. WEBサーバー設定
  4. サイト設定

1.マルチサイトモード有効化

wp-config.php の90行目辺り、define( ‘WP_DEBUG’, false ); の後ろ辺りに以下記述を追加

define( 'WP_ALLOW_MULTISITE', true );

2.ネットワーク作成

WordPress管理画面のメニュー「ツール」配下「サイトネットワークの設置」項目が増えるので遷移。

「サイトネットワーク名」に運営するサイト群の総称、「サイトネットワーク管理者のメールアドレス」に管理者メールアドレスを入力し「インストール」でネットワーク作成は完了する。

3.WEBサーバー設定

サイト設定追加後にアクセス出来るように、DNS / WEBサーバー / WordPress設定を変更する

※元々うまくアクセス出来るよう設定してあるものは省略して良い

DNS

example.jp を追加する場合、 A・AAAA・CNAMEレコードを追加しWordPressを載せたサーバーへアクセス出来るようにする

WEBサーバー

apache ならば Virtual Host 設定追加、 nginx であれば server 設定を追加するイメージ。ようは、WEBサーバーに設定したいドメイン名でアクセス出来るようにWEBサーバー設定を変更すれば良い。

WordPress設定

「2.ネットワークの作成」のインストール後に表示される wp-config.php 設定事項+αを define( ‘WP_ALLOW_MULTISITE’, true ); の行に続けて挿入する。

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
define( 'DOMAIN_CURRENT_SITE', 'example.com' );
define( 'PATH_CURRENT_SITE', '/article/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] );

注意事項として、一部設定は環境により異なる。

  • SUBDOMAIN_INSTALL は false の場合も必ず true に変えて記述
  • DOMAIN_CURRENT_SITE は最初にインストールしたドメイン名が入っていれば良い
  • PATH_CURRENT_SITE はWordPressをDocumentRootにインストールした場合は / となり、サブディレクトリなら上述の /article/ のようにWordPressインストールフォルダを指定してあれば良い
  • SITE_ID_*, BLOG_ID_* は固定項目なのでコピペで良い
  • どこから来たのか+α。define(‘COOKIE_DOMAIN’, $_SERVER[‘HTTP_HOST’] ); は各サイトでのログインを確立するには必要なので深い決め・厳密な考慮がなければとりあえず入れておくこと

4.サイト設定

WordPress管理画面上部メニュー『参加サイト→サイトネットワーク管理→サイト』を辿る

図2.サイトを追加画面

サイト追加画面ではサイトアドレスに最初に登録した .example.com が自動で付与される。そのまま「サイトを追加」し、後で編集するのがみそだ。

再度WordPress管理画面上部メニュー『参加サイト→サイトネットワーク管理→サイト』を辿り、追加したサイトのURLにカーソルを合わせると『編集』メニューが表示されるので遷移する。

図3.サイトの編集画面

ここで自由に編集出来るので、実際にアクセスしたいURLを設定する

確認

ここまで設定出来れば、追加したURLへアクセス出来るか確認。

ネットワークからテーマを追加⇒有効化し、一部のサイトのみでテーマを適用、更にそのサイトのみに投稿すれば、投稿内容もテーマも異なる別々のサイトを運用していると実感出来るはずだ。

ノーマライズ(Normalize)とカノニカライズ(Canonicalize)の違い

ノーマライズ(Normalize)とカノニカライズ(Canonicalize)の違いをまとめた。両方とも数学・コンピュータサイエンスの世界では正規化と翻訳され、構造の標準化・簡易化を意味するが、概念・処理内容は異なる。

※音楽に対するNormalizeは音の大きさを合わせること。これは毛色が異なる処理のため対象外とする

結論

Normalizeのゴールは項目内部での冗長削減である。

対して、Canonicalizeのゴールは項目間での横断的な比較体制の確立である。項目間に相違ないか確認できるよう表記を統一すると言っても良い。Normalizeにある冗長削減は必須でないが、Normalizeにない項目間比較のためのユニーク制約を含む文脈的な対応となる。

シンプルな例でイメージを掴む

数式の例:

  • Y = 32 + 2X + 8a + 4
  • 32 -2x + y = 8b+4

これら二つの数式をNormalize(冗長削減)すると、それぞれ『Y=36+2X+8a』、『28-2x+y=8b』に出来る。「同類項はまとめられるし、半角スペースは表現の無駄だから消して冗長を削減しよう」という話である。

Canonicalizeは目的によって実施事項が揺れる。

同じ表記にして、項目間に違いがあるか、同じ項目のことを表しているかを明らかにするのがCanonicalizeのゴールだから、式の目的により『同じ項目』の定義が変わってくる。

字ずらが違ったら別のもの扱いしたい:

両方の式がCanonicalize済みの状態。完全一致しないから、二つの式を比較出来て両者に相違ありと機械的に判断できる。

項目を維持した状態で比較したい:

『変数を昇順、定数を昇順(a, bは数値よりも先に記載)、末尾は = 0 で終える』と表記のルールを決めれば『-2X + Y -8a – 32 – 4 = 0』、『-2x + y – 8b + 32 – 4 = 0』にCanonicalize出来る。統一した表記方法になっているから二つの式を比較出来て大文字X, 小文字xの差により両者に相違ありと機械的に判断出来る。

簡素化した式に相違ないか比較したい:

大文字小文字に意味がなく、定数のa, b, c もただの表記ゆれというなら二つの式は『-2x + y -8a – 36 = 0』、『-2x + y – 8a + 28 = 0』にCanonicalize出来る。統一した表記方法になっているから二つの式を比較出来て-36と28の差により両者に相違ありと機械的に判断出来る。

URLの例:

  • /home/canonical/shortcut/test/url/
  • /hoge/../test/url/
  • /test/url/index.html
  • /test/url/
  • /test/url

※shortcut は /test へのシンボリックリンクとする、index.html はDirectoryIndex設定済みする。

Normalizeすると、二つ目は『/test/url/』にNormalize(冗長削減)出来る

対して、末尾スラッシュありのURLにCanonicalizeすると5項目ともすべて /test/url/ に置き換えられ、同一の基準でURLを比較できる。

※例では静的URLのみを取り扱ったが、#での見出し有の場合や?でのクエリありの場合、更にそのヴァリエーションとして ?hoge=a&fuga=b、?fuga=b&hoge=a、?hoge=a&hoge=aa&fuga=bなんかも取り扱ってみるとよりCanonicalURLの学びになる

※一つのサーバー上でのURLを取り扱ったが、複数サーバーの存在を考慮してURLをCanonicaizeするならドメイン名/ホスト名も含めて考えることとなる

XMLの例:

  • <record data1=”x” data2=”y” />
  • <record data2=”y” data1=”x1″></record>

Normalizeすると二つ目は<record data2=”y” data1=”x” />に出来る。

『要素(data1, data2)を昇順に並べる』とルール化してCanonicalizeすると二つ目は<record data1=”x1” data2=”y” />となり、表記を統一したので内容が同じか比較しやすくなった。data1の値に相違があるため異なる内容を表すと比較出来る状態となった。

歴史

数学世界ではCanonicalizeは1900年代(1900~1910年)には存在した話。コンピューターを利用するようになり、データの表記揺れ対応や冗長削減対応が増えたから大きく注目を浴びるようになったようだ。

Google geocoding APIを試し結果を得る

Google geocoding API でキーワードをもとに緯度経度・住所を取得できる。事前準備・手続きから試用して結果XMLを取得するまでを解説した。

無料枠で使ってみるまでに必要な手続き

  • Googleアカウントを作っておく
  • https://console.cloud.google.com/getting-started にアクセスし、『有効なAPIとサービス』メニューからGeocoding APIを探し有効化
  • https://console.cloud.google.com/billing で請求先アカウントを追加しておく
  • https://console.cloud.google.com/apis/credentials でAPIキーを作成しておく(XXXXとする)

アクセスを試す

以下URLにアクセスし、結果に示すような画面出力を得られるのを確認する

https://www.google.co.jp/maps/api/geocode/xml?address=skytree&sensor=true&key=XXXX

※addressの値は検索キーワード、keyの値は作成したAPIキーに適宜変更すること

結果

<GeocodeResponse>
	<status>OK</status>
	<result>
		<type>establishment</type>
		<type>point_of_interest</type>
		<type>tourist_attraction</type>
		<formatted_address>日本、〒131-0045 東京都墨田区押上1丁目1−2</formatted_address>
		<address_component>
			<long_name>2</long_name>
			<short_name>2</short_name>
			<type>premise</type>
		</address_component>
		<address_component>
			<long_name>1</long_name>
			<short_name>1</short_name>
			<type>political</type>
			<type>sublocality</type>
			<type>sublocality_level_4</type>
		</address_component>
		<address_component>
			<long_name>1丁目</long_name>
			<short_name>1丁目</short_name>
			<type>political</type>
			<type>sublocality</type>
			<type>sublocality_level_3</type>
		</address_component>
		<address_component>
			<long_name>押上</long_name>
			<short_name>押上</short_name>
			<type>political</type>
			<type>sublocality</type>
			<type>sublocality_level_2</type>
		</address_component>
		<address_component>
			<long_name>墨田区</long_name>
			<short_name>墨田区</short_name>
			<type>locality</type>
			<type>political</type>
		</address_component>
		<address_component>
			<long_name>東京都</long_name>
			<short_name>東京都</short_name>
			<type>administrative_area_level_1</type>
			<type>political</type>
		</address_component>
		<address_component>
			<long_name>日本</long_name>
			<short_name>JP</short_name>
			<type>country</type>
			<type>political</type>
		</address_component>
		<address_component>
			<long_name>131-0045</long_name>
			<short_name>131-0045</short_name>
			<type>postal_code</type>
		</address_component>
		<geometry>
			<location>
				<lat>35.7100627</lat>
				<lng>139.8107004</lng>
			</location>
			<location_type>ROOFTOP</location_type>
			<viewport>
				<southwest>
					<lat>35.7089225</lat>
					<lng>139.8084778</lng>
				</southwest>
				<northeast>
					<lat>35.7116204</lat>
					<lng>139.8132971</lng>
				</northeast>
			</viewport>
		</geometry>
		<partial_match>true</partial_match>
		<place_id>ChIJ35ov0dCOGGARKvdDH7NPHX0</place_id>
		<plus_code>
			<global_code>8Q7XPR66+27</global_code>
			<compound_code>PR66+27 東京都墨田区</compound_code>
		</plus_code>
	</result>
</GeocodeResponse>

所感

知らない人が試すには手続きで時間がかかる。けれど、ブラウザのGETメソッドで簡単にデータを取得できるから物凄く手軽。

無料枠でもいろいろ試せる&楽しめたから、いろんな人に試してほしい機能だ。