重写WordPress SQLite数据库集成插件正在测试

SQLite数据库被很多人说速度快，目前WordPress的贡献者们正在取得一些进展，在核心中正式支持SQLite数据库，这个项目将使不太复杂的网站（小型到中型网站和博客）受益，这些网站不一定需要WordPress的标准MySQL数据库。

在最近的更新中，Yoast赞助的核心贡献者Ari Stathopoulos说，在Automattic赞助的核心贡献者Adam Zielinski的帮助下，SQLite数据库集成功能插件已被重写，成为一个更适合未来的实现。

Stathopoulos说：”代码已经完全重写，使用SQL Lexer，现在很稳定，能够正确处理所有的WordPress查询。SQL Lexer是PHPMyAdmin/SQL-Parser项目的一部分（根据GPL 2.0许可），它被改编为WordPress，有效地实现了MySQL到SQLite的翻译引擎。这提供了更好的安全性，以及兼容性”。

Stathopoulos说，下一步是在WordPress核心中实现这些变化，”而不是使用一个插件，因为以其目前的形式，它只能在已经有MySQL数据库的预先存在的网站上进行测试。”

“使用特色插件是一个很好的方法，可以让用户测试实施，并消除任何问题等，”他说。”然而，从长远来看，把它作为一个插件使用是没有意义的。”

Stathopoulos创建了一个拉动请求草案和一个附带的Trac票据，建议将新的实现合并到核心部分。

虽然这项工作得到了社区和WordPress首席开发者Matt Mullenweg的积极反馈和支持，但这个功能插件只有30个活跃的安装，新的实现也很少得到测试。

包括核心提交人Aaron Jorbin和首席开发者Andrew Ozz在内的多个讨论参与者，对提案中要求将这些变化合并到核心部分作为下一步表示担忧。

Jorbin说：”由于一些原因，谈论合并到核心部分感觉非常不成熟。这个插件现在只有大约30个安装。我认为需要有更高的采用率，以了解近乎无限的插件将如何与WordPress的这种深层次的底层变化一起工作。”

Jorbin还提到了WordPress的哲学，即为那些不想对底层技术做决定，而只是想让事情顺利进行的终端用户构建东西。

“假设一个用户会理解不同的数据库引擎和潜在的权衡，对我来说感觉很勉强，” Jorbin说。”因此，任何实施都需要坚如磐石，并经过极其彻底的测试。”

Jorbin也呼应了其他贡献者在之前的对话中的担忧，关于SQLite的奇怪的充满宗教色彩的 “道德准则”。

Ozz建议这个插件可以作为一个mu-plugin或 “drop-in “加入到WordPress中，类似于缓存插件的实现方式，推倒了将其完全合并到核心中的僵化要求。

“这两种方法对用户来说也更好/更适合，因为它们可以由托管公司或用于WordPress安装的脚本来完成，”Ozz说。”还有一些其他的好处，如独立更新等”。

Stathopoulos回应了这些担忧，他说他认为合并到核心是一个长期的目标，尽管这个提议传达了更多的紧迫性，使讨论的参与者感到困惑。

“这是不成熟的，”Stathopoulos承认到，”然而，从大的方面来看，为未来做计划并做好准备并不为时过早。”

“现在可能为时过早，但两年后就不会了……问题是，除非我们现在就开始工作，否则将来就无法做到这一点。SQLite不是现在就能–或应该–在Core中发生的事情，甚至不是一年后的事情。这是一个长期的目标，应该如此对待。”

Stathopoulos同意，该插件需要更多的采用，以了解它如何与整个生态系统的插件一起工作。他还回应了关于用户不能完全理解他们在安装时选择的数据库引擎的影响的担忧。

Stathopoulos说：”我在Core PR中设置的概念验证UI就是这样–一个概念验证。触发讨论的东西，让我们找到解决方案。它可以是任何东西，甚至是安装场景（你想创建一个博客吗？一个小型的电子商务网站？一个大型新闻机构？下一个亚马逊？) 这是一个需要在讨论用户界面的时机成熟时进行的讨论，但现在还有点早，我认为我们还没有到那一步。”

Stathopoulos建议贡献者通过SQLite数据库集成插件或通过测试WordPress Core中的拉动请求草案，用他们通常使用的所有插件测试新的实现。