Setting post_status=future doesn't schedule event to actually publish

[seindal]

Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

I have a script with does this:

wp post update "$id" --post_status=future --post_date="$post_date" --post_modified="$post_date" --edit_date=1

The post is updated correctly, but doesn't publish as the requested time.

Inspecting the cron event list, the event "publish_future_post" is NOT scheduled for the post.

If I add this line to my script:

wp eval "check_and_publish_future_post($id);"

the post is published at the intended time.

WP-CLI doesn't cause the even to be scheduled when a post is marked as post_status=future, which I think is a bug.

My WP cron works (externally) and I get no warnings for missed events. Everything else works.

The necessary event is simply not scheduled.

Describe how other contributors can replicate this bug

• edit a status=draft/pending post to future with a future time
• run wp cron event list --all and verify the "publish_future_post" is NOT scheduled for that time
• wait for that time
• see the post is still status=future and not public

(Paste the output of "wp cli info" into this box)

OS:	Linux 6.12.43+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.43-1 (2025-08-27) x86_64
Shell:	/bin/bash
PHP binary:	/usr/bin/php8.4
PHP version:	8.4.11
php.ini used:	/etc/php/8.4/cli/php.ini
MySQL binary:	/bin/mariadb
MySQL version:	mariadb from 11.8.3-MariaDB, client 15.2 for debian-linux-gnu (x86_64) using  EditLine wrapper
SQL modes:	STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	phar:///usr/local/bin/wp
WP-CLI packages dir:	/home/seindal/rene/.wp-cli/packages/
WP-CLI cache dir:	/home/seindal/rene/.wp-cli/cache
WP-CLI global config:	
WP-CLI project config:	
WP-CLI version:	2.12.0

The server is Debian stable (trixie). WP installation is NOT from Debian, but locally for the site, which has everything set to update automatically.

Provide a possible solution

Add the line

 check_and_publish_future_post($id);

after any update to post_status. It will do nothing if post_status!=future.

This might afflict more than just "wp post update" -- I wouldn't know.

[swissspidy]

Heya, thanks for reaching out.

check_and_publish_future_post is usually already invoked by the publish_future_post cron event, which is scheduled by _future_post_hook(), which WP hooks by default for any changes to future when updating posts and calling wp_transition_post_status().

In other words, WordPress should automatically do this and there shouldn't be an extra need for WP-CLI to add anything extra.

We should probably add a Behat test for this to verify that, since this example is even in the readme. Plus it would help verify/reproduce this issue :)

[jigneshnakrani088]

@swissspidy @seindal I tried to reproduce the issue as mentioned above on a fresh WordPress installation, but couldn't replicate it.

Use cases

• Using the WP CLI command directly on command lines.

  • npm run env:cli -- post update 15 --post_status=future --post_date="2025-09-22 14:55:00" --post_modified="2025-09-22 14:55:00" --edit_date=1

• Using a custom CLI script that triggers wp post update using WP_CLI::runcommand.

  •       // Build the command dynamically.
          // Using escapeshellarg() is a good practice for security.
          $command = sprintf(
              'post update %d --post_status=future --post_date=%s --post_modified=%s --edit_date=1',
              $post_id,
              escapeshellarg($post_date),
              escapeshellarg($post_date)
          );
    
         $result = WP_CLI::runcommand( $command, $options );
         WP_CLI::success( "Command executed. Result: " . $result );
    

Result: Couldn't reproduce the issue.

[swissspidy]

Thanks! In that case I'm closing this for now. Feel free to reopen if it can be reproduced.