Ultimate Multisite 101

Ultimate Multisite ແມ່ນ plugin WordPress Multisite ដែលຊ່ວຍໃຫ້ທ່ານສາມາດສະເໜີ WaaS ຫຼື Websites as a Service ໃຫ້ລູກຄ້າໄດ້. ກ່ອນທີ່ພວກເຮົາຈະເຈາະເລິກ ແລະ ຮຽນຮູ້ວ່າ Ultimate Multisite ສາມາດຊ່ວຍທຸລະກິດ ແລະ ລູກຄ້າຂອງທ່ານໄດ້ແນວໃດ, ມີຄວາມຮູ້ພື້ນຖານບາງຢ່າງທີ່ພວກເຮົາຕ້ອງມີກ່ອນ.

WordPress Multisite

ສ່ວນຫຼາຍຂອງພວກເຮົາຄົນຈື່ຈຳການຕິດຕັ້ງ WordPress ມາດຕະຖານທີ່ມີຢູ່ແລ້ວ. ທ່ານສາມາດສ້າງມັນຜ່ານ control panel ຂອງຜູ້ໃຫ້ບໍລິການ hosting ຂອງທ່ານ ຫຼື, ສຳລັບຄົນທີ່ກ້າຫານ, ສ້າງ web server ແລະ database ແບບໃໝ່, ດາວໂຫຼດ core files ແລະ ເລີ່ມຂັ້ນຕອນການຕິດຕັ້ງ.

ສິ່ງນີ້ໃຊ້ໄດ້ກັບເວັບໄຊ WordPress ລ້ຽວເປັນລ້ານໆແຫ່ງທົ່ວໂລກ ແຕ່ໃນມຸມຂອງອົງການຈັດຕັ້ງ ຫຼື ຜູ້ໃຫ້ບໍລິການ hosting, ເຮົາຂໍສົນທະນາເລື່ອງປະລິມານ (volumes) ໜຶ່ງ.

ເຖິງແມ່ນວ່າການສ້າງເວັບໄຊ WordPress ໜຶ່ງແຫ່ງ ຫຼື ແມ່ນແຕ່ໜຶ່ງຮ້ອຍແຫ່ງຜ່ານ control panel ອັດຕະໂນມັດມັນກໍເປັນໄປໄດ້, ແຕ່ບັນຫາຕ່າງໆຈະເລີ່ມປາກົດຂຶ້ນເມື່ອເຖິງເວລາໃນການຄຸ້ມຄອງເວັບໄຊເຫຼົ່ານັ້ນ. ຖ້າບໍ່ໄດ້ຮັບການຄຸ້ມຄອງ, ເປັນເປົ້າໝາຍທີ່ດີຂອງ malware. ການຄຸ້ມຄອງໝາຍເຖິງການໃຊ້ຄວາມພະຍາຍາມ ແລະ ຊັບພະຍາກອນ ແລະ ເຖິງແມ່ນວ່າຈະມີ external tools ແລະ plugins ຕ່າງໆທີ່ມີຢູ່ເພື່ອຊ່ວຍເຮັດໃຫ້ການຄຸ້ມຄອງ ແລະ ບໍລິຫານ WordPress site ເປັນລະບຽບຂຶ້ນ, ແຕ່ການທີ່ລູກຄ້າເກັບຮັກສາສິດການເຂົ້າເຖິງໃນຖານະຜູ້ບໍລິຫານ (administrative access) ກໍໝາຍຄວາມວ່າຄວາມພະຍາຍາມເຫຼົ່ານີ້ອາດຈະຖືກເອົາຊະນະໄດ້ງ່າຍ.

ໃນ core ຂອງມັນ, WordPress ມີຟັງຊັນໜຶ່ງທີ່ເອີ້ນວ່າ ‘Multisite’ ເຊິ່ງມີຕົ້ນກຳເນີດຍ້ອນກັບປີ 2010 ໃນເວລາເປີດຕົວ WordPress 3.0. ນັບຕັ້ງແຕ່ນັ້ນ, ມັນໄດ້ຮັບການປັບປຸງຫຼາຍຄັ້ງໂດຍມີຈຸດປະສົງເພື່ອເພີ່ມຟັງຊັນໃໝ່ໆ ແລະ ເພື່ອເພີ່ມຄວາມປອດໄພໃຫ້ເຂັ້ມງວດຂຶ້ນ.

ໂດຍເນື້ອໃນສັ້ນໆ, WordPress multisite ສາມາດຄິດໄດ້ດັ່ງນີ້: ມະຫາວິທະຍາໄລຮັກສາການຕິດຕັ້ງ WordPress ໜຶ່ງແຫ່ງ ແຕ່ແຕ່ແຂວງຕ່າງໆຈະຮັກສາເວັບໄຊ WordPress ຂອງຕົນເອງ.

มาลองดูคำศัพท์พื้นฐานบางอย่างที่เจอทั้งในเอกสารของ Ultimate Multisite และในชุมชน WordPress กันครับ

เครือข่าย (The Network)

ในส่วนของ WordPress, เครือข่ายแบบ multisite คือการที่เราสามารถจัดการเว็บไซต์ย่อยๆ หลายๆ เว็บไซต์ได้จากแดชบอร์ดเดียว ถึงแม้ว่าการสร้างเครือข่าย multisite จะแตกต่างกันไปในแต่ละผู้ให้บริการโฮสติ้ง แต่ผลลัพธ์สุดท้ายมักจะเป็นการเพิ่มคำสั่งเล็กน้อยในไฟล์ wp-config.php เพื่อบอกให้ WordPress รู้ว่ากำลังทำงานในโหมดนี้

มีความแตกต่างที่ชัดเจนหลายอย่างระหว่างเครือข่าย multisite กับการติดตั้ง WordPress แบบเดี่ยว ซึ่งเราจะมาพูดถึงสั้นๆ กันครับ

ซับโดเมน (Subdomain) เทียบกับ ซับไดเรกทอรี (Subdirectory)

หนึ่งในการตัดสินใจแรกที่คุณต้องทำคือว่าจะให้การติดตั้งแบบ multisite ทำงานด้วย ซับไดเรกทอรี หรือ ซับโดเมน Ultimate Multisite ใช้งานได้ดีทั้งสองแบบ แต่ก็มีความแตกต่างทางสถาปัตยกรรมระหว่างการตั้งค่าทั้งสองแบบ

ในการตั้งค่าแบบ subdirectory เว็บไซต์ในเครือข่ายจะได้รับพาธ (path) โดยอิงจากชื่อโดเมนหลัก ตัวอย่างเช่น เว็บไซต์ที่ถูกตั้งชื่อว่า ‘site1’ จะมี URL เต็มเป็น https://domain.com/site1 ในการตั้งค่าแบบ subdomain เว็บไซต์ในเครือข่ายจะมี ซับโดเมน ของตัวเองซึ่งได้มาจากชื่อโดเมนหลัก ดังนั้นเว็บไซต์ที่ตั้งชื่อว่า ‘site1’ จะมี URL เต็มเป็น https://site1.domain.com/

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

ในแง่ของ DNS การใช้ subdirectories ถือเป็นความท้าทายที่ค่อนข้างง่ายครับ เพราะเว็บไซต์เครือข่ายก็เหมือนลูกของพาธหลัก เราจึงต้องการแค่รายการชื่อโดเมนเดียวสำหรับชื่อโดเมนหลักเท่านั้น ส่วนเรื่อง subdomains ความท้าทายจะซับซ้อนขึ้นนิดหน่อย ต้องมีรายการ CNAME แยกต่างหากสำหรับแต่ละไซต์เครือข่าย หรือต้องใช้ wildcard (*) ในเรคคอร์ด DNS ครับ

อีกส่วนที่ต้องพิจารณาคือเรื่อง SSL และการออกและการใช้งานใบรับรอง SSL ในกรณีของ subdirectory configuration เราสามารถใช้ใบรับรองโดเมนเดียวได้ เพราะเว็บไซต์เครือข่ายก็เป็นแค่พาธย่อยของชื่อโดเมนหลัก ดังนั้น ใบรับรองสำหรับ domain.com จะให้ SSL ที่เพียงพอสำหรับ https://domain.com/site1, https://domain.com/site2 และอื่นๆ ครับ

ในกรณีของ subdomain configuration การใช้ wildcard SSL certificate เป็นตัวเลือกที่พบบ่อยที่สุด ประเภทใบรับรอง SSL แบบนี้จะให้การเข้ารหัสสำหรับโดเมนและ subdomains ของมัน ดังนั้น wildcard SSL certificate จะให้การเข้ารหัสสำหรับ https://site1.domain.com, https://site2.domain.com และ https://domain.com เองด้วย

แม้ว่าจะมีตัวเลือกอื่นอยู่ แต่ส่วนใหญ่มักจะมีขอบเขตและการใช้งานที่จำกัด และต้องมีการตั้งค่าและพิจารณาเพิ่มเติมเกี่ยวกับความเหมาะสมครับ

Plugins and Themes

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

ด้วยเหตุนี้ เมื่อตั้งค่าเป็น WordPress multisite ระบบจะเอาความสามารถในการติดตั้ง plugin และ theme ออกจากผู้ดูแลระบบของแต่ละไซต์ แล้วย้ายไปให้บทบาทของผู้ดูแลระบบเครือข่าย (network administrator) หรือ 'super admin' ที่ถูกสร้างขึ้นใหม่แทน บทบาทพิเศษนี้จะสามารถตัดสินใจได้ว่าจะอนุญาตให้ผู้ดูแลระบบของไซต์ในเครือข่ายเห็นหรือเข้าถึงเมนู plugin ใน dashboard ของตนหรือไม่ และถ้าอนุญาตแล้ว สิทธิ์ดังกล่าวจะครอบคลุมถึงการ เปิดใช้งาน (activating) หรือ ปิดใช้งาน (deactivating) plugin ด้วยหรือไม่

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

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

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

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

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

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

Media (สื่อ)

เมื่อเว็บไซต์เครือข่ายแชร์ฐานข้อมูลเดียวกันใน WordPress Multisite พวกเขาจะเก็บไฟล์มีเดียไว้ในตำแหน่งที่แตกต่างกันบนระบบไฟล์ แต่ตำแหน่งมาตรฐานของ WordPress (wp-content/uploads) ยังคงอยู่ เพียงแต่เส้นทางของมันจะถูกเปลี่ยนให้สะท้อนถึง ID เฉพาะของไซต์เครือข่าย ไฟล์มีเดียสำหรับเว็บไซต์เครือข่ายจะปรากฏเป็น wp-contents/uploads/site/[id]

Permalinks (ลิงก์ถาวร)

เราเคยกล่าวไปแล้วว่าการตั้งค่าแบบ subdomain มีข้อดีที่แตกต่างจากการตั้งค่าแบบ subdirectory และนี่คือเรื่องของเส้นทาง (paths)

ในการตั้งค่าแบบ subdirectory ไซต์หลัก (ไซต์แรกที่สร้างขึ้นเมื่อมีการตั้งค่าเครือข่าย) และเว็บไซต์ย่อยในเครือข่ายจะต้องใช้เส้นทางเดียวกันที่นำไปสู่ชื่อโดเมน ซึ่งสิ่งนี้มีโอกาสเกิดความขัดแย้งได้มากมาย สำหรับโพสต์ จะมีการเพิ่มเส้นทาง /blog/ ที่บังคับให้กับไซต์หลัก เพื่อป้องกันการชนกับเว็บไซต์อื่นในเครือข่าย ซึ่งหมายความว่าลิงก์ถาวรที่ดูสวยงามอย่าง ‘Post name’ จะแสดงเป็น domain.name/blog/post-name/

ในการตั้งค่าแบบ subdomain ไม่จำเป็นต้องทำเช่นนี้ เพราะแต่ละไซต์ในเครือข่ายจะได้รับประโยชน์จากการแยกโดเมนอย่างสมบูรณ์ ดังนั้นจึงไม่จำเป็นต้องพึ่งพาเส้นทางเดียว แต่พวกเขาจะเก็บเส้นทางที่แตกต่างกันตาม subdomain ของตนเอง

Static Pages (หน้าคงที่)

ในการตั้งค่า subdirectory ความเสี่ยงที่จะเกิดชื่อซ้ำกับหน้าเว็บแบบ static นั้นมีอยู่ เพราะเว็บไซต์หลักและเว็บไซต์ในเครือใช้พาธ (path) เดียวกัน

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

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

การลงทะเบียน (Registration)

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

ต่างจากการติดตั้ง WordPress แบบเดี่ยว (stand-alone) เว็บไซต์ในเครือจะไม่มีตัวเลือกที่คุ้นเคยในการอนุญาตให้มีการลงทะเบียนผู้ใช้ หรือกำหนดการลงทะเบียนเหล่านั้นให้กับบทบาท (roles) ต่างๆ

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

举例来说，假设您的 WordPress Multisite 的业务是新闻和信息。您会建立这个 multisite，然后为金融、科技、娱乐和其他感兴趣的领域创建网络站点，同时保持对插件和主题的整体控制。每个网络站点在外观和用户体验方面都将比自定义文章类型或常规文章分类拥有更深层次的控制权。

到这种程度，当用户登录时，他们是登录到整个网络，最终也登录到了每个网络站点，以提供无缝的体验。如果您的新网站是基于订阅的，这将是理想的解决方案和结果。

然而，如果 multisite 的预期性质和目的是提供没有相互关系的独立网络站点，那么几乎总是需要外部或额外的插件来操作用户角色。

域名和 SSL

我们来谈谈一个 WordPress Multisite 安装中几乎容易被忽略的内容——Wordpress.com。这是最全面的 WordPress multisite 示例，它展示了它可以如何进行定制和塑造以实现特定目的的强大能力。

在当今的现代互联网上，使用 SSL（安全数据层）几乎是强制性的，WordPress multisite 的网络管理员很快就会面临这些挑战。

在 subdomain 配置中，站点是基于根域名创建的。因此，一个标记为 ‘site1’ 的站点将作为 ‘site1.domain.com’ 创建。利用通配符 SSL 证书，网络管理员可以成功解决这一挑战，并为整个网络提供 SSL 加密功能。

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

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

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

Ultimate Multisite

เมื่อเข้าใจความแตกต่างระหว่างการติดตั้ง WordPress แบบเดี่ยว (stand-alone) กับการติดตั้งแบบ 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) หรือการตลาด ซึ่งถูกระบุเป็นบริการเพิ่มเติม

ສຳລັບອົງການຈັດຕັ້ງ (agencies), Ultimate Multisite ນຳສະເໜີຂໍ້ໄດ້ປຽບທີ່ໜ້າທึ่งໃນຄວາມສາມາດຂອງມັນໃນການໂຮດ ແລະ ຈັດການເວັບໄຊທ໌ຫຼາຍໆແຫ່ງພາຍໃຕ້ເວທີດຽວ. ສຳລັບອົງການຈັດຕັ້ງທີ່ເຮັດແບບເປັນມາດຕະຖານກ່ຽວກັບການອອກແບບໂດຍໃຊ້ theme ໃດໜຶ່ງ ເຊັ່ນ GeneratePress, Astra, OceanWP ຫຼື ອື່ນໆ ກໍສາມາດໃຊ້ຄວາມສາມາດຂອງ Ultimate Multisite ເພື່ອເປີດໃຊ້ theme ເຫຼົ່ານັ້ນໃຫ້ກັບເວັບໄຊທ໌ໃໝ່ໆໄດ້ໂດຍອັດຕະໂນມັດ.

ຄືກັນກັບຂໍ້ສະເໜີສ່ວນຫຼຸດຫຼາຍຢ່າງສຳລັບລາຄາ agency ຕໍ່ plugin ທົ່ວໄປ ແລະ ເປັນທີ່ນິຍົມ, ການໃຊ້ Ultimate Multisite ຊ່ວຍໃຫ້ອົງການຈັດຕັ້ງສາມາດໃຊ້ການລົງທຶນທີ່ມີຢູ່ແລ້ວໄດ້ໂດຍການມີເວທີກາງ (common platform) ທີ່ plugin ສາມາດຕິດຕັ້ງ, ບຳລຸງຮັກສາ ແລະ ນຳໃຊ້ໄດ້.

ສ່ວນຫຼາຍແມ່ນການໃຊ້ configuration ແມ່ນເປັນທີ່ຕ້ອງການ ແລະ ເປັນໂຊກດີທີ່ Ultimate Multisite ເຮັດໃຫ້ການເຮັດ domain mapping ແລະ SSL certificates ງ່າຍຫຼາຍຜ່ານການເຊື່ອມຕໍ່ກັບຜູ້ໃຫ້ບໍລິການ hosting ທີ່ມີຊື່ສຽງຈຳນວນໜຶ່ງ ເຊັ່ນ Cloudflare ແລະ cPanel.

ດັ່ງນັ້ນ, ການໃຊ້ຜູ້ໃຫ້ບໍລິການໃດໜຶ່ງ ຫຼື ການວາງ Ultimate Multisite ໄວ້ຫຼັງ Cloudflare ສ່ວນດ້ານການຈັດການ domain ແລະ SSL certificates ກໍຈະງ່າຍຫຼາຍ.

ອົງການຈັດຕັ້ງທີ່ຕ້ອງການຄວບຄຸມການສ້າງເວັບໄຊທ໌ຢ່າງເຂັ້ມງວດ ຈະເຫັນເຖິງຄວາມສະດວກໃນການສ້າງເວັບໄຊທ໌ ແລະ ການເຊື່ອມໂຍງເວັບໄຊທ໌ກັບລູກຄ້າ ແລະ ແຜນການຕ່າງໆ ຜ່ານ interface ທີ່ເຮັດໃຫ້ງ່າຍຂຶ້ນຂອງ Ultimate Multisite.

ການຄວບຄຸມ plugin ແລະ theme ແມ່ນຍັງຖືກຮັກສາໄວ້ໃນລະດັບຜະລິດຕະພັນ (per-product basis) ໂດຍຜ່ານ interface ທີ່ເຂົ້າໃຈງ່າຍຂອງ Ultimate Multisite ເຊິ່ງເຮັດໃຫ້ສາມາດເປີດໃຊ້ ຫຼື ຊ່ອນໄວ້ໄດ້ວ່າ plugin ແລະ theme ນັ້ນຈະມີຢູ່ຫຼືບໍ່, ລວມທັງສະຖານະການເປີດໃຊ້ເມື່ອສ້າງເວັບໄຊທ໌ໃໝ່.

Theme ต่างก็ให้ฟังก์ชันที่คล้ายกัน ทำให้สามารถเปิดหรือปิดธีมเฉพาะบนเว็บไซต์ได้เมื่อสร้างเว็บไซต์

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

กรณีที่ 2: ผู้ให้บริการเฉพาะกลุ่ม (Niche Provider)

มีคำกล่าวเก่าๆ ที่ว่า “ทำสิ่งใดสิ่งหนึ่งให้ดี” สำหรับผู้เชี่ยวชาญหลายคน นี่หมายถึงการสร้างผลิตภัณฑ์หรือบริการโดยมีแนวคิดหลักเพียงอย่างเดียว

บางทีคุณอาจเป็นนักกอล์ฟตัวยงที่โปรโมตเว็บไซต์ให้กับสโมสร หรือคุณอาจเป็นเกมเมอร์อีสปอร์ตตัวยงที่ให้บริการเว็บไซต์แก่แคลน บางทีคุณอาจเป็นคนที่โปรโมตบริการจองโต๊ะให้กับร้านอาหาร?

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

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

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

ຂຶ້ນກັບຄວາມຕ້ອງການ Configuraton ຂອງ subdirectory ຫຼື subdomain ອາດຈະເໝາະສົມກໍໄດ້, ໃນກໍລະນີດັ່ງກ່າວ ການເລືອກ kiến trúc (architecture choices) ຈະຢູ່ລະຫວ່າງການໃຊ້ SSL certificate ງ່າຍໆສຳລັບ subdirectories ຫຼື wildcard SSL certificate ສຳລັບ subdomains.

ກໍລະນີທີ 3: ການໂຮດເວັບ WordPress

ມີວິທີການຫຼາກຫຼາຍໃນການໂຮດ (host) ເວັບໄຊທ໌ WordPress ແຕ່ຫາຍາກທີ່ມັນຈະງ່າຍຄືກັບການສະໜອງພື້ນທີ່ເວັບໃຫ້ລູກຄ້າທີ່ມີ WordPress pre-installed. ນີ້ເປັນເພາະວ່າຕ້ອງມີການຕັດສິນໃຈ ແລະ ການພິຈາລະນາຫຼາຍຢ່າງມາຮ່ວມກັນເພື່ອໃຫ້ໄດ້ບໍລິການທີ່ມີຄວາມໝາຍ.

Ultimate Multisite ເປັນຜູ້ຊ່ຽວຊານໃນດ້ານນີ້ໂດຍການສະໜອງວິທີແກ້ໄຂແບບ turnkey ທີ່ຄົບຖ້ວນສຳລັບການໂຮດ WordPress sites. ໃນວິທີແກ້ໄຂນີ້ປະກອບມີກົນໄກຫຼັກເພື່ອໃຫ້ບໍລິການແບບ subscription, ການເກັບເງິນ, checkout forms, discount vouchers ແລະ ການຕິດຕໍ່ສື່ສານກັບລູກຄ້າ.

ວຽກສ່ວນທີ່ສຳຄັນໃນການຕິດຕັ້ງ, configure ແລະ ບໍາລຸງຮັກສາ WordPress Multisite ຢ່າງຖືກຕ້ອງ ແມ່ນໄດ້ຮັບການຊ່ວຍເຫຼືອຈາກ Ultimate Multisite ເຖິງຂະໜາດທີ່ຜູ້ບໍລິຫານເຄືອຂ່າຍ (network administrators) ພຽງແຕ່ຕ້ອງພິຈາລະນາໃນດ້ານທີ່ກ່ຽວຂ້ອງກັບການບໍລິການ ຫຼື niche ຂອງເຂົາເຈົ້າ ເຊັ່ນ: product tiers, ການກຳນົດລາຄາ ແລະ service offers.

ສຳລັບ developer ທີ່ຕ້ອງການເຊື່ອມຕໍ່ກັບ Ultimate Multisite, ວິທີແກ້ໄຂນີ້ຍັງສະເໜີ RESTful API ແລະ Webhooks ທີ່ຄົບຖ້ວນສຳລັບການແຈ້ງເຕືອນ events.

ໂດຍບໍ່ຕ້ອງເພິ່ງພາ external plugins ແລະ licenses ຫຼາຍຢ່າງ, Ultimate Multisite ສະໜອງວິທີແກ້ໄຂທີ່ມີຟີເຈີຫຼາກຫຼາຍ ແລະ ທຽບເທົ່າກັບ Wix, Squarespace, WordPress.com ແລະ ອື່ນໆ.

ການພິຈາລະນາດ້ານ kiến trúc (Architecture Considerations)

ເຖິງວ່າຈະບໍ່ແມ່ນຄູ່ມືທີ່ຄົບຖ້ວນ, ຂໍ້ຕໍ່ໄປນີ້ຄວນເປັນຄຳແນະນຳໃນການເລືອກເຕັກໂນໂລຊີທີ່ຖືກຕ້ອງເພື່ອສະໜັບສະໜູນການຕິດຕັ້ງ Ultimate Multisite.

Shared vs. Dedicated Hosting

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

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

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

สรุปง่ายๆ คือ ราคาถูกไม่ได้แปลว่าดีเสมอไป

Ultimate Multisite เป็นที่ทราบกันว่าทำงานได้ดีกับผู้ให้บริการโฮสติ้งหลายราย และสามารถผสานรวมเข้ากับสภาพแวดล้อมของพวกเขาได้อย่างลงตัวเพื่อมอบฟังก์ชันต่างๆ เช่น การแมปโดเมน (domain mapping) และ SSL อัตโนมัติ ผู้ให้บริการเหล่านี้ให้ความสำคัญกับประสิทธิภาพและให้บริการในระดับที่สูงกว่าเว็บโฮสติ้งแบบแชร์

สำหรับรายชื่อผู้ให้บริการที่เข้ากันได้และคำแนะนำการตั้งค่าที่สมบูรณ์สำหรับแต่ละราย โปรดตรวจสอบเอกสารของ Compatible Providers

ข้อควรพิจารณาด้านประสิทธิภาพ

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

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

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

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

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

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

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

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

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

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

สิ่งที่ไม่มีข้อโต้แย้งก็คือ จำเป็นต้องมีการสำรองข้อมูล และแทบจะเป็นไปไม่ได้เลยที่ผู้ให้บริการจะไม่จัดการเรื่องนี้ โดยเฉพาะอย่างยิ่งผู้ให้บริการที่เป็นบริการแบบ Managed Service (บริการจัดการ) ดังนั้น ลูกค้าก็จะหันไปหาผู้ดูแลเครือข่ายเพื่อจัดเตรียมและจัดการบริการนี้ ซึ่งการจะมองหาผู้ดูแลเครือข่ายนั้นเป็นปัญหาที่แตกต่างออกไปโดยสิ้นเชิง

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

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

Snapshots (ภาพรวมสถานะ)

Snapshots เป็นเหมือนยาวิเศษสำหรับการสำรองข้อมูล เพราะมันง่าย ไม่ซับซ้อน (จนกว่าคุณจะต้องการกู้คืน) และใช้งานได้ทันที ถึงแม้ว่ามันจะต้องได้รับความช่วยเหลือจากผู้ให้บริการของคุณบ้าง แต่ส่วนใหญ่จะใช้ได้กับ VPS (Virtual Private Server) หรือเซิร์ฟเวอร์เสมือนที่คล้ายกัน ผู้ให้บริการหลายรายที่ระบุไว้ในเอกสาร ‘Compatible Providers’ ของเรา มีบริการ backup ที่ไม่จำเป็นต้องมีการแทรกแซงหรือพิจารณาเพิ่มเติมจากผู้ดูแลเครือข่ายเลย

การสำรองข้อมูลแบบดั้งเดิมจะเก็บไฟล์และฐานข้อมูล แต่ snapshot จะเก็บทั้งดิสก์ทั้งหมด ซึ่งหมายความว่าไม่เพียงแต่ข้อมูลของเว็บไซต์เท่านั้นที่จะถูกบันทึกใน snapshot แต่ยังรวมถึงระบบปฏิบัติการและการตั้งค่าด้วย สำหรับหลายๆ คน นี่เป็นข้อได้เปรียบที่ชัดเจน เพราะสามารถสร้างระบบใหม่จาก snapshot ได้เกือบจะทันที และนำมาใช้งานเพื่อแทนที่ระบบที่มีปัญหาได้ ในทำนองเดียวกัน กระบวนการกู้คืนเพื่อดึงไฟล์ก็เพียงแค่แนบ image ของ snapshot เป็นดิสก์ให้กับ instance ที่มีอยู่ เพื่อให้สามารถเข้าถึงและคัดลอกไฟล์ได้

Snapshot อาจมีค่าใช้จ่ายเพิ่มเติมจากผู้ให้บริการโฮสติ้ง แต่มันก็เหมือนกับประกันภัยสำหรับเหตุการณ์ไม่คาดฝันครับ

สคริปต์ภายนอก (External Scripts)

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

เราไม่สามารถแนะนำสคริปต์ใดเป็นพิเศษเหนืออีกตัวหนึ่งได้ แต่คำแนะนำทั่วไปของเราคือให้ทำการทดสอบการสำรองข้อมูลและการกู้คืนหลายๆ ครั้ง เพื่อให้แน่ใจว่าผลลัพธ์ที่ได้เป็นไปตามที่ต้องการ และ "ต้องมั่นใจให้มั่น" โดยการประเมินสคริปต์และฟังก์ชันของมันอย่างต่อเนื่อง โดยเฉพาะในส่วนที่มีการใช้กลยุทธ์การสำรองข้อมูลแบบ differential (differential backup strategy)

ควรทราบว่าขณะที่สคริปต์เหล่านี้กำลังทำงาน จะทำให้โหลดของระบบเพิ่มขึ้น ซึ่งต้องนำมาพิจารณาด้วยครับ

Plugins

แทบจะไม่มีปัญหาใดใน WordPress ที่ไม่สามารถแก้ไขได้ด้วย plugin และถ้าคุณไม่ถนัดในการจัดการสคริปต์ภายนอก บางที plugin อาจเป็นทางเลือกที่ดีที่สุดต่อไปก็ได้

แม้ว่าปลั๊กอินแต่ละตัวจะมีตัวเลือกและฟีเจอร์ที่แตกต่างกัน แต่ส่วนใหญ่ก็ทำหน้าที่เหมือนกัน นั่นคือการคัดลอกไฟล์ WordPress และเนื้อหาฐานข้อมูลไป จากนั้นฟังก์ชันต่างๆ ก็จะแตกต่างกันไป เพราะบางปลั๊กอินสามารถส่งสำเนาไปยังบริการภายนอก เช่น Google Drive หรือ Dropbox หรือบริการจัดเก็บวัตถุ (object storage service) ที่เข้ากันได้ เช่น S3, Wasabi หรืออื่นๆ ได้ ปลั๊กอินที่ครอบคลุมมากกว่าจะมีฟังก์ชันการสำรองข้อมูลแบบ differential backups หรือกลยุทธ์บางอย่างในการสำรองเฉพาะข้อมูลที่มีการเปลี่ยนแปลงเท่านั้น เพื่อประหยัดค่าใช้จ่ายในการจัดเก็บภายนอก

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

โดเมนและ 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 เพราะเซิร์ฟเวอร์ปลายทางจะถูกอ่านจาก HTTP headers แต่ไม่ค่อยมีเว็บไซต์ที่เรียบง่ายขนาดนี้ในปัจจุบันที่การทำธุรกรรม HTTPS ที่ปลอดภัยเกือบจะเป็นสิ่งที่จำเป็น

โชคดีที่มีตัวเลือกง่ายๆ สำหรับใบรับรอง SSL ครับ ในโหมด subdirectory คุณสามารถใช้ใบรับรองโดเมนปกติได้ ใบรับรองเหล่านี้มีให้ใช้งานฟรีและง่ายดายจากผู้ให้บริการโฮสติ้งที่อาจใช้บริการ LetsEncrypt ฟรี หรือแหล่งอื่น ๆ หากไม่ใช่กรณีนี้ ใบรับรองจะวางจำหน่ายเชิงพาณิชย์จากหน่วยงานต่างๆ หากคุณสามารถสร้างคำขอลงนามใบรับรอง (certificate signing request) ได้

สำหรับโหมด subdomain การใช้ใบรับรอง SSL แบบ wildcard จะเข้ากันได้อย่างสมบูรณ์กับโดเมนแบบ wildcard และทำให้ใบรับรองนั้นมีผลบังคับใช้สำหรับโดเมนหลักและทุก subdomain โดยไม่ต้องตั้งค่าเพิ่มเติมใดๆ

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

Ultimate Multisite ที่ติดตั้งมาพร้อมกับระบบ (out-of-the-box) นี้ได้นำทางออกสำหรับปัญหานี้ โดยแสดงให้เห็นถึงประสบการณ์อันกว้างขวางของเรากับความต้องการของ WordPress multisites การเปิดใช้งาน add-on ง่ายๆ นี้จะทำให้ Ultimate Multisite ใช้ข้อมูลการเข้าสู่ระบบ Cloudflare ของคุณเพื่อเพิ่มรายการ DNS สำหรับไซต์เครือข่ายใน Cloudflare โดยอัตโนมัติ และตั้งค่าโหมดเป็น ‘proxied’ ด้วยวิธีนี้ แต่ละ subsites ในเครือข่ายเมื่อถูกสร้างขึ้น จะได้รับความคุ้มครองและประโยชน์เต็มรูปแบบของ Cloudflare รวมถึง SSL ด้วย

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

สำหรับหลายๆ คน การใช้ 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 และมีข้อกำหนดหรือขั้นตอนพิเศษใดที่จำเป็นสำหรับการขอใบอนุญาตหรือไม่