Needs functional tests, regardless of the implementation.

See flags.feature for some examples.

This is good to go. We're already loading all of the admin utilities at the bottom of wp-cli.php, so I think simply defining WP_ADMIN is all we need.

We're already loading all of the admin utilities at the bottom of wp-cli.php

In that case, why not just always set WP_ADMIN to true? We could skip Utils\set_wp_query() then.

What I mean is that the default context should be 'admin', since when you're using WP-CLI, you're not displaying a template; you're performing administrative actions.

And since I don't want to think about other contexts right now, we don't need the --context flag at all, for the time being.

The $wp_query global handling was introduced way back in 8924c97 along with --url in #69.

In hindsight, I didn't end up using --url for functional testing. The WordPress test suite already has a handy go_to() method for that.

In that case, why not just always set WP_ADMIN to true?

This is why commit messages should explain why, not just what: 5b6efb9

I don't have a strong opinion against always defining WP_ADMIN as true, other than WP_Query behavior changes in a substantial way.

This is why commit messages should explain why, not just what: 5b6efb9

That code was added in #164 and then removed as part of #352, but yeah, being part of a pull request isn't a good excuse.

And that brought up #351, which was similar to my idea of using WP-CLI for unit testing, but I think this bit is spot on:

I know that a lot more would need to be built out to actually allow WP_CLI to mock up a front end page load, use the template loader, and so on

So, no --context=frontend for now.

In summary:

WP-CLI has always loaded most of the code for wp-admin because most commands need it.

Then, it sort of pretended it was also loading the front-end, for doing integration testing. (#69)

Then it pretended it was loading wp-admin, to side-step caching plugins. (#164)

Then it stopped pretending it was loading wp-admin, because we found a better way to side-step caching plugins. (#352)

TODO:

• treat WP-CLI as an alternative UI to wp-admin
• stop pretending to do a front-end page load

Ok, this sounds reasonable to me. I'll let you take the lead on resolving how it should be done. Let me know if I can help in any way.

Going to continue working on this PR, since it has all the background now.

Took a look through wp-admin/admin.php (the file that gets loaded by all admin screens) and the only relevant bits I found were these:

• defining WP_ADMIN, WP_USER_ADMIN and WP_NETWORK_ADMIN
• load wp-load.php
• load wp-admin/includes/admin.php
• do_action('admin_init');
• do_action('admin_action_' . $_REQUEST['action']);

All the rest are related to specific admin screens.