__group__ ticket summary owner _component _version priority severity milestone type _status workflow _created modified _description _reporter Candidates for Closure 57924 Cron fires twice j3gaming Cron API 6.1.1 normal critical Awaiting Review defect (bug) assigned dev-feedback 2023-03-14T22:13:57Z 2024-03-05T18:52:31Z "**Problem:** In wp-includes/cron.php _set_cron_array( $cron, $wp_error = false ) is rarely called without every cron task in the $cron parameter. Eventually leading to a random one being deleted by update_option('cron', $cron); **Expected Behaviour:** (Assuming 22 total crons) wp_schedule_event( ... ) runs. Passing in a total count of 23 $crons into _set_cron_array( $crons, $wp_error ); (not sure why it's +1 the total cron count) wp_unschedule_event( ... ) runs. Passing in a total count of 22 $crons into _set_cron_array( $crons, $wp_error ); (I assume the one from the previous call is being removed) Then the cron is executed. Ready for the next time. **The Bug:** RARELY, the incorrect amount is passed, causing a series of events, that deletes the cron entirely. I am debugging this myself as I can make this happen regularly and will continue to log my progress here. I am hoping to fix this myself for the community, I'm also posting to see if anything has been flagged in the past to give me a head start." j3gaming Candidates for Closure 32306 wp-cron throws 500 errors for SSL enabled sites Cron API 4.2.1 normal critical Awaiting Review defect (bug) reopened reporter-feedback 2015-05-08T07:49:05Z 2017-11-14T14:01:53Z "I have several WP installs that are throwing 500 error codes when calling wp-cron.php after a pageview. The error is not consistent - it will sometimes return 200, and sometimes 500. All the installs I see this on use SSL with properly signed certs with SNI in use on the server under Apache. Instances on the same server where do not use SSL have not shown this issue at all. I have managed to reproduce this on a clean WP install running twentyfifteen with no plugins installed so it doesn't appear to be plugin related. Oddly, I don't get any PHP warnings when it happens (though I've tested that if I force a php script in the same pool to throw an error, it does get captured) - I do get the following recorded in the Apache Virtualhost error log (redacted): [Fri May 08 08:29:34.479946 2015] [core:error] [pid 13870:tid 140644332824320] [client xxxx:xxxx:x:xx:xxxx:xx:x:x:57492] AH00524: Handler for fastcgi-script returned invalid result code 32 Apache access log (redacted): xxxx:xxxx:x:xx:xxxx:xx:x:x - - [08/May/2015:08:29:26 +0100] ""POST /wp-cron.php?doing_wp_cron=1431070166.8151741027832031250000 HTTP/1.0"" 500 4066 ""-"" ""WordPress/4.2.2; https://www.domain.com"" System config is as follows: * Fully patched Debian Jessie running on amd64 arch with kernel 3.16.0 * Webserver: Apache/2.4.10 (Debian), mod_fastcgi/mod_fastcgi-SNAP-0910052141, mod_fcgid/2.3.9, mod_python/3.3.1, Python/2.7.9, OpenSSL/1.0.1k * MySQL 5.5.43-0+deb7u1 * PHP 5.6.7+dfsg-1 running under PHP-FPM (seen with and without opcache in place) * Wordpress 4.2.2 fresh install (also seen on 4.2.1) with all plugins removed. The server listens both on IPv4 and IPv6 - I've tried forcing wp-cron to use IPv4 by setting the hostname in /etc/hosts but that makes no difference. Refer also to : https://wordpress.org/support/topic/wp-cron-throwing-500-errors-on-ssl-sites?replies=9" coatesg Tickets Awaiting Review 47127 Parameter Error in class-wp-hook files Cron API 5.1.1 normal major Awaiting Review defect (bug) new 2019-05-05T12:57:33Z 2019-05-09T02:26:49Z "After update, I am getting these in the logs, tens of thousands of lines of the same thing over and over again. I have to delete logs daily as the size grows into the 10+ megs. It is odd. This repeats over and over again without ceasing. I removed all plugins and switched to the default theme and the error still persists. It has to do with the core. [05-May-2019 12:50:43 UTC] PHP Warning: call_user_func_array() expects parameter 2 to be array, null given in /home/public_html/wp-includes/class-wp-hook.php on line 286 [05-May-2019 12:50:43 UTC] PHP Notice: Undefined index: args in /home/public_html/wp-cron.php on line 118 [05-May-2019 12:50:43 UTC] PHP Notice: Undefined index: args in /home/public_html/wp-cron.php on line 122 [05-May-2019 12:50:43 UTC] PHP Notice: Undefined index: args in /home/public_html/wp-cron.php on line 133 [05-May-2019 12:50:43 UTC] PHP Warning: count(): Parameter must be an array or an object that implements Countable in /home/public_html/wp-includes/class-wp-hook.php on line 272 " walkinverse Tickets Awaiting Review 53927 Add test for _get_cron_array() Cron API normal normal Awaiting Review defect (bug) new has-patch 2021-08-13T21:14:16Z 2021-08-17T16:22:38Z pbearne Tickets Awaiting Review 57271 Cron unschedule / reschedule event errors audrasjb Cron API 6.0 normal normal Awaiting Review defect (bug) assigned needs-unit-tests 2022-12-04T09:55:55Z 2024-03-07T01:04:44Z "Multiple users have reported errors since v6.0 across installs with completely different themes and plugins ... {{{ [09-Nov-2022 11:28:28 UTC] Cron unschedule event error for hook: do_pings, Error code: could_not_set, Error message: The cron event list could not be saved., Data: {“schedule”:false,”args”:[]} [09-Nov-2022 18:05:03 UTC] Cron unschedule event error for hook: wordfence_processAttackData, Error code: could_not_set, Error message: The cron event list could not be saved., Data: {“schedule”:false,”args”:[]} [21-Nov-2022 07:53:04 UTC] Cron reschedule event error for hook: wf_scan_monitor, Error code: could_not_set, Error message: The cron event list could not be saved., Data: {“schedule”:”wf_scan_monitor_interval”,”args”:[],”interval”:60} [21-Nov-2022 07:53:04 UTC] Cron unschedule event error for hook: wf_scan_monitor, Error code: could_not_set, Error message: The cron event list could not be saved., Data: {“schedule”:”wf_scan_monitor_interval”,”args”:[],”interval”:60} }}} There are many more examples on the support thread https://wordpress.org/support/topic/cron-unschedule-event-error-for-hook/ I have so far been unable to find a way to manually re-produce this issue but this is what I have discovered so far ... So this error happens when `wp_unschedule_event()` and `wp_reschedule_event()` fails. `could_not_set` error is presented by` _set_cron_array()` which is the return function for `wp_unschedule_event()` and `wp_schedule_event()`. `could_not_set` error is returned by `_set_cron_array()` when the updating of the cron table fails with `update_option( 'cron', $cron );`. `update_option()` fails when … 1) The `$option` parameter is empty This should never happen 2) The old option value is the same as the new option value This suggests the cron job is running more than once but may not be the only reason ... ? 3) The database insert query `$wpdb->update()` fails This is a bit worrying but shouldn’t be the case as surely there should be an accompanying database error? I think we can rule out (1) seeing as the `$option` parameter is never empty. We can maybe rule out (2) because from the thread above, this happens on high traffic sites as well as low traffic sites and on sites using the default wp-cron firing as well as cron fired by the system … ? The leaves (3) being the most likely cause of the ""bug"". I have tried to assign to @audrasjb (I hope that's OK to do?) because they added the commit on the 20th September that started to highlight the issue https://github.com/WordPress/WordPress/commit/84d19848666a81584e0007a6ab7f7ad3c990d71a I realise that this is not going to be easy to diagnose until the issue can be manually replicated but I think it should be looked into. Oliver " domainsupport Tickets Awaiting Review 36082 Schedule post, not added to cron, shown as 'scheduled' in admin. Doesn't publish. Cron API 4.4.1 normal normal Awaiting Review defect (bug) new 2016-03-03T14:08:09Z 2019-06-04T18:13:40Z "Hello, We have an intermittent problem on a high traffic site. The issue is that occasionally, a post will be scheduled but not picked up in cron (we log whats in the cron). In the admin, it shows as being scheduled but obviously never posts because it's not actually present in the cron. What could make this happen? The site has about 20 users in the admin, with around 30 pageviews/second on frontend. (4 webservers etc)" dencreativeltd Tickets Awaiting Review 39340 Scheduled Posts are being missed (problem with wp-cron.php?) Cron API 4.6.1 normal normal Awaiting Review defect (bug) new 2016-12-20T09:45:33Z 2020-04-03T14:39:45Z "Scheduled posts are missing their set time. This is not an issue with out server times, nor is it an issue with the cron jobs. I have seen that many other users are experiencing problems with this, but as of yet there has been no word from WordPress. Has this been fixed in 4.7? Or is this still outstanding? " remarkablemike Tickets Awaiting Review 29581 Scheduled Posts do not work in WordPress 4.0 Cron API 4.0 normal normal Awaiting Review defect (bug) new 2014-09-08T04:56:28Z 2019-06-04T18:13:38Z "The post says ""missed schedule"" after the scheduled time has passed. We have to manually force the publishing by changing the date and updating from the admin. We've done it on installs with no conflicting plugin and replicated the issue on different installs as well. All show the same behavior. This was not the case through 3.9.2." pro99 Tickets Awaiting Review 51716 WP Cron - looses entries Cron API normal normal Awaiting Review defect (bug) new has-patch 2020-11-05T20:42:26Z 2020-11-24T11:47:00Z "Hello, I've been working with an external API for submitting orders from Woocommerce. To ensure the system is responsive I've been calling the scheduled events to save the orders to the API shortly after the order is submitted. I have noted that if items are saved at the same time. One of the events will not be saved. This appears to be caused by the cron task being build around a single database record (object), and in many cases would be completely fine, but is not reliable when being used in any great capacity. I understand my use-case isn't potentially what this was designed for, but there is room for improvement with the scheduled events to ensure reliability. I'm not 100% sure if I'm correct here, but it also appears that these tasks are also run when subsequent web requests are made, is there any current normalized interface for setting this up to run via an OS cron task or similar. To ensure other visitors requests aren't slowed down by checks (small) and events being activated (potentially slow). " Nate1 Tickets Awaiting Review 55556 WP cron daily issue Cron API normal normal Awaiting Review defect (bug) new 2022-04-11T08:36:02Z 2022-04-11T08:36:02Z "In wordpress, a day is defined as having 24 hours: wp-includes/default-constants.php: define( 'DAY_IN_SECONDS', 24 * HOUR_IN_SECONDS ); but that doesn’t take summer/winter time into account of course. While it is being stated above the definition that these values are approximate and are provided for convenience, the DAY_IN_SECONDS is being used in the “daily” cron definition. This means - in case of DST - if you plan something to happen daily at midnight (say membership status recalc, half of the year it will happen one hour later/earlier (depending on the day you planned it initially). So, in order to be sure something happens daily “as soon as the new day starts”, you need to plan it at 01:00 at the earliest to be sure it is always on the same day (in case of DST). Since the fixed wp schedules are in fact “fixed”, why not have them calculate “daily” as the DateTime function “+1 day”? The same goes for weekly, monthly, yearly. The basic schedules could even be thrown away and WP could e.g. translate 'daily' to '+1 day' on the fly. I know WP cron doesn’t run exactly the moment you want it (unless you use system cron), but if running something “daily” at around midnight and it causes it to be ran at 23:00 instead, you might be giving people an extra free day entrance (again for memberships). Moreover, getting rid of ""schedules"" and moving cron to its own database table would be even better (planning a recurring action should not require the need for a schedule definition via a filter, but use ""last executed time"" + the recurrence definition in datetime notation as a cron-definition). But this last remark is a whole other discussion, so not for this issue (but I would be willing to invest time in this to help develop it)." liedekef Tickets Awaiting Review 56490 wp-cron.php using count() on null Cron API 6.0.2 normal normal Awaiting Review defect (bug) new 2022-09-01T16:47:36Z 2022-09-04T12:35:06Z "WE're using PHP 8.0 and the latest version of WordPress (6.0.2), we tried with all plugins disabled and the default theme enabled and we're having this fatal error happening every minute: {{{ PHP Fatal error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in wp-includes/class-wp-hook.php:292 }}} Here's the stack trace: {{{ #2 wp-cron.php(138): do_action_ref_array('wp_privacy_dele...', NULL)"",""Thu Sep 01 2022 18:37:06 GMT+0200 (Eastern European Standard Time)"" #1 plugin.php(524): WP_Hook->do_action(NULL)"",""Thu Sep 01 2022 18:37:06 GMT+0200 (Eastern European Standard Time)"" #0 /nas/content/live/bbgsstaging/wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters('', NULL)"",""Thu Sep 01 2022 18:37:06 GMT+0200 (Eastern European Standard Time)"" }}} It looks like the default WordPress core hook ""wp_privacy_delete_old_export_files"" is causing this error. We excluded this hook but then ""wp_version_check"" caused the same fatal error. This issue also happens when on PHP 7.4, but on 7.4 it's just a warning, but it's also occurring. We're happy to provide additional information or access to our staging site if needed." Bishoy.A Tickets Awaiting Review 60657 wp_schedule_event problem Cron API 6.4.3 normal normal Awaiting Review defect (bug) new 2024-02-29T08:44:32Z 2024-02-29T08:59:37Z "In some cases there are some problems with wp_schedule_event. It schedule the event, if we use wp_next_scheduled, it gives a timestamp, but using WP Crontrol, it doesn't appear there. Below some code to reproduce it. If you click on the button, it will schedule 500 events. Wait a bit, that 100 or so are processed (look at the logs or use WP Control to check). Then click again. The logs show that they should have been schedules, there is a timestamp and the transient is created. But it's not really scheduled, it doesn't appear with WP Control, and the transient is not deleted (for the 2nd round) {{{ if (!class_exists(""NSM_Test_Cron"")) { class NSM_Test_Cron { function __construct() { add_action('admin_menu', array($this, 'my_custom_button_menu')); add_filter('cron_schedules', array($this, 'cron_schedules')); add_action('nsm_test_cron', array($this, 'nsm_test_cron')); } public function cron_schedules($schedules) { if (!isset($schedules['nsm_60_seconds'])) { $schedules['nsm_60_seconds'] = array('interval' => 60, 'display' => '60 Seconds'); } return $schedules; } function my_custom_button_menu() { add_menu_page('My Custom Button', 'Custom Button', 'manage_options', 'my-custom-admin-button', array($this, 'my_custom_button_page')); } function my_custom_button_page() { error_log('my_custom_button_page'); if (isset($_POST['action']) && $_POST['action'] == 'myaction') { error_log('my_custom_button_page action'); for ($index = 0; $index < 500; $index++) { $args = array(array('email' => 'toto@foo.org', 'user_id' => '1234', 'tags' => $index)); if (!wp_next_scheduled('nsm_test_cron', $args)) { $error = wp_schedule_event(time(), 'nsm_60_seconds', 'nsm_test_cron', $args, true); set_transient( 'doing_cron_' . $index, $index ); error_log('error -> ' . print_r($error, true)); error_log(""wp_next_scheduled ($index)-> "" . print_r(wp_next_scheduled('nsm_test_cron', $args), true)); } } } ?>

My Custom Button

' . $args['tags']); sleep(1); delete_transient( 'doing_cron_' . $args['tags']); } } } new NSM_Test_Cron(); }}}" odoremieux Tickets Awaiting Review 52655 Ability to Change the wp_next_scheduled() function output. Cron API normal normal Awaiting Review enhancement new has-patch 2021-02-25T15:04:10Z 2021-02-28T23:48:55Z "If I want to replace WP Cron with the Action Scheduler Library it is necessary to change the wp_next_scheduled() function output by overriding it using a filter to use as_next_scheduled_action() function. {{{ function wp_next_scheduled( $hook, $args = array() ) { $next_event = wp_get_scheduled_event( $hook, $args ); if ( ! $next_event ) { return false; } return apply_filters( 'wp_next_scheduled', $next_event->timestamp, $next_event, $hook, $args ); } }}} If we use 'pre_get_scheduled_event' filter, it will also override the default Cron functions. So that I think 'wp_next_scheduled' is necessary." infosatech Tickets Awaiting Review 58470 Add configurable batching to `wp_scheduled_delete` for controlling cleanup operations Cron API 6.3 normal normal Awaiting Review enhancement new 2023-06-06T22:08:46Z 2023-06-07T14:17:17Z "When posts are trashed, they are automatically cleaned up by the `wp_scheduled_delete` wp-cron task. However, both the frequency that this cron task runs and the number of posts that can be cleaned up at once time lack configurability. Imagine a shop which has more than 100,000 orders: trashing thousands or tens of thousands of them at once could cause the website to become unresponsive when it comes time to clean up the trash. I suggest adding two constants: ||= Constant Name =||= Default Value =||= Description =|| || `EMPTY_TRASH_SCHEDULE` || `daily` || The cron schedule on which the trash scheduler runs. This is useful for increasing the number of times the cleanup process runs when using batching to delete many posts. || || `EMPTY_TRASH_BATCH_SIZE` || `50` || The maximum number of posts to delete at once. || It may also be useful for these and `EMPTY_TRASH_DAYS` to have filters to improve cleanup operations overall." johnrom Tickets Awaiting Review 60645 Add pre-fire hook for cron Cron API trunk normal normal Awaiting Review enhancement new has-patch 2024-02-27T12:38:20Z 2024-02-27T12:42:17Z "Followup to https://core.trac.wordpress.org/ticket/56048 https://core.trac.wordpress.org/changeset/54258 This adds an additional hook before every cron event to allow for custom code to run before a cron hook Use cases: - custom error checking (e.g. if a cron even has no callbacks,...) - load libraries/functions/classes that are only needed for a specific number of cron events and would otherwise slow down the site/cron - this hook allows you to handle multiple at once which is useful for e.g. dynamic hook names or for cases where you need to run it for a number of hooks (instead of adding 100 add_action with same callback) " kkmuffme Candidates for Closure 57534 Cron events stop working after PHP 8.0 update Cron API 5.9 normal normal Awaiting Review defect (bug) new reporter-feedback 2023-01-23T18:37:56Z 2023-08-08T16:18:52Z "Hello, I noticed that all wordpress cron events cease ruining upon migrating to PHP 8.0. When I change back to 7.4 the crdo events resume. " domagron Candidates for Closure 34913 Unscheduling cron jobs fails when original arguments were not an array. Cron API 3.0 normal normal Awaiting Review defect (bug) new dev-feedback 2015-12-08T13:31:40Z 2021-09-02T05:39:24Z "The Cron API does not check whether the cron job arguments passed are an array when scheduling a cron job. This inadvertently allows for scheduling cron jobs with string, integer or other arguments. However when unscheduling the cron job using `wp_clear_scheduled_hook()`, the arguments are ''always'' cast to an array which leads to cron jobs which '''*can*''' be scheduled, but can't be '''''*un*'''''scheduled using `wp_clear_scheduled_hook()`. The `wp_clear_scheduled_hook()` does throw a `deprecated` notices when non-array arguments are passed in, but this will most of the time go unnoticed as this function is most often used in a plugin deactivation routine. The patch which I'm submitting makes sure that cron job arguments are always cast to an array. The patch is backward compatible in that it: * will not break the `schedule_event` filter for plugins (which are ''doing it wrong'') which expect their original non-array argument to test against. * will schedule all newly schedule events with array arguments independently of how the arguments were passed. * will upgrade the cron array to ensure that all arguments are arrays. The patch includes unit tests proving the existence of the bug and the fixing of it by this patch. As far as I can see, this bug was introduced by the changes in https://core.trac.wordpress.org/changeset/12462 and has been in WP since 3.0. The patching of this bug also brought to my attention *another* (ancient) bug where in the cron option upgrade routine `_upgrade_cron_array()` the array structure wasn't respected properly leading to `Undefined index: args` notices and the inadvertent removal of cron events which were scheduled on the same hook for the same timestamp with different arguments. That bug has also been fixed in this patch." jrf Candidates for Closure 57589 transition_post_status hook does not fire when cron publishes scheduled post. Cron API 6.1.1 normal normal Awaiting Review defect (bug) new reporter-feedback 2023-01-30T22:32:39Z 2023-01-31T20:16:19Z "Ever since the most recent 6.1 update, a critical hook of ours is not firing any more. We have a custom cache clearing plugin that clears the nginx, redis and Cloudflare cache for a bunch of our landing pages. It runs on our site when a post's status changes from from 'future' to 'publish', from 'publish' to 'trash' or when a post is originally published of updated. We use the transition_post_status hook to trigger these cache clears. Everything was working great until the 6.1/6.1.1 updates. After the wp 6.1 update, the manual publish/update operations done directly using the wp-admin work fine, but when our cron runs to publish a scheduled post the transition_post_status hook does not fire at all. But here is the most curious thing... the ""publish_future_post"" cron job is not created when we schedule a post for the future. The function check_and_publish_future_post() uses this cron job to decide what posts need to be published, but the cron job never appears in my action scheduler or in my events tab of the wp-control plugin. So that mean that the wp_publish_post() function does not run, and the filter hooks don't fire. But the post DOES publishes as expected on the wp-cron. It is beyond weird, and i cant figure it out. Here is what I have done and tested thus far: I have tested all of the following hooks: none of them work either: - transition_post_status - future_to_publish - future_post I am using a manual cron fired from my ubuntu server, and I have confirmed my cron is firing using an output.log, and I can also confirm that other wp-cron jobs are running as as normal. I have tried both a conventional wget 'doing_wp_cron' and a wp-cli cron jobs, and both fail (see examples below): - * * * * * wget -q -O - --no-check-certificate https://domain.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1 - * * * * * cd /path/to/www; /usr/local/bin/wp cron event run --due-now >/dev/null 2>&1 In order to get back to where we were, I have had to spin up my own cron that publishes future posts myself, so I have solved this issue on my end, but I cannot be the only one experiencing this, so I thought that I would submit this information for your review, thanks!" tele2rn Tickets Needing Feedback 11800 doubled execution of cron jobs westi Cron API 2.9.1 normal normal Future Release defect (bug) new dev-feedback 2010-01-07T11:17:53Z 2021-04-04T10:34:28Z "Hi, as I've already mentioned in ticket #11505 , cron-jobs occasionally get executed twice (e.g. daily backup arrives two times). I've changed the code according to the patch attachment:ticket:11505:ticket-11505-stop-gap.patch (which derives from [http://wpengineer.com/ping-problem/]) after my comment:ticket:11505:49 and had no doubles within this time period. This week I've upgraded to WP 2.9.1 and since then backups arrive two, sometimes three times, again. Looking at the changes from 2.9 to 2.9.1, I have no other explanation for this behavior. - Maybe we should consider having a closer look again on this patch attachment:ticket:11505:ticket-11505-stop-gap.patch . Greetz, Berny" neoxx Tickets with Patches 35491 Add a function to check whether a hook is scheduled Cron API normal normal Future Release enhancement reopened has-patch 2016-01-17T04:46:47Z 2019-06-04T18:11:28Z "I'm working with a plugin that calls `wp_schedule_event()` with an unpredictable value for `$args`. Sometimes it would be helpful to know whether this plugin's event is scheduled, but because I can only guess at `$args`, I can't always detect it with `wp_next_scheduled()`. The attached patch attempts to address this scenario with a function that checks only whether a hook is scheduled, regardless of its `$args`. " dlh Tickets with Patches 49693 Drop duplicate recurring cron events whyisjake* Cron API 5.4 normal normal Future Release enhancement accepted has-patch 2020-03-24T19:03:36Z 2021-01-31T21:54:52Z "It's easy to break a site by mistakenly scheduling millions of events because of a typo or a bad check. Here's one example: https://wordpress.org/support/topic/error-in-addcustomcronschedule-degrades-site-performance/ In the past, I've also seen plugins use `get_option` and all kinds of different checks, instead of `wp_next_scheduled`. Fixing the site afterwards can be a bit of a PITA, specially for high traffic ones. DB replication is often an issue when the `cron` option grows in size due to the bug. It's probably a good idea to prevent scheduling recurring events that have the same hook, schedule and args. Additional thoughts: - This might make the `wp_next_scheduled` check obsolete when queuing an event? - Changing the arguments of `wp_schedule_event` isn't something I wanted to do, but considering the current code for reschedule/unschedule in `wp-cron.php`, it seemed the best route (case of missing schedule, and trying to get interval from the event that we're rescheduling). - We're currently doing this with a `schedule_event` filter. Another route could be to add it to `default-filters`, but I think it should be in the Cron API itself." aidvu Tickets with Patches 43801 Need better documentation to show importance of checking for args while using wp_schedule_event and wp_next_scheduled Cron API normal normal Future Release enhancement new has-patch 2018-04-18T15:47:51Z 2021-01-29T12:44:57Z "While the user notes https://developer.wordpress.org/reference/functions/wp_next_scheduled/#user-contributed-notes do relay the importance. I believe it is important that the documentation also be more clear about the issue. When coded incorrectly something like {{{ function schedule_my_event(){ if ( ! wp_next_scheduled( 'myevent' ) ) { // This will always be false wp_schedule_event( time(), 'daily', 'myevent', array( false ) ); } } add_action('init','schedule_my_event'); }}} It's potentially disastrous for a site. The cron value in the options would keep on increasing until the database could no longer withstand it. So keeping that in mind I feel the documentation for both wp_next_scheduled and wp_schedule_event should highlight this point more." digamberpradhan Tickets with Patches 28635 Add status codes and hooks to wp-cron.php chriscct7 Cron API normal normal Future Release feature request reopened has-patch 2014-06-25T18:06:05Z 2023-07-14T11:09:06Z "I've been debugging a site problem which turned out to be one of the cron actions resulting in a memory limit breach, and so PHP did a fatal error in the middle of the cron loop. (It's a high-traffic site so it has `DISABLE_WP_CRON` with system cron pinging wp-cron.php every minute.) There is currently very little debugging hooks provided in `wp-cron.php` to help diagnose why and where a scheduled event hook is failing. Some ideas for how `wp-cron.php` could be improved to facilitate debugging (and also to help with general logging): * Return a status message pinpointing at which point `wp-cron.php` exited * Return relevant HTTP status codes * Allow `die` behavior to be overridden, similarly to how `wp_die()` is used elsewhere * Add hooks before before and after each level in the triple-nested crons loop. " westonruter Unpatched Bugs 47590 Add unit tests for requests to wp-cron.php Cron API normal normal Future Release defect (bug) new needs-unit-tests 2019-06-22T13:51:07Z 2019-06-30T22:07:49Z "1. Ensure scheduled events are rescheduled correctly 1. Ensure single events are removed from the cron array 1. Ensure future events are not changed. 1. Ensure `doing_cron` transient is deleted." peterwilsoncc Unpatched Enhancements 40161 Wrong documented or coded 'schedule_event' filter Cron API low normal Future Release enhancement reopened 2017-03-15T12:39:06Z 2019-01-08T03:28:43Z "https://core.trac.wordpress.org/browser/trunk/src/wp-includes/cron.php#L41 says that $event parameter should always be an object. But the following code allows to terminate script only when passing ""false"" values to filter ("""", array(), null, 0 or false), whereas checking false as object will produce error. The documentation should be changed to force check isset( $event->hook ) when using this filter, otherwise the filter should be changed to something like this {{{#!php hook, $event ); if ( ! $event->hook ) return false; }}} " esemlabel