[Jonathan]

I noticed this on a few servers recently. Is Git Updater causing this? WP no longer auto-updating plugins like before.

wp cron event list --fields=hook,next_run --order=asc | grep auto
wp_scheduled_auto_draft_delete  2025-02-28 13:02:14

no results.

wp_maybe_auto_update(); missing.

If I run wp eval 'wp_maybe_auto_update();' using WP-CLI those plugins with pending auto-updates will then auto-update themselves.

[Barbara]

I had to re-add it to the schedule:

wp cron event schedule wp_maybe_auto_update now

so janky though, why is this being deleted from the WP Cron schedule?

[Sean]

that will not persist, try

1. delete it first

wp cron event delete wp_maybe_auto_update

2. add like this

wp eval 'if (!wp_next_scheduled("wp_maybe_auto_update")) { wp_schedule_event(time(), "twicedaily", "wp_maybe_auto_update"); echo "Scheduled.\n"; } else { echo "Already scheduled.\n"; }'

3. verify it was added

wp cron event list --fields=hook,next_run,recurrence | grep wp_maybe_auto_update

[Danielle]

Wow. What would cause this?

[Ralph]

according to ChatGPT the most recent WP versions do this on purpose if WordPress doesn’t trust your environment for certain reasons like it detects .git files anywhere or other random things that might conflict with auto-updates

wp eval 'var_dump( wp_is_auto_update_enabled_for_type("core") );'

if this returns false it means WordPress is probably removing the wp_maybe_auto_update

[Nathan]

You can test this with a quick MU plugin:

/var/www/html/wp-content/mu-plugins/force-auto-updates.php

<?php
add_filter( 'automatic_updater_disabled', '__return_false', 100 );
add_filter( 'auto_update_core', '__return_true', 100 );
add_filter( 'wp_is_auto_update_enabled_for_type', function( $enabled, $type ) {
    if ( $type === 'core' ) {
        return true;
    }
    return $enabled;
}, 100, 2 );

then try this command again

wp eval 'var_dump( wp_is_auto_update_enabled_for_type("core") );'

if it returns bool(true) so it’s fixed (override) but if still false, here what ChatGPT says:

WordPress Core’s Internal Return Path Is Being Short-Circuited
This means the logic inside the wp_is_auto_update_enabled_for_type() function is exiting early before the filter is even run.

Looking at WordPress core source, here’s the key code:

function wp_is_auto_update_enabled_for_type( $type ) {
	if ( wp_installing() ) {
		return false;
	}

	if ( defined( 'AUTOMATIC_UPDATER_DISABLED' ) && AUTOMATIC_UPDATER_DISABLED ) {
		return false;
	}

	if ( defined( 'WP_DISABLE_FATAL_ERROR_HANDLER' ) && WP_DISABLE_FATAL_ERROR_HANDLER ) {
		return false;
	}

	// only runs the filter *after* passing the above checks
	return apply_filters( "wp_is_auto_update_enabled_for_type", $enabled, $type );
}

1. Check if wp_installing() is returning true

wp eval 'var_dump( wp_installing() );'

if false,

This officially crosses into deep bug territory — we’ve now eliminated every normal and advanced cause:

– wp_installing() is false

– WP_DISABLE_FATAL_ERROR_HANDLER is false

– AUTOMATIC_UPDATER_DISABLED is not being redefined elsewhere

– No WP_INSTALLING defined

– You’ve deleted all MU plugins

– You’ve created a manual filter override in a new MU plugin

– Still getting wp_is_auto_update_enabled_for_type(‘core’) === false

[Janet]

It seems WP 6.8 is refactoring the wp_maybe_auto_update() function so I’m wondering if this is a bug on the 6.7 branch or something…

[Edward]

wp eval 'wp_maybe_auto_update();'
PHP Warning:  unlink(/var/www/html/wp-content/temp/block-bad-queries.20250324-kURKWq.tmp): No such file or directory in /var/www/html/wp-admin/includes/file.php on line 1182
Warning: unlink(/var/www/html/wp-content/temp/block-bad-queries.20250324-kURKWq.tmp): No such file or directory in /var/www/html/wp-admin/includes/file.php on line 1182
sh: 1: /usr/sbin/sendmail: not found

when trying to run it manually via wp-cli

[Author]

Posts