Skip to main content

ការរួមបញ្ចូលពហុភតិកៈ

Ultimate Multisite: Multi-Tenancy 1.2.0 ផ្លាស់ប្តូរចំណុចរួមបញ្ចូលជាច្រើន សម្រាប់ភតិកៈឯករាជ្យ ការផ្ទៀងផ្ទាត់ការផ្លាស់ទី និងស្វ័យប្រវត្តិកម្មវដ្តជីវិតភតិកៈ។

លំហូរចាប់ផ្តើមភតិកៈ

ការរួមបញ្ចូលដែលបង្កើត ឬកែប្រែភតិកៈ គួរធ្វើតាមលំដាប់នេះ៖

  1. ដោះស្រាយកំណត់ត្រាបញ្ជីភតិកៈ និងគំរូដាច់ដោយឡែក។
  2. បង្កើត ឬផ្ទៀងផ្ទាត់អ្នកសរសេរមូលដ្ឋានទិន្នន័យរបស់ភតិកៈ។
  3. ចាប់ផ្តើម schema របស់ភតិកៈ។
  4. ផ្តល់អ្នកប្រើភតិកៈ។
  5. ចុះបញ្ជីផ្លូវបញ្ជូនភតិកៈ និងទីតាំងប្រព័ន្ធឯកសារ។
  6. ដំណើរការការផ្ទៀងផ្ទាត់ការផ្លាស់ទី មុនពេលបង្ហាញភតិកៈឱ្យប្រើ។

កុំសន្មតថាភតិកៈឯករាជ្យអាចប្រើការភ្ជាប់មូលដ្ឋានទិន្នន័យបណ្តាញឡើងវិញបាន។ ប្រើបញ្ជីភតិកៈ និងអាប់ស្ត្រាក់អ្នកសរសេរ ដែលផ្តល់ដោយ addon។

SSO និង REST hooks

ការចូលស្វ័យប្រវត្តិរបស់ភតិកៈដែលគ្មានស្ថានភាព ប្រើ token អាយុកាលខ្លីដែលមាន purpose claim ការការពារ JTI replay កម្រិតផុតកំណត់ និងការភ្ជាប់ប្រភព។ ការរួមបញ្ចូលដែលបន្ថែមប៊ូតុងចូល ឬតំណគ្រប់គ្រងពីចម្ងាយ គួរបង្កើតការចូលមើលរបស់ភតិកៈតាមលំហូរ SSO ដែលគាំទ្រ ជំនួសឱ្យការបង្កើត URL ចូលរបស់ភតិកៈដោយផ្ទាល់។

ព្រឹត្តិការណ៍សវនកម្ម API ខាងបណ្តាញ និងសេចក្តីសង្ខេបប្រចាំថ្ងៃ អាចប្រើបានសម្រាប់ច្រកចូលភតិកៈឯករាជ្យ។ ប្រើកំណត់ហេតុទាំងនោះ ពេលកែកំហុសប្រព័ន្ធខាងក្រៅដែលហៅ endpoint វដ្តជីវិតភតិកៈ។

URL សកម្មភាពអតិថិជនឯករាជ្យ

Ultimate Multisite v2.13.0 បញ្ជូនសកម្មភាពអតិថិជនរបស់ភតិកៈឯករាជ្យត្រឡប់ទៅ site ចម្បង សម្រាប់លំហូរ account, checkout, billing, invoice, site, ការប្តូរ template និងការភ្ជាប់ domain។ ការរួមបញ្ចូលដែលបង្ហាញតំណគ្រប់គ្រងខាងភតិកៈ គួរចង្អុលសកម្មភាពទាំងនោះទៅកាន់ផ្ទាំងអតិថិជនរបស់ site ចម្បង ហើយបញ្ចូលគោលដៅត្រឡប់ដែលបានផ្ទៀងផ្ទាត់ នៅពេលអ្នកប្រើគួរអាចត្រឡប់ទៅភតិកៈវិញក្រោយបញ្ចប់សកម្មភាព។

ប្រើ wrapper SSO ស្នូលសម្រាប់តំណគ្រប់គ្រងឆ្លង domain៖

$url = wu_with_sso($main_site_customer_url);

URL ដែលបង្កើតនៅតែអាចត្រូវបានត្រងតាម wu_sso_url ដែលទទួល SSO URL អ្នកប្រើបច្ចុប្បន្ន ID site គោលដៅ និងបរិបទបញ្ជូនបន្ត។ Add-on អាចប្រើ filter នោះ ដើម្បីបន្ថែមបរិបទជាក់លាក់របស់ provider ឬជំនួស broker URL ខណៈរក្សាការផ្ទៀងផ្ទាត់ token របស់ Ultimate Multisite។

កុំចម្លងស្ថានភាព membership, invoice, billing-address, template ឬការគ្រប់គ្រង domain នៅក្នុងភតិកៈឯករាជ្យ។ ចាត់ទុក dashboard របស់ភតិកៈជា launcher ហើយផ្ទាំងអតិថិជនរបស់ site ចម្បងជាប្រព័ន្ធកំណត់ត្រាសម្រាប់សកម្មភាពដែលបានគ្រប់គ្រង។

ការផ្ទៀងផ្ទាត់ការផ្លាស់ទី

បន្ទាប់ពីការផ្លាស់ទី ឬការរួមបញ្ចូលវដ្តជីវិតបានផ្លាស់ប្តូរទិន្នន័យភតិកៈ សូមដំណើរការច្រកផ្ទៀងផ្ទាត់៖

  • wp tenant verify-no-legacy --site=<site-id> បញ្ជាក់ថាភតិកៈមិនអាស្រ័យលើផ្លូវចាស់ខាងបណ្តាញទៀតទេ។
  • wp tenant verify-sovereign-push --site=<site-id> បញ្ជាក់ថាការងារ push ឯករាជ្យអាចដំណើរការ និងបង្ហូរចេញបាន។

ការរួមបញ្ចូលគួរចាត់ទុកការផ្ទៀងផ្ទាត់ដែលបរាជ័យ ជាឧបសគ្គដល់ការដាក់ឱ្យប្រើ ហើយជៀសវាងការសម្គាល់ភតិកៈថា live រហូតដល់បានដោះស្រាយបញ្ហា។

ការលុបភតិកៈ

លំហូរលុបគួរហៅផ្លូវ teardown របស់ addon ដើម្បីសម្អាតលិខិតសម្គាល់មូលដ្ឋានទិន្នន័យរបស់ភតិកៈ។ ការរួមបញ្ចូលខាងក្រៅអាចលុបធនធាន provider បន្ទាប់ពី teardown ជោគជ័យ ប៉ុន្តែមិនគួរលុបមូលដ្ឋានទិន្នន័យ ឬថតរបស់ host ខណៈការផ្ទៀងផ្ទាត់ ឬការងារ push អសមកាលនៅតែដំណើរការ។

Router មូលដ្ឋានទិន្នន័យដែលឈប់ណែនាំឱ្យប្រើ

Database_Router ចាស់ត្រូវបានជំនួសដោយ stub deprecation។ ការរួមបញ្ចូលថ្មីគួរដោះស្រាយភតិកៈតាម site router បច្ចុប្បន្ន និង API បញ្ជីភតិកៈ ជំនួសឱ្យការពឹងផ្អែកលើ class router ចាស់។