Products
GG网络技术分享 2025-03-18 16:07 2
插件作者在他们产品的主要功能上投入了大量的时间和精力，以至于他们让不太重要的东西被搁置一旁。
以激活和停用为例。 虽然激活钩子很普遍——许多插件需要添加一些选项，刷新重写规则，可能创建数据库表，或者在安装时检查版本差异——停用和卸载钩子远不常见。
重点在这里？ 许多插件作者不会花时间自己清理。 WordPress 安装真的需要你删除插件后创建的自定义表吗？ 为什么不在删除插件之前清除一些插件独有的选项？
在本文中，我将向您展示如何使用激活、停用和卸载挂钩来初始化您的插件，并在用户使用完您的产品后更轻松地进行清理。
注意：如果您打算浏览本文，我强烈建议您看一下最后的“附加安全性”部分，它通过一些有价值的安全检查来补充代码。 此外，如果您在 WordPress 插件挂钩方面需要帮助，这里是关于使用 WordPress 挂钩以及如何在 WordPress 中激活功能的快速复习。
虽然激活钩子很简单，但安装它有点特殊，所以我们需要注意事件的顺序。 在我们进入所有这些之前，这里有一个简单的例子：
这一切的关键是 register_activation_hook() 功能。 第一个参数是主插件文件的路径； 第二个参数定义要运行的函数。 在内部， register_activation_hook() 函数是“activate_[plugin_name]” 动作，但由于它更易于使用，因此在插件中看到钩子是不寻常的。
了解安装顺序很重要，因为它会阻止使用您可能习惯的方法。 register_activation_hook() 在用户单击激活链接并因此看到激活通知之间调用。 它在一个中间页面上运行，该页面在任何钩子有机会运行之前立即重定向。
让我们看一个例子，看看为什么这是一个巨大的无赖：
许多插件创建自定义帖子类型。 在激活时刷新重写规则以确保用户在访问来自新自定义帖子类型的帖子时不会收到 404 错误是明智之举。
下面的代码似乎合乎逻辑，但会失败。
它 似乎 完全没问题。 创建自定义帖子类型，并在激活时刷新重写规则。 问题是当我们刷新重写规则时还没有创建自定义帖子类型。
以下是流程的外观：
Stack Overflow 上发布的一个解决方案，得到了 WordPress Codex 的正式认可，解决了我们的小问题。 该解决方案涉及添加一个选项以指示该插件刚刚安装。
如果存在此选项，我们会执行激活操作，然后将其删除。
像这样的东西：
就个人而言，我不太喜欢这种解决方案。 问题是第八行的检查在每一个页面加载时都会运行。 这没什么好担心的，因为它不会给您的服务器带来很大的负载，也不会减慢您用户的网站速度。 这是一个非常快速的检查，对性能的影响可以忽略不计。 然而，在 99.9% 的情况下，它是不必要的。
在 Codex 的文档中提到了一个更好的解决方案 flush_rewrite_rules() 功能。 在这个解决方案中，我们使用函数的模块化分别在激活时注册自定义帖子类型：
我们不再依赖需要一直运行的检查，而是使用激活函数来注册我们的帖子类型。 请注意，一旦我们的插件被激活，帖子类型将始终从 init 钩。
这是法典无处不在的一个可悲的例子。 一般来说，WordPress 确实有很好的文档，但如果有些东西看起来很浪费或不合逻辑，不要害怕自己做一些研究。
一些插件执行的另一项任务是创建数据库表。 通常，这是不必要的，但有一些合法的用例。
Codex 关于创建表的文章中的这个示例显示了如何使用多个激活调用：
第一个功能， jal_install() 创建一个新的数据库表。 第二个功能， jal_install_data 将初始数据添加到表中。 而不是使用 register_activation_hook() 要添加一个包含所有这些代码的函数，我们可以使用 register_activation_hook 多次。
这是模块化的一个很好的实践。 一方面，你不 有 添加初始测试数据——就像移除激活钩子一样简单——这样你就可以保持函数的完整性。 另一方面，您可以在任何地方自由地重用这些功能，因为它们是分开的。
激活函数的另一个常见任务是检查依赖关系。 您的插件可能依赖于特定版本的 WordPress、另一个插件，甚至是特定版本的 PHP。
下面的代码检查最低 WP 和 PHP 版本，并在必要时重定向用户（不激活插件）：
停用挂钩在用户停用插件但在卸载（删除）之前运行。 停用钩子的使用方式与激活钩子相同：
停用意味着用户仅停用了您的插件，因此您不会像卸载期间那样做太多事情。 您可能想要刷新重写规则，但在这个阶段，您不会想要摆脱所有选项和数据库表（如果有的话）。
这相当简单，但我会特别注意刷新重写规则，因为这些又是有问题的。
法典建议按照如下所示进行操作，但这 不工作：
这不起作用的原因与以前相同。 运行停用会执行 init 钩子，这意味着当我们停用我们的插件时，我们也在注册我们的自定义帖子类型。 重写规则已刷新，但它们考虑了自定义帖子类型。
有一张 Trac 票可以解决这个问题，但在那之前，我不能给你一个很好的方法来解决这个问题。 我发现可行的唯一方法是完全删除重写规则：
虽然这在过去对我有用，但我不推荐它。 与有一些额外的重写规则的问题相比，它引入了更大的不确定性。 我宁愿向用户显示一条注释，要求他们在停用后访问永久链接设置，这将刷新重写规则。 在实施更好的解决方案之前，我们一直坚持这一点……抱歉！
卸载插件时有两种运行代码的方法。 您可以通过以下方式使用卸载挂钩 register_uninstall_hook() 或者您可以使用专用的 uninstall.php 插件中的文件。 我将向您展示两者，但首选方法是使用卸载文件。
卸载钩子的主要问题是“它会阻止主插件文件在卸载期间运行，如果插件在全局空间中运行代码，这可能会出现问题。 卸载代码集中化也更好。” – 斯科特·莱利
下面的代码显示了使用基本挂钩的卸载过程：
如前所述，这不是最佳解决方案。 处理卸载的更好方法是使用 uninstall.php 文件。 您需要做的就是创建它，如果它可用，它将被使用。
如您所见，这实际上是一个更简单的解决方案。 最重要的是，它是独立的。
我不想让到目前为止显示的示例与安全相关问题过于复杂，但您确实应该采取一些步骤来确保只有那些被允许这样做的人才能运行这些操作。
在激活和停用时使用以下代码段：
此代码块确保用户有权执行此操作并且该操作源自正确的页面。 这应该可以防止大多数恶意尝试。
卸载过程很特殊，所以我们需要使用稍微不同的代码：
如果您的插件将内容添加到 WordPress，那么当用户决定删除您的插件时，您作为开发人员有责任将其删除。
使用上述激活、停用和卸载方法，您可以构建一个安全可靠的系统。 我还强烈推荐阅读这个 Stackexchange 线程，它概述了 OOP 环境中的这些过程。
如果您还不是 WPMU DEV 成员，请立即注册免费试用，完全无风险。 作为会员，您将可以访问我们所有出色的插件和超快的托管服务，以及针对您所有与 WordPress 相关的问题的专家 24/7 支持。
标签：Demand feedback
