Expose `author_uri` in the WP.org API

[Bernhard Reiter]

Please consider adding the Author URI field from a theme's style.css to the WP.org API's theme related endpoints (query_themes and theme_information actions), either as a standalone author_uri field, or as a subfield of the author associative array that is returned when request[fields][extended_author]=1 is set.

This would help in writing clients that provide theme information gathered from the WP.org theme showcase, as e.g. the Calypso theme showcase (see ​https://github.com/Automattic/wp-calypso/pull/11089#issuecomment-281374156 for some background, and note that both the WP.com showcase and Jetpack's theme related endpoints return that field).

[Otto42]

The extended author data returns user_nicename and displayname of the owning account from WordPress.org itself, so extended_author makes no sense for this.

However, it would be relatively easy to add the author_url as a standalone field. It would be something like request[fields][author_url]=1 instead.

[dd32]

FYI the Author URI is stored, however the Author field isn't (I misread it).

In chatting with @Bernhard Reiter I don't think the Author_URI is the correct field for what they wanted to use anyway.

Here's a chunk of code that can be inserted into the API code for when we do store the Author field (I don't think it's worth exposing one without the other).

$phil->author = (object) array(
	'user_nicename'     => $author->user_nicename,
	'display_name'      => $author->display_name,
	'profile_link'      => 'https://profiles.wordpress.org/' . $author->user_nicename,
	'header_author'     => wporg_themes_get_version_meta( $theme->ID, '_author', $phil->version ),
	'header_author_uri' => wporg_themes_get_version_meta( $theme->ID, '_author_url', $phil->version ),
);

[Otto42]

Well, given that the Theme URI field is available standalone, and it exists in the same place (the style.css file), then making it available on the same level makes more sense than exposing it in the extended_author data, which is w.org data. If we wanted to provide a URL there, then it would probably be the URL associated with that user account via the support forums, not the Author URI field from style.css.

[dd32]

Replying to Otto42:

Well, given that the Theme URI field is available standalone, and it exists in the same place (the style.css file), then making it available on the same level makes more sense than exposing it in the extended_author data, which is w.org data. If we wanted to provide a URL there, then it would probably be the URL associated with that user account via the support forums, not the Author URI field from style.css.

I would strongly disagree that it matters where it came from, Author data is author data.
It makes sense that the author property is a list of data about the author of the theme - that currently means the user_nicename, and includes the Display Name when the extended_author field is present (which is not publicly documented, nor used by WordPress currently). Extending that to include things like the profile link, and theme's author header data seems sane.

I'll also note, that the calypso PR mentioned in the ticket appears to wanted to use the Author URI as the Support location for the theme - A Support link in calypso should probably be to the w.org theme forum, or at most, to the theme_uri (not author_uri).

[joyously]

I want to see a link to the theme in the repo, and a link to the author's .org profile. The API is all about the themes in the repo, so it should show the data that relates to that. The Theme URI in the stylesheet is optional, and so is the Author URI. But the repo has both a theme page and an author profile page, which would be very useful, since the profile shows what other themes the author wrote and what the WP user name is (to be able to ping them on a review or support question), and the theme page has a link to the support forum and previous versions.

[dingo_d]

Any news on this?

[dd32]

In 10722:

Theme Directory: Include the Theme Author Name & URL in the extended_author object in API responses.

Fixes #2521.