不知道你會不會跟我一樣很想把 WordPress 作為 SaaS ( Software as a Service 軟體及服務 ) 平台，就像是 WordPress.com 這樣？

你知道客戶是誰並且了解他們的痛點，並且你也實際透過 WordPress 協助他們解決這些問題，如果可以把已經解決過的方案包裝成一套服務來賣給更多同性質的客戶，這樣豈不是比每個案件都要客製化來得更省事得多？

我在幾年前做過這樣的美夢，要達成這樣的自動化流程有幾個關鍵的技術點，首先是主機架構，該採用 WordPress 多站網路還是使用獨立的伺服器來存放客戶的網站，其次是該如何把已經包裝好的網站內容匯入同時又還能保有一些彈性設定供客戶在申請時選擇。

對當時的我來說最棘手的就是該如何讓這一切自動化，從建立伺服器、安裝 WordPress 環境、資料庫，再到既有資料的匯入，並將完成這一切後的登入帳密自動寄送給申請人，以及在試用期結束後自動進行信用卡扣款，這些環節我一直打不通，最後還是只能用手動的方式來處理。

當年想不通的事情隨著各家主機商或是管理面板的技術發展，讓這一切逐漸變得可能，我就自己曾經使用過的技術以及卡過的關，來介紹有哪些新功能可以使用，同時也收集了一些之後可能會派得上用場的服務，希望讓當年沒打通的自己以及想打造 SaaS 的你有一些參考方向！

自動化測試站申請

基於成本考量，在客戶還沒付錢時我不打算提供機器，畢竟一開下去就是要噴錢，但又要讓客戶可以實際體驗到整個服務的流程與前後台操作，我採用的解決方案是 WordPress Multisite 多站網路，好處是 WPMU 可以複製子站的資料，這樣我就可以先把要提供給客戶的測試網站做好，再根據客戶的選擇來複製出相同的測試站。

雖然這樣很方便但還是免不了手動的複製動作，後來發現到 WordPress Demo Builder Plugin 這支外掛，它可以在前台產生一個表單，輸入 Email 後就能將子站的登入連結寄送給申請者，我把這個功能用在自己販售商業外掛的頁面上：

在後台的設定上採用短碼的形式來處理：

source_id 就是子站的 ID，所以如果你想要讓申請者選擇不同的範本，就可以先做好幾個子站，然後前台去根據所選 ID 來動態產生申請表單，就能實現不同規格的選擇。而該外掛還可以去控制申請者在後台可以看到的選單，並且設定測試站自動銷毀的時間，這樣就能在試用期過後自動移除。

之後客戶付費只要把這個子站搬移到新主機的 WordPress 環境裡面就能讓客戶繼續使用，或是繼續留在子站裡面作為正式環境，這就要看主機架構怎麼規劃，我之前的作法是同一台機器但開新的站作為正式環境，理由是 WPMU 容易讓資料庫容易肥大。

但現在有越來越多的 Database as a Server 資料庫即服務，可以彈性擴充資料庫伺服器，而且使用 WPMU 可以在同一個地方管理所有子站的佈景主題與外掛，同時也能限制客戶自行安裝外掛而產生預期外的問題，採用 WPMU 比較適合沒用過 WordPress 的客戶，不想花太多心思在網站的設定上，你給他什麼就用什麼，可以協助他們達成商業目標即可。

如果你想採用獨立正式網站的架構，可以嘗試 Migrate WordPress Website & Backups – Prime Mover 這支外掛，這是在資男每日精選外掛看到的，照它的描述可以將子站搬移到獨立的站，但我還沒有實測過，也不確定它是否可以自動化進行，萬一真的要這樣做我應該還是會從 WP CLI 來處理。

自動化開主機&安裝 WordPress

我早期選用 Plesk 這套主機管理面板來管理所有客戶的網站，主要理由是它跟 WordPress 有深度整合，能直接在 Plesk 操作外掛更新或是安全性防護，但 REST API 這塊是它的弱項，雖然它有很豐富的 CLI 可以使用，但要用在 WEB 介面跑 CLI 還是有一定程度的門檻以及安全性問題。

REST API 的支援已經是各家廠商很強調的服務，不管是 VPS 或 Cloud 主機業者，或是這幾年非常流行的 WordPress 主機代管商，可以在管理後台直接開各家廠商的伺服器，這中間靠的都是 API 串接才得以實現。於是我就在研究如何透過代管商來自動化 WordPress 的安裝與架設，發現到這流程透過 Cloudways API 來做非常容易。

邏輯大概是設計一份申請表單，裡面列出可以選擇的主機，然後選擇要安裝 WordPress 或是 WooCommerce，對應到的 API 路徑是 ServerApi 以及 ListsApi，選好後取得主機規格與要安裝的 App，POST 請求 /server 就能搞定，具體的程式碼可以參考 Cloudways 的官方教學：https://www.cloudways.com/blog/how-to-create-and-delete-applications-via-cloudways-api/

採用代管商的服務會比較貴，底層架構也比較不容易隨心所欲，像我這種想要省成本的會選擇 VPS 來處理，我最常用的服務是 Linode，他們的 API 要開機器也是非常容易，還可以透過 StackScripts 來安裝預設的環境，像是搭載 Webinoly 的 WordPress：

然後在建立機器時帶入 StackScripts ID，就能在開好機器後繼續安裝該裝的軟體，另外 StackScripts 也很容易改成自己的版本，也能透過 API 帶入需要的參數，理論上就可以透過 WP CLI 去抓到要匯入的備份檔來還原客戶在試用時期的網站內容，更多的 API 細節可以參考官方文件 Linode Create。

自動化買網址

搞定機器後剩下的就是處理自訂網址的部分，讓付費客戶可以自行設定網址是 SaaS 服務常見的功能，因此需要讓客戶能在我們的服務裡面檢查網址是否已被使用，可以用的話不用跳轉頁面就能夠直接選擇，當然付款這一段就是包含在服務月費裡面，所以網域商直接跟我們請款即可，另外還需要做 DNS 的設定，這些都要能夠透過 API 達成。

目前各家網域商都有提供 API 來進行以上的操作，但我最常用的還是 Gandi，貪圖的就是那免費的兩個信箱XD，Gandi 的 API 十分完整，除了網址相關的操作，甚是連信箱、帳務以及他們家的主機服務都管得到：

我腦海中想像的邏輯是在 SaaS 後台會有一個表單，客戶輸入他想要的網址後會先用 /domain/check 來檢查是否已經註冊，可以用的話 POST 請求 /domain/domains 進行購買，完成後再以 PUT 請求 /livedns/domains/URL/records 來修改 DNS 對應到我們的主機 IP。

具體的 API 細節可以參考官方文件：https://api.gandi.net/docs/

結論

目前我能想到 SaaS 服務需要的流程是開測試機、開正式機、買網址以及 DNS 設定，但實務上可能不只這些，像是主機發信服務等等，使用 WordPress 打造 SaaS 一直是我心裡最軟的那一塊(?)，如果你有發現其他社團或論壇有在討論這個領域的還請務必分享給我，我們下週見！