Multi-Tenancy ինտեգրում
Ultimate Multisite: Multi-Tenancy 1.2.0-ը փոխում է մի քանի ինտեգրման հպման կետեր՝ ինքնիշխան տենանտների, միգրացիայի ստուգման և տենանտի կենսա ցիկլի ավտոմատացման համար։
Տենանտի սկզբնավորման հոսք
Տենանտներ ստեղծող կամ փոփոխող ինտեգրումները պետք է հետևեն այս հերթականությանը՝
- Որոշեք տենանտի ռեեստրի գրառումը և մեկուսացման մոդելը։
- Ստեղծեք կամ ստուգեք տենանտի տվյալների բազայի գրողը։
- Սկզբնավորեք տենանտի սխեման։
- Տրամադրեք տենանտի օգտատերերին։
- Գրանցեք տենանտի երթուղավորումը և ֆայլային համակարգի ուղիները։
- Գործարկեք միգրացիայի ստուգումը՝ նախքան տենանտը հասանելի դարձնելը։
Մի ենթադրեք, որ ինքնիշխան տենանտը կարող է կրկին օգտագործել ցանցի տվյալների բազայի միացումը։ Օգտագործեք addon-ի տրամադրած տենանտի ռեեստրի և գրողի աբստրակցիաները։
SSO և REST hooks
Անվիճակ տենանտի ավտոմուտքը օգտագործում է կարճաժամկետ token-ներ՝ նպատակի claim-ով, JTI կրկնակի օգտագործման պաշտպանությամբ, ժամկետի առավելագույն սահմանով և origin-ի ամրակցմամբ։ Ինտեգրումները, որոնք ավելացնում են մուտքի կոճակներ կամ հեռավար կառավարման հղումներ, պետք է ստեղծեն տենանտի այցելություններ աջակցվող SSO հոսքի միջոցով՝ տենանտի մուտքի URL-ներ ուղղակիորեն կառուցելու փոխարեն։
Ցանցի կողմի API աուդիտի իրադարձությունները և օրական ամփոփումները հասանելի են ինքնիշխան տենանտների դարպասների համար։ Օգտագործեք այդ մատյանները, երբ վրիպազերծում եք արտաքին համակարգեր, որոնք կանչում են տենանտի կենսացիկլի վերջնակետեր։
Ինքնիշխան հաճախորդի գործողությունների URL-ներ
Ultimate Multisite v2.13.0-ը ինքնիշխան տենանտի հաճախորդի գործողությունները երթուղավորում է դեպի հիմնական կայք՝ Account-ի, վճարման ձևակերպման, վճարային տվյալների, հաշիվ-ապրանքագրի, կայքի, ձևանմուշի փոխման և դոմենի քարտեզագրման հոսքերի համար։ Ինտեգրումները, որոնք ցուցադրում են տենանտի կողմի կառավարման հղումներ, պետք է այդ գործողությունները ուղղեն հիմնական կայքի հաճախորդի վահանակին և ներառեն վա վերացված վերադարձի նպատակակետ, երբ օգտատերը պետք է կարողանա գործողությունն ավարտելուց հետո վերադառնալ տենանտ։
Օգտագործեք հիմնական SSO wrapper-ը միջդոմենային կառավարման հղումների համար՝
$url = wu_with_sso($main_site_customer_url);
Ստեղծված URL-ը շարունակում է ֆիլտրվելի լինել wu_sso_url-ի միջոցով, որը ստանում է SSO URL-ը, ընթացիկ օգտատիրոջը, նպատակային կայքի ID-ն և redirect-ի համատեքստը։ Add-on-ները կարող են օգտագործել այդ ֆիլտրը՝ մատակարարին հատուկ համատեքստ ավելացնելու կամ broker URL-ը փոխարինելու համար՝ պահպանելով Ultimate Multisite-ի token-ի վավերացումը։
Մի կրկնօրինակեք անդամակցության, հաշիվ-ապրանքագրի, վճարային հա սցեի, ձևանմուշի կամ դոմենի կառավարման վիճակը ինքնիշխան տենանտի ներսում։ Տենանտի Dashboard-ը դիտարկեք որպես գործարկիչ, իսկ հիմնական կայքի հաճախորդի վահանակը՝ որպես կառավարվող գործողությունների համար գրառումների հիմնական համակարգ։
Միգրացիայի ստուգում
Այն բանից հետո, երբ միգրացիան կամ կենսացիկլի ինտեգրումը փոխում է տենանտի տվյալները, գործարկեք ստուգման դարպասները՝
wp tenant verify-no-legacy --site=<site-id>հաստատում է, որ տենանտն այլևս կախված չէ հին ցանցային ուղիներից։wp tenant verify-sovereign-push --site=<site-id>հաստատում է, որ ինքնիշխան push առաջադրանքները կարող են մշակվել և դատարկվել։
Ինտեգրումները պետք է ձախողված ստուգումը դիտարկեն որպես տեղակայման արգելափակիչ և խուսափեն տենանտը live նշելուց, մինչև ձախողումը լուծվի։
Տենանտի ջնջում
Ջնջման հոսքերը պետք է կանչեն addon-ի teardown ուղին, որպեսզի տենանտի տվյալների բազայի հավատարմագրերը մաքրվեն։ Արտաքին ինտեգրումները կարող են հեռացնել մատակարարի ռեսուրսները teardown-ի հաջող ավարտից հետո, բայց չպետք է ջնջեն հոսթի տվյալների բազաները կամ թղթապանակները, քանի դեռ ստուգումը կամ async push առաջադրանքները դեռ աշխատում են։
Հնացած տվյալների բազայի router
Հին Database_Router-ը փոխարինվել է հնացման stub-ով։ Նոր ինտեգրումները պետք է տենանտները որոշեն ընթացիկ կայքի router-ի և տենանտի ռեեստրի API-ների միջոցով՝ հին router class-ից կախում ունենալու փոխարեն։