Ultimate Multisite 101

Ultimate Multisite เป็น plugin สำหรับ WordPress Multisite ที่ช่วยให้คุณสามารถเปิดให้บริการ WaaS หรือ Websites as a Service แก่ลูกค้าได้ ก่อนที่เราจะเจาะลึกและเรียนรู้ว่า Ultimate Multisite จะช่วยธุรกิจและลูกค้าของคุณได้อย่างไร มีความรู้พื้นฐานบางอย่างที่เราต้องทำความเข้าใจก่อน

WordPress Multisite คืออะไร

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

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

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

ใน WordPress มีฟีเจอร์ที่เรียกง่ายๆ ว่า 'Multisite' ซึ่งมีต้นกำเนิดย้อนไปถึงปี 2010 เมื่อเปิดตัว WordPress 3.0 นับตั้งแต่นั้นมาก็มีการปรับปรุงหลายครั้งเพื่อเพิ่มฟีเจอร์ใหม่และเพิ่มความปลอดภัย

โดยหลักแล้ว WordPress multisite สามารถเข้าใจได้ว่า: มหาวิทยาลัยติดตั้ง WordPress เพียงครั้งเดียว แต่แต่ละคณะมีเว็บไซต์ WordPress ของตัวเอง

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

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

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

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

Subdomain vs. Subdirectory

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

ในการกำหนดค่าแบบ subdirectory เว็บไซต์ในเครือข่ายจะสืบทอด path ตามชื่อโดเมนหลัก ตัวอย่างเช่น เว็บไซต์ในเครือข่ายที่ชื่อ 'site1' จะมี URL เต็มเป็น https://domain.com/site1 ในการกำหนดค่าแบบ subdomain เว็บไซต์ในเครือข่ายจะมี subdomain ของตัวเองที่มาจากชื่อโดเมนหลัก ดังนั้นเว็บไซต์ที่ชื่อ 'site1' จะมี URL เต็มเป็น https://site1.domain.com/

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

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

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

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

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

Plugins และ Themes

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

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

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

ผู้ใช้และผู้ดูแลระบบ

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

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

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

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

สื่อ (Media)

ในขณะที่เว็บไซต์ในเครือข่ายใช้ฐานข้อมูลเดียวกันใน WordPress Multisite พวกมันจะมี paths แยกกันบนระบบไฟล์สำหรับไฟล์สื่อ

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

Permalinks

เราได้กล่าวไว้ก่อนหน้านี้ว่ามีข้อได้เปรียบที่ชัดเจนของ subdomain เหนือการกำหนดค่าแบบ subdirectory และนี่คือสิ่งนั้น: paths

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

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

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

หน้าแบบ Static

ในการกำหนดค่าแบบ subdirectory ศักยภาพสำหรับความขัดแย้งของชื่อขยายไปถึงหน้าแบบ static เนื่องจากเว็บไซต์หลักและเว็บไซต์ในเครือข่ายใช้ path เดียวกัน

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

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

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

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

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

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

ตัวอย่างเช่น สมมติว่า WordPress Multisite ของคุณอยู่ในธุรกิจข่าวสารและข้อมูล คุณจะสร้าง multisite และสร้างเว็บไซต์ในเครือข่ายสำหรับการเงิน เทคโนโลยี บันเทิง และด้านอื่นๆ ที่น่าสนใจ ในขณะที่ยังคงควบคุม plugins และ themes โดยรวม แต่ละเว็บไซต์ในเครือข่ายจะมีการควบคุมรูปลักษณ์และประสบการณ์ผู้ใช้ของเว็บไซต์ในเครือข่ายของตนได้มากกว่า custom post types หรือหมวดหมู่บทความปกติ

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

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

โดเมนและ SSL

มาพูดถึงการติดตั้ง WordPress Multisite ที่แทบจะหลุดจากความสนใจของเรา - Wordpress.com นี่คือตัวอย่างที่ครอบคลุมที่สุดของ Wordpress multisite และแสดงให้เห็นถึงความสามารถอันกว้างขวางในการปรับแต่งและหล่อหลอมให้ตอบสนองวัตถุประสงค์

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

ในการกำหนดค่าแบบ subdomain เว็บไซต์ถูกสร้างขึ้นตามชื่อโดเมนราก ดังนั้นเว็บไซต์ที่ชื่อ 'site1' จะถูกสร้างเป็น 'site1.domain.com' โดยใช้ wildcard SSL certificate ผู้ดูแลเครือข่ายสามารถจัดการกับความท้าทายนี้ได้สำเร็จและให้ความสามารถในการเข้ารหัส SSL สำหรับเครือข่าย

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

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

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

Ultimate Multisite

เมื่อเข้าใจความแตกต่างระหว่างการติดตั้ง WordPress แบบเดี่ยวและการติดตั้ง Multisite แล้ว มาดูกันว่า Ultimate Multisite เป็นอาวุธสุดยอดสำหรับการให้บริการ Websites as a Service อย่างไร

บทนำ

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

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

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

กรณีการใช้งาน

กรณีที่ 1: เอเจนซี่

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

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

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

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

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

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

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

Themes ให้ฟังก์ชันที่คล้ายกัน ช่วยให้ themes บางตัวถูกเปิดใช้งานหรือซ่อนเมื่อสร้างเว็บไซต์

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

กรณีที่ 2: ผู้ให้บริการเฉพาะทาง

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

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

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

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

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

ขึ้นอยู่กับความต้องการ ทั้งการกำหนดค่าแบบ subdirectory หรือ subdomain อาจเหมาะสม ซึ่งในกรณีนี้ตัวเลือกสถาปัตยกรรมจะอยู่ระหว่าง SSL certificate ง่ายๆ สำหรับ subdirectories หรือ wildcard SSL certificate สำหรับ subdomains

กรณีที่ 3: WordPress Web Hosting

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

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

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

สำหรับนักพัฒนาที่ต้องการผสานรวมกับ Ultimate Multisite โซลูชันยังมี RESTful API ที่ครอบคลุมและ Webhooks สำหรับการแจ้งเตือนเหตุการณ์

โดยไม่ต้องพึ่งพา plugins และใบอนุญาตภายนอกมากมาย Ultimate Multisite ให้โซลูชันที่มีฟีเจอร์หลากหลายและเทียบเคียงได้กับ Wix, Squarespace, WordPress.com และอื่นๆ

ข้อพิจารณาด้านสถาปัตยกรรม

แม้จะไม่ใช่คู่มือที่ครอบคลุม แต่รายการต่อไปนี้ควรใช้เป็นแนวทางในการเลือกเทคโนโลยีที่ถูกต้องเพื่อรองรับการติดตั้ง Ultimate Multisite

Shared vs. Dedicated Hosting

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

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

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

กล่าวโดยย่อ ราคาถูกไม่ได้หมายความว่าดี

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

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

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

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

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

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

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

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

เราสามารถแก้ปัญหานี้ได้ง่ายๆ โดยการอัปเกรดเซิร์ฟเวอร์ แต่มันไม่ได้แก้ปัญหารอง - ความล่าช้าทางภูมิศาสตร์ เฉพาะเซิร์ฟเวอร์หลายตัวในหลายสถานที่เท่านั้นที่สามารถแก้ปัญหานี้ได้อย่างเหมาะสม

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

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

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

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

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

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

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

Snapshots

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

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

Snapshots อาจมีค่าใช้จ่ายเพิ่มเติมกับผู้ให้บริการโฮสติ้ง แต่มันเป็นกรมธรรม์ประกันภัยต่ออุบัติเหตุ

External Scripts

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

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

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

Plugins

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

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

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

โดเมนและ SSL

มีการพูดคุยกันมากแล้วเกี่ยวกับชื่อโดเมนในโหมด multisite แบบ subdomain โซลูชันที่เกือบจะเป็นสากลสำหรับผู้ดูแลเครือข่ายคือการใช้รายการ wildcard DNS

รายการ DNS ประเภทนี้จะแก้ไข subdomains เช่น 'site1.domain.com' และ 'site2.domain.com' ไปยัง IP address 1.2.3.4 ได้สำเร็จ จึงรองรับ Ultimate Multisite และในขอบเขตที่กว้างขึ้น WordPress Multisite ที่ใช้โหมด subdomain

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

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

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

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

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

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

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

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

Plugins

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

แม้ว่า plugins ส่วนใหญ่จะติดตั้งได้ใน WordPress Multisite แต่การเปิดใช้งานและการให้สิทธิ์ใช้งานจะแตกต่างกันไปตามผู้พัฒนา

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

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