Making author taxonomy terms available in WP REST API

[douglas-johnson]

I'd like to make an issue out of this since there is an existing pull request and another related issue but the PR stalled out after this comment about keeping the author emails out of the API response.

Goal

It seems like to goal of #899 and #881 are to make co-authors available in the block editor.

I don't know if you can make it work in the Lastest Posts block in its current version, but it seems like a custom block could fetch author taxonomy terms based on the post context if it were included in the Post Template inside a Query Loop block. To do that, we would need access to the author taxonomy through the API.

Method

If we agree on that goal, does one of these methods for "not including the email address in the API response" work best? Or is there a better way? I'm happy to work on a PR if we have consensus about the approach.

• Stop putting the email in the term description
  • Pro: Smallest amount code
  • Con: Not retroactive. Would this break searching for authors by email when assigning authors to posts?
• Use filter on rest_prepare_author to change the description to an empty string.
  • Pro: Medium amount of code
  • Con: What if we need the description for something?
• Use filter on rest_prepare_author to change the description to an empty string for users without the edit_posts capability; then add that capability as a configurable filter in CAP similar to the coauthors_guest_author_manage_cap filter.
  • Pro: Most customizable
  • Con: Largest amount of code

[sbcatania]

Hi @douglas-johnson, Sam here from #851 and #899. Our only goal is to ensure that we can access author names/IDs via the public API. We need this to make our mobile app and other projects work. If this accomplishes that and makes the author name and ID available via the site's public API, then this works for us. Basically, we just want it so that any properties you could get on a normal author via the API you could also get for a co-author.

[sbcatania]

I'll also mention that we recently updated #899 with a very simple approach that should solve our issue; let me know if that also accomplishes the goal here. We didn't make that PR until recently, let me know if that solves this.

[douglas-johnson]

@sbcatania Great to hear from you about this!

Regarding your use case, either this pull request or your own #899 would once again make the author taxonomy available through the public API as the endpoint /wp/v2/coauthors. The id and name returned by that endpoint would be specific to the author taxonomy. It wouldn't include any info about the guest-author post type. Just pointing that out to make sure we're talking about the same type of id.

Regarding your fix for the email addresses in #899 — you've removed the email address from the /coauthors/v1/ endpoints rather than /wp/v2/coauthors. The emails in /coauthors/v1/ were already properly hidden behind authorization, and could be kept.

[sbcatania]

Hi @douglas-johnson, thanks for the clarity! We don't need guest authors, just secondary authors (all authors on posts with multiple) which the API currently does not return. So I think we're talking about the same thing?

As for the second one, how can we fix that? Thanks for your help! Let me know if you think it makes more sense to consolidate around your PR or use ours.

[douglas-johnson]

@sbcatania

As for the second one, how can we fix that?

I described three ways in this issue, and picked the third option for my PR.

Thanks for your help! Let me know if you think it makes more sense to consolidate around your PR or use ours.

Well, selfishly, I like my PR. I'm confident it works to display the author taxonomy terms and keep the emails hidden behind user capabilities.

[sbcatania]

Ok, if you think your PR fulfills all of our requirements, I'm happy to close mine out and redirect everyone to #931. Let me know if you know of any ways we could improve the speed this gets looked at/merged.