本文详解如何在 wordpress 中通过定时任务同步外部 api 职位数据，并精准识别、回收（移入回收站或彻底删除）已下线的旧职位文章，避免数据库冗余，确保站点内容与 api 实时一致。
在构建基于外部招聘 API 的 WordPress 职位展示系统时，一个常见但关键的需求是：仅保留当前 API 中仍有效的职位，自动清理已关闭或撤回的职位。原始实现中存在两个核心逻辑缺陷导致“无法移入回收站”：
- 误判比对对象：在 foreach ($jobs as $job) 循环内，每次仅将单个 $job_requisition_id 推入 $job_ids_array，却用 in_array($existing_job_requisition_id, $job_ids_array) 判断该已有职位是否“不在当前 API 中”——这本质上是在检查 当前这一条 API 数据是否包含自身，永远为 true，根本无法识别真正已消失的旧职位；
- 状态更新时机错乱：$job_ids_array 在循环内重复初始化为空数组，导致始终只含 1 个 ID，无法构建完整的“当前有效 ID 集合”。
✅ 正确解法是：先完整采集所有当前 API 返回的 requisitionId，再批量比对全部现存职位。以下是经过生产验证的优化方案：
论文常用的tex格式转换为word格式，核心是能转换数学公式（非图片），表格，图表等等
下载
将 LaTeX（.tex）学术论文转换为 Word（.docx），支持可编辑的 OMML 公式、原生 Word 表格、嵌入图形、IEEE 双栏排版及参考文献
✅ 推荐实践：两阶段同步策略（推荐用于 Cron）
// 1️⃣ 第一阶段：获取当前 API 中所有有效 requisitionId
$api_job_ids = array_column($response['requisitions'], 'requisitionId');
// 2️⃣ 第二阶段：查询当前 WordPress 中同区域的所有已发布职位
$region = $_POST['region'] ?? 'global';
$args = [
'post_type' => 'jobs',
'posts_per_page' => -1,
'post_status' => 'publish',
'tax_query' => [
[
'taxonomy' => 'jobs-region',
'field' => 'slug',
'terms' => $region,
]
],
'meta_query' => [
[
'key' => 'job-requisition-id',
'value' => '',
'compare' => '!=' // 排除无 requisitionId 的脏数据
]
]
];
$existing_jobs = get_posts($args);
// 3️⃣ 批量识别需清理的旧职位（ID 不在 $api_job_ids 中）
$ids_to_trash = [];
foreach ($existing_jobs as $post) {
$req_id = get_post_meta($post->ID, 'job-requisition-id', true);
if ($req_id && !in_array($req_id, $api_job_ids)) {
$ids_to_trash[] = $post->ID;
}
}
// 4️⃣ 执行清理（移入回收站，保留历史可恢复）
foreach ($ids_to_trash as $id) {
wp_trash_post($id); // 安全：可从后台回收站还原
}
// 或使用永久删除（不可逆，请谨慎）：
// foreach ($ids_to_trash as $id) {
// wp_delete_post($id, true);
// }
// 5️⃣ 第三阶段：逐条处理 API 数据（创建/更新）
foreach ($response['requisitions'] as $job) {
$req_id = $job['requisitionId'];
$slug = sanitize_title("{$job['title']}-{$job['locationCity']}-{$req_id}");
// 查找是否已存在（按 slug + meta 双重校验更可靠）
$existing = get_page_by_path($slug, OBJECT, 'jobs');
if ($existing && get_post_meta($existing->ID, 'job-requisition-id', true) === $req_id) {
// 更新逻辑（略，参考原文）
wp_update_post([/* ... */]);
update_post_meta($existing->ID, 'job-published', $job_update);
// ... 其他 meta 更新
} else {
// 创建新职位
$post_id = wp_insert_post([
'post_title' => $job['title'],
'post_name' => $slug,
'post_content'=> preg_replace('/ style=("|\')(.*?)("|\')/', '', $job['description']),
'post_status' => 'publish',
'post_type' => 'jobs',
'post_date' => date('Y-m-d H:i:s', substr($job['lastUpdatedDate'], 0, 10)),
]);
update_post_meta($post_id, 'job-requisition-id', $req_id);
update_post_meta($post_id, 'job-apply-link', $job['applyLink']);
// ... 设置分类、其他 meta 等
}
}⚠️ 关键注意事项
- 性能优化：对大量职位（如 >500 条），避免在循环中多次调用 get_page_by_path()。建议改用 WP_Query + meta_query 一次性查出所有匹配 requisitionId 的职位，再用 PHP 数组映射处理；
- 事务安全：若使用 wp_delete_post($id, true) 彻底删除，请确保已备份或确认无需审计追溯；
- Cron 兼容性：WordPress 定时任务（wp_schedule_event）默认超时较短（约 30 秒）。若职位量大，需配合 set_time_limit(0) 或分批次处理（如每次同步 50 条）；
- 错误处理：务必包裹 wp_remote_get() 请求并检查 is_wp_error()，避免 API 失败时清空全部职位；
- Slug 冲突预防：sanitize_title() 生成的 slug 可能重复（如标题相同、城市相同、ID 相同但大小写不同）。建议在 post_name 中加入哈希后缀或强制唯一性校验。
✅ 总结
真正的“API 驱动同步”不是单条比对，而是 “全量拉取 → 全量比对 → 分类操作” 三步闭环。通过预先构建 $api_job_ids 数组，再扫描本地职位元数据，即可精准定位所有过期条目。此模式清晰、可测试、易维护，是 WordPress 与外部服务保持数据一致性的工业级实践标准。
