WordPress 和十月 CMS 之間的詳細比較

三個月前，WordPress 終於發布了由 React 驅動的 Gutenberg 來為其默認內容編輯體驗提供支持，這引發了許多對這一變化不滿意的人尋找替代方案。 有些人決定分叉並發布古騰堡之前的 WordPress，然而，對我來說這沒有多大意義，因為它仍然背負著 15 年的技術債務。 如果我要找到 WordPress 的替代品，我會盡量避免被困在過去，並致力於通過一些建立在現代基礎上的成熟平台進行乾淨利落的切割。

本文在廣泛的技術和非技術主題上將 WordPress 與可以說相似但更現代的 10 月 CMS 進行了比較。 本文的目的不是說服人們堅持使用 WordPress 或切換到 10 月 CMS，而只是展示在結束遷移到不同平台之前必須考慮哪些方面。 在做出明智的決定之前，也可以（並且應該）與其他平台進行相同的比較。

為什麼選擇十月 CMS

我在 10 月 CMS 獲獎時發現了它，之後我進入了研究模式，並花了很多時間從用戶和開發人員的角度深入研究這個 CMS。 隨著我對這個 CMS 的了解，我有信心可以對它的功能進行客觀的評估，這與 WordPress 相比。 我選擇這個 CMS 是為了與 Grav、Statamic、ButterCMS、Joomla、Drupal、Jekyll、Hugo 等替代選項進行比較，原因如下：

• 我知道這個 CMS 是如何工作的（不像 Grav）；
• 它是免費和開源的（與 Statamic 和 ButterCMS 不同）；
• 五年後，它是“相對”新的（與 Joomla 和 Drupal 不同）；
• 它是一個動態（非靜態）內容生成器，基於 PHP（與 Jekyll 和 Hugo 不同）。
  

我相信十月 CMS 是一個很好的候選者，因為它基於 Laravel，這是一個用於構建現代應用程序的框架。 經過七年的存在，它得到了開發人員的積極認可（其龐大的社區和生態系統證明了這一點），並與 WordPress 中的編碼形成鮮明對比，即 WordPress 主要是過程編程，而 Laravel 絕對是面向對象的編程。

兩者有什麼區別？

下面我將比較不同類別的 WordPress 和 10 月 CMS，並強調我認為它們的優點和不太好的地方。 但是，我不會選擇獲勝者，因為這不是本文的目標，而且無論如何，沒有“最好”甚至“更好”的 CMS：每個 CMS 都有自己的優勢和劣勢，這將使它成為或多或少適用於每個任務、項目、公司、團隊和其他任何事物。 此外，一個項目可能會受益於使用多個 CMS，例如使用一些 CMS 來管理和提供數據，並使用另一個 CMS 來呈現視圖。 決定數十種 CMS 中哪一種最適合您自己的需求完全取決於您。

此外，這篇文章永遠無法得出明確的結論，因為它只涉及所有可能性的一個子集。 例如，我們還可以找到在線比較，例如“WordPress vs Drupal vs Joomla”、“WordPress vs Static Site Generators”，甚至“WordPress vs Medium”。 因為這些文章都沒有看到全貌，所以這些比較都不能是決定性的，也不應該被這樣對待。

讓我們從比較開始。

理念與目標群體

WordPress 為近三分之一的網站提供支持並非巧合。 自成立以來，它一直努力做到對用戶非常友好，並成功地做到了這一點，消除了技術和非技術用戶以及來自不同背景的人的摩擦——無論他們的教育和經濟水平如何。 WordPress 的創始人 Matt Mullenweg 表示，WordPress 在當前時代“出版民主化”的座右銘意味著以下內容：

“所有背景、興趣和能力的人都應該能夠訪問自由語音軟件，使他們能夠在開放的網絡上表達自己並擁有自己的內容。”

WordPress 對每個人都很容易使用，它的包容性在開發方面也得到了證明：找到沒有編程背景的人（如營銷人員、設計師、博主、銷售人員和其他人）修補他們的 WordPress 安裝、設計他們自己的主題並成功推出了自己的網站。 WordPress 以用戶為中心，用戶的需求勝過開發人員的需求。 在 WordPress 中，用戶是國王（或王后）。

相比之下，October CMS 更面向開發人員，正如其第一個版本所明確建立的那樣：

“October 提出了一個大膽但顯而易見的假設：客戶不建立網站，開發人員做。 客戶的角色是管理網站並傳達他們的業務需求。 Web 開發人員和行業本身都圍繞著調解這些因素。”

用其創始人的話來說，CMS 的使命是“證明製作網站不是火箭科學”。 基於 Laravel，October CMS 可以聲稱擁有可重用、模塊化代碼的堅實基礎，這些代碼可以生成架構合理的應用程序，可長期維護，完全可定制，無需 hack——這種類型吸引了認真的程序員。 十月 CMS 也可以提供出色的用戶體驗，但是，它並不像 WordPress 提供的那樣簡單或無摩擦。 用戶可能需要先了解如何使用某些功能，然後才能使用它。 例如，從某個插件嵌入表單對如何執行有很長的解釋，這比 WordPress 中的幾個表單插件提供的不言而喻的拖放功能更加繁瑣。

安裝

WordPress 以其 5 分鐘的安裝而聞名，儘管許多人指出（考慮到所有必須安裝的插件）典型的安裝需要 15 分鐘或更長時間。 此外，WordPress 還提供了多站點功能，它允許我們在一次安裝下創建多個虛擬站點的網絡。 此功能使代理機構可以輕鬆管理多個客戶的站點 - 以及其他用戶案例。

安裝October CMS 也很流暢：Wizard 安裝本身甚至不到五分鐘，如果通過Console 安裝的話，速度會更快。 您可以通過簡單地導航到目標目錄然後執行curl -s https://octobercms.com/api/installer | php來完成後者。 curl -s https://octobercms.com/api/installer | php （之後我們需要輸入數據庫配置，否則它的行為就像一個平面文件 CMS）。 安裝完成後，我們將擁有一個功能齊全的網站，但仍然很空曠（如果您添加安裝和配置所需插件所需的時間，您預計至少需要 15 分鐘）。

安全

由於不斷發現大量漏洞，WordPress 被指責為不安全。 這會迫使用戶將 CMS 軟件和所有已安裝的插件始終保持最新狀態，以避免安全漏洞。 主要問題之一是 WordPress 對 PHP 開發社區不再支持的舊版本 PHP 的支持（WordPress 當前支持 PHP 5.2.4，而最新的完全支持的 PHP 版本是 5.6）。 不過，這個問題應該會在 2019 年 4 月解決，屆時 WordPress 將正式開始支持 PHP 5.6 及更高版本。

否則，WordPress 不一定是因為它本身不安全，而是因為它的高人氣，這使它成為黑客的首要目標。 然而，這是雙向的：WordPress 無處不在意味著其安全團隊必須真正認真對待他們的工作，不斷尋找漏洞並儘快修復它們，否則多達三分之一的網絡處於危險之中。 賭注太高了。

另一方面，October CMS 並沒有不安全的名聲。 但是，由於與 WordPress 的數百萬相比，大約有 27,000 個使用 10 月的實時站點，因此我們不能以相同的條件來判斷這兩個站點。 儘管如此，October CMS 背後的團隊確實非常重視安全性，正如嚮導安裝提示輸入 CMS 後端 URL 所證明的那樣，默認設置為/backend但可以更改為其他任何內容，以使黑客更難瞄準該站點. 相反，將 WordPress 的登錄和後端 URL 從/wp-login.php和/wp-admin分別更改為其他內容必須通過插件完成。 此外，October CMS 可以作為平面文件 CMS（即沒有數據庫），避免 SQL 注入等數據庫相關漏洞。

技術棧

WordPress 和 October CMS 都在傳統的 LAMP 堆棧上運行：Linux、Apache、MySQL 和 PHP。 （然而，只有 PHP 是固定的：我們也可以使用 Windows、Nginx、MariaDB 和其他。）October CMS 也可以作為平面文件 CMS，這意味著它可以在沒有數據庫的情況下運行，但代價是放棄許多功能（例如博客文章和用戶）唯一得到保證的功能是頁面，它被認為是創建和發佈內容的基本單元，並作為核心功能提供。

關於語言堆棧，使用 WordPress 和 October CMS 構建的網站基於 HTML、CSS 和 JavaScript（請注意，PHP 用於生成 HTML）。 October CMS 還可以輕鬆使用 LESS 和 SASS 文件。

編程範式

WordPress 遵循函數式編程範式，基於通過調用沒有應用程序狀態的函數來計算計算。 儘管 WordPress 開發人員不需要堅持函數式編程（例如，為他們的主題和插件編寫代碼），但 WordPress 核心代碼繼承了 15 年來保持向後兼容性的這一範例，這一直是 WordPress 成功的支柱之一但這會帶來意想不到的後果，即積累技術債務。

另一方面，October CMS 遵循命令式編程範式，基於通過操作對象的狀態來計算計算。 October CMS 位於 Laravel 之上，Laravel 是一個完全基於面向對象編程原則的 Web 框架，它支持基於模型-視圖-控制器等概念的模塊化應用程序的生產，以將用戶界面與應用程序數據分離，依賴注入到配置類依賴關係和接口隔離原則來定義框架提供的核心服務等。

掛鉤/事件

WordPress中的編程可以被描述為HDD，它代表“Hook-Driven Development”。 鉤子是一種允許更改默認行為或值並允許其他代碼執行相關功能的機制。 鉤子是通過允許執行額外功能的“動作”和允許修改值的“過濾器”觸發的。

鉤子在 WordPress 代碼庫中廣泛存在，是我最喜歡在 WordPress 中編碼的概念之一。 它們允許插件以乾淨的方式與其他插件（或與核心或主題）交互，為面向方面的編程提供一些基本支持。

好消息是 Laravel（以及隨之而來的 10 月 CMS）也支持鉤子的概念，稱為“事件”。 事件提供了一個簡單的觀察者實現，使代碼能夠訂閱和偵聽應用程序中發生的事件並根據需要做出反應。 事件可以將復雜的功能拆分為組件，這些組件可以獨立安裝，也可以相互協作，從而能夠創建模塊化應用程序。

對 JavaScript 庫的依賴

最新版本的 WordPress 採用了基於 React 的 Gutenberg 來實現其默認的內容創建體驗。 因此，WordPress 開發現在基本上依賴於 JavaScript（主要通過 React），儘管也可以使用其他框架或庫（如基於 Marionette 的 Elementor Blocks for Gutenberg 所證明的）。 此外，WordPress 仍然依賴於 Backbone.js（用於媒體管理器）和 jQuery（遺留代碼），但是，隨著 Gutenberg 被整合為新規範，我們可以預期對這些庫的依賴將會消失。

October CMS 依賴於 jQuery，它使用它來實現其可選的 AJAX 框架以從服務器加載數據，而無需刷新瀏覽器頁面。

頁面、主題和插件

WordPress 和 October CMS 都將頁面視為創建和發佈內容的基本單元（在 WordPress 中，除了帖子之外），支持通過主題更改站點的外觀和感覺，並允許通過插件安裝和擴展站點的功能. 儘管兩個 CMS 中的概念相同，但在實現方面存在一些差異，從而產生了一些不同的行為。

在 WordPress 中，頁面被定義為內容並存儲在數據庫中。 因此，頁面內容只能通過 CMS 創建（例如在儀表板區域中），並且從一個主題切換到另一個主題不會使現有頁面變得不可用。 這產生了整體無摩擦的體驗。

另一方面，在十月 CMS 中，頁面是存儲在主題目錄下的靜態文件。 從這個架構決策的積極方面來看，頁面內容可以從外部應用程序創建，例如 Sublime 或 Visual Studio Code 等文本編輯器。 不利的一面是，當從一個主題切換到另一個主題時，需要手動重新創建或複制當前頁面到新主題的頁面，否則它們會消失。

值得注意的是，October CMS 解決了通過頁面的路由問題，因此頁面不僅用作內容容器，還用作功能容器。 例如，博客插件依賴於在所選 URL 下顯示博客文章列表的頁面，在另一個所選 URL 下顯示單個博客文章的頁面，等等。 如果這些頁面中的任何一個消失，插件的相關功能將變得不可用，並且該 URL 將產生 404。因此，10 月的 CMS 主題和插件沒有徹底解耦，必須小心切換主題。

核心與插件功能

WordPress 嘗試提供通過插件增強的最小核心功能。 WordPress 依靠“ ⁸⁰ ⁄ ₂₀規則”來決定是否在其核心體驗中包含某些功能。 如果它使 80% 的用戶受益，則它屬於插件領域。 向站點添加插件時，如果安裝了太多插件，它們可能會導致膨脹。 插件也可能無法很好地相互配合，或者執行類似的代碼或加載類似的資產，從而導致性能欠佳。 因此，雖然啟動 WordPress 網站相對容易，但更大的挑戰是它的一般維護以及在添加新功能時能夠保持最佳和高性能狀態。

同樣，October CMS 也嘗試提供最小的核心功能，但在類固醇上：唯一保證的功能是頁面的創建和發布，對於其他一切，我們需要安裝一個或另一個插件，這表示為：

“你需要的一切，沒有你不需要的東西。”

目標很明確：大多數簡單的站點僅由頁面組成，可能沒有博客文章、用戶或登錄區域。 那麼，為什麼應用程序要在不需要這些資源時為它們加載資源呢？ 因此，博客、用戶管理、翻譯和其他一些功能通過插件目錄發布。

October CMS 的核心還包括某些功能（即使它們並不總是需要）可以顯著增強應用程序。 例如，它提供開箱即用的支持，將媒體文件上傳到 Amazon S3 並通過 Rackspace CDN 訪問它們。 它還包括一個媒體管理器，主要通過插件使用，例如將圖像添加到博客文章中。 （頁面也可以使用媒體管理器來嵌入媒體文件，但是，CMS 還附帶了一個資產部分來上傳這些看起來更合適的媒體文件。）

我相信 10 月份的固執己見可以完美地使我們能夠生成盡可能精簡的應用程序——主要涉及簡單的站點。 但是，它也可能適得其反並鼓勵膨脹，因為需要和不需要的界限是任意的，並且很難由 CMS 預先設定。 在考慮“用戶”的概念時可以理解這個困難：在 WordPress 中，網站用戶和網站管理員屬於同一個用戶實體（通過角色和權限，我們可以使用戶成為管理員）。 在October CMS中，這兩個是分開實現的，核心是網站管理員可以登錄後台修改設置，通過插件實現網站用戶。 這兩種類型的用戶有不同的登錄過程和不同的數據庫表來存儲他們的數據，因此可以說違反了 DRY（不要重複自己）原則。

這個問題不僅與實體的行為有關，而且與它必須包含的數據字段有關。 例如，是否應該預定義網站用戶數據字段？ 是否需要電話字段？ 考慮到 Instagram 最近才變得有點酷，那麼 Instagram URL 字段呢？ 但是，在構建專業網站時，我們不應該使用 LinkedIn URL 字段嗎？ 這些決定顯然取決於應用程序，不能由 CMS 或插件決定。

十月 CMS 插件 User 實現了用戶，但沒有任何用戶字段，在插件 User Plus 之上添加了幾個任意用戶字段，這可能還不夠，所以插件 User Plus+ 還添加了其他用戶字段。 我們何時、何地以及如何停止這個過程？

另一個問題是當沒有空間向實體添加新功能時，這會導致創建另一個極其相似的實體，以支持那些所需的功能。 例如，October CMS 附帶頁面，並允許通過插件創建“靜態頁面”。 它們的本質是一樣的：頁面和靜態頁面都保存為靜態文件。 它們之間的唯一區別（據我所知）是靜態頁面是使用可視化編輯器而不是 HTML 編輯器進行編輯的，並且可以添加到菜單中。 在我看來，只有結構上的差異，例如將一個實體保存為靜態文件而另一個實體存儲在數據庫中，才能證明為頁面創建第二個實體是合理的（有一個拉取請求來執行此操作），但為了簡單功能，就像目前的情況一樣，它構成了開發膨脹。

總而言之，一個執行良好的 10 月 CMS 應用程序可以非常精簡和高效（例如，在不需要時刪除數據庫），但相反，它也可能變得不必要地臃腫，迫使開發人員為類似的實體實現多個解決方案，這可以使用起來非常混亂（“我應該使用頁面還是靜態頁面？”）。 因為 WordPress 和 October CMS 都沒有找到消除臃腫的完美解決方案，所以我們必須小心設計任何一種應用程序架構，以避免在路上遇到麻煩。

內容創作

Gutenberg 對 WordPress 做出了兩個重要貢獻：它使用組件作為構建站點的單元（與 HTML 的編碼 blob 相比具有幾個優點），並且它引入了一個稱為“塊”的實體，一旦 Gutenberg 階段 2 完成（大概在2019），將提供一種將內容整合到網站中的統一方式，從而實現更簡單的用戶體驗，而不是通過短代碼、TinyMCE 按鈕、菜單、小部件等添加內容的更混亂的過程。

因為 Gutenberg 塊可以生成和保存靜態 HTML 作為博客文章的一部分，所以安裝許多 Gutenberg 塊並不一定會在用戶端轉化為網站膨脹，但可以限制在管理員端。 因此，古騰堡可以說是一種以模塊化方式製作網站的好方法，具有簡單而強大的用戶體驗來創建內容。 可能最大的缺點是學習 React 的要求（不可避免，但不容易），其學習曲線相當陡峭。

如果 React 組件是在 WordPress 中創建內容的基本單元，那麼十月 CMS 的前提是了解良好的舊 HTML 足以構建站點。 實際上，在創建頁面時，我們只是簡單地呈現了一個 HTML（標記）編輯器：

如果頁面完全是靜態 HTML，那麼就不需要 CMS。 相反，October CMS 頁面是使用 Twig 模板編寫的，這些模板被編譯為經過優化的 PHP 代碼。 他們可以選擇一個佈局來包含頁面的腳手架（即重複元素，例如頁眉、頁腳等），可以實現佔位符，這些佔位符在佈局上定義以允許頁面自定義內容，並且可以包括部分，它們是可重用的代碼塊。 此外，頁面可以包含內容塊，它們可以是文本、HTML 或 Markdown 文件，可以自行編輯，並且可以附加組件，這些組件是通過插件實現的功能。 最後，當 HTML 不夠用時，我們需要生成動態代碼，我們可以添加 PHP 函數。

編輯器是關於 HTML 的。 沒有用於以視覺方式添加內容的 TinyMCE textarea ——至少不是通過默認體驗（此功能屬於插件領域）。 因此，了解 HTML 可以被認為是使用十月 CMS 的必要條件。 此外，用於創建內容的幾種不同輸入（頁面、佈局、佔位符、部分、內容塊、組件和 PHP 函數）可能非常有效，但是，它肯定不像通過 WordPress 的統一塊接口那麼簡單。 它甚至會變得更複雜，因為還可以添加其他元素（例如靜態頁面和菜單以及片段），其中一些（例如頁面和靜態頁面）似乎提供相同的功能，從而使決定何時添加變得混亂使用其中一種。

因此，我敢說，雖然幾乎任何人都可以從管理員方面使用 WordPress 網站，但 10 月 CMS 對開發人員更友好，而不是非技術用戶友好，所以程序員可能會覺得使用它很有趣，但某些其他的角色（營銷人員、銷售人員等）可能會覺得它不直觀。

媒體經理

WordPress 和十月 CMS 都附帶媒體管理器，可以輕鬆地將媒體文件添加到站點，支持通過拖放界面同時添加多個文件並在內容區域內顯示圖像。 它們的外觀和行為相似； 我發現的唯一顯著差異是 WordPress 的媒體管理器允許嵌入圖片庫，而十月的媒體管理器允許手動創建一個文件夾結構來放置上傳的文件。

然而，自從 Gutenberg 推出以來，WordPress 的媒體功能得到了極大的增強，與 TinyMCE textarea相比，它能夠在適當的位置嵌入視頻、圖片和照片庫（它只提供了一個不准確的外觀版本）在網站中），並解鎖強大但易於使用的功能，如本視頻所示。

國際化

WordPress 核心使用gettext來啟用主題和插件的翻譯。 從包含所有要翻譯的字符串的.pot文件開始，我們需要創建一個.po文件，其中包含它們到相應語言/區域的翻譯，然後將該文件編譯為適合快速翻譯提取的二進制.mo文件。 執行這些任務的工具包括 GlotPress（在線）和 Poedit（可下載的應用程序）。 方便的是，這種機制也適用於 Gutenberg 的客戶端本地化。

WordPress 目前沒有提供任何核心解決方案來翻譯內容，並且直到古騰堡的第 4 階段（目標是 2020 年+）才會這樣做。 在此之前，此功能由插件提供，這些插件提供不同的策略來存儲和管理翻譯的內容。 例如，雖然 Polylang 和 WPML 等插件將每個翻譯存儲在自定義數據庫表中自己的行中（這很乾淨，因為它不會將內容混合在一起，但速度較慢，因為在查詢時需要兩個表的額外INNER JOIN數據庫），插件 qTranslate X 將所有翻譯存儲在原始數據庫表的同一字段中（查詢數據更快，但如果禁用插件，混合在一起的內容可能會在網站上產生殘骸）。 因此，我們可以貨比三家並決定最適合我們需求的策略。

October CMS 不會通過其核心提供多語言功能，而是作為由 October CMS 團隊創建的插件，可確保完美地集成到系統中。 從功能的角度來看，這個插件實現了它所承諾的。 從開發的角度來看，這個插件的實際工作方式並不理想。 在 WordPress 中，頁面只是一個帖子類型為“page”的帖子，並且它們只有一個翻譯機制，但在 10 月 CMS 中，有實體“page”、“static page”和“blog post”，即使非常相似，它們的翻譯需要三種不同的實現！ 然後，來自“頁面”的內容可以包括消息代碼（例如，稱為nav.content 、 header.title等的代碼），每個消息代碼都包含其針對所有語言環境的翻譯，作為數據庫表rainlab_translate_messages中的序列化 JSON 對象。 來自“靜態頁面”的內容被創建到每個語言環境的新靜態文件中，但是，所有語言環境的所有翻譯 URL 都不是存儲在其相應的文件中，而是存儲在默認語言的文件中。 “博客文章”的內容以序列化 JSON 對象的形式存儲在數據庫表rainlab_translate_attributes中，每個區域設置一行，翻譯後的 URL 存儲在數據庫表rainlab_translate_indexes中，每個區域設置一行。 我不知道這種複雜性是由於插件的實現方式還是由於十月 CMS 的架構。 無論哪種情況，這都是開發方面不希望出現的另一個膨脹實例。

插件管理

WordPress 和 October CMS 都提供了一個複雜的插件管理器，它允許搜索插件、安裝新插件以及將當前安裝的插件更新到最新版本——所有這些都來自後端。

依賴管理

October CMS 使用 Composer 作為首選包管理器，使插件能夠在安裝時下載並安裝其依賴項，從而提供無痛體驗。

相反，WordPress 尚未正式採用 Composer（或任何 PHP 依賴項管理器），因為社區無法就 WordPress 是站點還是站點依賴項達成一致。 因此，如果他們的項目需要 Composer，開發人員必須自己添加它。 隨著切換到 Gutenberg，npm 已成為首選的 JavaScript 依賴項管理器，一個流行的開發人員工具包依賴於它，客戶端庫作為自主包穩定地發佈在 npm 註冊表中。

與數據庫的交互

WordPress 提供了檢索數據庫數據（例如get_posts ）並存儲它（例如wp_insert_post和wp_update_post ）的功能。 在檢索數據時，我們可以傳遞參數來過濾、限制和排序結果，以指示結果是必須作為類的實例還是作為屬性數組等傳遞。 當函數不能完全滿足我們的要求時（例如，當我們需要對自定義表進行INNER JOIN時），我們可以通過全局變量$wpdb直接查詢數據庫。 在創建具有自定義帖子類型的插件時，代碼很可能會執行自定義 SQL 查詢以檢索和/或將數據保存到自定義表中。 綜上所述，WordPress 嘗試在第一階段通過通用函數提供對數據庫的訪問，在第二階段通過對數據庫的低級訪問。

October CMS 採用了不同的方法：應用程序可以使用 Laravel 的 Eloquent ORM 通過稱為模型的類的實例來訪問和操作數據庫數據，而不是直接連接到數據庫，從而使與數據庫的交互也基於面向對象編程. 它是高級訪問； 只需遵循有關如何創建表和設置實體之間關係的規則，插件就可以檢索和/或保存數據，而無需編寫一行 SQL。 例如，下面的代碼通過模型Flight從數據庫中檢索一個對象，修改一個屬性，然後再次存儲它：

 $flight = Flight::find(1); $flight->name = 'Darwin to Adelaide'; $flight->save();

升級數據模型

WordPress 成功的另一個原因（除了不破壞向後兼容性）是其數據庫架構，該架構旨在使應用程序隨著時間的推移而增長。 這個目標是通過“元”屬性實現的，即可以在任何時候鬆散地添加到數據庫對象的屬性。 這些屬性不存儲在相應實體表（ wp_posts 、 wp_users 、 wp_comments或wp_terms ）的列中，而是作為相應“元”表（ wp_postmeta 、 wp_usermeta 、 wp_commentmeta或wp_termmeta ）中的一行並通過INNER JOIN檢索INNER JOIN 。 因此，即使檢索這些元值速度較慢，它們也提供了無限的靈活性，並且應用程序的數據模型很少需要從頭開始重新架構以實現一些新功能。

October CMS 不使用元屬性，而是可以將多個任意值存儲為序列化 JSON 對象，這些值不直接映射為數據庫表中的列。 Otherwise, when an object needs some new property, we need to add a new column on the corresponding table (which is the reason behind plugins User Plus and User Plus+, mentioned earlier on). To update the application's database schema, October CMS relies on Laravel's Migrations, which are sets of instructions to execute against the schema (such as add or drop a column, rename an index, etc) and which are executed when upgrading the software (eg when installing a plugin's new version).

Headless Capabilities

Both WordPress and October CMS can be used as headless, ie treating the CMS as a content management system that makes content accessible through APIs, which allows to render the website on the client-side and can power other applications (such as mobile apps). Indeed, WordPress is steadily heading towards headless, since the Gutenberg content editor itself treats WordPress as a headless CMS (and, as a consequence, Gutenberg can also work with any other CMS too, as Drupal Gutenberg demonstrates).

A headless system needs to implement some API to return the data, such as REST and GraphQL. WordPress supports REST through WP REST API (merged in core), exposing endpoints under some predefined route /wp-json/wp/v2/... ; October CMS supports REST through plugins RESTful and API Generator, which allow to create custom endpoints and, as a consequence, support versioning as part of the endpoint URL and can offer a better security against bots. Concerning GraphQL, WordPress supports it through WPGraphQL, while October CMS currently has no implementations for it.

Quite importantly, a headless system needs to offer powerful content management capabilities. As mentioned earlier on, WordPress has a very solid database architecture, offering a plethora of data entities (users, posts and custom posts, pages, categories, tags and custom taxonomies, comments) over which the application can be reasonably well modelled, meta properties to extend these data entities (enabling the application to upgrade its data model accordingly and without major changes), and with plugin Advanced Custom Fields filling the gap to construct relationships among the data entities. In addition, plugin VersionPress allows to version control the database content using Git. Hence, WordPress is undoubtedly a good fit for managing content, as demonstrated in several projects in the wild.

On its part, and as mentioned earlier on, October CMS can omit the database and behave as a flat-file system, or it can have a database and behave as a hybrid, storing the content from pages as static files and blog posts (and others) on the database. As a consequence, content is not centralized, and its management involves a different approach. For instance, while we can use Git to version control pages, there is no support to version control the database per se; the solution to this is to populate data into the database through Seeders which, being code, can be put under version control and executed upon deployment. In addition, October CMS doesn't offer a baked-in database model featuring predefined data entities that can support the needs of most applications. Hence, more likely than not the application will need custom development to implement its data model, which means more work, but also means that it can be more efficient (eg accessing a property from a column is faster than from a row in another table through an INNER JOIN , which is the case with WordPress' meta properties).

CLI Support

Both WordPress and October CMS can be interacted with from the console through a Command Line Interface (CLI): WordPress through WP-CLI and October CMS through Laravel's Artisan. In addition to Laravel's commands, October CMS implements several custom commands for updating the system, migrating the database, and others. These tools make it very convenient to access the site from outside a browser, for instance for testing purposes.

託管主機

It is not a problem finding a managed hosting provider for a WordPress site: given WordPress' market share, there are dozens (if not hundreds) of providers out there vying with each other for the business, constituting a very dynamic market. The only problem is finding the most suitable provider for our specific sites based on all of their offerings, which can vary based on price, quality, type (shared or dedicated services), bandwidth and storage size, customer support, location, frequency of renewal of equipment, and other variables which we can navigate mainly through reviews comparing them (such as this one, this one or this one).

Even though nothing near as many as WordPress, October CMS still enjoys the offering from several hosting providers, which allows for some consideration and selection. Many of them are listed as October Partners, and several others are found DuckDuckGoing, but since I haven't found any independent review of them or article comparing them, the task of finding out the most suitable one will take some effort.

Marketplace, Ecosystem And Cost

WordPress' commercial ecosystem is estimated to be USD $10 billion/year, evidencing how many people and companies have managed to make a living by offering WordPress products and services, such as the creation of sites, hosting, theme and plugin development, support, security, and others. Indeed, its size is so big it is even bloated, meaning that it is very common to find different plugins solving the same problem, plugins that underdeliver, underperform or have not been updated for years, and themes which seem to look-alike each other. However, when creating a new site, the size and variety of the ecosystem also means that we will most likely find at least one plugin implementing each of the required functionalities, enabling us to save money by not having to develop the functionality ourselves, and the availability of customizable themes enables to produce a reasonably distinctive-looking site with minimal effort. As a consequence, we can easily create and launch a WordPress site for less than USD $100, making WordPress a sensible option for projects of any budget.

Being relatively new (only five years so far), OctoberCMS certainly doesn't enjoy anything near WordPress' marketplace and ecosystem sizes, however, it has been growing steadily so its size is bound to become bigger. Currently, its marketplace boasts 600+ plugins, and only a handful of themes. Concerning plugins, the October CMS team is requesting the community to put their effort into the creation of original plugins, delivering functionality not yet provided by any other plugin.

Hence, even though 600+ plugins doesn't sound like much, at least these translate into 600+ different functionalities. This way, even though it is not possible to choose among several vendors, at least we can expect to have those basic website features (such as blogging, comments, forum, integration with social media, e-commerce, and others) to be covered. Also, since October's founders are personally reviewing all submitted plugins and judging them according to quality guidelines, we can expect these plugins to perform as expected. As another plus, October plugins can incorporate elements from Laravel packages (even though not all of them are compatible with October, at least not without some hacks). Concerning themes, the low number of offerings implies we will most likely need to develop our own theme by hiring a developer for the task. In fact, I dare say that the theme in October CMS will most likely be a custom development, since themes and plugins are not thoroughly decoupled (as explained earlier), with the consequence that a market for easily-swappable themes is more difficult to arise. (This is a temporary problem though: once this pull request is resolved, pages will be able to be stored in the database, and swapping themes should not disrupt functionality.)

In my opinion, because of the smaller offerings of themes and plugins, creating a simple site with OctoberCMS will be more expensive than creating a simple WordPress site. For complex sites, however, October's better architecture (Object-Oriented Programming and Model-View-Controller paradigms) makes the software more maintainable and, as a consequence, potentially cheaper.

社區

Being a part of and having access, WordPress' community represents one of the most compelling reasons for using WordPress. This is not simply as a matter of size (powering nearly one third of all websites in the world, there are so many stakeholders involved with WordPress, and its community is representatively big) but also as a matter of diversity. The WordPress community involves people from many different professions (developers, marketers, designers, bloggers, sales people, and so on), from all continents and countries, speaking countless languages, from different social, educational and economic backgrounds, with or without disabilities, from corporate, not-for-profit and governmental organizations, and others. Hence, it is quite likely that, for whatever problem we encounter, somebody will be able to help on any of the support forums. And contributing to WordPress is pretty straightforward too: The Make WordPress group congregates stakeholders interested in supporting different projects (accessibility, design, internationalization, and many others) and organizes how and how regularly they communicate — mostly through some dedicated channel on its Slack workspace.

Furthermore, the WordPress community is real and tangible: it doesn't exist just online, but it gathers offline in WordCamps and meetups all over the world; in 2018, there were a total of 145 WordCamps in 48 countries with over 45,000 tickets sold, and a total of 5,400 meetup events from 687 meetup groups. Hence, it is likely that there is a local chapter nearby which anyone can join to ask for help, learn how to use the platform, keep learning on a regular basis, and teach others as well. In this sense, WordPress is not just a CMS but, more importantly, it's also people, and considering to leave WordPress should never be done only on its technical merits but on the power of its community, too.

October CMS' community is nothing near in size or diversity as WordPress', even though it has been growing steadily following the increasing popularity of the software. October provides a support forum to ask for help, however, it is not very active. A Slack workspace exists which is pretty active and where, quite importantly, October's founders participate regularly, helping make sure that all enquiries are properly addressed. This channel is a great source for learning low-level tips and tricks about the software, however, it is geared towards developers mainly: There are no channels concerning accessibility, design, internationalization, and other topics as in the WordPress community, at least not yet. Currently, there are no conferences concerning October CMS, but there is Laracon, the conference for the Laravel community.

Maintainers And Governance

Can we trust that the software will be maintained in the long term, so that if we decide to start a project today, we will not need to migrate to some other platform down the road? How many people are taking care of developing the software? And who is deciding in what direction the software moves towards?

WordPress 為全球三分之一的網站提供支持，不乏為軟件做出貢獻的利益相關者。 因此，我們不必擔心軟件會衰落。 然而，WordPress 正在對其治理模式進行內部審議，許多社區成員表示，有關 WordPress 方向的決定是由運營 WordPress.com 的公司 Automattic 單方面做出的。 這種看法的中心階段是決定推出古騰堡，許多成員不同意，並且項目負責人在開發和發布期間缺乏適當的溝通。 因此，許多社區成員質疑“良性獨裁者”的角色，這是歷史上授予 WordPress 創始人兼 Automattic 首席執行官 Matt Mullenweg 的角色，並研究不同的治理模型以找到更適合 WordPress 未來的治理模型。 這個任務是否會產生任何結果，或者現狀是否會持續，還有待觀察。

關於十月 CMS 方向的決定主要由創始人 Alexey Bobkov 和 Samuel Georges 以及開發商和社區經理 Luke Towers 做出，他們使項目保持強勁發展。 十月 CMS 還沒有治理問題：它目前關注的是如何通過為核心軟件的維護者創造收入來使項目可持續發展。

文檔

WordPress 自己站點中的文檔不是非常全面，但它的工作做得相當好。 但是，當考慮所有來源的所有關於 WordPress 的文檔時，例如一般網站（Smashing Magazine、CSS 技巧等）、專業網站（WPShout、WPBeginner 等）、個人博客、在線課程、等等，幾乎沒有任何處理 WordPress 的方面尚未涵蓋。

十月 CMS 不像 WordPress 那樣喜歡許多第三方課程、教程或博客文章，但是，其網站上的文檔相當全面，當然足以開始編碼。 October 創始人還定期通過教程添加新文檔。 我個人喜歡的一個方面是將 Laravel 的文檔複製到 10 月份的所有相關文檔中，因此讀者不能自己填補空白，而不得不猜測 10 月份的領域和 Laravel 的領域。 然而，這並不是 100% 完美的。 October 的文檔使用了源自 Laravel 的術語，例如中間件、服務容器、外觀和合同，但沒有充分解釋這些是什麼。 然後，提前閱讀 Laravel 的文檔會很有幫助（幸運的是，Laravel 的文檔非常全面，Laravel 的截屏視頻 Laracasts 是另一個很好的學習資源，不僅涉及 Laravel，還涉及一般的 Web 開發）。

結論

我開始通過將 WordPress 與類似的 CMS 進行比較來發現哪些功能可能對尋找 WordPress 替代品的開發人員具有吸引力. 從滿足這些條件的 CMS 中，我選擇了 10 月份的 CMS 進行比較，因為我對它有所了解，而且我很欣賞 Laravel 提供的干淨和模塊化的編碼方法，它可以為建築工地提供全新的現代視角。

本文並不打算選擇獲勝者，而只是分析何時選擇一個或另一個 CMS 是有意義的，並強調它們的優缺點。 沒有“最佳”CMS：只有最適合特定情況的 CMS。 此外，任何想要在特定項目中使用 CMS 並與特定團隊並在一定預算下使用的人，都應該進行一些研究並比較所有產品，以找出最適合特定環境的產品。 重要的是不要像我在本文中所做的那樣僅限於幾個 CMS，而是為所有這些 CMS 提供機會。

就個人而言，作為一名開發人員，我在 10 月份的 CMS 中發現的東西真的很吸引我，主要是它能夠構建通過 Laravel 提供的模塊化應用程序。 我當然會考慮將此 CMS 用於新網站。 然而，在寫這篇文章的過程中，我也“重新發現”了 WordPress。 如此受歡迎，WordPress 受到的批評超過了它的公平份額，主要是關於它的​​舊代碼庫，以及最近引入的古騰堡； 但是，WordPress 也有一些很少被稱讚但也應該考慮的優秀特性（例如其超可擴展的數據庫模型）。 最重要的是，不應僅考慮 WordPress 的技術方面：特別是其社區和生態系統的規模使其比其替代品高出一兩個級別。 簡而言之，一些項目可能會從堅持使用 WordPress 中受益，而其他項目可能會更好地依賴 October CMS 或其他平台。

作為最後一點，我想指出，探索另一個 CMS 如何工作本身就是一項非常有益的活動，與是否使用該特定 CMS 的決定無關。 就我而言，我已經在 WordPress 上工作了多年，深入研究 10 月份的 CMS 非常令人耳目一新，因為它教會了我許多我沒有通過 WordPress 接觸過的東西（例如 PHP 標準建議的存在）。 我現在可能決定切換 CMS，或者堅持使用 WordPress，知道如何生成更好的代碼。

關於 SmashingMag 的進一步閱讀：

• 古騰堡時代的巧妙緩存
• 使用現代 PHP 改進 WordPress 代碼
• 開發 WordPress 插件時的經驗教訓
• 如何使用熱圖來跟踪 WordPress 網站上的點擊次數
• 注意：可能使您的網站不安全的 PHP 和 WordPress 函數