Інтеграція Multi-Tenancy
Ultimate Multisite: Multi-Tenancy 1.2.0 змінює кілька точок інтеграції для суверенних тенантів, перевірки міграції та автоматизації життєвого циклу тенанта.
Потік початкового налаштування тенанта
Інтеграції, які створюють або змінюють тенантів, мають дотримуватися такого порядку:
- Визначити запис реєстру тенанта та модель ізоляції.
- Створити або перевірити записувач бази даних тенанта.
- Ініціалізувати схему тенанта.
- Підготувати користувачів тенанта.
- Зареєструвати маршрутизацію тенанта та шляхи файлової системи.
- Запустити перевірку міграції перед відкриттям доступу до тенанта.
Не припускайте, що суверенний тенант може повторно використовувати підключення до мережевої бази даних. Використовуйте реєстр тенантів і абстракції записувача, надані додатком.
SSO та REST-хуки
Безстановий автологін тенанта використовує короткочасні токени з claim призначення, захистом JTI від повторного використання, обмеженням терміну дії та прив’язкою до походження. Інтеграції, які додають кнопки входу або посилання віддаленого керування, мають генерувати відвідування тенанта через підтримуваний потік SSO замість прямого конструювання URL входу тенанта.
Події аудиту API на боці мережі та щоденні зведення доступні для шлюзів суверенних тенантів. Використовуйте ці журнали під час налагодження зовнішніх систем, які викликають endpoint-и життєвого циклу тенанта.
URL дій суверенного клієнта
Ultimate Multisite v2.13.0 маршрутизує дії клієнта суверенного тенанта назад на основний сайт для потоків Account, checkout, виставлення рахунків, інвойсів, сайту, перемикання шаблонів і зіставлення доменів. Інтеграції, які відображають посилання керування на боці тенанта, мають спрямовувати ці дії на клієнтську панель основного сайту та включати перевірену ціль повернення, коли користувач повинен мати змогу повернутися до тенанта після завершення дії.
Використовуйте основну обгортку SSO для міждоменних посилань керування:
$url = wu_with_sso($main_site_customer_url);
Згенерований URL залишається фільтрованим через wu_sso_url, який отримує SSO URL, поточного користувача, ID цільового сайту та контекст перенаправлення. Додатки можуть використовувати цей фільтр, щоб додати контекст, специфічний для провайдера, або замінити URL брокера, зберігаючи перевірку токенів Ultimate Multisite.
Не дублюйте стан membership, інвойсів, платіжної адреси, шаблонів або керування доменами всередині суверенного тенанта. Розглядайте Dashboard тенанта як запускник, а клієнтську панель основного сайту — як систему запису для керованих дій.
Перевірка міграції
Після того як міграція або інтеграція життєвого циклу змінює дані тенанта, запустіть контрольні перевірки:
wp tenant verify-no-legacy --site=<site-id>підтверджує, що тенант більше не залежить від застарілих шляхів на боці мережі.wp tenant verify-sovereign-push --site=<site-id>підтверджує, що завдання суверенного push можуть оброблятися та завершуватися.
Інтеграції мають розглядати невдалу перевірку як блокер розгортання та уникати позначення тенанта як live, доки збій не буде усунено.
Видалення тенанта
Потоки видалення мають викликати шлях teardown додатка, щоб облікові дані бази даних тенанта були очищені. Зовнішні інтеграції можуть видаляти ресурси провайдера після успішного teardown, але не повинні видаляти бази даних або папки хоста, поки перевірка чи асинхронні push-завдання все ще виконуються.
Застарілий маршрутизатор бази даних
Застарілий Database_Router було замінено stub-ом deprecation. Нові інтеграції мають визначати тенантів через поточні API маршрутизатора сайту та реєстру тенантів, а не залежати від старого класу маршрутизатора.