Fix wp-cli/wp-cli#1323

Behat won my patience. I couldn't get the STDERR to match Exception nor could the term be inserted during the test.
Behat make it hard to debug (obtain actual output to identify how it differs from expected string/table).
I'll let you terminate it. I hope you'll have better chance than me.

Actually my use-case is for a custom taxonomy where I was able to get it working using ID.
https://codex.wordpress.org/Function_Reference/wp_set_post_terms
I was not able to register a custom taxonomy for the tests.
Here, with the default "post_tag" taxonomy neither name nor IDs worked during behat runs.

I fixed the first failure, but the second one seems to replicate what I had initially encountered when I add support for JSON-encoded array passing. The pull request in #133 originally included --tax_input as well, but I removed it again because I couldn't make it work.

I did some more digging, and the actual problem is that the capability check for "assign_post_tags" returns false. So the user is not allowed to add a term for that taxonomy.

@johnbillion you introduced the more fine-grained capabilities for taxonomies, so I suppose you know what the expected behavior is.

Currently, the WP-CLI code to use --tax_input on post create with the post_tag taxonomy fails because the capability is not granted here: https://github.com/WordPress/WordPress/blob/4.9.8/wp-includes/post.php#L3520

Is that meant to be the case, or is this a bug in Core?

AFAICT @johnbillion does not seem subscribed to this PR

The $tax->cap->assign_terms check is performed in about twenty places in core so if there was a bug here I would expect to have seen it by now.

What's the error that's occurring here? Is that capability check definitely the part that's failing?

The capability check is failing in this context because there's no --user=<user> set. It's one of the few capability checks within wp_insert_post(): https://core.trac.wordpress.org/ticket/19373

As a workaround, WP-CLI could filter the capability check on the fly. Or, we could simply document that wp post (create|update) requires --user=<user> when setting --tax_input=<terms>

Thanks for the link to that ticket, @danielbachhuber, that helps a lot!

@johnbillion I still consider this a bug. This is the current behavior I observe:

• 'category' & 'tags_input' work for the built-in taxonomies (category & post_tag);
• the supposedly general-purpose 'tax_input' works for custom taxonomies, but not for the built-in taxonomies.

Why would the general-purpose syntax only work for non-built-ins and break for 'category' and 'post_tag'? I can't think of a technical reason for such a limitation...

Additional note:
One more indicator that this would be a bug is that there is a check to see if people are doing_it_wrong, but that is not triggered in this case:

			if ( ! $taxonomy_obj ) {
				/* translators: %s: taxonomy name */
				_doing_it_wrong( __FUNCTION__, sprintf( __( 'Invalid taxonomy: %s.' ), $taxonomy ), '4.4.0' );
				continue;
			}

I still consider this a bug.

Worth noting before we invest too much time trying to change core: "bugs" in 7+ year old code generally aren't fixed because of the costs of unknown, unintended consequences generally outweigh the benefits. You'll find some number of workarounds in WP-CLI "correcting" WordPress' behavior.

@danielbachhuber Yes, I completely agree. I just want to make sure it is properly flagged as a bug in Trac if that's the case. We'll need to find a workaround nevertheless, though.

Proceeding with wp-cli/wp-cli#5594 for this repository. I've captured this PR to https://gist.github.com/danielbachhuber/9299d3d83d7947472df3545fe87b821b in case this PR is auto-closed or broken in some way.

I gave it a quick look but it sounds that the merge conflicts more than what my mind is able to remember regarding this PR. Sorry.

@drzraf I Tested splaying the diff to to latests main - it's applying cleanly https://github.com/wp-cli/entity-command/compare/main...wojsmol:entity-command:wp-cli-entity-command-207?expand=1 - try change base branch for this PR as a first step.