Ultimate Multisite ១០១

Ultimate Multisite គឺជា plugin មួយសម្រាប់ WordPress Multisite ដែលអនុញ្ញាតឱ្យអ្នកផ្តល់សេវា WaaS ឬ Websites as a Service ដល់អតិថិជន។ មុននឹងយើងចាប់ផ្តើមរៀនពីរបៀបដែល Ultimate Multisite អាចជួយអាជីវកម្ម និងអតិថិជនរបស់អ្នកបាន មានចំណេះដឹងជាមូលដ្ឋានមួយចំនួនដែលយើងត្រូវទទួលបាន។

WordPress Multisite

ពួកយើងភាគច្រើនស្គាល់ការដំឡើង WordPress ដែលមានស្តង់ដារ។ អ្នកមិនថាបង្កើតវាតាមរយៈ control panel របស់ hosting provider ឬសម្រាប់អ្នកក្លាហាន អ្នកអាចរៀបចំ web server និង database ថ្មី ទាញយក core files ហើយចាប់ផ្តើមដំណើរការដំឡើងបានទេ។

វាមិនមែនសម្រាប់គេហទំព័រ WordPress រាប់លានកន្លែងជុំវិញពិភពលោកនោះទេ ប៉ុន្តែពីទស្សនៈរបស់ក្រុមហ៊ុនអភិវឌ្ឍន៍ (agency) ឬអ្នកផ្តល់ hosting សូមពិភាក្សាអំពីបរិមាណមួយភ្លែត។

ខណៈពេលដែលវាស្រួលក្នុងការបង្កើតគេហទំព័រ WordPress តែមួយ ឬសូម្បីតែរយគេហទំព័រតាមរយៈ control panel អូតូម៉ាទិក បញ្ហាឆាប់នឹងចាប់ផ្តើមលេចចេញមកនៅពេលដែលការគ្រប់គ្រងគេហទំព័រទាំងនោះធ្លាក់ទៅលើអ្នក។ ប្រសិនបើមិនបានគ្រប់គ្រងទេ អ្នកនឹងក្លាយជាគោលដៅដ៏ល្អសម្រាប់ malware។ ការគ្រប់គ្រងមានន័យថាជាការប្រើប្រាស់កម្លាំង និងធនធាន ហើយទោះបីជាមានឧបករណ៍ និង plugin ខាងក្រៅដែលអាចជួយសម្រួលដល់ការគ្រប់គ្រង និងការរដ្ឋបាលគេហទំព័រ WordPress ក៏ដោយ ការពិតដែលថាអតិថិជនរក្សាទុកការចូលប្រើជាអ្នកគ្រប់គ្រង មានន័យថាការខិតខំប្រឹងប្រែងទាំងនេះអាចនឹងត្រូវបានយកឈ្នះបានយ៉ាងងាយស្រួល។

នៅក្នុង core របស់វា WordPress បានផ្តល់នូវមុខងារមួយដែលមានឈ្មោះថា ‘Multisite’ ដែលមានប្រភពដើមត្រលប់ទៅឆ្នាំ ២០១០ នៅពេលដែល WordPress 3.0 បើកដំណើរការ។ ចាប់តាំងពីពេលនោះមក វាបានទទួលការកែសម្រួលជាច្រើនដែលមានគោលបំណងណែនាំមុខងារថ្មីៗ និងពង្រឹងសុវត្ថិភាព។

និយាយឱ្យងាយគឺ WordPress multisite អាចត្រូវបានគេគិតថាដូចនេះ៖ សាកលវិទ្យាល័យមួយរក្សាទុកការដំឡើង WordPress តែមួយ ប៉ុន្តែសាកលវិទ្យាល័យនីមួយៗរក្សាទុកគេហទំព័រ WordPress របស់ខ្លួនផ្ទាល់។

បណ្តាញ (The Network)

និយាយទៅក្នុង WordPress វិញ បណ្តាញ multisite network គឺជាកន្លែងដែលអ្នកអាចគ្រប់គ្រង subsites ចំនួនច្រើនពី dashboard តែមួយ។ ទោះបីជាការបង្កើតបណ្តាញ multisite ខុសគ្នាទៅតាមអ្នកផ្តល់ hosting ក៏ដោយ ប៉ុន្តែលទ្ធផលចុងក្រោយគឺភាគច្រើនវាត្រូវការការកំណត់បន្ថែមមួយចំនួននៅក្នុងឯកសារ wp-config.php ដើម្បីប្រាប់ WordPress ថាវាកំពុងដំណើរការក្នុងរបៀបជាក់លាក់នេះ។

មានភាពខុសគ្នាច្រើនរវាងបណ្តាញ multisite និងការដំឡើង WordPress ដែលនៅតែឯង (stand-alone installation) ដែលយើងនឹងពិភាក្សាខ្លីៗ។

Subdomain ប៉ះ vs. Subdirectory

ការសម្រេចចិត្តមួយដែលអ្នកត្រូវធ្វើភ្លាមៗបំផុតគឺថាការដំឡើង multisite នោះនឹងដំណើរការជាមួយ subdirectories ឬ subdomains? Ultimate Multisite អាចដំណើរការបានល្អទាំងពីរជម្រើស ប៉ុន្តែមានភាពខុសគ្នានៃស្ថាបត្យកម្មរវាងការកំណត់ទាំងពីរនេះ។

នៅក្នុងការកំណត់ subdirectory បណ្តាញគេហទំព័រនឹងទទួលមេរៀន (inherit) ផ្លូវមួយផ្អែកលើឈ្មោះដែនចម្បង។ ឧទាហរណ៍ បណ្តាញគេហទំព័រដែលមានស្លាកថា ‘site1’ នឹងមាន URL ពេញជា https://domain.com/site1។ ចំណែកឯនៅក្នុងការកំណត់ subdomain បណ្តាញគេហទំព័រនោះនឹងមាន subdomain ផ្ទាល់ខ្លួនដែលបានមកពីឈ្មោះដែនចម្បង។ ដូច្នេះគេហទំព័រដែលមានស្លាកថា ‘site1’ នឹងមាន URL ពេញជា https://site1.domain.com/។

ខណៈពេលដែលជម្រើសទាំងពីរនេះគឺត្រឹមត្រូវទាំងអស់ ប៉ុន្តែការប្រើប្រាស់ subdomains ផ្តល់នូវអត្ថប្រយោជន៍មួយចំនួន ប៉ុន្តែវាក៏ទាមទារឱ្យមានការគិត និងការរៀបចំផែនការស្ថាបត្យកម្មច្រើនជាងមុនផងដែរ។

ទាក់ទងនឹង DNS ការប្រើប្រាស់ subdirectories គឺជារឿងដែលមិនសូវពិបាកប៉ុន្មានទេ។ ដោយសារគេហទំព័រក្នុងបណ្តាញគឺជាកូនរបស់ផ្លូវមេតែមួយ មានឈ្មោះដែន (domain name) តែមួយក៏គ្រប់គ្រាន់សម្រាប់ឈ្មោះដែនសំខាន់។ ចំពោះ subdomains បញ្ហាគឺស្មុគស្មាញជាងនេះបន្តិច ដោយតម្រូវឱ្យមានការបញ្ចូល CNAME entry ដាច់ដោយឡែកសម្រាប់គេហទំព័រក្នុងបណ្តាញនីមួយៗ ឬប្រើ wildcard (*) entry នៅក្នុងកំណត់ត្រា DNS។

ផ្នែកមួយទៀតដែលត្រូវពិចារណាគឺសុវត្ថិភាព SSL និងការចេញប្រើប្រាស់ និងការប្រើប្រាស់វិញ្ញាបនបត្រ SSL។ ក្នុងការកំណត់រចនាសម្ព័ន្ធ subdirectory វិញ្ញាបនបត្រដែនតែមួយអាចត្រូវបានប្រើបាន ដោយសារគេហទំព័រក្នុងបណ្តាញគ្រាន់តែជាផ្លូវនៃឈ្មោះដែនសំខាន់។ ដូច្នេះ វិញ្ញាបនបត្រសម្រាប់ domain.com នឹងផ្តល់ SSL គ្រប់គ្រាន់សម្រាប់ https://domain.com/site1, https://domain.com/site2 និងផ្សេងៗទៀត។

នៅក្នុងការកំណត់រចនាសម្ព័ន្ធ subdomain ការប្រើប្រាស់ wildcard SSL certificate គឺជាជម្រើសមួយដែលគេប្រើញឹកញាប់បំផុត។ វិញ្ញាបនបត្រ SSL ប្រភេទនេះផ្តល់ការเข้ารหัส (encryption) សម្រាប់ដែនとその subdomains។ ដូច្នេះ wildcard SSL certificate នឹងផ្តល់ការเข้ารหัสសម្រាប់ https://site1.domain.com, https://site2.domain.com និងhttps://domain.com ផ្ទាល់ផងដែរ។

ទោះបីជាមានជម្រើសផ្សេងទៀតក៏ដោយ ប៉ុន្តែជម្រើសទាំងនេះច្រើនតែមានវិសាលភាព និងការអនុវត្តដែលកំណត់ ហើយតម្រូវឱ្យមានការកំណត់រចនាសម្ព័ន្ធ និងការពិចារណាបន្ថែមទាក់ទងនឹងភាពសមស្រប។

Plugins និង Themes

អ្វីដែល WordPress ផ្តល់ឱ្យក៏វាអាចយកទៅដែរ ជាពិសេសពីទស្សនៈរបស់អតិថិជន។ ប្រសិនបើអ្នកគ្រប់គ្រងគេហទំព័រ (site administrator) ដំឡើង plugin ដែលមិនល្អ ឬមិនរក្សាការដំឡើងរបស់ខ្លួនឱ្យទាន់សម័យនោះ អ្នកដែលរងគ្រោះ និងជាអ្នកទទួលរងផលប៉ះពាល់តែមួយគត់គឺខ្លួនឯងផ្ទាល់។ ប៉ុន្តែប្រសិនបើអ្នកគ្រប់គ្រងគេហទំព័រដំឡើង plugin មិនល្អនៅលើការដំឡើង multisite វាបង្កើតជនរងគ្រោះសម្រាប់គ្រប់គេហទំព័រទាំងអស់ដែលបានដំឡើងនៅក្នុងបណ្តាញនោះ។

ដោយសារតែเหตุผลนี้ เมื่อตั้งค่าเป็น WordPress multisite ระบบจะลบความสามารถในการติดตั้งปลั๊กอินและธีมออกจากผู้ดูแลระบบของแต่ละไซต์ และย้ายความสามารถนั้นไปให้บทบาทของผู้ดูแลระบบเครือข่าย (network administrator) หรือ 'super admin' ที่ถูกสร้างขึ้นใหม่แทน บทบาทที่มีสิทธิ์นี้สามารถตัดสินใจได้ว่าจะอนุญาตให้ผู้ดูแลระบบของไซต์ในเครือข่ายเห็นหรือเข้าถึงเมนูปลั๊กอินในแดชบอร์ดของตนหรือไม่ และหากอนุญาตแล้ว สิทธิ์ดังกล่าวจะครอบคลุมถึงการ เปิดใช้งาน หรือ ปิดใช้งาน ปลั๊กอินด้วยหรือไม่

ในส่วนนี้ ผู้ดูแลระบบเครือข่ายมีหน้าที่รับผิดชอบในการติดตั้งปลั๊กอินและธีมเข้าสู่เครือข่าย และมอบสิทธิ์เพื่อให้ผู้ดูแลไซต์ต่างๆ ในเครือข่ายสามารถใช้ปลั๊กอินและธีมเหล่านั้นได้ ผู้ดูแลไซต์ไม่สามารถติดตั้งปลั๊กอินหรือธีมที่ไม่ได้กำหนดให้กับไซต์ของตนได้

ผู้ใช้และผู้ดูแลระบบ (Users and Administrators)

ใน WordPress Multisite ไซต์ทั้งหมดในเครือข่ายจะแชร์ฐานข้อมูลเดียวกัน ดังนั้นจึงแชร์ผู้ใช้ บทบาท และความสามารถเหมือนกัน วิธีคิดที่เหมาะสมที่สุดคือ ผู้ใช้ทุกคนเป็นสมาชิกของเครือข่าย ไม่ใช่ไซต์ใดไซต์หนึ่งโดยเฉพาะ

จากความเข้าใจนี้ อาจไม่พึงประสงค์ที่จะอนุญาตให้สร้างผู้ใช้ และด้วยเหตุนี้ WordPress Multisite จึงลบความสามารถในการสร้างผู้ใช้ออกจากผู้ดูแลระบบของแต่ละไซต์ และย้ายไปอยู่ที่บทบาทของผู้ดูแลระบบเครือข่าย ในทางกลับกัน ผู้ดูแลระบบเครือข่ายสามารถมอบสิทธิ์ที่จำเป็นให้กับผู้ดูแลระบบไซต์ เพื่อให้พวกเขาสามารถสร้างบัญชีผู้ใช้สำหรับไซต์ของตนเองได้

ย้ำอีกครั้งว่า แม้ว่าบัญชีผู้ใช้นั้นจะดูเหมือนเกี่ยวข้องกับไซต์ที่พวกเขาอยู่ แต่ในความเป็นจริงแล้วมันถูกจัดสรรให้กับเครือข่ายและต้องมีเอกลักษณ์เฉพาะกันทั่วทั้งเครือข่าย อาจมีบางกรณีที่ชื่อผู้ใช้ไม่สามารถลงทะเบียนได้เนื่องจากเหตุผลนี้

ទោះបីជាវាមិនមែនជាគំនិតថ្មីនៅក្នុងប្រព័ន្ធសាជីវកម្មក៏ដោយ ប៉ុន្តែការចុះឈ្មោះអ្នកប្រើប្រាស់ និងការផ្ទៀងផ្ទាត់អត្តសញ្ញាណតែមួយនេះ តែងតែពិបាកយល់សម្រាប់អ្នកដែលធ្លាប់ប្រើការដំឡើង WordPress ដាច់ដោយឡែក ដែលការគ្រប់គ្រងអ្នកប្រើប្រាស់គឺងាយស្រួលជាង។

Media (មេឌៀ)

នៅពេលដែលគេហទំព័រជាបណ្តាញ (Network sites) ចែករំលែកមូលដ្ឋានទិន្នន័យតែមួយនៅក្នុង WordPress Multisite ពួកគេនឹងរក្សាទុកផ្លូវ (paths) ដាច់ដោយឡែកនៅលើប្រព័ន្ធឯកសារ (filesystem) សម្រាប់ឯកសារមេឌៀ។

ទីតាំងស្តង់ដាររបស់ WordPress (wp-content/uploads) នៅតែមានដូចដើម ប៉ុន្តែផ្លូវរបស់វាត្រូវបានផ្លាស់ប្តូរដើម្បីឆ្លុះបញ្ចាំងពីអត្តសញ្ញាណប្លែកៗនៃគេហទំព័រជាបណ្តាញនោះ។ ជាលទ្ធផល ឯកសារមេឌៀសម្រាប់គេហទំព័រជាបណ្តាញមួយនឹងបង្ហាញដូចជា wp-contents/uploads/site/[id]។

Permalinks (ផ្លូវអចិន្ត្រៃយ៍)

យើងបានលើកឡើងពីមុនថា មានគុណសម្បត្តិពិសេសនៃការកំណត់រចនាសម្ព័ន្ធ subdomain បើប្រៀបធៀបនឹង subdirectory ហើយនេះគឺជាផ្លូវ (paths)។

នៅក្នុងការកំណត់រចនាសម្ព័ន្ធ subdirectory គេហទំព័រចម្បង (គេហទំព័រដំបូងដែលបង្កើតនៅពេលបង្កើតបណ្តាញ) និងគេហទំព័ររងជាបណ្តាញត្រូវតែប្រើផ្លូវដូចគ្នាដែលនាំទៅកាន់ឈ្មោះដែន។ ការធ្វើបែបនេះអាចបង្កឱ្យមានការប៉ះទង្គិចគ្នាច្រើន។

សម្រាប់អត្ថបទ (posts) គេបានបន្ថែមផ្លូវ /blog/ ជាកាតព្វកិច្ចនៅលើគេហទំព័រចម្បង ដើម្បីការពារការជួបគ្នាជាមួយគេហទំព័រជាបណ្តាញ។ មានន័យថា Permalinks ដែលមើលទៅស្អាតៗដូចជា ‘Post name’ នឹងបង្ហាញជា domain.name/blog/post-name/

នៅក្នុងការកំណត់រចនាសម្ព័ន្ធ subdomain ការធ្វើសកម្មភាពនេះមិនចាំបាច់ទេ ព្រោះគេហទំព័រជាបណ្តាញនីមួយៗទទួលបានអត្ថប្រយោជន៍ពីការបំបែកឈ្មោះដែនទាំងស្រុង ហើយដូច្នេះមិនចាំបាច់ពឹងផ្អែកលើផ្លូវតែមួយទេ។ ផ្ទុយទៅវិញ ពួកគេរក្សាទុកផ្លូវដាច់ដោយឡែករបស់ខ្លួនដោយផ្អែកលើ subdomain របស់ពួកគេ។

Static Pages (ទំព័រឋិតិវន្ត)

នៅក្នុងការកំណត់ subdirectory មានលទ្ធភាពនៃឈ្មោះដែលជាន់គ្នាអាចកើតមានលើទំព័រឋិតិវន្ត (static pages) ដូចជាគេហទំព័រចម្បង និងគេហទំព័រក្នុងបណ្តាញ (network sites) ដែលប្រើផ្លូវ (path) ដូចគ្នា។

ដើម្បីការពារបញ្ហានេះ WordPress មានវិធីមួយសម្រាប់ដាក់បញ្ជីឈ្មោះដែលមិនអនុញ្ញាត (blacklist) ដើម្បីកុំឱ្យវាជាន់គ្នានិងឈ្មោះនៃគេហទំព័រដំបូង។ ជាធម្មតា អ្នកគ្រប់គ្រងបណ្តាញនឹងបញ្ចូលផ្លូវឫស (root paths) នៃទំព័ររបស់គេហទំព័រចម្បង។

នៅក្នុងការកំណត់ subdomain លទ្ធភាពនៃបញ្ហាឈ្មោះជាន់គ្នានេះត្រូវបានកាត់បន្ថយដោយសារតែ subdomain គឺមានលក្ខណៈប្លែកសម្រាប់គេហទំព័រក្នុងបណ្តាញ ហើយមិនពាក់ព័ន្ធអ្វីជាមួយគេហទំព័រចម្បងឡើយ។

ការចុះឈ្មោះ (Registration)

នៅក្នុងការកំណត់បណ្តាញរបស់ WordPress Multisite មានជម្រើសថ្មីៗសម្រាប់ការចុះឈ្មោះអ្នកប្រើប្រាស់ ដែលអនុញ្ញាតឱ្យអ្នកប្រើប្រាស់ថ្មី និងអ្នកប្រើប្រាស់ដែលមានស្រាប់បង្កើតគេហទំព័របាន។

ខុសពីការដំឡើង WordPress ដែលដំណើរការដោយឯករាជ្យ (stand-alone installations) គេហទំព័រក្នុងបណ្តាញមិនរក្សាទុកជម្រើសដែលធ្លាប់ស្គាល់សម្រាប់ការចុះឈ្មោះអ្នកប្រើប្រាស់ ឬការកំណត់តួនាទី (roles) សម្រាប់អ្នកចុះឈ្មោះទាំងនោះទេ។

នៅពេលបង្កើតគណនីអ្នកប្រើប្រាស់ គណនីទាំងនោះនឹងត្រូវបានបង្កើតនៅកម្រិតបណ្តាញ។ ដូច្នេះជំនួសឱ្យការជាកម្មសិទ្ធិរបស់គេហទំព័រជាក់លាក់ណាមួយ ពួកវាស្ថិតនៅក្នុងបណ្តាញវិញ។ ការធ្វើបែបនេះមានគុណសម្បត្តិ និងគុណវិបត្តិមួយចំនួន។

ឧទាហរណ៍ suppose WordPress Multisite របស់អ្នកធ្វើការក្នុងអាជីវកម្មព័ត៌មាន។ អ្នកនឹងបង្កើត multisite ហើយបន្ទាប់មកបង្កើត sites បណ្តាញសម្រាប់ផ្នែកហិរញ្ញវត្ថុ បច្ចេកវិទ្យា ការកម្សាន្ត និងផ្នែកផ្សេងៗទៀតដែលចាប់អារម្មណ៍ផ្សេងៗគ្នា ខណៈពេលដែលរក្សាការគ្រប់គ្រងរួមលើ plugins និង themes។ ក្នុងនោះ site បណ្តាញនីមួយៗនឹងមានកម្រិតនៃការគ្រប់គ្រងខ្ពស់ជាងលើរូបរាង និងបទពិសោធន៍អ្នកប្រើប្រាស់នៃ site បណ្តាញរបស់ពួកគេជាង custom post types ឬ regular post categories។

ដល់ចំណុចនេះ នៅពេលដែលអ្នកប្រើប្រាស់ចូលログイン ពួកគេនឹងចូលទៅក្នុង network ហើយទីបំផុតត្រូវបានចូលទៅកាន់គ្រប់ network site ក៏ដោយ ដើម្បីផ្តល់នូវបទពិសោធន៍រលូន។ ប្រសិនបើ site ថ្មីរបស់អ្នកផ្អែកលើការជាវ (subscription based) នោះនេះគឺជាដំណោះស្រាយ និងលទ្ធផលដ៏ល្អបំផុត។

ទោះជាយ៉ាងណាក៏ដោយ ប្រសិនបើគោលបំណង និងធម្មជាតិដែលគ្រោងទុកនៃ multisite គឺដើម្បីផ្តល់នូវ sites បណ្តាញផ្សេងៗគ្នាដែលគ្មានទំនាក់ទំនងអ្វីជាមួយគ្នា វាជារឿងធម្មតាដែលតម្រូវឱ្យមាន plugins ខាងក្រៅ ឬបន្ថែម ដើម្បីគ្រប់គ្រង user roles។

Domain និង SSL

សូមនិយាយអំពីការដំឡើង WordPress Multisite ដែលស្ទើរតែគេមើលរំលង - Wordpress.com។ នេះគឺជាឧទាហរណ៍ដ៏ធំបំផុតនៃការប្រើប្រាស់ WordPress multisite ហើយបង្ហាញពីសមត្ថភាពដ៏ទូលំទូលាយរបស់វាក្នុងការត្រូវបានកែសម្រួល និងបង្កើតឱ្យស្របតាមគោលបំណងជាក់លាក់មួយ។

នៅថ្ងៃនេះនៅលើអ៊ីនធឺណិតទំនើប ការប្រើប្រាស់ SSL គឺស្ទើរតែជាការបង្ខំ ហើយអ្នកគ្រប់គ្រង network នៃ WordPress multisites ក៏កំពុងជួបនឹងបញ្ហាទាំងនេះឆាប់ៗនេះដែរ។

នៅក្នុងការកំណត់ subdomain sites ត្រូវបានបង្កើតឡើងដោយផ្អែកលើឈ្មោះ domain មូលដ្ឋាន។ ដូច្នេះ site ដែលដាក់ស្លាកថា ‘site1’ នឹងត្រូវបានបង្កើតជា ‘site1.domain.com’។ ដោយប្រើ wildcard SSL certificate អ្នកគ្រប់គ្រង network អាចដោះស្រាយបញ្ហានេះបានយ៉ាងជោគជ័យ និងផ្តល់សមត្ថភាពเข้ารหัส SSL ដល់ network។

WordPress Multisite មានฟังก์ชันการจับคู่โดเมน (domain mapping function) ที่ช่วยให้เว็บไซต์ในเครือข่ายสามารถเชื่อมโยงกับชื่อโดเมนที่กำหนดเอง หรือชื่อโดเมนที่แตกต่างจากโดเมนหลักของเครือข่ายได้

สำหรับผู้ดูแลระบบเครือข่าย สิ่งนี้จะเพิ่มความซับซ้อนอีกชั้น ทั้งในเรื่องการตั้งค่าชื่อโดเมน และการออกและการบำรุงรักษาใบรับรอง SSL (SSL certificates)

ในระดับนี้ แม้ว่า WordPress Multisite จะมีวิธีการให้สามารถจับคู่ www.anotherdomain.com กับ 'site1' ได้ แต่ผู้ดูแลระบบเครือข่ายก็ยังคงต้องเผชิญกับความท้าทายในการจัดการรายการ DNS ภายนอกและการติดตั้งใบรับรอง SSL

Ultimate Multisite

เมื่อเข้าใจความแตกต่างระหว่างการติดตั้ง WordPress แบบเดี่ยว (stand-alone installation) และการติดตั้งแบบ Multisite แล้ว ลองมาดูว่า Ultimate Multisite เป็นคลังเครื่องมือชั้นยอดสำหรับการให้บริการเว็บไซต์เป็นบริการ (Website as a Service - WaaS) ได้อย่างไร

บทนำ

Ultimate Multisite เปรียบเสมือนมีดสวิสของคุณเมื่อต้องสร้าง Website as a Service (WaaS) ลองนึกถึง Wix.com, Squarespace, WordPress.com และจากนั้นลองคิดถึงการเป็นเจ้าของบริการของคุณเองดูสิ

ภายใต้เบื้องหลัง Ultimate Multisite ใช้ประโยชน์จาก WordPress Multisite แต่ทำในลักษณะที่ไม่เพียงแต่แก้ปัญหามากมายที่ผู้ดูแลระบบเครือข่ายต้องเผชิญกับการติดตั้งแบบ multisite เท่านั้น แต่ยังช่วยเพิ่มความสามารถเพื่อให้รองรับกรณีการใช้งานที่หลากหลายได้อีกด้วย

ในส่วนถัดไป เราจะมาดูบางกรณีการใช้งานทั่วไปและข้อควรพิจารณาที่จำเป็นในการสนับสนุนกรณีเหล่านั้น

กรณีการใช้งาน (Use Cases)

กรณีที่ 1: เอเจนซี่ (An Agency)

โดยปกติแล้ว ทักษะหลักของเอเจนซี่จะอยู่ที่การออกแบบเว็บไซต์ โดยมีส่วนประกอบต่างๆ เช่น การโฮสต์ (hosting) หรือการตลาด ซึ่งถูกระบุเป็นบริการเพิ่มเติม

សម្រាប់เอเจนซี่ต่างๆ สุดยอดระบบ Ultimate Multisite นำเสนอข้อเสนอที่คุ้มค่าอย่างเหลือเชื่อ ด้วยความสามารถในการโฮสต์และจัดการเว็บไซต์หลายๆ เว็บไซต์บนแพลตฟอร์มเดียว ยิ่งสำหรับเอเจนซี่ที่กำหนดมาตรฐานการออกแบบของตนด้วยธีมเฉพาะ เช่น GeneratePress, Astra, OceanWP หรืออื่นๆ ก็ยิ่งสามารถใช้ประโยชน์จากความสามารถของ Ultimate Multisite เพื่อเปิดใช้งานธีมเหล่านี้โดยอัตโนมัติสำหรับแต่ละเว็บไซต์ใหม่ได้

ในทำนองเดียวกัน ด้วยข้อเสนอมากมายสำหรับราคาเอเจนซี่สำหรับปลั๊กอินยอดนิยมและเป็นที่นิยม การใช้ Ultimate Multisite ช่วยให้เอเจนซี่สามารถใช้การลงทุนที่มีอยู่เดิมได้ โดยมีแพลตฟอร์มกลางที่สามารถติดตั้ง บำรุงรักษา และใช้งานปลั๊กอินต่างๆ ได้

ส่วนใหญ่แล้ว การตั้งค่าจะเป็นสิ่งที่ต้องการ และโชคดีที่ Ultimate Multisite ทำให้การทำ domain mapping และ SSL certificates เป็นเรื่องง่ายมาก ด้วยการผสานรวมกับผู้ให้บริการโฮสติ้งยอดนิยมหลายราย รวมถึงบริการอย่าง Cloudflare และ cPanel

ดังนั้น ด้วยการใช้ผู้ให้บริการเหล่านี้ หรือการวาง Ultimate Multisite ไว้เบื้องหลัง Cloudflare การจัดการโดเมนและ SSL certificates ก็จะกลายเป็นเรื่องง่ายไปเลย

เอเจนซี่ที่ต้องการควบคุมการสร้างเว็บไซต์อย่างใกล้ชิด จะชื่นชมความง่ายในการสร้างเว็บไซต์และการเชื่อมโยงเว็บไซต์กับลูกค้าและแผนต่างๆ ผ่านอินเทอร์เฟซที่เรียบง่ายของ Ultimate Multisite

การควบคุมปลั๊กอินและธีมอย่างใกล้ชิดจะถูกรักษาไว้ในระดับผลิตภัณฑ์แต่ละรายการผ่านอินเทอร์เฟซที่เข้าใจง่ายของ Ultimate Multisite ซึ่งช่วยให้สามารถทำให้ปลั๊กอินและธีมพร้อมใช้งานหรือซ่อนได้ รวมถึงสถานะการเปิดใช้งานเมื่อมีการสร้างสำหรับเว็บไซต์ใหม่

Theme ផ្តល់មុខងារស្រដៀងគ្នា ដែលអនុញ្ញាតឱ្យអ្នកបើកដំណើរការ ឬបិទកម្មវិធី (theme) ជាក់លាក់មួយនៅលើគេហទំព័រដែលកំពុងបង្កើត។

ក្រុមហ៊ុនភ្នាក់ងារ (Agencies) នឹងមានភាពស្ងប់ស្ងាត់ជាមួយ Ultimate Multisite ដែលអនុញ្ញាតឱ្យពួកគេធ្វើអ្វីដែលពួកគេពូកែបំផុត - រចនាគេហទំព័រដ៏អស្ចារ្យ។

ករណីទី ២: អ្នកផ្តល់សេវាកម្មเฉพาะផ្នែក (Niche Provider)

មានសុភាសិតចាស់មួយដែលនិយាយថា "ធ្វើរឿងមួយឱ្យបានល្អ"។ ចំពោះអ្នកជំនាញជាច្រើន មានន័យថាការបង្កើតផលិតផល ឬសេវាកម្មជុំវិញគំនិតស្នូលតែមួយ។

ប្រហែលជាអ្នកគឺជាអ្នកលេងកីឡាហ្គោលដែលចូលចិត្តផ្សព្វផ្សាយគេហទំព័រទៅកាន់ក្លឹប ឬអ្នកអាចជាអ្នកលេង esports ដែលចូលចិត្តផ្តល់គេហទំព័រដល់ក្រុម (clans)។ តើអ្នកជាបុគ្គលម្នាក់ដែលផ្សព្វផ្សាយសេវាកម្មការកក់ទៅកាន់ភោជនីយដ្ឋានមែនទេ?

ដោយសារមូលហេតុជាច្រើន អ្នកចង់ផ្តល់សេវាកម្មផ្អែកលើក្របខ័ណ្ឌ និងវេទិកា (framework and platform) តែមួយ។ វាអាចជាអ្នកបានរចនា ឬវិនិយោគលើ plugin ដែលធ្វើតាមតម្រូវការដើម្បីផ្តល់មុខងារដែលត្រូវការ ឬវាអាចជាករណីដែលការអនុវត្តល្អបំផុតក្នុងឧស្សាហកម្ម ទាមទារឱ្យមានវិធីសាស្រ្តស្តង់ដារសម្រាប់ការរចនា។

មធ្យោបាយថ្មីមួយនៃ Ultimate Multisite គឺការប្រើប្រាស់ template sites (គេហទំព័រគំរូ)។ template site គឺជាកន្លែងដែល theme ត្រូវបានដំឡើង និងបើកដំណើរការរួចហើយ plugin ដែលចាំបាច់ត្រូវបានដំឡើង និងបើកដំណើរការ ហើយមានការបង្កើត posts ឬ pages គំរូ។ នៅពេលដែលអតិថិជនបង្កើតគេហទំព័រថ្មីដោយផ្អែកលើ template ខ្លឹមសារ និងការកំណត់របស់ template នឹងត្រូវបានចម្លងទៅគេហទំព័រដែលបានបង្កើតថ្មីនោះ។

សម្រាប់អ្នកផ្តល់សេវាកម្មគេហទំព័រ និងសេវាកម្មเฉพาะផ្នែកនេះ វាផ្តល់នូវអត្ថប្រយោជន៍ដ៏គ្មានគូប្រៀបក្នុងការបង្កើតគេហទំព័រដែលត្រៀមរួចរាល់ភ្លាមៗជាមួយនឹង plugin និងការរចនាផ្ទាល់ខ្លួន។ អតិថិជនគ្រាន់តែត្រូវផ្តល់នូវធាតុបញ្ចូលតិចបំផុតដើម្បីបំពេញសេវាកម្មនោះ។

អាស្រ័យលើតម្រូវការ ទាំងការកំណត់ subdirectory ឬ subdomain ក៏អាចសមស្របដែរ ដែលក្នុងករណីនោះ ការជ្រើសរើសស្ថាបត្យកម្មនឹងស្ថិតនៅចន្លោះការប្រើប្រាស់ SSL certificate សាមញ្ញសម្រាប់ subdirectories ឬ wildcard SSL certificate សម្រាប់ subdomains.

ករណីទី ៣៖ ការបង្ហោះ WordPress Web Hosting

មានវិធីជាច្រើនក្នុងការបង្ហោះគេហទំព័រ WordPress ប៉ុន្តែវាជារឿងដែលមិនសូវងាយស្រួលដូចការផ្តល់ទំហំផ្ទុក (web space) ដល់អតិថិជនជាមួយនឹងកំណែ WordPress ដែលបានដំឡើងរួចរាល់នោះទេ។ នេះគឺដោយសារតែមានការសម្រេចចិត្ត និងការពិចារណាជាច្រើនត្រូវរួមបញ្ចូលគ្នាដើម្បីផ្តល់សេវាកម្មដែលមានន័យ។

Ultimate Multisite មានភាពល្អប្រសើរក្នុងផ្នែកនេះ ដោយផ្តល់នូវដំណោះស្រាយបិទបញ្ចប់ (turnkey solution) ដ៏ពេញលេញសម្រាប់ការបង្ហោះគេហទំព័រ WordPress។ ដំណោះស្រាយនេះរួមបញ្ចូលទាំងយន្តការស្នូលដើម្បីផ្តល់សេវាកម្មជាប្រចាំ (subscription services) ការប្រមូលប្រាក់ ការបង្កើតទម្រង់ Checkout ទំនិញបញ្ចុះតម្លៃ និងការទំនាក់ទំនងជាមួយអតិថិជន។

ការងារសំខាន់ៗជាច្រើនដែលតម្រូវឱ្យមានសម្រាប់ការដំឡើង បញ្ជាក់ការកំណត់រចនាសម្ព័ន្ធ និងការថែរក្សា WordPress Multisite ឱ្យបានត្រឹមត្រូវ ត្រូវបានសម្រួលដោយ Ultimate Multisite រហូតដល់អ្នកគ្រប់គ្រងបណ្តាញ (network administrators) គ្រាន់តែពិចារណាលើចំណុចដែលទាក់ទងនឹងសេវាកម្ម ឬផ្នែកឯកទេសរបស់ពួកគេ ដូចជាកម្រិតផលិតផល តម្លៃ និងការផ្តល់ជូនសេវាកម្ម។

សម្រាប់អ្នកអភិវឌ្ឍន៍ដែលចង់រួមបញ្ចូលជាមួយ Ultimate Multisite ក៏មានដំណោះស្រាយ RESTful API និង Webhooks ដ៏ពេញលេញសម្រាប់ការជូនដំណឹងអំពីព្រឹត្តិការណ៍ផងដែរ។

ដោយមិនពឹងផ្អែកលើ plugin និង license ខាងក្រៅជាច្រើនទេ Ultimate Multisite ផ្តល់នូវដំណោះស្រាយដែលមានមុខងារសម្បូរបែប និងអាចប្រៀបធៀបបាននឹង Wix, Squarespace, WordPress.com និងផ្សេងៗទៀត។

ការពិចារណាផ្នែកស្ថាបត្យកម្ម (Architecture Considerations)

ទោះបីជាវាមិនមែនជាមគ្គុទ្ទេសក៍ដ៏ពេញលេញក៏ដោយ ចំណុចខាងក្រោមនេះគួរតែដើរតួជាការណែនាំសម្រាប់ការជ្រើសរើសបច្ចេកវិទ្យាត្រឹមត្រូវដើម្បីគាំទ្រដល់ការដំឡើង Ultimate Multisite។

ការបង្ហោះរួម (Shared) ប៉ះនឹងការបង្ហោះឯកជន (Dedicated Hosting)

អូសូដ្យមិនមែនទាំងអស់សុទ្ធតែដូចគ្នាទេ ហើយអ្នកខ្លះអនុវត្តនូវកម្រិត Server density ខ្ពស់បំផុត។ អ្នកផ្តល់សេវាដែលមានតម្លៃទាបជាធម្មតាកំណើនចំណូលដោយការបង្កើន Server density ឱ្យបានច្រើនបំផុត។ ដោយសារតែបែបនេះ ការដំឡើង Ultimate Multisite របស់អ្នកអាចនឹងមានតែមួយក្នុងចំណោមគេរាប់រយគេហទំព័រនៅលើ Server តែមួយប៉ុណ្ណោះ។

បើគ្មានវិធានការការពារសមស្របពីអ្នកផ្តល់សេវាទេ គេហទំព័រនៅលើ server តែមួយនឹងជួបប្រទះបញ្ហា 'noisy neighbour' (អ្នកជិតខាងដែលរំខាន)។ មានន័យថា គេហទំព័រមួយនៅលើ server តែមួយប្រើប្រាស់ធនធានច្រើនដល់ចំណុចដែលគេហទំព័រផ្សេងទៀតត្រូវប្រកួតប្រជែងគ្នាដើម្បីយកធនធានដែលនៅសល់។ ជាញឹកញាប់ បញ្ហានេះបង្ហាញខ្លួនជាគេហទំព័រដែលយឺត ឬមិនឆ្លើយតបបានទាន់ពេលវេលា។

ក្នុងនាមជាអ្នកផ្តល់សេវាកម្ម web hosting ផ្ទាល់ លំហូរនៃផលប៉ះពាល់នឹងមានន័យថា អតិថិជនរបស់អ្នកនឹងជួបប្រទះល្បឿនយឺត ការជាប់ចំណាត់ថ្នាក់គេហទំព័រទាប និងអត្រា bounce rate ខ្ពស់ ដែលជាលទ្ធផលនាំឱ្យអតិថិជនផ្លាស់ប្តូរទៅរកសេវាកម្មផ្សេង។

និយាយឲ្យខ្លី តម្លៃថោកមិនមែនមានន័យថាល្អនោះទេ។

Ultimate Multisite ត្រូវបានគេស្គាល់ថាដំណើរការជាមួយអ្នកផ្តល់សេវា hosting ដែលល្អមួយចំនួន ហើយរួមបញ្ចូលគ្នាបានយ៉ាងល្អជាមួយបរិយាកាសរបស់ពួកគេដើម្បីផ្តល់មុខងារដូចជា domain mapping និង automatic SSL។ អ្នកផ្តល់សេវាកម្មទាំងនេះឱ្យតម្លៃលើប្រសិទ្ធភាព (performance) ហើយផ្តល់សេវាកម្មកម្រិតខ្ពស់ជាង hosting ធម្មតា។

សម្រាប់បញ្ជីអ្នកផ្តល់សេវាដែលត្រូវគ្នា និងការណែនាំពេញលេញសម្រាប់ការរៀបចំសម្រាប់នីមួយៗ សូមពិនិត្យមើលឯកសារ Compatible Providers។

ការពិចារណាលើប្រសិទ្ធភាព (Performance Considerations)

Ultimate Multisite មិនមែនជាកម្មវិធីដែលយឺតនោះទេ ប៉ុន្តែវាលឿនគួរឱ្យកត់សម្គាល់។ ទោះជាយ៉ាងណាក៏ដោយ វាដំណើរការបានល្អត្រឹមតែដូចកម្មវិធី និងហេដ្ឋារចនាសម្ព័ន្ធមូលដ្ឋានប៉ុណ្ណោះ ហើយអាចប្រើប្រាស់បានតែអ្វីដែលវាមានសិទ្ធិទទួលបានប៉ុណ្ណោះ។

សូមពិចារណាដូចនេះ៖ អ្នកគឺជាអ្នកគ្រប់គ្រងបណ្តាញ (network administrator) នៃ Ultimate Multisite installation ដែលមានគេហទំព័រ ១០០ កន្លែង។ គេហទំព័រមួយចំនួនកំពុងដំណើរការបានល្អ និងទាក់ទាញអ្នកចូលមើលគេហទំព័រជាច្រើនក្នុងមួយថ្ងៃ។

สถานการณ์นี้จะแตกต่างออกไปในขนาดที่เล็กกว่า เช่น เว็บไซต์หนึ่งถึงห้าเว็บไซต์ แต่ก่อนที่จะเกิดปัญหาเรื่องขนาด (scale) จะเห็นปัญหาชัดเจนขึ้น

หากปล่อยทิ้งไว้โดยไม่มีคนดูแล เว็บไซต์ Ultimate Multisite เพียงแห่งเดียวจะต้องรับผิดชอบในการตอบสนองคำขอของผู้เข้าชมทุกเว็บไซต์ คำขอนั้นอาจเป็นสำหรับหน้า PHP แบบไดนามิก หรือไฟล์คงที่ เช่น ไฟล์สไตล์ชีต (stylesheets), javascript หรือไฟล์สื่อ (media files) ไม่ว่าจะเป็นหนึ่งเว็บไซต์หรือร้อยเว็บไซต์ งานเหล่านี้จะกลายเป็นงานซ้ำซาก น่าเบื่อ และสิ้นเปลือง เป็นเรื่องที่ไม่จำเป็นเลยที่จะใช้พลังของ CPU และหน่วยความจำในการประมวลผลไฟล์ PHP เมื่อผลลัพธ์ที่ได้เป็นข้อมูลคงที่เหมือนกันสำหรับทุกคำขอ

ในทำนองเดียวกัน คำขอหนึ่งสำหรับหน้า PHP หรือ HTML จะสร้างคำขอต่อเนื่องหลายรายการสำหรับสคริปต์ (scripts), สไตล์ชีต และไฟล์รูปภาพ คำขอเหล่านี้จะถูกส่งตรงไปยังเซิร์ฟเวอร์ Ultimate Multisite ของคุณ

สามารถแก้ไขปัญหานี้ได้ง่ายๆ โดยการอัปเกรดเซิร์ฟเวอร์ แต่สิ่งนี้ไม่ได้แก้ปัญหาทุติยภูมิ นั่นคือ ความล่าช้าทางภูมิศาสตร์ (geographic latencies) จะต้องมีเซิร์ฟเวอร์หลายตัวในหลายตำแหน่งจึงจะสามารถจัดการกับปัญหานี้ได้อย่างเหมาะสม

ด้วยเหตุนี้ ผู้ดูแลระบบเครือข่ายส่วนใหญ่จึงใช้โซลูชันการแคชฝั่งหน้า (front-end caching solutions) และเครือข่ายการกระจายเนื้อหา (CDN) เพื่อตอบสนองคำขอสำหรับหน้าเว็บคงที่ การตอบสนองคำขอเหล่านี้และการเสิร์ฟไฟล์ก่อนที่คำขอจะไปถึงเซิร์ฟเวอร์ จะช่วยประหยัดทรัพยากรในการประมวลผล ขจัดความล่าช้า หลีกเลี่ยงการอัปเกรดที่ไม่จำเป็น และเพิ่มประสิทธิภาพการลงทุนในเทคโนโลยี

Ultimate Multisite มีส่วนเสริม Cloudflare ที่ซับซ้อน ซึ่งช่วยให้ผู้ดูแลระบบเครือข่ายสามารถวางการติดตั้งของตนไว้เบื้องหลัง Cloudflare และใช้ประโยชน์จากความสามารถในการแคช (caching capabilities) การโฮสต์ DNS, ใบรับรอง SSL และกลไกความปลอดภัยต่างๆ

การสำรองข้อมูล (Backups)

คุณอาจขอคำแนะนำเกี่ยวกับการสำรองข้อมูลจากคน 50 คน และได้รับความคิดเห็นที่แตกต่างกันถึง 50 แนวทางในการวางแผนการสำรองข้อมูล คำตอบคือ มันขึ้นอยู่กับปัจจัยนั้น

អ្វីដែលមិនមានការចម្រូងចម្រាសគឺថា ការធ្វើបច្ចុប្បន្នភាពជាចម្លង (backups) គឺជាតម្រូវការ ហើយវាស្ទើរតែមិនអាចស្រមៃបានទេដែលអ្នកផ្តល់សេវាកម្ម ដែលផ្តល់នូវសេវាកម្មគ្រប់គ្រង (managed service) មិនបានគ្រប់គ្រងវាឡើយ។ ជាលទ្ធផល អតិថិជននឹងមើលទៅអ្នកគ្រប់គ្រងបណ្តាញ (network administrator) ដើម្បីផ្តល់ និងគ្រប់គ្រងសេវាកម្មនេះ។ អ្នកដែលអ្នកគ្រប់គ្រងបណ្តាញត្រូវមើលទៅគឺជាបញ្ហាខុសគ្នាទាំងស្រុងមួយទៀត។

សម្រាប់ផ្នែកនេះ សូមយើងព្រមព្រៀងថា backup គឺជាការចម្លងស្ថានភាពប្រព័ន្ធនៅពេលជាក់លាក់មួយនៃពេលវេលាដែលការធ្វើបច្ចុប្បន្នភាពត្រូវបានចាប់ផ្តើម។ សាមញ្ញនិយាយថា អ្វីក៏ដោយដែលជាស្ថានភាពរបស់ប្រព័ន្ធនៅពេលធ្វើបច្ចុប្បន្នភាពនោះ ស្ថានភាពនោះនឹងត្រូវបានចាប់យក និងរក្សាទុកនៅក្នុង backup។

ជាមួយនឹងការយល់ដឹងនេះ ចម្លើយអំពីរបៀបសម្រេចបាននូវ backups និងអ្វីដែលល្អបំផុតសម្រាប់បរិស្ថានរបស់អ្នក នឹងអាស្រ័យយ៉ាងខ្លាំងទៅលើតម្រូវការរបស់អ្នក និងសមត្ថភាពរបស់អ្នកផ្តល់ hosting ដើម្បីបំពេញតាមតម្រូវការទាំងនោះ។ ទោះជាយ៉ាងណាក៏ដោយ តាមលំដាប់ពី opinions ដែលមានច្រើនបំផុតទៅតិចបំផុត ជម្រើសខាងក្រោមគួរតែផ្តល់នូវការណែនាំខ្លះៗ។

Snapshots (រូបថតស្ថានភាព)

Snapshots គឺជាដំណោះស្រាយដ៏ល្អបំផុតសម្រាប់ការធ្វើ backup ព្រោះវាស្រួលប្រើ មិនស្មុគស្មាញទេ (រហូតដល់អ្នកចង់ស្តារឡើងវិញ) ហើយវាដំណើរការដោយខ្លួនឯង។ ទោះជាយ៉ាងណាក៏ដោយ វាទាមទារជំនួយពីអ្នកផ្តល់សេវាកម្មរបស់អ្នក ហើយភាគច្រើនគឺអនុវត្តបានតែប្រសិនបើអ្នកមាន VPS (Virtual Private Server) ឬអ្វីដែលស្រដៀងគ្នា។ អ្នកផ្តល់សេវាកម្មមួយចំនួនដែលរាយក្នុងឯកសារ ‘Compatible Providers’ របស់យើង ផ្តល់នូវ backups ដែលមិនទាមទារការអន្តរាគមន៍បន្ថែម ឬការពិចារណាពីអ្នកគ្រប់គ្រងបណ្តាញទៀតឡើយ។

ការបម្រុងទុកបែបប្រពៃណី (traditional backups) គឺកំណត់គោលដៅទៅលើឯកសារ និងមូលដ្ឋានទិន្នន័យ (databases) ចំណែកឯ snapshot វិញ គឺចាប់យកទាំងរាល់ឌីស្ក៍ទាំងមូល។ មានន័យថា មិនត្រឹមតែទិន្នន័យរបស់គេហទំព័រត្រូវបានចាប់យកនៅក្នុង snapshot ប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងប្រព័ន្ធប្រតិបត្តិការ (operating system) និងការកំណត់រចនាសម្ព័ន្ធ (configuration) ផងដែរ។ ចំពោះមនុស្សជាច្រើន នេះគឺជាអត្ថប្រយោជន៍ដ៏សំខាន់មួយ ព្រោះប្រព័ន្ធថ្មីអាចត្រូវបានបង្កើតឡើងស្ទើរតែភ្លាមៗពី snapshot ហើយយកមកដំណើរការដើម្បីជំនួសប្រព័ន្ធដែលមានបញ្ហាបានយ៉ាងងាយស្រួល។ ដូចគ្នានេះដែរ ដំណើរការស្តារ (recovery process) ដើម្បីយកឯកសារមកវិញ គឺគ្រាន់តែភ្ជាប់រូបភាព snapshot ជាឌីស្ក៍ទៅនឹង instance ដែលមានរួចហើយ ដើម្បីឱ្យអាចចូលប្រើ និងចម្លងឯកសារបានប៉ុណ្ណោះ។

Snapshot អាចនឹងបង្កបន្ថែមលើថ្លៃដើមជាមួយអ្នកផ្តល់សេវាផ្ទុក (hosting provider) ប៉ុន្តែវាក៏ជាគោលការណ៍ធានារ៉ាប់រងការពារគ្រោះថ្នាក់ផងដែរ។

External Scripts (ស្គ្រីបខាងក្រៅ)

ហាក់ដូចជាមិនខ្វះនូវស្គ្រីប និងដំណោះស្រាយខាងក្រៅសម្រាប់ការធ្វើបម្រុងទុកធនធាន WordPress និង MySQL នោះទេ ហើយវាក៏នឹងដំណើរការបានល្អសម្រាប់ Ultimate Multisite ដែលជា plugin របស់ WordPress ដែលប្រើប្រាស់ប្រព័ន្ធឯកសារ (filesystem) និងមូលដ្ឋានទិន្នន័យរបស់ WordPress។ ដូច្នេះ ដំណោះស្រាយដែលធ្វើបម្រុងទុកគេហទំព័រ WordPress គឺគ្រប់គ្រាន់ដើម្បីបំពេញតម្រូវការរបស់ Ultimate Multisite។

យើងមិនអាចណែនាំស្គ្រីបមួយឱ្យល្អជាងមួយទៀតបានទេ ប៉ុន្តែដំបូន្មានទូទៅរបស់យើងគឺត្រូវដំណើរការការសាកល្បងធ្វើបម្រុងទុក និងស្តារជាច្រើន ដើម្បីធានាថាលទ្ធផលដែលទទួលបានគឺសមស្រប ហើយត្រូវតែ "ប្រាកដចិត្ត" ដោយការវាយតម្លៃស្គ្រីប និងមុខងាររបស់វាជាបន្តបន្ទាប់ ជាពិសេសនៅកន្លែងដែលអនុវត្តយុទ្ធសាស្ត្រធ្វើបម្រុងទុកបែបភាពខុសគ្នា (differential backup strategy)។

គួរចំណាំថា ស្គ្រីបទាំងនេះ នៅពេលកំពុងដំណើរការ នឹងបង្កើនបន្ទុកប្រព័ន្ធ ដែលត្រូវយកមកពិចារណា។

Plugins (កម្មវិធីបន្ថែម)

ស្ទើរតែគ្មានបញ្ហាអ្វីនៅក្នុង WordPress ដែលមិនអាចដោះស្រាយបានដោយប្រើ plugin ហើយប្រសិនបើអ្នកមិនសូវពូកែក្នុងការគ្រប់គ្រង external scripts ប្រហែលជា plugin គឺជាជម្រើសដ៏ល្អបន្ទាប់។

Plugins នីមួយៗមានជម្រើស និងមុខងារខុសគ្នា ប៉ុន្តែភាគច្រើនវាធ្វើមុខងារដូចគ្នា គឺការចម្លងឯកសារ WordPress និងទិន្នន័យមូលដ្ឋានទិន្នន័យ។ បន្ទាប់មកមុខងារនឹងខុសគ្នា ដោយសារតែពភព្ភបច្ចេកទេសខ្លះអាចបញ្ជូនការสำรอง (backups) ទៅកាន់សេវាកម្មខាងក្រៅដូចជា Google Drive ឬ Dropbox ឬទៅកាន់សេវាកម្មផ្ទុកវត្ថុដែលត្រូវគ្នាដូចជា S3, Wasabi ឬផ្សេងៗទៀត។ ប្លុកដែលមានមុខងារច្រើនជាងមុន នឹងផ្តល់នូវការสำรองបែបប្រៀបធៀប (differential backups) ឬយុទ្ធសាស្ត្រមួយដើម្បីสำรองតែទិន្នន័យដែលបានផ្លាស់ប្តូរ ដើម្បីសន្សំចន្លោះផ្ទុកខាងក្រៅ។

នៅពេលជ្រើសរើស plugin របស់អ្នក សូមប្រុងប្រយ័ត្នដើម្បីផ្ទៀងផ្ទាត់ថាវាគាំទ្រ multisite (ពហុគេហទំព័រ) ឬអត់។ ដោយសារតែលក្ខណៈនៃការដំណើរការរបស់វា ខណៈពេលដែលការสำรองកំពុងដំណើរការ អ្នកអាចរំពឹងថានឹងមានបន្ទុកបណ្តោះអាសន្នលើ server រហូតដល់ដំណើរការនោះបញ្ចប់។

ដែន (Domain) និង SSL

មានការពិភាក្សាជាច្រើនរួចហើយអំពីឈ្មោះដែនក្នុងរបៀប subdomain នៃ multisite។ ដំណោះស្រាយស្ទើរតែប្រើបានសម្រាប់អ្នកគ្រប់គ្រងបណ្តាញគឺការប្រើប្រាស់ wildcard DNS entries។

DNS entry ប្រភេទនេះនឹងអាចដោះស្រាយ subdomains ដូចជា ‘site1.domain.com’ និង ‘site2.domain.com’ ទៅកាន់អាសយដ្ឋាន IP 1.2.3.4 ដែលគាំទ្រ Ultimate Multisite និង WordPress Multisite កាន់តែច្រើនទៀតដោយប្រើរបៀប subdomain។

នេះអាចដំណើរការបានយ៉ាងល្អសម្រាប់ HTTP ព្រោះ host គោលដៅត្រូវបានអានពី HTTP headers ប៉ុន្តែមិនសូវមានគេប្រើ web ធម្មតាទេដូចពេលបច្ចុប្បន្ន ដែលប្រតិបត្តិការ HTTPS ដែលមានសុវត្ថិភាពគឺជារឿងចាំបាច់។

ជាសំណាងល្អ មានជម្រើសងាយៗសម្រាប់ SSL certificates។ ក្នុង mode subdirectory អ្នកអាចប្រើ certificate ធម្មតាសម្រាប់ domain របស់អ្នកបាន។ Certificate ទាំងនេះមានស្រាប់ និងឥតគិតថ្លៃពី hosting providers ដែលអាចប្រើ service free LetsEncrypt ឬប្រភពផ្សេងទៀត។ បើមិនដូច្នោះទេ វាអាចរកបានតាមរយៈអាជ្ញាធរពាណិជ្ជកម្ម ប្រសិនបើអ្នកអាចបង្កើត certificate signing request បាន។

សម្រាប់ mode subdomain ការប្រើ wildcard SSL certificate នឹងដំណើរការយ៉ាងល្អជាមួយ wildcard domain ហើយអនុញ្ញាតឱ្យ certificate នោះក្លាយជា authoritative សម្រាប់ root domain និង subdomains ទាំងអស់ដោយមិនបាច់កំណត់រចនាសម្ព័ន្ធបន្ថែមអ្វីឡើយ។

ទោះជាយ៉ាងណាក៏ដោយ វាគួរតែចំណាំថា wildcard SSL certificates ប្រហែលជាមិនដំណើរការជាមួយ service ដូចជា Cloudflare ទេ លុះត្រាតែអ្នកប្រើ enterprise plan ឬកំណត់ entry ជា DNS only ដែលក្នុងករណីនោះ ការ caching និង optimization ទាំងអស់នឹងត្រូវបាន bypass។

Ultimate Multisite ដែលមានស្រាប់ (out-of-the-box) បានផ្តល់ដំណោះស្រាយបញ្ហានេះ ដោយបង្ហាញពីបទពិសោធន៍យ៉ាងទូលំទូលាយរបស់យើងជាមួយនឹងតម្រូវការរបស់ WordPress multisites។ ការបើក add-on សាមញ្ញនេះ នឹងធ្វើឱ្យ Ultimate Multisite ប្រើប្រាស់ credentials Cloudflare របស់អ្នកដើម្បីបន្ថែម DNS entries ដោយស្វ័យប្រវត្តិសម្រាប់ network sites នៅក្នុង Cloudflare និងកំណត់ mode របស់វាទៅជា ‘proxied’។ តាមរបៀបនេះ subsite នីមួយៗនៃ network នៅពេលបង្កើតឡើង នឹងទទួលបានការការពារពេញលេញ និងអត្ថប្រយោជន៍ទាំងអស់ពី Cloudflare រួមទាំង SSL ផងដែរ។

អាស្រ័យលើលក្ខណៈ និងគោលបំណងនៃការដំឡើង Ultimate Multisite របស់អ្នក អ្នកអាចនឹងត្រូវការឱ្យអតិថិជនប្រើ domain ផ្ទាល់ខ្លួនរបស់ពួកគេ។ ក្នុងករណីនេះ អ្នកគ្រប់គ្រង network ត្រូវទទួលខុសត្រូវក្នុងការដោះស្រាយបញ្ហាពីរយ៉ាង៖ ការបង្ហោះឈ្មោះ domain និង SSL certificates សម្រាប់ domain នោះ។

សម្រាប់មនុស្សជាច្រើន การใช้ Cloudflare เป็นทางเลือกที่ง่ายมาก ลูกค้าเพียงแค่ต้องนำโดเมนของตนไปไว้บน Cloudflare ชี้ CNAME ไปยังโดเมนหลัก (root domain) ของ Ultimate Multisite และแมปโดเมนของพวกเขาใน Ultimate Multisite เพื่อเริ่มใช้ประโยชน์จากชื่อโดเมนที่กำหนดเองได้

นอกเหนือจากนี้ จำเป็นต้องมองหาโซลูชันทางเลือกอื่น ซึ่งนี่คือเหตุผลว่าทำไม Ultimate Multisite จึงแนะนำรายการผู้ให้บริการที่เข้ากันได้ (Compatible Providers) เพราะกระบวนการตั้งค่า DNS และ SSL อาจเป็นเรื่องที่ไม่ใช่เรื่องง่าย อย่างไรก็ตาม ด้วยการผสานรวมของ Ultimate Multisite กับผู้ให้บริการเหล่านี้ ความซับซ้อนจะลดลงมากและขั้นตอนทั้งหมดจะถูกทำให้เป็นอัตโนมัติ

Plugins

มีความเป็นไปได้สูงที่คุณจะต้องใช้ปลั๊กอินเพิ่มเติมเพื่อมอบฟังก์ชันให้กับลูกค้าหรือเว็บไซต์ในเครือของคุณ ปลั๊กอินทุกตัวทำงานกับ WordPress Multisite และ Ultimate Multisite หรือไม่? มันขึ้นอยู่กับปัจจัยนั้น

แม้ว่าปลั๊กอินส่วนใหญ่จะสามารถติดตั้งใน WordPress Multisite ได้ แต่การเปิดใช้งานและการอนุญาต (licensing) จะแตกต่างกันไปตามผู้พัฒนาแต่ละราย

ความท้าทายอยู่ที่วิธีการนำใบอนุญาตมาใช้กับปลั๊กอินบางตัวที่ต้องการใบอนุญาตแบบต่อโดเมน ซึ่งหมายความว่าสำหรับปลั๊กอินบางตัว ผู้ดูแลระบบเครือข่ายจำเป็นต้องเปิดใช้งานใบอนุญาตด้วยตนเองสำหรับแต่ละปลั๊กอินในแต่ละเว็บไซต์ใหม่

ดังนั้น อาจเป็นวิธีที่ดีที่สุดที่จะตรวจสอบกับผู้พัฒนาปลั๊กอินว่าปลั๊กอินของพวกเขาจะทำงานอย่างไรกับ WordPress Multisite และมีข้อกำหนดหรือขั้นตอนพิเศษใดที่จำเป็นสำหรับการขอใบอนุญาตหรือไม่