मल्टी-टेनन्सी एकत्रीकरण

Ultimate Multisite: मल्टी-टेनन्सी 1.2.0 सार्वभौम टेनंट्स, स्थलांतर पडताळणी, आणि टेनंट जीवनचक्र स्वयंचलनासाठी अनेक एकत्रीकरण संपर्कबिंदू बदलते.

टेनंट बूटस्ट्रॅप प्रवाह

टेनंट्स तयार किंवा बदलणाऱ्या एकत्रीकरणांनी हा क्रम पाळावा:

1. टेनंट नोंदणी रेकॉर्ड आणि विलगीकरण मॉडेल निश्चित करा.
2. टेनंट डेटाबेस रायटर तयार करा किंवा पडताळा.
3. टेनंट स्कीमा बूटस्ट्रॅप करा.
4. टेनंट वापरकर्ते प्रोव्हिजन करा.
5. टेनंट रूटिंग आणि फाइलसिस्टम मार्ग नोंदणी करा.
6. टेनंट उघड करण्यापूर्वी स्थलांतर पडताळणी चालवा.

सार्वभौम टेनंट नेटवर्क डेटाबेस कनेक्शन पुन्हा वापरू शकतो असे गृहीत धरू नका. अॅडऑनने पुरवलेल्या टेनंट नोंदणी आणि रायटर अमूर्तीकरणांचा वापर करा.

SSO आणि REST हुक्स

स्टेटलेस टेनंट ऑटोलॉगिन अल्पायुषी टोकन्स वापरते ज्यात उद्देश दावा, JTI रीप्ले संरक्षण, कालबाह्यता मर्यादा, आणि ओरिजिन पिनिंग असते. लॉगिन बटणे किंवा दूरस्थ व्यवस्थापन दुवे जोडणाऱ्या एकत्रीकरणांनी टेनंट लॉगिन URLs थेट तयार करण्याऐवजी समर्थित SSO प्रवाहाद्वारे टेनंट भेटी तयार कराव्यात.

नेटवर्क-बाजूचे API लेखापरीक्षण इव्हेंट्स आणि दैनंदिन सारांश सार्वभौम टेनंट गेटवेजसाठी उपलब्ध आहेत. टेनंट जीवनचक्र endpoints कॉल करणाऱ्या बाह्य प्रणालींचे डीबगिंग करताना ते लॉग्स वापरा.

सार्वभौम ग्राहक कृती URLs

Ultimate Multisite v2.13.0 account, checkout, बिलिंग, चलन, साइट, टेम्पलेट-स्विचिंग, आणि डोमेन-मॅपिंग प्रवाहांसाठी सार्वभौम-टेनंट ग्राहक कृती पुन्हा मुख्य साइटकडे रूट करते. टेनंट-बाजूचे व्यवस्थापन दुवे रेंडर करणाऱ्या एकत्रीकरणांनी त्या कृती मुख्य-साइट ग्राहक पॅनेलकडे निर्देशित कराव्यात आणि कृती पूर्ण केल्यानंतर वापरकर्त्याला टेनंटकडे परत नेव्हिगेट करता यावे असे असल्यास पडताळलेले परतण्याचे लक्ष्य समाविष्ट करावे.

क्रॉस-डोमेन व्यवस्थापन दुव्यांसाठी core SSO wrapper वापरा:

$url = wu_with_sso($main_site_customer_url);

तयार झालेला URL wu_sso_url द्वारे फिल्टर करण्यायोग्य राहतो, ज्याला SSO URL, सध्याचा वापरकर्ता, लक्ष्य साइट ID, आणि रीडायरेक्ट संदर्भ मिळतो. अॅडऑन्स तो फिल्टर वापरून प्रदाता-विशिष्ट संदर्भ जोडू शकतात किंवा Ultimate Multisite चे टोकन पडताळणी जपून broker URL बदलू शकतात.

सार्वभौम टेनंटमध्ये membership, चलन, बिलिंग-पत्ता, टेम्पलेट, किंवा डोमेन-व्यवस्थापन स्थितीची पुनरावृत्ती करू नका. टेनंट Dashboard ला लाँचर म्हणून आणि मुख्य-साइट ग्राहक पॅनेलला व्यवस्थापित कृतींसाठी नोंदीची अधिकृत प्रणाली म्हणून माना.

स्थलांतर पडताळणी

स्थलांतर किंवा जीवनचक्र एकत्रीकरणाने टेनंट डेटा बदलल्यानंतर, पडताळणी गेट्स चालवा:

• wp tenant verify-no-legacy --site=<site-id> टेनंट आता जुन्या नेटवर्क-बाजूच्या मार्गांवर अवलंबून नाही याची पुष्टी करते.
• wp tenant verify-sovereign-push --site=<site-id> सार्वभौम push jobs प्रक्रिया करून रिकामे होऊ शकतात याची पुष्टी करते.

एकत्रीकरणांनी अयशस्वी पडताळणीला तैनाती अडथळा मानावे आणि अपयश सोडवले जाईपर्यंत टेनंट live म्हणून चिन्हांकित करणे टाळावे.

टेनंट हटवणे

हटवण्याच्या प्रवाहांनी अॅडऑन teardown मार्ग कॉल करावा जेणेकरून टेनंट डेटाबेस credentials साफ केले जातील. Teardown यशस्वी झाल्यानंतर बाह्य एकत्रीकरणे प्रदाता संसाधने काढू शकतात, परंतु पडताळणी किंवा async push jobs अजूनही चालू असताना host डेटाबेसेस किंवा folders हटवू नयेत.

कालबाह्य डेटाबेस राउटर

जुना Database_Router deprecation stub ने बदलला आहे. नवीन एकत्रीकरणांनी जुन्या router class वर अवलंबून राहण्याऐवजी सध्याच्या साइट राउटर आणि टेनंट नोंदणी APIs द्वारे टेनंट्स निश्चित करावेत.