Logged-out Users Run Your WordPress Cron Jobs

? Code that works in a plugin might not behave the same in a scheduled wp-cron job.

Things That Don’t Always Work in WordPress Cron Jobs

1. get_posts() calls that return posts with unpublished statuses
   Workaround: use $wpdb queries to retrieve posts or force admin
2. tax_input parameter during wp_insert_post() or wp_update_post() calls
   Workaround: use wp_set_object_terms() or force_admin
3. wp_get_update_data()
4. Other functions or codes that call current_user_can() or current_user_can_for_blog()

Why do wp-cron jobs behave differently?

WordPress cron jobs are triggered by any visitor to your site on or after the scheduled time. A logged-out visitor could be running your WordPress cron job.

Any code that uses current_user_can() to restrict permissions can behave differently during wp-cron, including get_posts() and wp_update_post() calls.

SOLUTIONS

1. Test Your Code as a Logged-Out Visitor

Testing wp-cron job code with a tool that runs tasks on demand (like the fantastic Advanced Cron Manager) will fool you into believing the code will always run as an Administrator user. It’s not true. Use a short interval during development so it’s easier to trigger jobs as a logged-out visitor.

2. Briefly Force Administrator

Use wp_set_current_user() to explicitly use an Administrator account at the beginning of your job’s code, and restore the original user ID even if zero to avoid leaking Administrator privileges.

$user_id = get_current_user_id(); // Could be 0.
wp_set_current_user( 1 ); // One (1) is the user ID of an Administrator.

// Do the stuff that needs to run as an admin.
$drafts = get_posts( array(
	'post_status' => 'draft', // Drafts aren't accessible to logged-out users.
) );

// Don't leak Administrator privileges, restore the previous user even.
wp_set_current_user( $user_id );

2. Use Real Cron

Almost every hosting company on the planet has written an article about triggering wp-cron with a real cron job. Here’s one at Kinsta.