WordPress wp_trash_post系列钩子未按预期工作问题排查

核心原因 #

你遇到的问题本质是：WordPress在触发wp_trashed_post这类回收站钩子后，会立刻执行页面跳转并强制终止PHP进程，导致你的函数后续代码还没跑完就被打断了。

具体流程是这样的：当你在后台把文章移入回收站时，WordPress会按以下步骤执行：

• 调用wp_trash_post()完成文章移入回收站的核心操作
• 触发pre_trash_post、wp_trash_post、trashed_post以及状态过渡钩子
• 执行wp_safe_redirect跳转到文章列表页（或之前的编辑页）
• 调用exit;直接终止整个PHP脚本

如果你的函数里没加die;，WordPress自带的exit;会比你的do_something等操作先结束进程，导致代码执行到一半就停了；而手动加die;会提前终止WordPress的后续跳转逻辑，让你的代码完整跑完，但这会破坏后台正常的跳转体验。

另外注意：你的代码里直接用$post->post_name但函数参数是$post_id，这依赖全局$post变量，容易出现不可控问题，建议改为$post = get_post($post_id);来获取当前操作的文章对象。

靠谱的解决办法 #

不要依赖die;来强制完成代码，推荐用以下两种方式：

1. 改用异步任务执行（最稳定）

把需要完成的操作放到WordPress的定时任务里，让它在后台异步执行，不依赖当前请求的进程：

function to_fire_on_hook($post_id) {
    $post = get_post($post_id);
    if (!$post) return;
    $slug = $post->post_name;

    // 调度一个立即执行的异步任务
    wp_schedule_single_event(time(), 'my_trashed_post_process_task', array($slug));
}
add_action('wp_trashed_post', 'to_fire_on_hook');

// 定义异步任务的具体执行逻辑
function run_trashed_post_process($slug) {
    do_something(..., $slug, ...);
}
add_action('my_trashed_post_process_task', 'run_trashed_post_process');

2. 优化同步操作的执行速度

如果必须同步执行，尽量精简do_something的逻辑，比如减少数据库查询、避免外部API请求等，确保它能在WordPress执行exit;之前快速完成。不过这种方式受服务器性能影响，稳定性不如异步方案。

内容的提问来源于stack exchange，提问作者Chris Pink