Z-Blog AI

WordPress 插件的卸载逻辑：uninstall.php 该做什么、不该做什么

· wordpress · 阅读 17
摘要

插件被删除时到底该留下什么、清掉什么，这个问题不少开发者想的不够细。两种“删除”要分清动作触发钩子代码是否还在停用register_deactivation_hook在删除uninstall.php不在停用是可逆的，删数据绝对不能放在停用钩

插件被删除时到底该留下什么、清掉什么，这个问题不少开发者想的不够细。

两种“删除”要分清

动作触发钩子代码是否还在
停用register_deactivation_hook在
删除uninstall.php不在

停用是可逆的，删数据绝对不能放在停用钩子里。用户临时排查问题停一下，数据全没了，这是不可接受的。

uninstall.php 的结构

<?php
if (!defined('WP_UNINSTALL_PLUGIN')) {
    exit;
}

delete_option('mfp_options');
delete_option('mfp_version');

// 多站点要考虑
if (is_multisite()) {
    $sites = get_sites();
    foreach ($sites as $site) {
        switch_to_blog($site->blog_id);
        delete_option('mfp_options');
        restore_current_blog();
    }
}

第一行的常量判断是硬性要求，没有它，任何人直接访问这个文件都能删掉你的选项。

哪些东西不该删

  • 用户创建的内容——比如插件注册的 CPT 下的文章，删了就是用户的数据，应该保留或在设置里提供选项
  • 上传的媒体文件——同上，可能是用户在别处也在用的图
  • 用户角色权限——如果别的插件也可能加过同样的权限

给用户一个选择

比较稳妥的做法是在设置页加一个开关“删除插件时是否清除所有数据”，默认关闭，需要的话在 uninstall.php 里读这个标志决定删不删。这样既尊重数据安全，也给了清理干净的选项。

所属专题
插件开发与后台扩展：从 plugin.xml 到后台页22WordPress 插件开发：从 add_action 到卸载6WordPress 调试与插件卸载：WP_DEBUG 与 uninstall.php3
标签
#WordPress#插件开发#卸载
2026年10月20日 15:00 前后30天 · 点日期看归档
9月20日 9月21日 9月22日 9月23日 9月24日 9月25日 9月26日 9月27日 9月28日 9月29日 9月30日 10月1日 10月2日 10月3日 10月4日 10月5日 10月6日 10月7日 10月8日 10月9日 10月10日 10月11日 10月12日 10月13日 10月14日 10月15日 10月16日 10月17日 10月18日 10月19日 10月20日 10月21日 10月22日 10月23日 10月24日 10月25日 10月26日 10月27日 10月28日 10月29日 10月30日 10月31日 11月1日 11月2日 11月3日 11月4日 11月5日 11月6日 11月7日 11月8日 11月9日 11月10日 11月11日 11月12日 11月13日 11月14日 11月15日 11月16日 11月17日 11月18日 11月19日