wp-cron在FrankenPHP下怎么触发才可靠-php教程-PHP中文网

frankenphp的worker模式下wp-cron默认不触发，因其常驻内存且无http请求入口；必须禁用内置cron并改用系统crontab调用wp-cli执行任务。

wp-cron在frankenphp下怎么触发才可靠

FrankenPHP 默认不触发 wp-cron，因为没 HTTP 请求入口

FrankenPHP 的 worker 模式是常驻内存的，不依赖传统页面请求触发机制。而 wp-cron.php 默认靠外部 HTTP 请求（比如浏览器访问或系统 cron 调用 wget）来驱动执行。但在 FrankenPHP 的纯 CLI worker 场景下，wp-cron.php 文件根本不会被当作 Web 资源暴露或响应——它压根不走 HTTP 流程，所以靠“访问 URL”触发 wp-cron.php 会直接 404 或超时。

必须用 wp-cli + 系统 cron 替代默认触发链

可靠方案只有一条路：禁用 WordPress 内置触发，改用系统级 cron 定期调用 wp-cli 执行任务。这绕过了所有 Web 层依赖，也适配 FrankenPHP 的无 Nginx/FPM 架构。

在 wp-config.php 中添加：define('DISABLE_WP_CRON', true);

用 crontab -e 添加真实系统定时任务，例如每 15 分钟执行一次：

*/15 * * * * cd /var/www/your-site && /usr/local/bin/wp cron event run --due-now --path=/var/www/your-site/ > /dev/null 2>&1

--path 参数必须显式指定，FrankenPHP 下 wp-cli 往往无法自动识别 WordPress 根目录
确保 wp-cli 使用的 PHP 可执行文件与 FrankenPHP 加载的版本一致（比如都是 PHP 8.3），否则可能出现扩展缺失或配置不一致

自定义 cron 间隔在 FrankenPHP 下要小心注册时机

FrankenPHP 的 worker 进程长期存活，如果在主题 functions.php 或插件中直接用 add_filter('cron_schedules', ...) 注册新间隔，该代码只在首次加载时运行一次；但后续 worker 复用时不会重复执行这个 filter，导致新间隔对 cron 调度器不可见。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

把自定义间隔注册逻辑移到 wp-config.php 开头，或封装为 mu-plugin（必须放在 wp-content/mu-plugins/ 下）
避免在钩子如 init 或 wp 中注册间隔——这些钩子在 worker 模式下可能根本不触发
验证是否生效：运行 wp cron schedule list，确认你的自定义间隔（如 five_seconds）出现在输出中

手动调试时别信 `wp-cron.php?doing_wp_cron` 这套 URL

FrankenPHP 的 HTTP server 模块默认不启用 wp-cron.php 的可访问性，即使你强行配置路由让它能被访问，也会因缺少 $_SERVER['HTTP_HOST']、$_SERVER['REQUEST_URI'] 等关键变量而中途报错退出，日志里常见 PHP Warning: Undefined array key "HTTP_HOST"。

调试唯一可信路径是 wp cron event run --due-now 或 wp cron event run <hook_name></hook_name>
加 --debug 查看完整执行栈，比如：wp cron event run hits_set_zero --debug
如果函数内用了 wp_mail() 等依赖全局环境的函数，需确认 wp-config.php 已加载且 ABSPATH 正确定义

FrankenPHP 下 wp-cron 最容易被忽略的点，是误以为“常驻进程 = 自动轮询”，其实它完全不感知 WordPress 的调度器——cron 事件仍是被动触发的，只是触发器必须从 HTTP 切换到 CLI。任何试图复用旧有 wget 或 curl 方案的尝试，都会卡在第一层网络请求上。