メインコンテンツまでスキップ

Ultimate Multisite 101

Ultimate Multisite は、顧客に WaaS、つまり Websites as a Service を提供できる WordPress Multisite plugin です。Ultimate Multisite があなたのビジネスと顧客にどのように役立つかを学ぶ前に、まず押さえておくべき基礎知識があります。

WordPress Multisite​

私たちの多くは、標準的な WordPress インストールに慣れています。ホスティングプロバイダーのコントロールパネルから作成するか、勇気のある人なら新しいウェブサーバーとデータベースを用意し、コアファイルをダウンロードしてインストール手順を開始します。

これは世界中の何百万もの WordPress サイトで機能していますが、代理店やホスティングプロバイダーの視点から、少し規模について考えてみましょう。

自動化されたコントロールパネルを使えば、WordPress サイトを 1 つ、あるいは 100 個作成することさえ簡単です。しかし、これらのサイトを管理する段階になると、すぐに問題が見えてきます。管理されていないサイトは、マルウェアの格好の標的です。管理には労力とリソースが必要です。WordPress サイトの管理と運用を効率化する外部ツールやプラグインはありますが、顧客が管理者アクセスを保持しているという事実により、その取り組みは簡単に無効化されてしまう可能性があります。

WordPress のコアには、単に「Multisite」と呼ばれる機能が用意されています。その起源は、WordPress 3.0 が公開された 2010 年にさかのぼります。それ以来、新機能の導入とセキュリティ強化を目的として、何度も改訂されてきました。

本質的に、WordPress Multisite は次のように考えることができます。大学が WordPress の単一インストールを維持しつつ、各学部がそれぞれ自分たちの WordPress サイトを運営する、という形です。

この説明を分解するために、Ultimate Multisite のドキュメントだけでなく WordPress コミュニティ全体でも使われる基本用語をいくつか見てみましょう。

ネットワーク​

WordPress において、Multisite ネットワークとは、複数のサブサイトを 1 つの Dashboard から管理できる仕組みです。Multisite ネットワークの作成方法はホスティングプロバイダーによって異なりますが、最終的には通常、WordPress がこの特定のモードで動作していることを認識できるように、wp-config.php ファイルへいくつかの追加ディレクティブを記述します。

Multisite ネットワークと単独の WordPress インストールには、いくつか明確な違いがあります。ここではそれらを簡単に説明します。

サブドメイン対サブディレクトリ​

Multisite インストールを サブディレクトリ で運用するか、サブドメイン で運用するかは、最初に決めるべきことの 1 つです。Ultimate Multisite はどちらの選択肢でも同じように機能しますが、2 つの構成にはいくつかのアーキテクチャ上の違いがあります。

サブディレクトリ 構成では、ネットワークサイトはメインドメイン名に基づくパスを継承します。たとえば「site1」というネットワークサイトの完全な URL は https://domain.com/site1 になります。サブドメイン 構成では、ネットワークサイトはメインドメイン名から派生した独自の サブドメイン を持ちます。したがって「site1」というサイトの完全な URL は https://site1.domain.com/ になります。

どちらの選択肢も十分に有効ですが、サブドメイン の使用には多くの利点がある一方で、そのアーキテクチャについてより多くの検討と計画が必要です。

DNS の観点では、サブディレクトリ の使用は比較的単純です。ネットワークサイトは親パスの子にすぎないため、メインドメイン名に対して 1 つのドメイン名エントリだけが存在すれば十分です。サブドメイン の場合は少し複雑で、各ネットワークサイトに対する個別の CNAME エントリ、または DNS レコード内のワイルドカード（*）エントリが必要になります。

さらに考慮すべき点として、SSL と SSL 証明書の発行および使用があります。サブディレクトリ 構成では、ネットワークサイトはメインドメイン名のパスにすぎないため、単一ドメイン証明書を使用できます。したがって domain.com 用の証明書で、https://domain.com/site1、https://domain.com/site2 などに十分な SSL を提供できます。

サブドメイン 構成では、ワイルドカード SSL 証明書の使用が最も一般的な選択肢の 1 つです。この種類の SSL 証明書は、ドメインとその サブドメイン に暗号化を提供します。そのため、ワイルドカード SSL 証明書は https://site1.domain.com、https://site2.domain.com、そして https://domain.com 自体に暗号化を提供します。

ほかの選択肢もありますが、多くの場合は範囲や用途が限られ、適合性について追加の構成と検討が必要になります。

プラグインとテーマ​

WordPress が与えるものは、少なくとも顧客の視点では、同時に取り上げられるものでもあります。単独の WordPress インストールでは、サイト管理者が不適切なプラグインをインストールしたり、インストール環境を最新に保たなかったりしても、その行為の被害者は自分自身だけです。しかし、Multisite インストールでサイト管理者が不適切なプラグインをインストールすると、ネットワーク内にインストールされたすべてのサイトが被害を受けます。

このため、Multisite として構成された WordPress では、サイト管理者からプラグインとテーマをインストールする権限が取り除かれます。その代わりに、この権限は新しく作成されるネットワーク管理者、または「スーパー管理者」ロールへ移されます。この特権ロールは、ネットワークサイトの管理者が自分の Dashboard でプラグインメニューを表示またはアクセスできるようにするかどうかを決定できます。また、許可する場合、その権限をプラグインの 有効化 や 無効化 にまで広げるかどうかも決められます。

この範囲において、ネットワーク管理者はネットワークへプラグインとテーマをインストールする責任を持ちます。そして、これらのプラグインとテーマを利用する権限をネットワークサイトへ委任します。サイト管理者は、自分のサイトに割り当てられていないプラグインやテーマをインストールしたり、アクセスしたりすることはできません。

ユーザーと管理者​

WordPress Multisite では、すべてのネットワークサイトが同じデータベースを共有するため、同じユーザー、ロール、権限を共有します。最も適切な考え方は、すべてのユーザーが特定のサイトではなくネットワークのメンバーである、というものです。

この理解に基づくと、ユーザーの作成を許可することは望ましくない場合があります。そのため WordPress Multisite は、この権限をサイト管理者から取り除き、ネットワーク管理者の権限へ移します。さらにネットワーク管理者は、必要な権限をサイト管理者に委任し、自分のサイト用のユーザー Account を作成できるようにできます。

上記を繰り返すと、ユーザー Account はサイトに関連しているように見えますが、実際にはネットワークに割り当てられています。そのため、ネットワーク全体で一意でなければなりません。この理由により、登録できないユーザー名がある場合があります。

企業システムでは珍しい概念ではありませんが、このようにユーザー登録と認証を単一の情報源で扱う仕組みは、ユーザー管理が比較的簡単な単独の WordPress インストールに慣れている人には理解しにくいことがよくあります。

メディア​

WordPress Multisite では、ネットワークサイトは単一のデータベースを共有しますが、メディアファイルについてはファイルシステム上で別々のパスを保持します。

標準の WordPress の場所（wp-content/uploads）は残ります。ただし、そのパスはネットワークサイト固有の ID を反映するように変更されます。その結果、ネットワークサイトのメディアファイルは wp-contents/uploads/site/[id] のように表示されます。

以前、subdomain 設定には subdirectory 設定より明確な利点があると述べましたが、それがここでの「パス」です。

subdirectory 設定では、メインサイト（ネットワーク作成時に最初に作成されたサイト）とネットワークのサブサイトが、ドメイン名から続く同じパスを共有しなければなりません。これにより、多くの競合が発生する可能性があります。

投稿については、ネットワークサイトとの衝突を防ぐため、必須の /blog/ パスがメインサイトに追加されます。つまり、「投稿名」のような見やすいパーマリンクは domain.name/blog/post-name/ として表示されます。

subdomain 設定では、各ネットワークサイトが完全にドメインで分離されるため、この処理は不要です。そのため単一のパスに依存する必要がありません。代わりに、それぞれの subdomain に基づく独自のパスを保持します。

固定ページ​

subdirectory 設定では、メインサイトとネットワークサイトが同じパスを共有するため、名前の競合が固定ページにも及ぶ可能性があります。

これを防ぐため、WordPress は特定のサイト名をブラックリストに登録し、最初のサイトの名前と競合しないようにする手段を提供します。通常、ネットワーク管理者はメインサイトのページのルートパスを入力します。

subdomain 設定では、subdomain がネットワークサイトに固有であり、メインサイトとは一切関係しないため、名前の競合の可能性は軽減されます。

登録​

WordPress Multisite のネットワーク設定では、新規ユーザーと既存ユーザーがサイトを作成できるようにする、いくつかの新しいユーザー登録オプションを利用できます。

単独の WordPress インストールとは異なり、ネットワークサイトには、ユーザー登録を許可したり、それらの登録を権限グループに割り当てたりするおなじみのオプションはありません。

ユーザー Account が作成されると、それらの Account はネットワークレベルで生成されます。したがって、特定の 1 つのサイトに属するのではなく、ネットワークに属します。これにはいくつかの明確な利点と欠点があります。

たとえば、あなたの WordPress Multisite がニュースと情報を扱う事業だとします。マルチサイトを構築し、プラグインとテーマの全体管理を維持しながら、金融、技術、娯楽、その他の関心分野向けにネットワークサイトを作成します。各ネットワークサイトは、カスタム投稿タイプや通常の投稿カテゴリーよりも、自分のネットワークサイトの見た目や使い勝手、ユーザー体験をはるかに細かく制御できます。

この範囲では、ユーザーがログインするとネットワークにログインし、最終的には各ネットワークサイトにもログインした状態になり、途切れのない体験が提供されます。新しいサイトがサブスクリプション型であるなら、これは理想的な解決策であり結果です。

しかし、マルチサイトの意図された性質と目的が、互いに関係のない別々のネットワークサイトを提供することである場合、ほとんどの場合、ユーザー権限を操作するために外部または追加のプラグインが必要になります。

ドメインと SSL​

見落としがちな WordPress Multisite インストールについて話しましょう。それは Wordpress.com です。これは Wordpress マルチサイトの中で群を抜いて大規模な例であり、目的を満たすためにどれほど広範にカスタマイズし形作れるかを示しています。

現代のインターネットでは SSL の使用はほぼ必須であり、WordPress マルチサイトのネットワーク管理者はすぐにこれらの課題に直面します。

subdomain 設定では、サイトはルートドメイン名に基づいて作成されます。したがって、「site1」というラベルのサイトは「site1.domain.com」として作成されます。ワイルドカード SSL 証明書を利用することで、ネットワーク管理者はこの課題にうまく対応し、ネットワークに SSL 暗号化機能を提供できます。

WordPress Multisite には、ネットワークサイトをカスタムドメイン名、またはネットワークのルートドメインとは異なるドメイン名に関連付けられるドメインマッピング機能があります。

ネットワーク管理者にとって、これはドメイン名設定だけでなく、SSL 証明書の発行と維持にも追加の複雑さをもたらします。

この範囲では、WordPress Multisite は www.anotherdomain.com を「site1」にマッピングできる手段を提供しますが、ネットワーク管理者には DNS エントリーの外部管理と SSL 証明書の実装という課題が残ります。

Ultimate Multisite​

単独の WordPress インストールと Multisite インストールの違いを理解したところで、Websites as a Service を提供するための究極の武器として Ultimate Multisite がどのように機能するのかを見ていきましょう。

はじめに​

Ultimate Multisite は、Website as a Service（WaaS）を作成する際の万能ナイフです。Wix.com、Squarespace、WordPress.com を思い浮かべ、そのうえで自分自身のサービスを所有することを想像してください。

内部では Ultimate Multisite は WordPress Multisite を利用しています。ただし、Multisite インストールでネットワーク管理者が直面する数多くの課題を解決するだけでなく、機能を強化し、幅広いユースケースに対応できる形で利用しています。

以下のセクションでは、一般的なユースケースと、それらをサポートするために必要な考慮事項を見ていきます。

ユースケース​

ケース 1: 代理店​

一般的に、代理店の中核となるスキルは Web サイトのデザインにあり、ホスティングやマーケティングなどは追加サービスとして扱われます。

代理店にとって Ultimate Multisite は、単一のプラットフォーム上で複数の Web サイトをホストし管理できる点で、非常に大きな価値を提供します。さらに、GeneratePress、Astra、OceanWP などの特定のテーマでデザインを標準化している代理店は、新しいサイトごとにこれらのテーマを自動的に有効化できる Ultimate Multisite の機能を活用できます。

同様に、一般的で人気のある plugin には代理店向け価格の取引が豊富にあります。Ultimate Multisite を使用することで、代理店は plugin をインストール、保守、利用できる共通プラットフォームを提供し、既存の投資を活用できます。

多くの場合、構成の使用が望まれます。幸いなことに Ultimate Multisite は、多くの人気ホスティングプロバイダーや Cloudflare、cPanel などのサービスとの連携により、ドメインマッピングと SSL 証明書を非常に簡単に実現できます。

したがって、これらのプロバイダーのいずれかを活用するか、Ultimate Multisite を Cloudflare の背後に配置することで、ドメインや SSL 証明書の管理といった要素はかなり簡単になります。

サイト作成を厳密に管理したい代理店は、Ultimate Multisite の合理化されたインターフェースを通じて、サイトを作成し、サイトを顧客や plan に関連付けることが容易である点を高く評価するでしょう。

Ultimate Multisite サイト管理インターフェース

plugin と theme の厳密な管理は、Ultimate Multisite の直感的なインターフェースを通じて product ごとに維持されます。これにより、新しいサイトの作成時に、plugin と theme を利用可能にしたり非表示にしたり、有効化状態を制御したりできます。

Product plugin 制限インターフェース

theme も同様の機能を提供し、サイト作成時に特定の theme を有効化または非表示にできます。

Product theme 制限インターフェース

代理店は、Ultimate Multisite によって、自分たちが最も得意とすること、つまり優れた Web サイトのデザインに集中できる安心感を得られます。

ケース 2: ニッチプロバイダー​

「一つのことを行い、それをうまく行え」という古いことわざがあります。多くの専門家にとって、これは単一の中核的なアイデアを中心に product やサービスを作成することを意味します。

たとえば、熱心なゴルファーとしてクラブ向けに Web サイトを提案しているかもしれません。あるいは熱心な eスポーツゲーマーとしてクラン向けに Web サイトを提供しているかもしれません。レストラン向けに予約サービスを提案する個人という場合もあるでしょう。

多くの理由から、共通のフレームワークとプラットフォームに基づいてサービスを提供したいはずです。必要な機能を提供するために独自 plugin を設計または投資している場合もあれば、業界のベストプラクティスとしてデザインに何らかの標準化されたアプローチが求められる場合もあります。

Ultimate Multisite の革新的な機能の一つが、テンプレートサイトの使用です。テンプレートサイトとは、theme がインストールされ有効化され、必要な plugin がインストールされ有効化され、サンプルの投稿やページが作成されたサイトです。顧客がそのテンプレートに基づいて新しいサイトを作成すると、テンプレートの内容と設定が新しく作成されたサイトにコピーされます。

ニッチなサイトやサービスのプロバイダーにとって、これはカスタム plugin とデザインを備えた、すぐに使えるサイトを即座に作成できる比類ない利点をもたらします。顧客は、サービスを完了するためにごく最小限の入力を行うだけで済みます。

要件に応じて、サブディレクトリ または サブドメイン の構成が適している場合があります。その場合、アーキテクチャの選択肢は、サブディレクトリ 向けのシンプルな SSL 証明書か、サブドメイン 向けのワイルドカード SSL 証明書になります。

ケース 3: WordPress Web ホスティング​

WordPress サイトをホストする方法は無数にありますが、WordPress が事前にインストールされた Web スペースを顧客に提供するほど単純なことはめったにありません。意味のあるサービスを提供するには、いくつもの判断と考慮事項を組み合わせる必要があるためです。

Ultimate Multisite は、WordPress サイトのホスティングに対する包括的なターンキーソリューションを提供することで、この分野で優れた力を発揮します。ソリューションには、subscription サービス、支払いの回収、checkout フォーム、割引クーポン、顧客コミュニケーションを提供するための中核的な仕組みが含まれています。

WordPress Multisite を正しくインストール、構成、保守するために必要な重要作業の多くは、Ultimate Multisite によって容易になります。そのため、ネットワーク管理者は product の階層、価格設定、サービス提供内容など、自分たちのサービスやニッチに関係する要素だけを考慮すればよくなります。

Ultimate Multisite と連携したい開発者向けに、このソリューションは包括的な RESTful API とイベント通知用の Webhooks も提供しています。

無数の外部プラグインやライセンスに依存せずに、Ultimate Multisite は Wix、Squarespace、WordPress.com などに匹敵する、機能豊富なソリューションを提供します。

アーキテクチャ上の考慮事項​

包括的なガイドではありませんが、以下の項目は Ultimate Multisite のインストールを支える技術を正しく選ぶための指針になります。

共有ホスティングと専用ホスティング​

残念ながら、すべてのホスティング事業者が同じ品質ではありません。極端に高いサーバー集約率で運用している事業者もあります。低価格の事業者は通常、サーバー集約率を最大化して収益を得ています。そのため、あなたの Ultimate Multisite インストールは、同じサーバー上にある数百のサイトのうちの一つにすぎない場合があります。

事業者側で適切な保護策がない場合、共有サーバー上のサイトは「うるさい隣人」問題を経験します。つまり、同じサーバー上のあるサイトが大量のリソースを消費し、他のサイトが残りのリソースを奪い合わなければならない状態です。多くの場合、サイトが遅くなったり、適切な時間内に応答しなくなったりします。

あなた自身がウェブホスティングの事業者である場合、その影響は顧客に及びます。顧客は速度低下、低いページ順位、高い直帰率を経験し、結果として別のサービスを求めて離脱することがよくあります。

要するに、安いことは良いことを意味しません。

Ultimate Multisite は、複数の優良ホスティング事業者で動作することが確認されており、それらの環境とよく統合され、ドメインマッピングや自動 SSL などの機能を提供します。これらの事業者はパフォーマンスを重視し、共有ホスティングより高品質なサービスを提供しています。

互換性のある事業者の一覧と、それぞれの完全なセットアップ手順については、互換性のある事業者のドキュメントを確認してください。

パフォーマンス上の考慮事項​

Ultimate Multisite は遅いアプリケーションではありません。むしろ非常に高速です。ただし、基盤となるアプリケーションとインフラストラクチャの性能に応じて動作し、アクセスできるものだけを活用できます。

次の状況を考えてみてください。あなたは 100 個のサイトを持つ Ultimate Multisite インストールのネットワーク管理者です。そのうちいくつかのサイトは好調で、毎日多くの訪問者を集めています。

これは、たとえば 1〜5 個のサイトという小規模な場合とは異なります。しかし、やがて規模に伴う問題が明らかになります。

放置すると、単一の Ultimate Multisite サイトが、すべてのサイト訪問者からのリクエストを処理する責任を負います。これらのリクエストは、動的な PHP ページの場合もあれば、スタイルシート、JavaScript、メディアファイルなどの静的アセットの場合もあります。サイトが 1 個でも 100 個でも、これらの処理は反復的で単調であり、無駄が多くなります。すべてのリクエストに対して出力が同じ静的情報であるなら、PHP ファイルを処理するために CPU 能力とメモリを使う必要はありません。

同様に、PHP または HTML ページへの 1 回のリクエストは、スクリプト、スタイルシート、画像ファイルへの複数の後続リクエストを生成します。それらのリクエストは、あなたの Ultimate Multisite サーバーに直接送られます。

サーバーをアップグレードすれば、この問題は簡単に解決できるように見えるかもしれません。しかし、それでは二次的な問題である地理的な遅延は解決できません。この問題に適切に対処するには、複数の場所に複数のサーバーを置く必要があります。

このため、多くのネットワーク管理者は、静的ページのリクエストを処理するために、フロントエンドのキャッシュソリューションやコンテンツ配信ネットワーク（CDN）を利用します。リクエストがサーバーに到達する前にこれらのリクエストを処理し、アセットを配信することで、処理リソースを節約し、遅延をなくし、不要なアップグレードを避け、技術投資を最大化できます。

Ultimate Multisite には高度な Cloudflare アドオンが含まれており、ネットワーク管理者はインストールを Cloudflare の背後に配置し、キャッシュ機能だけでなく、DNS ホスティング、SSL 証明書、セキュリティ機構も利用できます。

バックアップ​

バックアップについて 50 人に助言を求めれば、バックアップ戦略について 50 通りの意見が返ってくるでしょう。答えは、状況によります。

異論がないのは、バックアップが必要であること、そして特に管理サービスを提供する事業者であれば、それを事業者が管理していないとはほとんど考えられないということです。そのため、顧客はこのサービスの提供と管理をネットワーク管理者に期待します。ネットワーク管理者が誰に頼るかは、まったく別の問題です。

このセクションでは、バックアップとは、バックアップが開始された時点のシステム状態の時点コピーであると定義します。簡単に言えば、バックアップ時点でのシステムの状態が何であれ、その状態が取得され、バックアップ内に保存されます。

この理解に基づくと、どのようにバックアップを実現するか、またあなたの環境に最適な方法は何かという答えは、主に要件と、それらの要件を満たすホスティング事業者の能力によって決まります。ただし、主張の強いものから弱いものの順に、以下の選択肢が一定の指針になります。

スナップショット​

スナップショットはバックアップにおける万能策です。簡単で、複雑ではなく（復元したくなるまでは）、そして「そのまま機能」します。ただし、事業者の支援がいくらか必要で、主に VPS（仮想専用サーバー）または類似の環境を利用している場合にのみ当てはまります。私たちの「互換性のある事業者」ドキュメントに掲載されている複数の事業者は、ネットワーク管理者による追加の介入や検討を必要としないバックアップを提供しています。

従来のバックアップがファイルとデータベースを対象にするのに対し、スナップショットはディスク全体を対象にします。つまり、サイトのデータだけでなく、オペレーティングシステムと構成もスナップショットに含まれます。多くの人にとって、これは明確な利点です。スナップショットからほぼ即座に新しいシステムを生成し、不調なインスタンスの代替として稼働させることができるためです。同様に、ファイルだけを取り出す復旧プロセスでは、スナップショットイメージを既存のインスタンスにディスクとして接続するだけで、ファイルにアクセスしてコピーできます。

スナップショットにはホスティング事業者で追加費用が発生する場合がありますが、事故に備える保険です。

外部スクリプト​

WordPress と MySQL リソースをバックアップするための外部スクリプトやソリューションは不足していないようです。Ultimate Multisite は WordPress のファイルシステムとデータベースを利用する WordPress plugin であるため、これらは Ultimate Multisite にも問題なく機能します。したがって、WordPress サイトをバックアップするソリューションであれば、Ultimate Multisite の要件を十分に満たせます。

特定のスクリプトを推奨することはできませんが、一般的な助言としては、結果が意図どおりであることを確認するために、バックアップと復元のテストを複数回実行することです。また、特に差分バックアップ戦略が適用される場合は、スクリプトとその機能を継続的に評価し、「念には念を入れて」確認してください。

これらのスクリプトは実行中にシステム負荷を増加させるため、その点を考慮する必要があります。

Plugins​

WordPress には、plugin で解決できない問題はほとんどありません。外部スクリプトの管理が好みでない場合は、plugin が次善の選択肢になるかもしれません。

plugin によってオプションや機能は異なりますが、多くは同じ機能、つまり WordPress ファイルとデータベース内容のコピーを作成します。その後の機能は異なり、一部の plugin はバックアップを Google Drive や Dropbox などの外部サービス、または S3、Wasabi などの互換性のあるオブジェクトストレージサービスへ送信できます。より包括的な plugin では、外部ストレージ費用を節約するために、差分バックアップや、変更されたデータのみをバックアップする何らかの戦略を提供しています。

plugin を選択する際は、multisite に対応していることを必ず確認してください。バックアップ実行中は、その動作の性質上、処理が完了するまでサーバーに一時的な負荷がかかることが予想されます。

Domain and SSL​

multisite の subdomain モードにおけるドメイン名については、すでに多く議論されています。ネットワーク管理者にとって、ほぼ一般的な解決策はワイルドカード DNS エントリーを使用することです。

ワイルドカード DNS エントリー設定例

この種類の DNS エントリーは、「site1.domain.com」や「site2.domain.com」などの subdomains を 1.2.3.4 の IP アドレスへ正常に解決します。これにより、Ultimate Multisite と、より広い意味で subdomain モードを使用する WordPress Multisite をサポートできます。

HTTP では、対象ホストが HTTP ヘッダーから読み取られるため、これは完全に機能する場合があります。しかし、現在の Web はそれほど単純ではなく、安全な HTTPS トランザクションがほぼ必須になっています。

幸い、SSL 証明書には簡単な選択肢があります。subdirectory モードでは通常のドメイン証明書を使用できます。これらは、無料の LetsEncrypt サービスや別の提供元を利用するホスティングプロバイダーから、容易かつ無料で入手できます。そうでない場合でも、証明書署名要求を生成できるのであれば、認証局から商用で入手できます。

subdomain モードでは、ワイルドカード SSL 証明書を使用するとワイルドカードドメインと完全に組み合わせることができ、余分な設定なしでルートドメインとすべての subdomains に対して証明書を有効にできます。

ただし、Cloudflare などのサービスでは、エンタープライズ plan を利用している場合、またはエントリーを DNS のみに設定している場合を除き、ワイルドカード SSL 証明書が機能しないことがあります。その場合、すべてのキャッシュと最適化はバイパスされます。

標準の Ultimate Multisite は、この問題に対するソリューションを提供しており、WordPress multisite のニーズに関する当社の豊富な経験を示しています。このシンプルな add-on を有効化すると、Ultimate Multisite は Cloudflare 認証情報を使用して、ネットワークサイトの DNS エントリーを Cloudflare に自動的に追加し、そのモードを「proxied」に設定します。このようにして、各ネットワークサブサイトは作成時に、SSL を含む Cloudflare の完全な保護と利点を得られます。

Ultimate Multisite インストールの性質や目的によっては、顧客が独自のドメインを使用する必要がある場合があります。この場合、ネットワーク管理者は 2 つの問題を解決する責任を負います。1 つはドメイン名のホスティング、もう 1 つはそのドメインの SSL 証明書です。

多くの場合、Cloudflare の使用は簡単な選択肢です。顧客は自分のドメインを Cloudflare に配置し、CNAME を Ultimate Multisite のルートドメインに向け、Ultimate Multisite でドメインをマッピングするだけで、カスタムドメイン名の利点を利用し始めることができます。

それ以外では、代替ソリューションを探す必要があります。そのため Ultimate Multisite は Compatible Providers の一覧を推奨しています。これは DNS と SSL の設定プロセスが単純ではない場合があるためです。しかし、Ultimate Multisite がこれらのプロバイダーと統合していることで、複雑さは大幅に軽減され、手順は自動化されます。

Plugins​

顧客やネットワークサイトに機能を提供するために、追加の plugin が必要になる可能性は高いです。すべての plugin が WordPress Multisite と Ultimate Multisite で動作するのでしょうか。答えは、場合によります。

ほとんどの plugin は WordPress Multisite にインストールできますが、有効化とライセンスは作成者によって異なります。

課題は、ライセンスがどのように適用されるかにあります。一部の plugin では、ドメインごとにライセンスが必要です。つまり、そのような plugin では、ネットワーク管理者が新しいサイトごとに各 plugin のライセンスを手動で有効化する必要があります。

そのため、plugin が WordPress Multisite でどのように動作するか、またライセンスに必要な特別な要件や手順があるかについて、plugin 作者に確認するのが最善かもしれません。