Plugins API

[obenland]

• Continue supporting everything it currently supports
• (Create a comprehensive list of what it currently supports).

[obenland]

• Write (client-side) Core Unit Tests alongside of it.

Split out in #1614.

[dd32]

Just noting it here, since it'll trip someone up.

The Author field in the Plugins API response, is not a committer, contributor, or even the post author. It's the Author and Author URI headers directly from the plugin headers.

[dd32]

See also: [3020] [3021] [3022]

In [3020]:
Plugin Directory: Add a REST API endpoint which represents the full plugin data currently exposed through api.wordpress.org.
Although it's unlikely api.wordpress.org will run the API directly, this is a test to verify that all data we have on file is available.

See #1576

[swissspidy]

As discussed in the Shiny Updates weekly meeting, it would be great if the plugin updates API would include the plugin icons for use on the update screens.

See ​https://github.com/obenland/shiny-updates/issues/5 for some mockups on how the plugin icons would be used.

[dd32]

Replying to swissspidy:

As discussed in the Shiny Updates weekly meeting, it would be great if the plugin updates API would include the plugin icons for use on the update screens.

See ​https://github.com/obenland/shiny-updates/issues/5 for some mockups on how the plugin icons would be used.

Feel free to file a meta ticket for that. The update response API needs to be modernised and have those features added for sure, but for now/in this ticket we're only focusing on migrating from the existing bbPress powered API to a WordPress backend.

[swissspidy]

Thanks! Just opened #1714.

[dd32]

We need

• A stand alone PHP script which reads the WordPress postmeta table to perform updates
• (ideally) A stand alone PHP script which can handle the plugin_information requests & /hello-dolly.json requests. I'd probably suggest we should just cache a full response from the REST API (/wp-json/plugins/v1/plugin/hello-dolly/) and handle the fields and conditional wp_version checks, as well as the output format (PHP serialized, XML, and JSON) in that handler
• A REST API Endpoint which can be used for the hot_tags endpoint
• A REST API Endpoint which can be used for the query_plugins endpoints, this mostly wraps WP_Query but has a lot of random and weird logic burried in it

Loading WordPress for all these requests isn't going to be viable, but for some we'll have little choice.

• The update handler should most definitely not load WordPress at all.
• The hot_tags handler could just cache the result of the WordPress endpoint, so it doesn't require loading WordPress often.
• The plugin_information handler would be a good one to cache, and not hit WordPress on, as it's requested often enough and accounts for a significant amount of the api traffic.
• The plugin_information handler via hello-dolly.json should be made cacheable, that means it should only use the data contained within the URL for the response, fetching the WordPress version from the user_agent isn't viable

[dd32]

In 3228:

Plugin Directory: Update a missed taxonomy name and correct a typo.

See #1579, #1573

[dd32]

In 3289:

Plugin Directory: First swipe at handlers for api.wordpress.org/plugins/info/*.
The API handlers are designed to be stand-alone scripts which run only with an object cache for caching, When cached data is unavailable, WordPress is included to fetch the data from a rest api endpoint.

See #1579

[dd32]

In 3368:

Plugin Directory: api.wordpress.org handlers: Fix a classname typo in r3289

See #1579

[obenland]

In 3439:

Plugin Directory: Consolidate review queries.

See #1719, #1579.

[obenland]

In 3440:

Plugin Directory: Revert [3439] until we have caching figured out.

See #1719, #1579.

[tellyworth]

attachment:1579-fix-plugin-object-type.diff​ fixes two issues in the PHP API:

1. PHP Warning: Invalid argument supplied for foreach() when the $contribs array is null.

2. A regression: in the old API, query_plugins returns an array of plugin objects. In the new one, they were assoc arrays - this casts them to objects.

[dd32]

In 3805:

Plugin Directory: Fix the return types for the PHP API to be compatible with the previous return behaviour.

Props tellyworth.
See #1579.

[obenland]

In 3863:

Plugin Directory: Use Reviews output instead of rolling our own.

Returns two reviews with the proper markup. We should review what we want the
final output to be here.

Also passes the section slug as a second parameter to the_content filter
for more context, similarly to the Plugin Directory theme..

See #1579, #1719.

[obenland]

In 3864:

Plugin Directory: Add support information to API response.

Allows us toe rebuild the support loading bar in React.

See #1579, #1719.

[obenland]

In 3888:

Plugin Directory: Add screenshots to API response.

Allows us to build the screenshots section in JS.

See #1828, #1579.

[tellyworth]

Closing this, replaced by #2112.

[dd32]

In 4310:

Plugin Directory: Revert [3863] as the Reviews markup in the API is intentionally different from the markup used on WordPress.org.

This fixes review display when WordPress is using the new API.

See #1579, #1719.

[dd32]

In 4311:

Plugin Directory: Pull reviews from bbPress2 rather than the old bbPress1 support forums.

See #1579

[samuelsidler]

Milestone Plugin Directory v3 - M7 deleted