線上教學平台，功能越多越好嗎？當 WordPress、LMS 與外掛越裝越多，長期維護會發生什麼事？
目錄
很多人在規劃線上教學平台時，第一個想到的通常是：
「這個功能有沒有？」
「那個功能能不能做？」
「會員有沒有？」
「課程管理有沒有？」
「測驗有沒有？」
「金流有沒有？」
「手機版有沒有？」
於是最後很容易變成一個看起來什麼都有的系統。
尤其在 WordPress 生態裡，從 WordPress 本身開始，再加入 Tutor LMS、Tutor LMS Add-ons、會員外掛、金流外掛、表單、Email、CRM、影音服務，以及其他各式各樣的 Plugin。
功能確實可以非常多。
但是，功能很多，真的代表系統比較簡單嗎？
這其實是兩件完全不同的事情。
一套線上教學平台真正需要考慮的，不只是「今天能不能把功能做出來」，而是：
五年後、十年後，這整套系統還好不好維護？
當某一個功能突然不能用了，你知道問題在哪裡嗎？
當 WordPress 更新之後，某個外掛開始出現問題，你知道應該找誰嗎？
當學生突然無法進入課程，你能不能判斷究竟是會員系統、LMS、權限設定、Plugin 相容性，還是其他地方出了問題？
這些問題，往往不是網站剛建好的時候會看到的。
而是使用幾年之後，才慢慢浮現。
目錄
1. 拼裝型線上教學平台是怎麼組成的？
先說清楚，這裡不是要說 WordPress 不好。
事實上，WordPress 是非常成熟、自由度也非常高的網站架構。
它最大的特色之一，就是可以透過 Plugin 與各種第三方服務，不斷增加網站的功能。
如果今天要用 WordPress 建立一個線上教學平台，很可能會出現這樣的架構：
系統功能 | 可能使用的元件 |
網站基礎 | WordPress |
LMS | Tutor LMS |
LMS 擴充 | Tutor LMS Add-ons |
會員登入 | Membership Plugin |
付款 | Payment Plugin |
表單 | Form Plugin |
Email / SMTP Plugin | |
CRM | CRM Plugin |
影音 | YouTube / Vimeo / Bunny 等 |
網站主題 | WordPress Theme |
主機 | Hosting |
資料庫 | MySQL / MariaDB |
程式環境 | PHP |
其他功能 | 各種 WordPress Plugin |
單獨看每一個元件，其實都沒有問題。
而且這種方式最大的優點，就是自由度非常高。
你需要什麼功能，就去找 Plugin。
找不到，就自己開發。
需要特殊功能，也可以找 PHP 開發者客製。
所以 WordPress 能夠做到非常龐大的網站，也不是沒有原因。
真正需要思考的是：
當這些東西全部組在一起之後，整個系統還是不是一件簡單的事情？
2. 功能越多，真的代表系統越簡單嗎？
這是一個很容易被忽略的問題。
假設今天有一套系統：
只有 10 個核心功能。
另一套系統：
有 100 個功能。
一般人可能直覺認為：
「100 個功能的比較厲害。」
這沒有錯。
但是「功能比較多」和「系統比較簡單」完全不是同一件事。
因為每增加一個外掛，就代表系統多了一個需要考慮的元件。
而每一個元件，都可能有：
自己的版本
自己的更新週期
自己的開發團隊
自己的 API
自己的資料結構
自己的設定方式
自己的授權機制
自己的相容性問題
所以真正複雜的地方，往往不是「功能有多少」。
而是：
這些功能彼此之間，是怎麼連在一起的？
例如：
WordPress↓Theme↓Tutor LMS↓Tutor LMS Add-ons↓Membership Plugin↓Payment Plugin↓其他 Plugin↓影音服務
看起來每個東西都很正常。
但是當其中一個元件更新之後，問題就可能開始出現。
3. 最麻煩的不是建置，而是出問題之後
網站剛建好的時候，通常是最漂亮的。
所有功能都可以正常使用。
老師可以新增課程。
學生可以登入。
可以觀看影片。
可以付款。
可以取得課程權限。
一切看起來都沒有問題。
真正麻煩的，通常是幾年之後。
例如某一天：
WordPress 更新了。
結果某個 Plugin 出現相容性問題。
接著 Tutor LMS 某個功能異常。
學生登入之後，突然看不到原本購買的課程。
老師看到的可能只是一句：
「學生無法進入課程。」
但是這句話根本沒有告訴你真正的原因。
這時候才開始進入真正的除錯。
可能需要：
停用 Plugin
一個一個重新測試
回退版本
檢查 PHP 版本
檢查 Theme
檢查 LMS
檢查 Add-ons
查看錯誤紀錄
檢查 API
確認資料庫
再重新啟用 Plugin
最後才發現：
原來不是 LMS 壞掉。
而是另一個 Plugin 更新之後，跟 LMS 發生了相容性問題。
這就是拼裝型系統比較容易遇到的地方。
真正麻煩的不是「做出來」。
而是：
五年後出了問題，誰知道問題到底在哪裡？
4. 為什麼 A 壞掉，原因可能在 B？
這也是第三方元件越多之後，很容易發生的事情。
假設學生突然無法觀看課程。
老師第一個想到的可能是：
「是不是影片壞了？」
但實際上可能完全不是。
也可能是：
會員登入出了問題。
或者：
課程權限沒有正確判斷。
或者：
LMS 更新之後，某個 Add-on 不相容。
甚至可能是：
PHP 版本改變。
所以原本正常的程式突然出現錯誤。
也就是說：
你看到的問題，不一定是問題真正發生的地方。
這就是系統架構複雜之後，除錯會變困難的原因。
可以想像成：
WordPress 更新↓PHP 環境改變↓某個 Plugin 相容性出問題↓Tutor LMS 某個功能異常↓學生權限判斷失效↓老師最後看到的是「學生無法進入課程」
如果不了解整套系統的結構，最後很容易變成：
「到底是哪裡壞掉？」
這也是為什麼真正維護一個 WordPress 線上教學平台，和「會操作 WordPress 後台」是兩件不同的事情。
5. 第三方外掛與影音服務，會帶來哪些依賴？
使用第三方元件本身並沒有錯。
甚至可以說，現代網站本來就會使用大量第三方服務。
例如影音使用 Vimeo、YouTube 或 Bunny。
金流使用第三方服務。
Email 使用第三方服務。
這些都很正常。
真正需要注意的是：
你到底有多少東西依賴別人？
如果一個線上教學平台裡面有：
WordPress Core
＋ Theme
＋ Tutor LMS
＋ Tutor LMS Add-ons
＋ Membership Plugin
＋ Payment Plugin
＋ Form Plugin
＋ CRM Plugin
＋ Video Service
＋ Hosting
＋ Database
＋ API
那麼整個系統其實已經形成了一條很長的依賴鏈。
任何一個環節發生變化，都有可能需要重新確認整體系統是否正常。
而且這些元件通常不是由同一家公司開發。
每個開發者都有自己的：
更新時間
開發方向
技術架構
API
授權制度
維護週期
相容性處理方式
所以問題不是：
「第三方 Plugin 不好。」
而是：
當第三方元件越多，你就必須同時管理越多的技術依賴。
6. 「買斷」之後，真的就完全不用再付錢嗎？
這也是很多人在比較線上教學平台時，很容易忽略的一件事情。
「買斷」聽起來很漂亮。
但是：
買斷建置費，不代表未來完全沒有成本。
如果是 WordPress 架構，網站本身可能沒有傳統 SaaS 那種平台月租。
但這不代表後面沒有其他支出。
例如：
網域
主機
SSL
WordPress 維護
Theme
LMS
LMS Add-ons
第三方 Plugin
影音服務
金流服務
Email
資安
備份
程式更新
相容性處理
技術維護
有些服務可能是一次性購買。
有些是年費。
有些則是使用量計費。
有些甚至可能需要另外請人維護。
所以真正應該問的不是：
「這套系統是不是買斷？」
而是：
「買斷之後，誰負責它未來十年的技術生命週期？」
這兩件事情差很多。
7. 老師真的有能力自己維護整套系統嗎？
這裡又有一個很容易產生誤解的地方。
老師會操作課程後台，並不代表老師需要成為 WordPress 工程師。
例如：
老師可以新增課程。
可以上傳影片。
可以設定課程價格。
可以管理學生。
可以查看訂單。
這些都屬於「使用系統」。
但是下面這些事情，就完全是另一個層次：
PHP 版本
WordPress Core 更新
Plugin 相容性
Database
API
Server
Cache
Security
Backup
Error Log
JavaScript
Plugin conflict
這些已經不是「會不會操作課程後台」的問題。
而是：
你是不是同時在經營一套技術系統？
如果答案是「不是」，那麼這些事情最後還是必須交給其他人處理。
因此，真正應該比較的不是：
「誰的功能比較多？」
而是：
「這套系統未來的技術複雜度，是誰負責？」
8. 兩種架構放在一起比較
比較項目 | WordPress＋多外掛拼裝型 | 莫斯利垂直型 SaaS |
基礎架構 | WordPress | Wix |
LMS | Tutor LMS 等第三方 LMS | 莫斯利自己的 Core |
課程管理 | LMS | Course Core |
課程單元 | LMS / Add-on | Lesson Core |
會員授權 | 第三方 Plugin / LMS | MemberCourse Core |
系統授權 | 視架構而定 | License Core |
Quiz | 第三方 Add-on | 獨立 Quiz Core |
影音 | YouTube / Vimeo / Bunny / 自架等 | Bunny Stream |
金流 | 第三方金流＋Plugin | 依實際需求整合 |
擴充方式 | 增加 Plugin / Add-on | 增加獨立 Core |
第三方依賴 | 多 | 核心邏輯較集中 |
Plugin 相容性問題 | 可能較複雜 | 沒有大量 WordPress Plugin 依賴 |
除錯 | 需要確認多個元件之間的關係 | 模組責任較明確 |
系統更新 | WordPress / Theme / Plugin / Add-on 多方更新 | 由系統端統一維護 |
老師需要處理技術問題 | 較多 | 幾乎沒有 |
自由度 | 非常高 | 以線上教學需求為核心 |
功能數量 | 可以非常龐大 | 不追求無限制功能 |
長期維護 | 需要管理整個 Plugin 生態 | 由 SaaS 系統統一維護 |
這張表其實沒有誰一定比較好。
因為兩種架構追求的東西本來就不一樣。
WordPress 的優勢是：
自由度非常高。
如果你有能力管理 PHP、Database、Server、Plugin 與整套 WordPress 生態，那麼它可以做到非常多事情。
而垂直型 SaaS 追求的則是另一件事情：
不要讓使用者需要自己管理整套技術架構。
9. 莫斯利為什麼不走「什麼都裝」的路線？
這其實和莫斯利自己的經驗有很大的關係。
莫斯利不是先開發一套軟體，再去想老師需要什麼。
而是自己經營線上課程很多年。
從課程製作、影音、會員、課程權限，到學生實際使用的學習環境，這些事情莫斯利自己都長期使用過。
也正因為如此，莫斯利後來在重新設計系統時，反而沒有一直追求：
「再加一個功能。」
「再加一個功能。」
「再加一個功能。」
因為功能不是越多越好。
真正重要的是：
老師到底需要哪些功能？
而且這些功能之間，應該怎麼組合。
所以現在的架構比較接近模組化：
Course Core
負責課程。
Lesson Core
負責課程單元與內容。
MemberCourse Core
負責會員與課程授權。
License Core
負責系統授權。
Quiz Core
負責測驗。
而 Quiz Core 又可以獨立存在。
如果老師根本不需要 Quiz，就不一定要使用。
這種設計背後的想法很簡單：
不是把所有功能塞進系統，而是讓真正需要的功能各自負責自己的事情。
10. 真正需要比較的，是誰負責未來？
當你選擇一套線上教學平台時，很多人會花很多時間比較：
哪一套功能比較多？
哪一套價格比較便宜？
哪一套畫面比較漂亮？
哪一套有更多 Plugin？
這些當然都可以比較。
但是還有一個問題，可能更值得問：
五年後出問題的時候，誰負責？
如果今天選擇 WordPress＋LMS＋Plugin 的架構，那麼你買到的不只是網站。
你其實也選擇了一套技術生態。
未來就必須面對：
WordPress 更新。
PHP 更新。
Plugin 更新。
LMS 更新。
Add-on 更新。
Theme 更新。
第三方服務更新。
這並不是缺點。
這就是這種架構本來的特性。
而如果選擇 SaaS，則是把這一部分的技術維護交給 SaaS 平台。
相對的，你的自由度也會受到平台架構限制。
所以最後真正需要比較的，其實不是：
「哪一套功能比較多？」
而是：
「你想經營的是線上課程，還是你願不願意同時經營一個技術系統？」
11. 結語｜真正要比較的，不只是功能
線上教學平台的選擇，從來不只是：
「哪一套功能最多？」
因為功能越多，並不代表系統越簡單。
WordPress＋LMS＋Plugin 的方式，可以非常強大，也可以做到非常多事情。
它最大的優勢就是自由度。
但自由度的另一面，就是：
你必須承擔更多的系統管理與技術複雜度。
相反地，垂直型 SaaS 不追求什麼都做。
它更重視的是：
把一個特定領域真正需要的核心功能做好，並且把底層的技術維護集中處理。
這兩種方式沒有絕對的對錯。
如果你本身就是技術團隊，懂 PHP、Server、Database、Plugin、生態系與系統維護，那麼 WordPress 的高度自由可能正是你需要的。
但如果你真正想做的是：
經營自己的線上課程。
那麼也許還有一個問題值得想一想：
五年後的自己，還願不願意管理今天選下來的這整套系統？
因為線上教學事業真正要經營的，應該是：
課程、學生、內容、品牌與自己的事業。
而不是花大量時間研究：
為什麼昨天更新了一個 Plugin，今天學生就不能上課了。 😆
