具体表现
删掉不再使用的插件,数据库里还能看到它建的表和选项。
先判断哪一层出错
插件卸载钩子没有做清理,删除文件不会动数据库。判断时先分清是 WordPress 插件残留 本身的配置问题,还是上游调用、运行环境带进来的差异;前者改配置就能收口,后者要沿着请求链路一层层往上找,处理顺序不能颠倒。先在出问题的机器上复现一次,把报错原文和发生时间记下来,再对着日志定位。
操作步骤
- 先备份再确认表归属
- 删除对应表与选项
- 清理定时任务残留
对应的命令或配置片段如下,可直接复制:
DROP TABLE IF EXISTS wp_oldplugin_log; DELETE FROM wp_options WHERE option_name LIKE 'oldplugin_%'; DELETE FROM wp_usermeta WHERE meta_key LIKE 'oldplugin_%';
测试环境复现不了时,先对比两边的版本号和配置文件,差异往往就在被忽略的那几行里。如果同一现象隔一段时间又出现,多半是某个定时任务或重启流程把配置覆盖回去了,顺手查一遍启动脚本。
收尾检查
数据库中不再有该插件相关表与选项,站点访问正常。