Fix ( guest-authors-for-cli ): allow GAs for CLI context

[ronchambers]

All Submissions:

• Have you followed the Newspack Contributing guideline?
• Does your code follow the WordPress' coding standards and VIP Go coding standards?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Changes proposed in this Pull Request:

Fix / idea: Don't turn off Guest Authors for CLI. Most of the built-in CoAuthorsPlus CLI commands don't properly check to see if GAs are enabled or not. If GAs are not enabled, then many commands will throw a PHP FATAL:

PHP Fatal error: Uncaught Error: Call to a member function get_guest_author_by() on null in /wp-content/plugins/co-authors-plus/php/class-wp-cli.php:1085

Of all the CLIs, there is only 1 that checks if GAs are enabled:

https://github.com/Automattic/Co-Authors-Plus/blob/7330dc12643bd5f8dc3d177815f8b81ff5a72820/php/class-wp-cli.php#L855

Overall, it seems that the filter coauthors_guest_authors_enabled is generally ignored in CLI context, but used in WP Admin. Which seems inline with what the Newspack Plugin wants: to disable the existing GA admin page and replace with the new Newspack Contributor admin page.

As such, this PR will keep GAs enabled for CLI.

This will also help with Newspack Custom Content Migrator and Newspack Migration Tools where their CLIs have a requirement for GA in their constructor. ( Issue: Automattic/newspack-migration-tools#41 )

How to test the changes in this Pull Request:

1. Make sure Newspack and CoAuthorsPlus plugins are enabled.
2. Before pulling this branch, run a CAP CLI command such as wp co-authors-plus create-author
3. Verify PHP threw a FATAL error in debug.log.
4. Now, pull this branch and run the same command.
5. Verify that no fatal was thrown. You'll just see a warning that arguments are missing: -- Not found; creating profile. Warning: -- Failed to create guest author: display_name is a required field. That is OK. It means no fatal was thrown and the CLI command can be used properly.

Other information:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your changes, as applicable?
• Have you successfully ran tests with your changes locally?

[ronchambers]

Hey @leogermani - Any thoughts on this PR above?

[leogermani]

Hey @leogermani - Any thoughts on this PR above?

I have mixed feelings. I understand where this is coming from but I fear that enabling it to any WP_CLI command might be too broad. Having guest authors disabled changes the behavior of CAP in many places, including some queries it does. If in the future we are running CLI commands where we expect the same behavior from the "standard" site we can run into problems... I don't know, it's just a theoretical situation.

Is it not a good idea to add the check to our commands? Or to add a more targeted check in the plugin to keep it enabled?

If not, I think it's fine to do it, but if we have a more targeted solution I'd prefer it

[ronchambers]

Thanks @leogermani . We (launch team) briefly discussed this in today's morning meeting and a point was brought up that CAP allows developers the ability to use add_filter( 'coauthors_guest_authors_enabled', '__return_false' ), but when a developer actually does this, then CAP's own CLIs fail. So I changed my perspective now to look at the fatal issue as a failure within CAP itself, not Newspack Plugin. We discussed a few solutions, which I'll explore this week, but I wanted to share now with you. Most likely we'll just go around this issue completely and I'll end up closing this PR. I'll leave it here for now. Thanks!

[ronchambers]

I'm now closing this PR as "not doing".

FYI: I'm still looking into going around the CoAuthorsPlus CLI for our migrator needs, but since it was just a few lines of code, and it helped me understand the problem a little better, I pushed a PR to CAP here: Automattic/Co-Authors-Plus#1090