wp_update_post()未登录/命令行下无法更新cheatsheetcat分类求助

Let's break down why your cheatsheetcat taxonomy isn't updating in non-logged-in or CLI contexts, even though everything works when you're logged into the browser. Here are the most likely culprits and actionable fixes:

1. tax_input Relies on Implicit User Permissions That Fail in Non-Interactive Contexts #

The tax_input parameter in wp_update_post() ties into WordPress's user permission system. When running via CLI or incognito mode, the user context might not be properly initialized (even if you assume you're running as admin), or WordPress enforces stricter checks for non-HTTP requests.

Fix: Replace tax_input with a direct call to wp_set_object_terms()—this function is more reliable for non-interactive scripts and avoids the implicit permission hurdles tied to wp_update_post().

Modify your import script like this:

// First update attachment metadata without tax_input
$attachment = [
    'ID' => $id,
    'post_title' => $filename,
    'post_content' => $content,
    'post_excerpt' => $excerpt,
];
$post_id = wp_update_post($attachment, true);

if (!is_wp_error($post_id)) {
    // Manually set custom taxonomy terms
    $term_update_result = wp_set_object_terms(
        $post_id,
        $arTaxCheetSheet,
        'cheatsheetcat',
        false // Set to true if you want to append terms instead of replacing existing ones
    );

    if (is_wp_error($term_update_result)) {
        foreach ($term_update_result->get_error_messages() as $error) {
            echo "Taxonomy update error: $error\n";
        }
    }
} else {
    foreach ($post_id->get_error_messages() as $error) {
        echo "Post update error: $error\n";
    }
}

2. Your Taxonomy May Not Be Registered When the Script Runs #

If you're executing your script directly via PHP (not WP CLI), the init hook (where you register cheatsheetcat) might not fire before your import logic runs. WordPress doesn't automatically trigger all core hooks when you just include wp-load.php in a standalone script.

Fix: Ensure the taxonomy is registered before your import code runs:

require_once('wp-load.php');

// Either trigger the init hook to load all registered taxonomies/post types
do_action('init');

// OR manually call your taxonomy registration function if you know it's safe
pios_add_cheatsheet_taxonomy();

// Proceed with your import logic...

If using WP CLI, run your script with wp eval-file your-script.php instead of plain php your-script.php—WP CLI fully bootstraps WordPress, including all core hooks.

3. User Context Isn't Set to an Admin Account #

Even in CLI mode, WordPress might not default to an admin user (depending on how you execute the script). Without admin privileges, modifying taxonomies can fail silently or throw permissions errors.

Fix: Force the current user to your site's admin account at the start of your script:

require_once('wp-load.php');

// Replace 1 with your admin user ID (usually 1 for the first registered user)
wp_set_current_user(1);

// Proceed with taxonomy registration and import logic...

4. Verify Term Existence and Taxonomy Configuration #

While you confirmed $arTaxCheetSheet is correct, double-check that the terms actually exist in the cheatsheetcat taxonomy (not another taxonomy). Add a quick validation step:

foreach ($arTaxCheetSheet as $term_name) {
    $term = term_exists($term_name, 'cheatsheetcat');
    if (!$term) {
        echo "Warning: Term '$term_name' does not exist in cheatsheetcat\n";
    }
}

Your taxonomy registration looks correct (with public => true), but explicitly setting publicly_queryable => true in your $args array can resolve edge cases in non-interactive contexts (it inherits from public by default, but forcing it removes ambiguity).

内容的提问来源于stack exchange，提问作者Luke Pittman