WPML 3.5 包含了对字符串翻译的一项重大更改。在发布后，我们了解到了一些在开发过程中未出现的情况。后续更新处理了所有问题并进一步提升了性能。
WPML 3.5 以来的修复
- 修复了 icl_strings 表中不存在 domain_name_context_md5 列时未捕获的异常
- 修复了过滤固定链接时出现的 Fatal error: Uncaught exception ‘InvalidArgumentException’ with message ‘Argument ID must be numeric and greater than 0
- 修复了升级期间出现的致命错误：WordPress database error: specified key was too long; max key length is 1000
- 修复了针对 PHP 5.2 的 Fatal error: Declaration of WPML_Post_Element::get_type() must be compatible with that of WPML_Translation_Element::get_type()
- 移除了前导反斜杠 \，以避免在 PHP 5.3 之前的版本中出现警告
速度提升
我们对存储字符串在哪些页面上出现的新表进行了一些调整。这些更改显著减小了表的大小，提升了性能，并降低了内存消耗。
- 将一个存在冗余的大表拆分为两个高效的小表
- 优化了表索引
- 通过使用修改页面选择的参数白名单，限制了使用 URL 参数的站点可能出现的表增长
结果
我们在版本更新期间对我们自己站点的性能进行了一些测量。您可以看到负载是如何下降，然后上升（当表索引未优化时），现在又回落并低于原始水平的。
所有这些图表中的绝对数值意义不大，因为它们是在一周中的不同日子测量的。在周五，我们的流量远低于周一。要了解这些变化，请查看各部分之间的比例。您可以看到，最初 icl_strings 的访问时间与获取文章的时间大致相同（这并不是件好事）。现在，WPML 的所有数据库访问平均只占文章查询的 1/3。这非常重要，因为 WPML 需要加载大量字符串，而 WordPress 只需要加载几篇文章。
下次采用更好的流程
由于包含了针对 WordPress 4.6 的更改，我们不得不在能够运行完整的性能测量之前发布此更新。未来，我们将确保将性能提升与 WordPress 兼容性分离开来。一旦 WordPress 的新版本达到“候选发布版本”，我们将发布一个仅包含兼容性更改的次要版本。我们将保留时间来运行更长期的性能更改，这些更改与错误修复和兼容性更新无关，并且只有在我们对结果非常满意后才会发布。
WPML 的下一个版本将继续关注稳定性和性能。现在 99% 运行 WPML 的站点都在平稳运行，但有少数站点使用了 Web 服务器、PHP 或数据库的“独特”配置。我们将在即将发布的次要版本中解决这些问题。我们还包含了一些额外的性能优化，这将使管理后台和前端都变得更加精简。
有反馈意见？
如果您有任何问题、想法和建议，请添加您的评论。我们非常乐意收到您的反馈，并会尽最大努力满足您的需求。
