マルチテナンシー統合
Ultimate Multisite: マルチテナンシー 1.2.0 では、独立テナント、移行検証、テナントライフサイクル自動化に関する複数の統合接点が変更されています。
テナントのブートストラップフロー
テナントを作成または変更する統合は、次の順序に従ってください。
- テナントレジストリレコードと分離モデルを解決する。
- テナントデータベースライターを作成または検証する。
- テナントスキーマをブートストラップする。
- テナントユーザーをプロビジョニングする。
- テナントのルーティングとファイルシステムパスを登録する。
- テナントを公開する前に移行検証を実行する。
独立テナントがネットワークデータベース接続を再利用できると想定しないでください。アドオンが提供するテナントレジストリとライター抽象化を使用してください。
SSO と REST フック
ステートレスなテナント自動ログインでは、用途クレーム、JTI リプレイ保護、有効期限上限、オリジン固定を備えた短期トークンを使用します。ログインボタンやリモート管理リンクを追加する統合では、テナントログイン URL を直接組み立てるのではなく、対応済みの SSO フローを通じてテナント訪問を生成してください。
ネットワーク側の API 監査イベントと日次サマリーは、独立テナントゲートウェイで利用できます。テナントライフサイクル endpoint を呼び出す外部システムをデバッグするときは、これらのログを使用してください。
独立顧 客アクション URL
Ultimate Multisite v2.13.0 は、独立テナントの顧客アクションを、Account、チェックアウト、請求、請求書、サイト、テンプレート切り替え、ドメインマッピングの各フローについてメインサイトへルーティングします。テナント側の管理リンクを表示する統合では、それらのアクションをメインサイトの顧客パネルに向け、アクション完了後にユーザーがテナントへ戻れるようにする必要がある場合は、検証済みの戻り先を含めてください。
クロスドメイン管理リンクには、コアの SSO ラッパーを使用してください。
$url = wu_with_sso($main_site_customer_url);
生成された URL は引き続き wu_sso_url でフィルター可能で す。このフィルターは、SSO URL、現在のユーザー、対象サイト ID、リダイレクトコンテキストを受け取ります。アドオンはこのフィルターを使って、プロバイダー固有のコンテキストを追加したり、Ultimate Multisite のトークン検証を維持したままブローカー URL を置き換えたりできます。
メンバーシップ、請求書、請求先住所、テンプレート、ドメイン管理の状態を独立テナント内で重複して保持しないでください。テナント Dashboard は起動元として扱い、メインサイトの顧客パネルを管理アクションの信頼できる記録元として扱ってください。
移行検証
移行またはライフサイクル統合によってテナントデータを変更した後は、検証ゲートを実行してください。
wp tenant verify-no-legacy --site=<site-id>は、テナントが従来のネットワーク側パスに依存しなくなっていることを確認します。wp tenant verify-sovereign-push --site=<site-id>は、独立プッシュジョブを処理し、キューを空にできることを確認します。
統合では、検証失敗をデプロイのブロッカーとして扱い、失敗が解決されるまでテナントを本番公開済みとしてマークしないでください。
テナント削除
削除フローでは、テナン トデータベース認証情報がクリーンアップされるように、アドオンのティアダウンパスを呼び出してください。外部統合は、ティアダウンの成功後にプロバイダーリソースを削除できますが、検証または非同期プッシュジョブがまだ実行中の間は、ホストデータベースやフォルダーを削除しないでください。
非推奨のデータベースルーター
従来の Database_Router は非推奨スタブに置き換えられました。新しい統合では、古いルータークラスに依存するのではなく、現在のサイトルーターとテナントレジストリ API を通じてテナントを解決してください。