Ultimate Multisite 入門指南

Ultimate Multisite 是一款 WordPress Multisite 外掛，讓你能夠為客戶提供 WaaS（網站即服務）。在深入了解 Ultimate Multisite 如何幫助你的業務和客戶之前，我們需要先掌握一些基礎知識。

WordPress Multisite 是什麼

我們大多數人都熟悉標準的 WordPress 安裝方式。你可以透過主機商的控制面板來建立網站，或者如果你比較有冒險精神，也可以自己架設網頁伺服器和資料庫、下載核心檔案，然後開始安裝流程。

這種方式適用於全球數百萬個 WordPress 網站，但從網站代理商或主機商的角度來看，讓我們來談談規模化的問題。

建立一個 WordPress 網站很簡單，甚至透過自動化控制面板建立一百個網站也不難，但當需要管理這些網站時，問題就會開始浮現。如果疏於管理，你很容易成為惡意軟體的攻擊目標。要做好管理需要投入心力和資源，雖然市面上有外部工具和外掛可以協助簡化 WordPress 網站的管理和維護，但由於客戶仍然擁有管理員權限，這些努力很容易被破壞殆盡。

WordPress 核心提供了一個功能，簡稱為「Multisite」，最早可以追溯到 2010 年 WordPress 3.0 推出的時候。此後經過多次改版，陸續加入新功能並強化安全性。

簡單來說，WordPress Multisite 可以這樣理解：一所大學只需維護一套 WordPress 安裝，但每個學院都可以擁有自己的 WordPress 網站。

為了更清楚說明，讓我們來看看一些基本術語，這些術語不僅出現在 Ultimate Multisite 的文件中，也廣泛使用於整個 WordPress 社群。

網路（Network）

在 WordPress 的術語中，Multisite 網路是指可以從單一控制台管理多個子網站的架構。雖然建立 Multisite 網路的方式因主機商而異，但最終結果通常是在 wp-config.php 檔案中加入一些額外的設定，讓 WordPress 知道它正在這種特定模式下運作。

Multisite 網路與獨立的 WordPress 安裝之間有一些明顯的差異，我們接下來會簡單說明。

子網域 vs. 子目錄

你需要做的第一個重要決定是：Multisite 安裝要使用「子目錄」還是「子網域」模式。Ultimate Multisite 在這兩種配置下都能正常運作，但兩者在架構上有一些差異。

在「子目錄」模式下，網路中的網站會繼承主網域的路徑。例如，一個名為「site1」的網路網站，其完整網址會是 https://domain.com/site1。在「子網域」模式下，網路網站會有自己的子網域，衍生自主網域名稱。因此，名為「site1」的網站，其完整網址會是 https://site1.domain.com/。

這兩種選擇都完全可行，但使用「子網域」確實有一些優勢，同時也需要在架構規劃上多花一些心思。

從 DNS 的角度來看，「子目錄」模式相對簡單。由於網路網站只是主路徑的子項目，主網域只需要一筆 DNS 記錄即可。「子網域」模式則比較複雜，需要為每個網路網站分別建立 CNAME 記錄，或者在 DNS 記錄中使用萬用字元（*）。

另一個需要考慮的是 SSL 憑證的核發與使用。在「子目錄」模式下，只需要一張網域憑證即可，因為網路網站只是主網域的路徑。因此，一張 domain.com 的憑證就能為 https://domain.com/site1、https://domain.com/site2 等網址提供 SSL 保護。

在「子網域」模式下，最常見的做法是使用萬用字元 SSL 憑證。這種 SSL 憑證可以為一個網域及其所有子網域提供加密。因此，一張萬用字元 SSL 憑證就能為 https://site1.domain.com、https://site2.domain.com 以及 https://domain.com 本身提供加密保護。

雖然還有其他選項，但這些方案通常在範圍和應用上比較受限，需要額外的設定，並且要評估是否適合你的情況。

外掛和佈景主題

WordPress 給予的，它也會收回——至少從客戶的角度來看是這樣。在獨立的 WordPress 安裝中，如果網站管理員安裝了有問題的外掛或未能保持安裝更新，受害者只有他們自己。然而，在 Multisite 安裝中，如果網站管理員安裝了有問題的外掛，整個網路中的每個網站都會成為受害者。

因此，在 Multisite 模式下，WordPress 會移除網站管理員安裝外掛和佈景主題的權限，改由新建立的網路管理員（或稱「超級管理員」）角色來負責。這個特權角色可以決定是否允許網路網站的管理員在他們的控制台中看到或存取外掛選單，以及是否可以「啟用」或「停用」外掛。

因此，網路管理員負責在網路中安裝外掛和佈景主題，並將使用這些外掛和佈景主題的權限委派給網路網站。網站管理員無法安裝外掛和佈景主題，也無法存取未分配給他們網站的外掛和佈景主題。

使用者和管理員

在 WordPress Multisite 中，所有網路網站共用同一個資料庫，因此也共用相同的使用者、角色和權限。最好的理解方式是：所有使用者都是網路的成員，而不是某個特定網站的成員。

基於這個理解，允許建立使用者可能並不理想，因此 WordPress Multisite 會將這項權限從網站管理員移除，改由網路管理員來負責。網路管理員可以將必要的權限委派給網站管理員，讓他們能夠為自己的網站建立使用者帳號。

重申上述觀點，雖然使用者帳號看起來是屬於某個網站的，但實際上它們是分配給整個網路的，因此在整個網路中必須是唯一的。可能會有些使用者名稱因為這個原因而無法註冊。

雖然這種單一來源的使用者註冊和驗證方式在企業系統中並不陌生，但對於熟悉獨立 WordPress 安裝（使用者管理相對簡單）的人來說，這通常是一個難以理解的概念。

媒體檔案

在 WordPress Multisite 中，網路網站雖然共用單一資料庫，但在檔案系統上各自維護獨立的媒體檔案路徑。

標準的 WordPress 位置（wp-content/uploads）仍然存在，但路徑會被修改以反映網路網站的唯一 ID。因此，網路網站的媒體檔案會出現在 wp-contents/uploads/site/[id] 路徑下。

永久連結

我們之前提到「子網域」相較於「子目錄」模式有明顯的優勢，這裡就是一個例子：路徑問題。

在「子目錄」模式下，主網站（建立網路時創建的第一個網站）和網路子網站必須共用從網域名稱延伸出來的相同路徑。這可能會造成大量的衝突。

對於文章，主網站會強制加上 /blog/ 路徑以防止與網路網站衝突。這意味著像「文章名稱」這樣的美化永久連結會呈現為 domain.name/blog/post-name/

在「子網域」模式下則不需要這樣做，因為每個網路網站都享有完整的網域分隔，不需要依賴單一路徑。它們各自基於自己的子網域維護獨立的路徑。

靜態頁面

在「子目錄」模式下，命名衝突的可能性也延伸到靜態頁面，因為主網站和網路網站共用相同的路徑。

為了防止這種情況，WordPress 提供了一種方式來將某些網站名稱加入黑名單，避免它們與主網站的名稱衝突。通常網路管理員會輸入主網站頁面的根路徑。

在「子網域」模式下，命名衝突的可能性因為子網域的存在而得到緩解，因為子網域對於網路網站來說是唯一的，與主網站沒有任何關聯。

註冊

在 WordPress Multisite 的網路設定中，有幾個新的使用者註冊選項，允許新使用者和現有使用者建立網站。

與獨立的 WordPress 安裝不同，網路網站沒有我們熟悉的允許使用者註冊或將註冊分配給角色的選項。

當使用者帳號被建立時，這些帳號是在網路層級產生的。因此，它們不屬於任何特定網站，而是屬於整個網路。這有一些明顯的優勢和劣勢。

舉例來說，假設你的 WordPress Multisite 是從事新聞和資訊業務。你可以建立 Multisite，然後為財經、科技、娛樂和其他領域建立網路網站，同時保持對外掛和佈景主題的整體控制。每個網路網站對於其外觀、風格和使用者體驗的控制程度，會比使用自訂文章類型或一般文章分類來得更大。

因此，當使用者登入時，他們是登入到整個網路，最終也同時登入到每個網路網站，提供無縫的體驗。如果你的新網站是採用訂閱制，這將是理想的解決方案和成果。

然而，如果 Multisite 的預定性質和目的是提供彼此無關的獨立網路網站，幾乎總是需要使用外部或額外的外掛來調整使用者角色。

網域和 SSL

讓我們來談談一個幾乎被我們忽視的 WordPress Multisite 安裝——WordPress.com。這是迄今為止最廣泛的 WordPress Multisite 範例，展示了其被客製化和塑造以實現特定目的的強大能力。

在現代網路中，SSL 的使用幾乎是強制性的，WordPress Multisite 的網路管理員很快就會面臨這些挑戰。

在「子網域」模式下，網站是基於根網域名稱建立的。因此，名為「site1」的網站會被建立為「site1.domain.com」。透過使用萬用字元 SSL 憑證，網路管理員可以成功應對這個挑戰，為整個網路提供 SSL 加密能力。

WordPress Multisite 包含網域對應功能，允許網路網站與自訂網域名稱或與網路根網域不同的網域名稱關聯。

對於網路管理員來說，這帶來了額外的複雜性，包括網域名稱設定以及 SSL 憑證的核發和維護。

因此，雖然 WordPress Multisite 提供了將 www.anotherdomain.com 對應到「site1」的方式，但網路管理員仍需自行解決外部管理 DNS 記錄和實作 SSL 憑證的挑戰。

Ultimate Multisite

在了解獨立 WordPress 安裝和 Multisite 安裝之間的差異後，讓我們來看看 Ultimate Multisite 如何成為提供網站即服務的終極利器。

簡介

Ultimate Multisite 是你建立網站即服務（WaaS）的瑞士刀。想想 Wix.com、Squarespace、WordPress.com，然後想像擁有你自己的服務。

在底層，Ultimate Multisite 使用 WordPress Multisite，但它的運作方式不僅解決了網路管理員在 Multisite 安裝中面臨的眾多挑戰，還增強了功能，支援各種不同的使用情境。

在接下來的章節中，我們將探討一些常見的使用情境以及支援這些情境所需的考量。

使用情境

情境 1：網站代理商

通常代理商的核心技能在於網站設計，而主機託管或行銷等則列為附加服務。

對於代理商來說，Ultimate Multisite 在單一平台上託管和管理多個網站的能力提供了極高的價值。更棒的是，那些將設計標準化到特定佈景主題（如 GeneratePress、Astra、OceanWP 等）的代理商，可以利用 Ultimate Multisite 為每個新網站自動啟用這些佈景主題。

同樣地，由於許多常見和熱門外掛都有代理商授權優惠，使用 Ultimate Multisite 可以讓代理商善用現有投資，提供一個可以安裝、維護和使用外掛的共同平台。

大多數情況下會需要使用網域對應設定，而 Ultimate Multisite 透過與多家熱門主機商以及 Cloudflare 和 cPanel 等服務的整合，讓網域對應和 SSL 憑證的處理變得非常容易。

因此，透過這些主機商或將 Ultimate Multisite 放在 Cloudflare 後面，網域和 SSL 憑證的管理就變得相當簡單了。

喜歡嚴格控制網站建立的代理商，會欣賞 Ultimate Multisite 簡潔的介面，可以輕鬆建立網站並將網站與客戶和方案關聯起來。

透過 Ultimate Multisite 直觀的介面，可以按產品維護對外掛和佈景主題的嚴格控制，讓外掛和佈景主題可以設定為可用或隱藏，以及在建立新網站時的啟用狀態。

佈景主題也有類似的功能，允許在建立網站時啟用或隱藏特定的佈景主題。

代理商可以透過 Ultimate Multisite 獲得安心感，讓他們專注於自己最擅長的事——設計出色的網站。

情境 2：垂直市場供應商

有句老話說：「專精一件事，把它做好。」對許多專業人士來說，這意味著圍繞單一核心理念建立產品或服務。

也許你是個高爾夫球愛好者，想為球會推廣網站；或者你是個電競玩家，想為戰隊提供網站。又或者你想為餐廳推廣訂位服務？

基於多種原因，你會想要基於共同的框架和平台提供服務。可能是因為你已經設計或投資了專屬外掛來提供所需功能，也可能是因為產業最佳實務需要某種標準化的設計方法。

Ultimate Multisite 最創新的功能之一是使用範本網站。範本網站是指已經安裝並啟用佈景主題、安裝並啟用必要外掛，並建立了範例文章或頁面的網站。當客戶基於範本建立新網站時，範本的內容和設定會被複製到新建立的網站。

對於提供垂直市場網站和服務的供應商來說，這提供了無與倫比的優勢——能夠立即建立一個配備自訂外掛和設計、隨時可用的網站。客戶只需要提供最少的輸入就能完成服務。

根據需求，「子目錄」或「子網域」配置都可能適合，在這種情況下，架構選擇會是「子目錄」使用簡單的 SSL 憑證，或「子網域」使用萬用字元 SSL 憑證。

情境 3：WordPress 網站託管

託管 WordPress 網站的方式有很多種，但很少像只是提供預先安裝 WordPress 的網頁空間給客戶那麼簡單。這是因為需要考慮多方面的決策才能提供有意義的服務。

Ultimate Multisite 在這方面表現出色，為 WordPress 網站託管提供了全面的交鑰匙解決方案。解決方案中包含了提供訂閱服務、收款、結帳表單、折扣券和客戶通訊的核心機制。

正確安裝、設定和維護 WordPress Multisite 所需的大部分整合工作都由 Ultimate Multisite 處理，讓網路管理員只需要考慮與其服務或利基市場相關的方面，例如產品層級、定價和服務方案。

對於希望與 Ultimate Multisite 整合的開發人員，解決方案還提供了完整的 RESTful API 和用於事件通知的 Webhooks。

不需要依賴大量的外部外掛和授權，Ultimate Multisite 提供了功能豐富且可與 Wix、Squarespace、WordPress.com 等相媲美的解決方案。

架構考量

雖然這不是一份全面的指南，但以下項目應該可以作為選擇正確技術來支援 Ultimate Multisite 安裝的參考。

共享主機 vs. 專用主機

不幸的是，並非所有主機商都是平等的，有些會採用極端的伺服器密度。低價主機商通常透過最大化伺服器密度來創造收入。因此，你的 Ultimate Multisite 安裝可能只是同一台伺服器上數百個網站中的一個。

如果主機商沒有適當的保護措施，共享伺服器上的網站會遇到「吵鬧鄰居」問題。也就是說，同一台伺服器上的某個網站消耗了大量資源，導致其他網站必須爭奪剩餘的資源。這通常表現為網站速度緩慢或無法及時回應。

作為網站託管服務的供應商，這種連鎖效應意味著你的客戶會遇到速度慢、搜尋排名低和跳出率高的問題，通常會導致客戶流失，因為他們會轉向其他服務。

簡而言之，便宜不等於好。

Ultimate Multisite 已知可以與多家優質主機商配合使用，並與他們的環境良好整合，提供網域對應和自動 SSL 等功能。這些主機商重視效能，提供比共享主機更高級別的服務。

如需相容主機商清單和各家的完整設定說明，請查閱相容主機商文件。

效能考量

Ultimate Multisite 不是一個緩慢的應用程式，相反地，它相當快速。然而，它的效能取決於底層應用程式和基礎設施，只能利用它能存取的資源。

想像一下：你是一個擁有 100 個網站的 Ultimate Multisite 安裝的網路管理員。其中一些網站表現良好，每天吸引大量訪客。

如果規模較小，比如一到五個網站，這種情況會有所不同，但不久後規模化的問題就會顯現。

如果不加以處理，單一的 Ultimate Multisite 網站將負責處理所有網站訪客的請求。這些請求可能是動態 PHP 頁面或靜態資源，如樣式表、JavaScript 或媒體檔案。無論是一個還是一百個網站，這些任務都會變得重複、單調且浪費資源。當輸出對每個請求都是相同的靜態資訊時，使用 CPU 運算能力和記憶體來處理 PHP 檔案是不必要的。

同樣地，一個 PHP 或 HTML 頁面的請求會接著產生多個對腳本、樣式表和圖片檔案的後續請求。這些請求都直接指向你的 Ultimate Multisite 伺服器。

人們可以透過升級伺服器來解決這個問題，但這並不能解決第二個問題——地理延遲。只有在多個地點部署多台伺服器才能適當解決這個問題。

因此，大多數網路管理員會使用前端快取解決方案和內容分發網路（CDN）來處理靜態頁面的請求。在請求到達伺服器之前就處理這些請求並提供資源，可以節省處理資源、消除延遲、避免不必要的升級並最大化技術投資。

Ultimate Multisite 包含一個精密的 Cloudflare 附加元件，讓網路管理員可以將他們的安裝放在 Cloudflare 後面，不僅可以使用其快取功能，還可以使用 DNS 託管、SSL 憑證和安全機制。

備份

你可以問 50 個人關於備份的建議，會得到 50 種不同的備份策略意見。答案是：視情況而定。

毫無爭議的是備份是必要的，而且由供應商來管理幾乎是不可想像的，特別是提供託管服務的供應商。因此，客戶會期望網路管理員提供和管理這項服務。而網路管理員要找誰來處理則是另一個問題。

為了本節的目的，讓我們同意備份是在備份啟動時系統狀態的時間點副本。簡單來說，備份時系統處於什麼狀態，該狀態就會被擷取並鎖定在備份中。

有了這個理解，如何實現備份以及什麼最適合你的環境，很大程度上取決於你的需求和主機商滿足這些需求的能力。然而，按照從最有主見到最沒有主見的順序，以下選項應該可以提供一些指導。

快照

快照是備份的銀彈，因為它們簡單、不複雜（直到你想要還原）而且「就是能用」。但它確實需要主機商的一些支援，而且主要適用於你擁有 VPS（虛擬專用伺服器）或類似服務的情況。我們「相容主機商」文件中列出的幾家主機商提供備份服務，不需要網路管理員進行額外的干預或考量。

傳統備份針對檔案和資料庫，而快照則針對整個磁碟。這意味著不僅網站的資料被擷取在快照中，作業系統和設定也一起被擷取。對許多人來說，這是一個明顯的優勢，因為可以幾乎立即從快照產生一個新系統並投入運作，以取代出問題的實例。同樣地，恢復過程只需要將快照映像作為磁碟附加到現有實例，就可以存取和複製檔案。

快照可能會產生主機商的額外費用，但這是對意外的保險。

外部腳本

似乎有無數的外部腳本和解決方案可以備份 WordPress 和 MySQL 資源，這些都適用於 Ultimate Multisite，因為它是一個使用 WordPress 檔案系統和資料庫的 WordPress 外掛。因此，備份 WordPress 網站的解決方案就足以涵蓋 Ultimate Multisite 的需求。

我們無法推薦任何一個腳本優於另一個，但我們的一般建議是執行多次備份和還原測試，以確保結果符合預期，並且透過持續評估腳本及其功能來「確保萬無一失」，特別是在採用某種差異備份策略的情況下。

應該注意的是，這些腳本在執行時會增加系統負載，這一點應該納入考量。

外掛

WordPress 中幾乎沒有什麼問題是外掛無法解決的，如果管理外部腳本不是你的菜，那麼外掛可能是下一個最佳選擇。

雖然外掛在選項和功能上有所不同，但它們大多執行相同的功能，那就是複製 WordPress 檔案和資料庫內容。之後功能就有所不同，有些外掛可以將備份傳送到外部服務，如 Google Drive 或 Dropbox，或某種相容的物件儲存服務，如 S3、Wasabi 等。更全面的外掛提供差異備份或某種策略，只備份已變更的資料以節省外部儲存成本。

在選擇外掛時，請務必確認它是否支援 Multisite。由於其運作性質，在備份執行期間，你可以預期伺服器會有暫時的負載，直到過程完成。

網域和 SSL

關於 Multisite「子網域」模式中的網域名稱，我們已經討論了很多。對網路管理員來說，幾乎通用的解決方案是使用萬用字元 DNS 記錄。

這種 DNS 記錄可以成功地將「site1.domain.com」和「site2.domain.com」等子網域解析到 IP 位址 1.2.3.4，從而支援 Ultimate Multisite，以及更廣泛地支援使用「子網域」模式的 WordPress Multisite。

這對於 HTTP 可能運作得很好，因為目標主機是從 HTTP 標頭中讀取的，但現今的網路很少這麼簡單，安全的 HTTPS 傳輸幾乎是強制性的。

幸運的是，SSL 憑證有簡單的選項。在「子目錄」模式下，可以使用常規的網域憑證。這些憑證可以從使用免費 LetsEncrypt 服務或其他來源的主機商免費且輕鬆地取得。否則，如果你能夠產生憑證簽署請求，這些憑證也可以從憑證機構商業購買。

對於「子網域」模式，使用萬用字元 SSL 憑證將與萬用字元網域完美配對，讓憑證對根網域和所有子網域都具有權威性，無需額外設定。

然而，應該注意的是，萬用字元 SSL 憑證可能無法與 Cloudflare 等服務配合使用，除非你使用企業方案，或者將記錄設定為僅 DNS 模式，在這種情況下所有快取和最佳化都會被繞過。

Ultimate Multisite 開箱即用地提供了這個問題的解決方案，展示了我們對 WordPress Multisite 需求的豐富經驗。啟用這個簡單的附加元件後，Ultimate Multisite 將使用你的 Cloudflare 憑證自動在 Cloudflare 中為網路網站新增 DNS 記錄，並將其模式設定為「已代理」。這樣，每個網路子網站在建立時都將獲得 Cloudflare 的完整保護和優勢，包括 SSL。

根據你 Ultimate Multisite 安裝的性質和目的，客戶可能需要使用自己的網域。在這種情況下，網路管理員需要解決兩個問題。第一，網域名稱的託管；第二，網域的 SSL 憑證。

對許多人來說，使用 Cloudflare 是一個簡單的選擇。客戶只需要將他們的網域放在 Cloudflare 上，將 CNAME 指向 Ultimate Multisite 的根網域，並在 Ultimate Multisite 中對應他們的網域，就可以開始利用他們的自訂網域名稱。

除此之外，需要尋求替代解決方案，這就是為什麼 Ultimate Multisite 推薦一份相容主機商清單。這是因為設定 DNS 和 SSL 的過程可能不是那麼簡單。然而，透過 Ultimate Multisite 與這些主機商的整合，複雜性大大降低，流程也實現了自動化。

外掛

你很可能需要額外的外掛來為客戶或網路網站提供功能。所有外掛都能在 WordPress Multisite 和 Ultimate Multisite 中運作嗎？嗯，這要視情況而定。

雖然大多數外掛都可以安裝在 WordPress Multisite 中，但它們的啟用和授權方式因作者而異。

挑戰在於授權是如何套用的，有些外掛需要按網域授權。這意味著對於某些外掛，網路管理員需要為每個新網站上的每個外掛手動啟用授權。

因此，最好先向外掛作者確認他們的外掛如何在 WordPress Multisite 中運作，以及授權所需的任何特殊要求或程序。