Hi Addonify team,
We've identified a fatal error in the UDP (usage data) agent bundled with Addonify Quick View. The error fires during WP-Cron runs and does not affect frontend page loads, but it causes the cron process to abort.
Error
Critical: Uncaught Error: Call to undefined function get_core_updates() in wp-admin/includes/class-wp-debug-data.php:156
Backtrace
#0 wp-admin/includes/class-wp-debug-data.php(47): WP_Debug_Data::get_wp_core()
#1 addonify-quick-view/includes/udp/class-udp-agent.php(229): WP_Debug_Data::debug_data()
#2 addonify-quick-view/includes/udp/class-udp-agent.php(313): Udp_Agent->get_data()
#3 addonify-quick-view/includes/udp/init.php(175): Udp_Agent->send_data_to_engine()
#4 wp-includes/class-wp-hook.php: cc_udp_agent_send_data_on_action()
#5 wp-cron.php(191): do_action_ref_array()
Root cause
In class-udp-agent.php, get_data() loads its admin file dependencies inside a single class_exists guard:
if ( ! class_exists( 'WP_Debug_Data' ) ) {
require_once ABSPATH . 'wp-admin/includes/class-wp-debug-data.php';
require_once ABSPATH . 'wp-includes/load.php';
require_once ABSPATH . 'wp-admin/includes/update.php'; // defines get_core_updates()
require_once ABSPATH . 'wp-admin/includes/plugin.php';
require_once ABSPATH . 'wp-admin/includes/misc.php';
}
WordPress's own Site Health cron job (wp_site_health_scheduled_check) also loads WP_Debug_Data during cron runs, but does so without loading update.php. When Site Health runs first in the same cron process, class_exists( 'WP_Debug_Data' ) returns true, the entire block is skipped, get_core_updates() is never defined, and the subsequent call to WP_Debug_Data::debug_data() fatals at line 156 of class-wp-debug-data.php.
Fix
Separate the update.php dependency from the class check so it is always loaded regardless of whether WP_Debug_Data was previously loaded by another code path:
if ( ! class_exists( 'WP_Debug_Data' ) ) {
require_once ABSPATH . 'wp-admin/includes/class-wp-debug-data.php';
require_once ABSPATH . 'wp-includes/load.php';
require_once ABSPATH . 'wp-admin/includes/plugin.php';
require_once ABSPATH . 'wp-admin/includes/misc.php';
}
if ( ! function_exists( 'get_core_updates' ) ) {
require_once ABSPATH . 'wp-admin/includes/update.php';
}
The same logic should be applied to any other functions called by WP_Debug_Data::debug_data() that live in files not guaranteed to be loaded in a cron context.
Workaround for affected users
Disabling usage tracking in the Addonify plugin settings sets udp_agent_allow_tracking to no, which causes send_data_to_engine() to return early before get_data() is called. This stops the fatal error immediately while waiting for a fix.
Thanks for a great plugin — hope this helps!
Hi Addonify team,
We've identified a fatal error in the UDP (usage data) agent bundled with Addonify Quick View. The error fires during WP-Cron runs and does not affect frontend page loads, but it causes the cron process to abort.
Error
Critical: Uncaught Error: Call to undefined function get_core_updates() in wp-admin/includes/class-wp-debug-data.php:156Backtrace
Root cause
In class-udp-agent.php, get_data() loads its admin file dependencies inside a single class_exists guard:
WordPress's own Site Health cron job (
wp_site_health_scheduled_check) also loadsWP_Debug_Dataduring cron runs, but does so without loadingupdate.php. When Site Health runs first in the same cron process,class_exists( 'WP_Debug_Data' )returns true, the entire block is skipped,get_core_updates()is never defined, and the subsequent call toWP_Debug_Data::debug_data()fatals at line 156 ofclass-wp-debug-data.php.Fix
Separate the
update.phpdependency from the class check so it is always loaded regardless of whether WP_Debug_Data was previously loaded by another code path:The same logic should be applied to any other functions called by
WP_Debug_Data::debug_data()that live in files not guaranteed to be loaded in a cron context.Workaround for affected users
Disabling usage tracking in the Addonify plugin settings sets
udp_agent_allow_trackingtono, which causessend_data_to_engine()to return early beforeget_data()is called. This stops the fatal error immediately while waiting for a fix.Thanks for a great plugin — hope this helps!