[dhrupo]

Fixes #691

wp post term remove prints Success even when nothing was removed:

$ wp post term add 1 post_tag apple
$ wp term create post_tag banana
$ wp post term remove 1 post_tag banana
Success: Removed term.

banana is not assigned to post 1. wp_remove_object_terms() returns false when it deletes no relationship, and WP_Error only for an invalid taxonomy or a failed term lookup. remove() only checks is_wp_error(), so false falls through to the success message.

remove() now treats false like a WP_Error and exits with the existing Error: Failed to remove term. (or terms). I chose an error over a warning to match the closest sibling: wp post meta delete <id> <key> on a key that is not set also ends with Error: Failed to delete custom field., and the other failure paths in CommandWithTerms all use WP_CLI::error(). Removing several terms where at least one is assigned still succeeds, because core returns true then. --all is unchanged. The change also covers wp user term remove, which shares CommandWithTerms.

Testing

Adds a scenario to features/post-term.feature, after "Add terms by term id". It assigns one tag to a post, creates a second tag that is not assigned, removes the second one and checks for the error, exit code 1 and an empty STDOUT, then checks the first tag is still attached.

• Without the fix, the scenario fails because wp post term remove 1 post_tag banana prints Success: Removed term. with exit status 0 (WordPress 7.1.4, MySQL 8.4).
• With the fix, features/post-term.feature (7 scenarios, including the existing remove steps) and features/user-term.feature (3 scenarios) pass on WordPress 7.1.4, MySQL 8.4.
• PHPCS passes on src/WP_CLI/CommandWithTerms.php. The linter and Gherkin lint pass.

AI assistance: I used Claude Code to find this and write the change; I reviewed and ran everything myself.

Summary by CodeRabbit

• Bug Fixes
  • Failed attempts to remove a taxonomy term that is not assigned to a post now return an error instead of appearing successful. The post’s existing term assignments remain unchanged.

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

The term removal command now reports an error when wp_remove_object_terms() returns false. A feature scenario checks the error response and confirms that the post’s assigned term remains listed.

Changes: Term removal failure handling

Layer / File(s)	Summary
Handle and verify unsuccessful removal src/WP_CLI/CommandWithTerms.php, features/post-term.feature	remove() now treats a false return as a failure. The scenario checks the error, exit code, empty STDOUT, and that only apple remains assigned to the post.

Estimated code review effort: 2 (Simple) | ~8 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested labels: bug, scope:testing
Suggested reviewers: schlessera

Merge Risk: Minimal · up to b4e84

Unassigned terms now produce an error, while --all remains unchanged. No merge-blocking risk was identified.

Pre-merge checks: 5

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly describes the change to report a failure when a post term is not removed.
Linked Issues check		[ #691 ] CommandWithTerms::remove() now reports an error when wp_remove_object_terms() returns false. The added post-term scenario checks the error, exit code 1, empty STDOUT, and preservation of …
Out of Scope Changes check		[ #691 ] The shared removal fix and post-term regression test address the linked issue. No unrelated changes are identified in the whole-PR summary.
Docstring Coverage		Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentat…

Full details: Linked Issues check

Explanation

[ #691 ] CommandWithTerms::remove() now reports an error when wp_remove_object_terms() returns false. The added post-term scenario checks the error, exit code 1, empty STDOUT, and preservation of the assigned term. The shared implementation also applies to user terms.

Full details: Docstring Coverage

Explanation

Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 1 functions across 1 files. (1 skipped: 1 unsupported.)

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

• X
• Mastodon
• Reddit
• LinkedIn

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: aeeb3b5a-0cc9-40fe-b2f0-4a276e3892fe

Commits

Reviewing files that changed from the base of the PR and between 47ff5a1 and b4e84e9.

Files selected for processing: 2

• features/post-term.feature
• src/WP_CLI/CommandWithTerms.php

Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 0 remain after this review.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!