Интеграция за Multi-Tenancy
Ultimate Multisite: Multi-Tenancy 1.2.0 променя няколко интеграционни точки на допир за суверенни наематели, проверка на миграции и автоматизация на жизнения цикъл на наемателите.
Поток за първоначално зареждане на наемател
Интеграциите, които създават или променят наематели, трябва да следват този ред:
- Определете записа в регистъра на наемателя и модела на изолация.
- Създайте или проверете записващия модул за базата данни на наемателя.
- Инициализирайте схемата на наемателя.
- Осигурете потребителите на наемателя.
- Регистрирайте маршрутизирането и пътищата във файловата система на наемателя.
- Изпълнете проверка на миграцията, преди да изложите наемателя.
Не приемайте, че суверенен наемател може да използва повторно връзката към мрежовата база данни. Използвайте регистъра на наемателите и абстракциите за записване, предоставени от добавката.
SSO и REST hooks
Автоматичното влизане без състояние за наематели използва краткоживеещи токени с 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.
Не дублирайте състояние за членство, фактура, адрес за фактуриране, шаблон или управление на домейни вътре в суверенния наемател. Третирайте таблото на наемателя като стартер, а клиентския панел на основния сайт като системата на запис за управляваните действия.
Проверка на миграцията
След като миграция или интеграция на жизнения цикъл промени данните на наемателя, изпълнете проверъчните gate-ове:
wp tenant verify-no-legacy --site=<site-id>потвърждава, че наемателят вече не зависи от наследени пътища от страна на мрежата.wp tenant verify-sovereign-push --site=<site-id>потвърждава, че суверенните push задачи могат да се обработват и източват.
Интеграциите трябва да третират неуспешната проверка като блокер за внедряване и да избягват маркирането на наемател като live, докато проблемът не бъде решен.
Изтриване на наемател
Потоците за изтриване трябва да извикват пътя за teardown на добавката, така че идентификационните данни за базата данни на наемателя да бъдат почистени. Външните интеграции могат да премахнат ресурсите на доставчика след успешен teardown, но не трябва да изтриват бази данни или папки на хоста, докато проверката или асинхронните push задачи все още се изпълняват.
Оттеглен маршрутизатор на база данни
Наследеният Database_Router е заменен от stub за оттегляне. Новите интеграции трябва да определят наемателите чрез текущия маршрутизатор на сайта и API-тата на регистъра на наемателите, вместо да зависят от стария клас на маршрутизатора.