Make WordPress Core

Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#49961 closed enhancement (fixed)

Expose the reason for failures that occur within WP-Cron functions

Reported by: johnbillion's profile johnbillion Owned by: johnbillion's profile johnbillion
Milestone: 5.7 Priority: normal
Severity: normal Version: 5.1
Component: Cron API Keywords: has-patch has-unit-tests dev-feedback has-dev-note
Focuses: Cc:


Since WordPress 5.1, the various WP-Cron related functions (wp_schedule_event() etc) now return meaningful return values, but this still doesn't expose the underlying reason for failure.

My WP Crontrol plugin regularly gets support requests from users who are managing cron events but getting a generic error message. It would be useful if core exposed the underlying problem so that anything that calls wp_schedule_event(), wp_unschedule_event() etc can provide a meaningful error message to the end user.

I see two potential approaches:

  1. Add an optional $wp_error parameter to these functions, similar to wp_update_post(), wp_set_comment_status() etc, and return a meaningful error when one occurs.
  2. Trigger an action containing the error details, similar to http_api_debug, which can be hooked into before calling the cron functions.

Change History (13)

This ticket was mentioned in PR #914 on WordPress/wordpress-develop by johnbillion.

3 years ago

  • Keywords has-patch has-unit-tests added

#2 @johnbillion
3 years ago

  • Keywords dev-feedback added; 2nd-opinion removed
  • Milestone changed from Awaiting Review to 5.7

PR ready for review at One thing I'm particularly interested in hearing is if anybody thinks it will cause a problem for the various pre_* filters to now potentially pass a WP_Error object, when previously they only passed null|stdClass|false.

TimothyBJacobs commented on PR #914:

3 years ago

This is the nitiest of nits, but why no period on the error messages?

#4 @johnbillion
3 years ago

  • Keywords needs-dev-note added

peterwilsoncc commented on PR #914:

3 years ago

Thanks for the replies @johnbillion, this all looks good to me. Your reply about setting the array/updating option response makes sense.

#6 @johnbillion
3 years ago

The changes to the pre_* filters which means the $pre value can be a WP_Error after this change might have more of an impact than I thought. Looking through some plugin directory scans now.

#7 @johnbillion
3 years ago

Okay false alarm. We're all good. Only WP-Optimize needs an update for its back-compat function.



  • No plugins affected



  • No plugins affected


In addition I checked Cavalcade, Cron Control, Action Scheduler, and WP Background Processing. Cavalcade will gracefully handle a WP_Error in all the $pre parameters with no change, and the others don't use the affected filters.

#8 @johnbillion
3 years ago

  • Owner set to johnbillion
  • Resolution set to fixed
  • Status changed from new to closed

In 50143:

Cron API: Introduce a $wp_error parameter to functions that write to the cron array.

This allows the functions to return a WP_Error object containing more information in case of a problem, instead of just boolean false.

The various pre_ filters in these functions are also updated so they can return or be passed a WP_Error object.

Fixes #49961

#10 @desrosj
3 years ago

In 50152:

Coding Standards: Fix several minor coding standards issues.

These are made by running composer format.

Follow up to [50124], [50129], [50143].

See #49961, #52192, #34281.

#11 @SergeyBiryukov
3 years ago

In 50174:

Docs: Add a @since note to wp_clear_scheduled_hook() for the $wp_error parameter.

Follow-up to [50143].

See #49961.

#12 @johnbillion
3 years ago

In 50394:

Cron API: Add a missing $wp_error parameter to the pre_reschedule_event filter.

Props tmatsuur, mukesh27

Fixes #52572
See #49961

Note: See TracTickets for help on using tickets.