fix: query for CAP terms

[dkoo]

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:

Co-Authors Plus author terms for WP users match the WP user's user_login at the time of the WP user's creation. The user_login can't be updated in WP once the user is created, so it assumes that these values will always match. But in production environments, we've seen cases where this is not the case: specifically, the user_login and user_email differ, but the CAP term name matches the user_email instead of the `user_login. This seems to be possible only through direct DB manipulation, so I suspect this is happening from data migration. I haven't been able to recreate this scenario in a test site using WP admin, so the risk of it happening seems low for sites that haven't run into it, but it can be a serious issue with no workaround for sites that are affected.

How to test the changes in this Pull Request:

1. On release, using a test site with Co-Authors Plus active, create a new WP "author" user. Make sure the user_login is something different from the user_email.
2. Assign the user to one or more posts. This will also assign an author taxonomy term to the posts, as is standard CAP behavior. By default, the CAP term name will match the WP user's user_login, which you can verify by running wp term get author <user_login> and verifying that term exists. You can also run wp post term list author <post_id> on any of the posts assigned to the user to verify that this term is assigned to those posts.
3. Using WP CLI, change the name of the author term to the user_email: wp term update author <term_id> --name=<user_email>
4. In a page or post, add a new Homepage Posts block and set the Authors field to the WP user. Observe that the block finds 0 posts because it assumes the term's name will match the user's user_login.
5. Check out this branch and refresh. Confirm that the block now shows the posts assigned to the user in step 2, in the editor and the front-end.
6. Create another a new WP user and assign to different posts, but this time don't change anything about the term. Confirm that the user's posts still get fetched properly in the Homepage Posts block when setting the Author to this user.

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?

[laurelfulford]

This works as described -- thanks @dkoo! 🚢

[dkoo]

Update: this has been confirmed to be caused by a data migration, so the better approach would be to fix the migrated data.

[dkoo]

Reopening because we need more time to clean the data on the affected sites, and this solves the reader-facing issue in the meantime. We can potentially revert the change once the data is cleaned.

[dkoo]

Merging because it was already tested and approved!

[matticbot]

🎉 This PR is included in version 1.75.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀