让 WordPress 正式支持 SQLite

WordPress 可以(并且正在)用于任何类型的网站,无论大小或复杂性如何。一些常见的用例包括:

  • 单页登陆站点
  • 简单的公司网站,只有几页。这些站点通常很少更新,并且本质上是具有管理方面的静态站点。
  • 简单的单用户博客
  • 复杂的新闻网站
  • 电子商务网站
  • 成熟的 CMS 解决方案

WordPress 成功的部分原因在于它是可扩展的、可挂钩的,并且可以使用和调整来完成网络上的几乎所有任务。

让 WordPress 正式支持 SQLite
让 WordPress 正式支持 SQLite

然而,无论 WP 的用例和受欢迎程度如何增加,WordPress 的一个方面从未改变:数据库。 WordPress 需要在站点上安装 MySQL/MariaDB。 MySQL 可以说只在某些情况下是最佳的:“中间层”范围的站点类型。

大型站点通常根据其特定需求实施自定义数据库堆栈,因此超出了本提案的范围。

在频谱的低端,有一些小而简单的网站。这些网站数量众多,包括所有博客、公司页面和没有数千名用户或数千篇文章的网站等。这些网站并不总是需要 MySQL/MariaDB 数据库的复杂性。对专用 MySQL 服务器的要求增加了它们的托管成本和安装的复杂性。在低端服务器上,它也会降低性能,因为同一个“盒子”需要同​​时满足 PHP 和 MySQL/MariaDB 服务器的需求。

理想的场景

理想情况下,WordPress 将允许我们在安装过程中选择数据库类型。 这可以使用安装指南或 wp-config.php 中的简单常量来完成。 为此,WordPress 需要有一个数据库抽象层。 这在 CMS 领域不是一个创新或激进的想法。 十多年来,Drupal 拥有可靠的数据库抽象层。 Laravel、Symfony 等也包括允许使用多种数据库类型的 ORM。

为 WordPress 构建数据库抽象层将是一项艰巨的任务——尽管在未来的某个时候,我们可能不得不承担这项任务,以确保项目的持续发展和长期存在。

中间地带

作为中间地带,我们可以为底层实现一个解决方案:中小型网站和博客。 这些站点不一定需要成熟的 MySQL 数据库。

SQLite 似乎是完美的选择:

  • 它是全球使用最广泛的数据库
  • 它是跨平台的,可以在任何设备上运行
  • 它默认包含在所有 PHP 安装中(除非明确禁用)
  • WordPress 的最低要求是一个简单的 PHP 服务器,而不需要单独的数据库服务器。
  • SQLite 支持可降低托管成本、降低能耗并降低低端服务器的性能成本。

在 WordPress 核心中实现 SQLite

目前,在 WordPress 中使用 SQLite 很简单; 有些实现已经存在并发展了 8 年多。 它们已经过全面测试并证明可以无缝工作。 这些实现是插入式 wp-content/db.php 文件,用户可以添加到他们的安装中; 它们并不难使用。

然而,大多数人并没有意识到它们。 他们不知道他们可以选择购买更便宜的主机 sans-mysql,然后使用 SQLite 数据库安装 WordPress。 他们也不应该知道它……毕竟,他们只想要一个简单的公司网站或博客。

WordPress 可以通过在 Core 中包含现有的 SQLite 实现之一来正式支持 SQLite。 我们需要确保它得到适当的测试和支持,此外,还需要提高认识并向用户公开选项。

为什么这应该在核心而不是插件中?

选择数据库类型是首次安装站点时应该发生的事情。 这不是事后应该做的事情,因为这需要将数据从一个数据库迁移到另一个数据库,这通常很复杂。

WordPress 在 Core 中包含 MySQL 实现,因此如果我们支持 SQLite,那么该实现应该与它并存。

如果他们希望这样做,数据迁移可以(并且应该)在一个插件中以促进现有站点的迁移,但是数据库引擎本身属于 Core。

这将确保实施得到适当的支持、适当的测试,并且 WordPress 将能够受益,如以下部分所述。

SQLite 的好处是什么?

在 WordPress 中正式支持 SQLite 可以带来很多好处。 一些值得注意的将包括:

  • 提高低端服务器和环境的性能。
  • 由于系统要求,我们无法访问的市场中 WordPress 的增长潜力。
  • 使用安装“场景”的托管市场增长潜力。
  • 降低能源消耗——提高 WordPress 项目的可持续性。
  • 进一步推进 WordPress 为所有人“实现出版民主化”的使命。
  • 更容易为 WordPress 做出贡献——下载文件并运行内置的 PHP 服务器,无需任何其他设置。
  • 更容易使用自动化测试套件。
  • 站点可以是“可移植的”和独立的。

下一步

接下来的步骤需要在本提案的评论部分进行讨论。如果在 WordPress Core 中实现 SQLite 达成共识,接下来的步骤大纲将如下所示:

  • 创建必要的 Trac 票证
  • 决定如何定义数据库类型。最简单的场景是 wp-config.php 中的 DATABASE_TYPE 常量,允许用户选择他们的新站点是使用 MySQL 还是 SQLite 数据库,但在以后的讨论中可能会出现其他解决方案。
  • 将 SQLite 实现移植到 WordPress Core,应用必要的更改,如编码标准、代码内文档、迁移测试等。
  • 使用 SQLite 测试 WordPress 核心功能。
  • 外展插件开发人员进行测试。

在 WCEU 2022 期间,以非官方身份在走廊里详细讨论了数据库抽象和使用 SQLite 的主题。这篇文章是这些对话的精华,旨在将讨论带到更广泛的社区以供认真考虑。

发表回复

您的电子邮箱地址不会被公开。