Ultimate Multisite 101

Ultimate Multisite は、顧客に WaaS（Website as a Service）や Websites as a Service を提供できる WordPress Multisite プラグインです。Ultimate Multisite がどのようにビジネスや顧客をサポートできるかを学ぶ前に、まずは基礎知識を身につけておきましょう。

The WordPress Multisite

ほとんどの人は、標準的な WordPress インストールに慣れています。ホスティングプロバイダーのコントロールパネルから作成するか、勇敢な方は新しいウェブサーバーとデータベースを設定し、コアファイルをダウンロードしてインストールプロセスを開始します。

これは世界中の数百万の WordPress サイトで機能しますが、代理店やホスティングプロバイダーの観点からは、ボリュームについて少し話しましょう。

WordPress サイトを1つ、あるいは自動化されたコントロールパネルで100個作成することは同期的に行えますが、これらのサイトの管理に落ちると、問題がすぐに表面化します。管理されていないと、マルウェアの標的になります。管理は労力とリソースを要します。外部ツールやプラグインが WordPress サイトの管理と運営を合理化するのを助けますが、顧客が管理者アクセスを維持していると、これらの努力は簡単に破られます。

WordPress のコアには、2010 年に WordPress 3.0 のリリース時に登場した「Multisite」という機能があります。その後、機能追加とセキュリティ強化のためにいくつかの改訂が行われました。

本質的に、WordPress マルチサイトは次のように考えることができます：大学が単一の WordPress インストールを維持し、各学部が独自の WordPress サイトを管理する。

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

The Network

WordPress の観点から、マルチサイトネットワークは複数のサブサイトを単一のダッシュボードから管理できるものです。ホスティングプロバイダーによってマルチサイトネットワークの作成方法は異なりますが、最終的には wp-config.php ファイルにいくつかの追加ディレクティブを追加して、WordPress に特定のモードで動作していることを知らせます。

マルチサイトネットワークと単体の WordPress インストールの間には、いくつかの明確な違いがあります。以下では簡単に説明します。

Subdomain vs. Subdirectory

最も直ちに決定しなければならない選択肢の一つは、マルチサイトインストールが サブディレクトリ で動作するか サブドメイン で動作するかです。Ultimate Multisite は両方の選択肢で同じように機能しますが、アーキテクチャ上の違いがあります。

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

両方のオプションは完全に有効な選択肢ですが、サブドメイン の使用は多くの利点を提供しますが、アーキテクチャ上でより多くの考慮と計画が必要です。

DNS の観点から、サブディレクトリ の使用は比較的単純な課題です。ネットワークサイトは親パスの単なる子であるため、メインドメイン名に対して単一のドメイン名エントリだけが必要です。サブドメイン の場合、課題は少し複雑で、各ネットワークサイトごとに個別の CNAME エントリ、または DNS レコードにワイルドカード (*) エントリが必要です。

SSL と SSL 証明書の発行・使用に関しては、サブディレクトリ 構成では、単一のドメイン証明書を使用できます。ネットワークサイトは単にメインドメイン名のパスであるため、domain.com の証明書は https://domain.com/site1、https://domain.com/site2 などに SSL を適切に提供します。

サブドメイン 構成では、ワイルドカード SSL 証明書の使用が最も一般的なオプションです。このタイプの SSL 証明書は、ドメインとその サブドメイン を暗号化します。したがって、ワイルドカード SSL 証明書は https://site1.domain.com、https://site2.domain.com、そして https://domain.com 自体の暗号化を提供します。

他のオプションもありますが、これらは通常、範囲と適用が限定され、適切な構成と適合性に関する追加の考慮が必要です。

Plugins and Themes

WordPress が提供するものを取り、顧客の観点からはそれを取り戻すこともあります。単体の WordPress インストールでは、サイト管理者が悪いプラグインをインストールしたり、インストールを最新に保たない場合、被害は自分自身に限定されます。しかし、マルチサイトインストールで悪いプラグインをインストールすると、ネットワークにインストールされているすべてのサイトが犠牲になります。

このため、マルチサイトとして構成されると、WordPress はサイト管理者からプラグインとテーマのインストール権限を削除し、代わりに新しく作成されたネットワーク管理者（または「スーパー管理者」）に移動します。この特権ロールは、ネットワークサイトの管理者がダッシュボードでプラグインメニューを表示またはアクセスできるかどうか、さらにその権限がプラグインの 有効化 または 無効化 に拡張されるかどうかを決定できます。

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

Users and Administrators

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

この理解に基づくと、ユーザーを作成することを許可することは望ましくない場合があります。そのため、WordPress Multisite はサイト管理者からこの機能を削除し、ネットワーク管理者に移動します。ネットワーク管理者は、サイト管理者に必要な権限を委譲して、独自のサイトにユーザーアカウントを作成できるようにします。

上記の声明を繰り返すと、ユーザーアカウントはサイトに関連しているように見えますが、実際にはネットワークに割り当てられ、したがってネットワーク全体で一意である必要があります。このため、ユーザー名が登録できない場合があります。

エンタープライズシステムでは珍しい概念ではありませんが、単体の WordPress インストールに慣れた人にとっては、単一のユーザー登録と認証ソースを理解するのは難しい場合があります。

Media

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

標準の WordPress 位置（wp-content/uploads）は残りますが、そのパスはネットワークサイトの一意の ID を反映するように変更されます。したがって、ネットワークサイトのメディアファイルは wp-contents/uploads/site/[id] として表示されます。

Permalinks

前述したように、サブドメイン の構成は サブディレクトリ よりも多くの利点を提供します。ここではパスに関するものです。

サブディレクトリ 構成では、メインサイト（ネットワークが確立されたときに最初に作成されるサイト）とネットワークサブサイトは、ドメイン名から派生する同じパスを共有します。これにより、多くの衝突が発生する可能性があります。

投稿の場合、メインサイトには衝突を防ぐために必須の /blog/ パスが追加されます。したがって、'Post name' のような美しいパーマリンクは domain.name/blog/post-name/ と表示されます。

サブドメイン 構成では、この操作は不要です。各ネットワークサイトは完全にドメインを分離しているため、単一のパスに依存する必要はありません。代わりに、各ネットワークサイトは独自の サブドメイン に基づく別々のパスを維持します。

Static Pages

サブディレクトリ 構成では、メインサイトとネットワークサイトが同じパスを共有するため、静的ページの命名衝突の可能性が拡大します。

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

サブドメイン 構成では、命名衝突の可能性は サブドメイン によって緩和されます。これはネットワークサイトに固有であり、メインサイトとは何ら関係ありません。

Registration

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

単体の WordPress インストールとは対照的に、ネットワークサイトはユーザー登録を許可するオプションや、これらの登録をロールに割り当てるオプションを保持しません。

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

たとえば、WordPress Multisite がニュースと情報のビジネスであると仮定します。マルチサイトを確立し、金融、テクノロジー、エンターテイメントなどのネットワークサイトを作成し、プラグインとテーマを一元管理します。各ネットワークサイトは、カスタム投稿タイプや通常の投稿カテゴリよりも、ネットワークサイトの外観とユーザーエクスペリエンスをより細かく制御できます。

この範囲で、ユーザーがログインすると、ネットワークにログインし、最終的に各ネットワークサイトにもログインしてシームレスな体験を提供します。新しいサイトがサブスクリプションベースの場合、これは理想的なソリューションと結果です。

ただし、マルチサイトの意図と目的が、互いに関係のない分散したネットワークサイトを提供することである場合、外部または追加のプラグインがユーザー権限を操作するために必要になることがほぼ常です。

Domain and SSL

WordPress Multisite インストールについて、ほぼ私たちの注意を逃すことができないものを話しましょう - Wordpress.com。これは、WordPress マルチサイトの最も広範な例であり、カスタマイズと形作りのための広範な機能を示しています。

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

サブドメイン 構成では、サイトはルートドメイン名に基づいて作成されます。したがって、サイトに「site1」というラベルが付けられた場合、'site1.domain.com' として作成されます。ワイルドカード SSL 証明書を使用すると、ネットワーク管理者はこの課題を成功裏に解決し、ネットワークに SSL 暗号化機能を提供できます。

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

ネットワーク管理者にとって、これはドメイン名の構成と SSL 証明書の発行・保守の両方において追加の複雑さをもたらします。

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

Ultimate Multisite

単体の WordPress インストールとマルチサイトインストールの違いを理解したら、Ultimate Multisite が Websites as a Service を提供する究極のアーサルをどのように提供するかを見てみましょう。

Introduction

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

裏側では、Ultimate Multisite は WordPress Multisite を利用しますが、マルチサイトインストールでネットワーク管理者が直面する多くの課題を解決するだけでなく、幅広いユースケースをサポートできるように機能を拡張します。

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

Use Cases

Case 1: An Agency

エージェンシーの主なスキルは、ウェブサイトのデザインにあり、ホスティングやマーケティングなどの側面は追加サービスとしてリストされています。

エージェンシーにとって、Ultimate Multisite は単一のプラットフォーム上で複数のウェブサイトをホストおよび管理するという驚くべき価値提案を提供します。GeneratePress、Astra、OceanWP などの特定のテーマでデザインを標準化しているエージェンシーは、Ultimate Multisite の機能を活用して各新しいサイトに自動的にこれらのテーマを有効化できます。

同様に、エージェンシー向けの一般的で人気のあるプラグインのディールが豊富にあるため、Ultimate Multisite の使用により、プラグインをインストール、保守、活用できる共通プラットフォームを提供することで既存の投資を活用できます。

構成を望む場合、幸いにも Ultimate Multisite は、人気のあるホスティングプロバイダーや Cloudflare、cPanel などのサービスとの統合により、ドメインマッピングと SSL 証明書を簡単に実現できます。

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

サイト作成を厳密に管理したいエージェンシーは、Ultimate Multisite のストリームラインされたインターフェースを通じて、サイトを作成し、顧客やプランと関連付けることが容易であると評価します。

プラグインとテーマの厳密な管理は、Ultimate Multisite の直感的なインターフェースを通じて、製品ごとに管理され、プラグインとテーマを利用可能または非表示にし、新しいサイトでインスタンス化されたときの有効化状態を設定できます。

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

エージェンシーは、Ultimate Multisite を使用して卓越したウェブサイトを設計することに集中できるため、安心感を得られます。

Case 2: Niche Provider

「一つのことをやり遂げる」という古い格言があります。多くの専門家にとって、これは単一のコアアイデアを中心に製品やサービスを構築することを意味します。

たとえば、ゴルフクラブ向けにウェブサイトを宣伝する熱心なゴルファー、あるいはクラン向けにウェブサイトを提供する熱心な e‑スポーツゲーマー、あるいはレストランに予約サービスを提供する個人などです。

多くの理由から、共通のフレームワークとプラットフォームに基づくサービスを提供したいと考えるでしょう。必要な機能を提供するためにカスタムプラグインを設計または投資したか、業界のベストプラクティスが標準化されたアプローチを必要とする場合があります。

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

ニッチサイトとサービスのプロバイダーにとって、これはカスタムプラグインとデザインを備えた即座に稼働可能なサイトを作成できる比類のない利点を提供します。顧客はサービスを完了するために最小限の入力だけを提供すればよいです。

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

Case 3: WordPress Web Hosting

WordPress サイトをホストする方法は多岐にわたりますが、顧客に事前にインストールされた WordPress バージョンを提供するだけでなく、意味のあるサービスを提供するためには、いくつかの決定と考慮事項が必要です。

Ultimate Multisite は、この分野で優れています。WordPress サイトのホスティングに対する包括的なターンキーソリューションを提供します。サブスクリプションサービス、支払い収集、チェックアウトフォーム、割引バウチャー、顧客コミュニケーションを提供するコアメカニズムが含まれます。

WordPress Multisite を正しくインストール、構成、保守するために必要な多くの作業は、Ultimate Multisite によって促進され、ネットワーク管理者はサービスやニッチに関連する側面（製品階層、価格設定、サービスオファーなど）のみを考慮すればよくなります。

開発者が Ultimate Multisite と統合したい場合、ソリューションは包括的な RESTful API とイベント通知用の Webhooks も提供します。

外部プラグインやライセンスに依存せず、Ultimate Multisite は Wix、Squarespace、WordPress.com などと同等の機能豊富で比較可能なソリューションを提供します。

Architecture Considerations

包括的なガイドではありませんが、以下の項目は Ultimate Multisite インストールをサポートするために適切な技術を選択する際の指針として役立ちます。

Shared vs. Dedicated Hosting

残念ながら、すべてのホスティングプロバイダーが同じではなく、一部は極端なサーバー密度を実践しています。低コストプロバイダーは、サーバー密度を最大化して収益を上げることが一般的です。そのため、Ultimate Multisite インストールは同じサーバー上に数百のサイトのうちの一つにすぎない場合があります。

プロバイダーから適切な保護策がない場合、共有サーバー上のサイトは「騒がしい隣人」問題に直面します。すなわち、同じサーバー上のサイトが多くのリソースを消費し、他のサイトが残りのリソースを競合することになります。これは、サイトが遅くなるか、タイムリーに応答しないこととして現れます。

ウェブホスティングのプロバイダーとして、フローの影響は、顧客が速度低下、低いページランク、そして高いバウンス率を経験し、他のサービスを探す結果として顧客離れにつながります。

結論として、安いことは良いことを意味しません。

Ultimate Multisite は、いくつかの優れたホスティングプロバイダーと連携し、ドメインマッピングや自動 SSL などの機能を提供する環境と統合されます。これらのプロバイダーはパフォーマンスを重視し、共有ホスティングよりも高いレベルのサービスを提供します。

互換性のあるプロバイダーのリストと各プロバイダーの完全なセットアップ手順については、Compatible Providers のドキュメントを確認してください。

Performance Considerations

Ultimate Multisite は遅いアプリケーションではありません。むしろ、驚くほど高速です。ただし、基盤となるアプリケーションとインフラストラクチャに依存し、アクセスできるものだけを活用できます。

例として、Ultimate Multisite インストールのネットワーク管理者で 100 サイトを管理しているとします。そのうちのいくつかは順調に動作し、毎日多くのウェブサイト訪問者を引き付けます。

このシナリオは、1〜5 サイト程度の小規模なスケールでは異なりますが、スケールの問題はすぐに明らかになります。

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

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

サーバーをアップグレードすることでこの問題を簡単に解決できますが、地理的遅延という二次的な問題は解決しません。複数の場所にある複数のサーバーが必要です。

このため、ほとんどのネットワーク管理者はフロントエンドキャッシュソリューションと CDN（コンテンツ配信ネットワーク）を使用して静的ページのリクエストを処理し、サーバーに到達する前に資産を提供します。これにより、処理リソースが節約され、遅延が排除され、不要なアップグレードが回避され、技術投資が最大化されます。

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

Backups

バックアップ戦略について 50 人に尋ねると、50 つの異なる意見が返ってきます。答えは「それは状況に依存します」。

議論の余地がないのは、バックアップが必要であり、管理サービスを提供するプロバイダー（特に管理サービスを提供するプロバイダー）がこれらを管理しないことはほぼ想像できないということです。したがって、顧客はネットワーク管理者にこのサービスを提供・管理してもらうことを期待します。ネットワーク管理者が誰に頼むかは別の問題です。

このセクションの目的として、バックアップはバックアップが開始された時点でのシステム状態の時点コピーと定義します。簡単に言えば、バックアップ時点でのシステム状態がその状態としてキャプチャされ、バックアップにロックされます。

この理解に基づき、バックアップを実現する方法と環境に最適な方法は、要件とホスティングプロバイダーの要件を満たす能力に大きく依存します。ただし、最も意見が強いものから最も弱いものへと順に、以下のオプションがガイダンスを提供します。

Snapshots

スナップショットはバックアップへの銀の弾丸です。簡単で、複雑ではなく（復元したいとき以外は）、「ただ機能する」からです。ただし、プロバイダーからのサポートが必要で、主に VPS（Virtual Private Server）や同様の環境にのみ適用されます。Compatible Providers のドキュメントにリストされているいくつかのプロバイダーは、ネットワーク管理者の追加介入や考慮なしにバックアップを提供します。

従来のバックアップがファイルとデータベースを対象とするのに対し、スナップショットはディスク全体を対象とします。したがって、サイトのデータだけでなく、オペレーティングシステムと構成もスナップショットにキャプチャされます。多くの人にとって、これは明確な利点です。新しいシステムはスナップショットからほぼ瞬時に生成され、機能するインスタンスに置き換えることができます。同様に、ファイルを復元するプロセスは、スナップショットイメージを既存のインスタンスにディスクとして添付するだけで、ファイルにアクセスしてコピーできます。

スナップショットはホスティングプロバイダーに追加費用がかかる場合がありますが、事故に対する保険ポリシーです。

External Scripts

WordPress と MySQL リソースをバックアップする外部スクリプトやソリューションは豊富にあり、Ultimate Multisite にも適しています。Ultimate Multisite は WordPress ファイルシステムとデータベースを使用する WordPress プラグインです。したがって、WordPress サイトをバックアップするソリューションは Ultimate Multisite のニーズを十分にカバーします。

どのスクリプトが最適かは推奨できませんが、一般的なアドバイスとして、複数のバックアップと復元テストを実行し、結果が望ましいことを確認し、継続的にスクリプトとその機能を評価して「確実に確実である」ことを確認してください。差分バックアップ戦略が適用される場合は特に注意してください。

実行中は、システム負荷が増加するため、考慮する必要があります。

Plugins

WordPress で問題を解決できないものはほぼありません。外部スクリプトを管理するのが好きでない場合、プラグインが次善の選択肢です。

プラグインはオプションと機能が異なりますが、ほとんど同じ機能を実行します。すなわち、WordPress ファイルとデータベースのコピーを作成します。その後、機能は異なり、いくつかのプラグインは Google Drive や Dropbox、あるいは S3、Wasabi などの互換オブジェクトストレージサービスにバックアップを送信できます。より包括的なプラグインは差分バックアップや、変更されたデータのみをバックアップする戦略を提供します。

プラグインを選択する際は、マルチサイト対応であることを確認してください。バックアップが実行されている間、サーバーに一時的な負荷がかかることが予想されます。

Domain and SSL

マルチサイトの サブドメイン モードでのドメイン名については、ほぼすべてのネットワーク管理者にとってワイルドカード DNS エントリを使用するのが最も一般的な解決策です。

このタイプの DNS エントリは、site1.domain.com や site2.domain.com などの サブドメイン を 1.2.3.4 の IP アドレスに正しく解決し、Ultimate Multisite と WordPress Multisite の サブドメイン モードをサポートします。

HTTP ではターゲットホストが HTTP ヘッダーから読み取られるため、HTTP では完璧に機能しますが、近年は HTTPS トランザクションがほぼ必須であるため、ウェブはそれほど単純ではありません。

幸い、SSL 証明書の簡単なオプションがあります。サブディレクトリ モードでは、通常のドメイン証明書を使用できます。これらはホスティングプロバイダーから無料で入手できる LetsEncrypt サービスや他のソースから入手できます。そうでない場合は、証明書署名要求を生成できる場合は、商業的に入手可能です。

サブドメイン モードでは、ワイルドカード SSL 証明書の使用が完璧にペアリングし、ワイルドカードドメインとともに、ルートドメインとすべての サブドメイン に対して権威を持つ証明書を提供します。

ただし、ワイルドカード SSL 証明書は Cloudflare などのサービスと互換性がない場合があります。エンタープライズプランに加入していない、または DNS のみを設定している場合は、すべてのキャッシュと最適化がバイパスされます。

Out-of-the-box Ultimate Multisite はこの問題に対するソリューションを提供し、WordPress multisites のニーズに対する豊富な経験を示しています。このシンプルなアドオンを有効にすると、Ultimate Multisite は Cloudflare の認証情報を使用してネットワークサイトの DNS エントリを自動的に追加し、モードを「proxied」に設定します。これにより、各ネットワークサブサイトは作成時に Cloudflare の完全な保護とメリット（SSL を含む）を享受します。

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

多くの人にとって、Cloudflare の使用は簡単なオプションです。顧客はドメインを Cloudflare に置き、CNAME を Ultimate Multisite のルートドメインにポイントし、Ultimate Multisite でドメインをマッピングしてカスタムドメイン名の利点を享受します。

それ以外の場合は、代替ソリューションを探す必要があります。これが Ultimate Multisite が Compatible Providers のリストを推奨する理由です。DNS と SSL の設定は非トリビアルなプロセスです。しかし、Ultimate Multisite の統合により、複雑さは大幅に削減され、手順は自動化されます。

Plugins

追加のプラグインが必要になる可能性が高いです。WordPress Multisite と Ultimate Multisite ですべてのプラグインが機能するかどうかは、状況によります。

ほとんどのプラグインは WordPress Multisite でインストール可能ですが、アクティベーションとライセンスは作者ごとに異なります。

課題は、ライセンスがドメインごとに適用されるプラグインがあることです。これは、ネットワーク管理者が各新しいサイトで各プラグインのライセンスを手動で有効化する必要があることを意味します。

したがって、プラグインの作者に、WordPress Multisite でどのように機能するか、またライセンスを取得するために必要な特別な要件や手順について確認するのが最善です。