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 之上，这是一个完全基于面向对象编程原则的 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 支持

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 函数