Alain Schlesser

This would now work with the latest `master` through the use of JSON notation added to `--meta_input`: ``` wp post update --meta_input='{"key1":"value1","key2":"value2",...}' ```

@Diego-Schmidt This seems to be a misuse of the `option patch` command. When using `option patch update`, you need to provide a `key` (the option to patch), a `key-path` (which...

At first glance, this looks like a bug in the argument parsing code. I could reproduce it by adding `< /dev/null` to it: ``` $ wp option patch update wp_user_roles...

Some more details on this bug after trying to resolve it without success yesterday... The root cause lies in `WP_CLI\Entity\Utils::has_stdin()`. Under some circumstances (due to the way the surrounding shell...

Related #194

@soderlind I already experimented with a similar approach, reading the mode directly, but the main issue is not detecting what type of pipe we have, but rather, whether the pipe...

@soderlind The above code for reading from STDIN would be a blocking request, though. That works fine if you can rely on STDIN content being available. But if the content...

Yes, I think this should be a supported use case, probably using an additional flag or two. Do you have a plan of attack for this already?

The above does not really guarantee that the target taxonomy does even apply to the CPT you've migrated the posts to. That's also something that WP-CLI can't really change, as...

I think it might make sense to skip mismatches with a warning, with a `--force` flag to just execute indiscriminately. However, that would be a BC break...