优化 WordPress 时学到的主要经验教训（为了客户成功）

你最后一次有云九时刻是什么时候？

顺利通过学校.. 或者你的女朋友/男朋友接受了你的提议？

两周前我有一个云九时刻！ 我在 WordCamp Mumbai 2017 上发表演讲——印度最大的 WordCamp。

这个话题很贴近我的心，也是我每天都在处理的事情——为客户成功优化 WordPress 的经验教训。

这是关于我在处理大型 WordPress 数据库时遇到的问题以及我如何解决它们。

是什么鼓励我在孟买 WordCamp 演讲？

开发 WordPress 插件是一次很棒的学习体验。 你可以扩展一个极好的框架，专注于编写解决客户问题的代码，并与优秀的团队成员一起工作。

在 StoreApps，开发人员不仅编写代码，还支持客户。 解决客户的疑问给了我一些最大的教训。

所以这就是我的日常，而且非常令人兴奋。

但是你知道什么对我来说更令人兴奋吗？ 使用大型数据库并解决复杂的数据库问题！

我们的插件被超过 35000 名用户使用。 我已经看到了与大型 WooCommerce 商店和流行的 WordPress 网站合作的许多挑战。

值得庆幸的是，我能够解决这些挑战并学到了很多东西。

但是等等，就像我一样，会有数百名其他开发人员在使用 WordPress 和 WooCommerce 时面临类似的问题。

所以我决定与其他人分享我的课程。

还有什么比在印度最大的 WordCamp 演讲机会更好的平台！

让我彻夜难眠的三个问题（有解决方案和从中吸取的教训）

最后，这是我正在谈论的三个问题。 因此，让我们一个一个地开始。

将页面加载时间从 3 分钟减少到毫秒……

问题

我遇到了智能优惠券插件的情况，其中在商店的关键页面（即购物车、结帐和我的帐户页面）上显示优惠券的简单功能使结帐过程停滞不前。

Smart Coupons是一个插件，用于为 WooCommerce 商店批量创建和处理优惠券和礼券。

解决方案

现在，使用 WP Query 会导致多个 JOIN ，因为要显示特定用户的可用优惠券需要评估多个元条件。

因此，我没有使用理想的数据库查询方式，即 WP Query，而是编写了自定义 SQL 查询。

此外，在自定义查询中，我所做的是：

• 我没有在单个 MySQL 查询中检查所有元条件，而是简单地评估了第一个元条件
• 之后，我将逗号分隔的 post_ids（优惠券 ID）列表存储在选项表中
• 然后，我通过评估每个其他元条件来简单地映射减少相同的 post_id 集

我一直这样做，直到我得到一组需要为特定用户显示的最终 post_id。

增强解决方案

这确实解决了页面加载问题。 但是，按照我们朋友的建议，为了在毫秒内加载页面，我不得不重新定义问题。

而不是显示用户有资格获得的所有优惠券，
我对在购物车和结帐页面上向用户显示的优惠券数量设置了限制。

超时错误如何成为我们插件最畅销的功能？

问题

为了处理非常庞大的数据库更新，我编写了自定义查询，因为使用核心 WordPress 功能可能会成为巨大的开销。

示例：如果一个人必须将他/她商店中所有产品的价格降低 40%，那么他们只需选择“价格”、“降低 40%”并点击更新按钮。 使用我们的插件 Smart Manager 可以轻松实现这一点，该插件旨在使您的 WooCommerce 商店的批量更新更容易。

但是，每当有人尝试一次更新 1k 个产品或整个商店时，批量更新过程就会开始停滞并给出超时错误。

最初我开始考虑优化查询，但这并没有帮助。

我的情况类似于武城的参赛者。 不管我怎么努力，我总是掉进水里。

解决方案

据说有时您必须摆脱问题并鸟瞰问题才能找到确切的原因。

我做了同样的事情并发现实际问题是
不是在查询级别，而是在请求级别。

因此，我所做的不是单个请求进行所有更新，而是将相同的请求分解为多个连续的 AJAX 调用，进行小批量更新，从而完全消除了超时错误。

增强解决方案

现在，这种将单个请求分解为多个较小的 AJAX 请求的方法不仅解决了超时错误，而且改进了批量更新的 UX 。

现在，商店经理正在了解更新的进度，这只会增加他们对产品的信心。

此外，同样的方法使 Smart Manager 能够处理任何形状和大小的 WooCommerce 商店的批量更新，并使 Smart Manager 成为 StoreApps 最畅销的插件之一。

共享主机环境如何迫使我们重写插件？

问题

对于任何报告插件来说，不仅准确而且快速地报告统计数据非常重要。 现在，获取报告统计数据需要多个查询，涉及加入 2 个主要 WordPress 表，即帖子和 postmeta。

正如上面已经看到的， JOIN 非常昂贵。

在 Smart Reporter（我们的 WooCommerce 报告解决方案）中，我们在单个页面视图中显示了 20 个不同的报告统计信息，并且在页面加载时也是如此。

解决方案

因此，我采用了与大多数报告解决方案相同的方法，即创建汇总表，即平面结构自定义表。

该表将包含插件所需的所有数据的摘要，从而消除连接的使用并缩短页面加载时间。

此外，为了更新这些汇总表，我们使用了 WordPress 操作和过滤器。

课程总结

• 尽可能遵循最佳实践
• 循环中没有查询
• 避免大型复杂连接
• 在 MySQL 级别做的比在 PHP 级别做的更多
• 深入代码
• 摘要/自定义/临时表
• 注意用户体验——响应能力、通知……
• 你在解决正确的问题吗？

你的选择是什么？

我相信您已经处理了一些巨大的问题并找到了解决方案。 在下面的评论部分让我们知道。 这对读者来说真的很有价值。