Taxonomies in cron jobs cause problems

[blatan]

The problem is similiar to this one: #19373

I had figured out the workaround for my issue before I found the above ticket.

I created an import data from an external database. It can be called by admin manually or in daily cron jobs.
In the cron job I have to check if a taxonomy exists in my DB, so I get it with

get_term_by('slug', ... );

If user calls it everything worked fine, but in cron job didn't. I noticed the problem is in get_term_by -> taxonomy_exists.

Taxonomy_exists checks if the given taxonomy is in global $wp_taxonomies array.

I tried to use set_current_user in beginning of the cron job, but it does not work. It seems to $wp_taxonomies is set before the job.

I searched if there a hook like 'before_cron_job', but I haven't found any.

My workaround is quite silly but it works. In the beginning of my cron job callback I call:

function updateTaxonomiesForCron() {
    global $wp_taxonomies;
    if ( defined('DOING_CRON') ){
	$wp_taxonomies['region'] = [];
    }
}

I can see the problem with current_user_can for taxonomies is quite old and probably my ticket will be set as duplicated but I just want to show my case of the issue.

Best regards
Bernard

[ocean90]

Hello @blatan, thanks for your report.

This doesn't sound like #19373. Are you sure that you register your taxonomy correctly? Can you provide some code and steps to reproduce this issue? Thanks!

[blatan]

Wwe register taxonomies with this function:

public function init()
    {
        register_taxonomy($this->taxonomy_key, $this->object_type, $this->getArgs());
        if (count($this->default_terms)) {
            foreach ($this->default_terms as $term) {
                wp_insert_term($term, $this->taxonomy_key);
            }
        }
    }

To reproduce the problem:

function abp_daily_callback() {
		update_option('abp_daily_callback', date('Y-m-d H:i'));

		MyImporter::importTermsFromExternalDb();
	}

// in MyImporter class
public static function importTerms() {
    // get $termSlug and $taxonomyName from external DB to check if it exists in my DB
    $term = get_term_by('slug', $termSlug, $taxonomyName, ARRAY_A);
    // $term returned from get_term_by is set to invalid because taxonomy_exists returns false
}

[ocean90]

@blatan Where and when is the init() method called?

[blatan]

add_action('init', array($this, 'register_taxonomies'));

function register_taxonomies() {
		TaxonomyLoader::loadTaxonomies();
	}

array and $this added because we've got twig in the project

[jrfoell]

This is actually an issue if using the "Alternative Cron"

define( 'ALTERNATE_WP_CRON', true );

I attached an example plugin to show a use case. You'll have to set the define in wp-config.php to see it in action. Changing the taxonomy registration init hook to priority 9 will alleviate this problem, but it would be better to instead change the alternate cron to use a much higher init priority so any start-up code has a chance to execute.

[jrfoell]

example plugin to illustrate issue.

[blatan]

Thanks for the reply, but it was 5 months ago and honestly speaking I completly forgot about. The workaround which I figured out still works.

I don't know if I can help. Tell me please if you want me to do something.

Happy New Year :-)

[jrfoell]

@blatan what was your workaround? Curious to know if we're addressing the same issue from two different angles.

[dd32]

Hey @jrfoell

Thanks for your demo plugin, and mention of ALTERNATE_WP_CRON - It makes a lot more sense now!

wp_cron() is hooked on init at default; when ALTERNATE_WP_CRON is defined cron jobs are processed within that function.
Due to the order of action registration, if a plugin registers something on init at the default 10 it'll run after the cron has already spawned.

A temporary fix for plugin authors would be to enqueue on init at an earlier priority - such as 9 or to register them on an earlier hook such as after_setup_theme (Note: many WordPress functionalities are not available before init, such as capabilities for users, etc).

I think we should move wp_cron() to being fired on something later - wp_loaded looks like a better spot. It's after init and before template functionality. However, it's after the multisite suspended checks, so it we'd no longer be spawning cron for suspended multisites.. which is what #20537 wants anyway. (FYI @jeremyfelt)

A safer bet, would be to simply move wp_cron to running much later on init, at say priority 100.

[SergeyBiryukov]

Replying to dd32:

I think we should move wp_cron() to being fired on something later - wp_loaded looks like a better spot.

I agree. Previously moved from sanitize_comment_cookies to init in #19818.

[flixos90]

This should land early in a cycle, so let's come back in a future release.

[peterwilsoncc]

I agree with Felix, it's best this lands early in a cycle. This puts it in 5.1 at the earliest.

Along with setting the hook to run later on init when adding the filter, removing the filter will need to be modified in src/wp-includes/class-wp-customize-manager.php.

[peterwilsoncc]

#24160 raises the same issue, running cron jobs on init, 10 causes problems for sites using ALTERNATE_WP_CRON. I'll add a note to the other ticket to highlight that it is an issue for sites registering custom taxonomies and close this as a duplicate.