Plugin Directory API integration

Projects Core Development
#1

I want to work on intgerating the Plugin Directory with CP via the API.

The first thing I have done is to try to reach out to the API from the native wp_remote_post function with a very simple example:

$request = wp_remote_post('https://directory.classicpress.net/api/plugins');
print_r($request);

And I am getting the following error:

image
image1332Ă—503 96.4 KB

I expected that this would return the actual JSON, just like when directly accessing it via GET on the browser.

The default method of the HTTP Class is GET, so I don’t know what is causing the communication issue. Any hints?

Does anyone want to work on ClassicPress v2 (with breaking changes)?
#2

Well, actually passing the $args array with method GET makes it work:

$request = wp_remote_post('https://directory.classicpress.net/api/plugins', array('method' => 'GET'));

I wonder what goes on, since as far as I know the request method is GET by default. Anyway, will keep this topic open to keep track of Plugin Directory integration issues.

#3

So yeah, integrating the API itself is not a complex task, but I have a question here. Would it not be better to make the API return data in a way that is as close as possible to how WP is currently doing it?

I mean, why change the returned structure and then adapt the core to that new structure?

Why not make the API return data in a way that is as close as possible (if not the same) as WP is currently doing it?

#4

@wadestriebel is the best person to answer any questions about the API. He built the directory and the API.

2 Likes
#5

Why don’t you use wp_remote_get? Then GET is indeed the default.

2 Likes
#6

_get is the right thing to use yes - as per the doc examples which should be fully functional ClassicPress Directory API | ClassicPress Documentation

Changing the api at this point is suboptimal
While nothing is yet really implemented… amongst other things there’s a request to create shields for GitHub that is already sent to the folks making those, and while they don’t seem to have started on it, it would be bad changing this at such late point

I’m also not so sure that’d be without a considerable effort to redo the directory api at this point.

However Wade is the only who can really answer that particular detail, as Viktor mentioned

1 Like
#7

Perfect :slight_smile: I just wonder why the API has been implemented in a different way than the WP one. Making it spit out the same structure would have been more straight to the point, especially because things like the following wouldn’t require any change:

class-wp-plugin-install-table.php

...

$this->items = $api->plugins;

if ( $this->orderby ) {
	uasort( $this->items, array( $this, 'order_callback' ) );
}

$this->set_pagination_args( array(
	'total_items' => $api->info['results'],
	'per_page' => $args['per_page'],
) );

if ( isset( $api->info['groups'] ) ) {
	$this->groups = $api->info['groups'];
}

...

I will anyways wait for input by @wadestriebel - Already did some tests with the current API and it shouldn’t be too much drama to get that implemented.

#8

As I’ve mentioned in other places, there is good reason to have the API the same (although a bit improved for versions) as WP, because there was a small change put into WP that is easily backported, that checks for Update URI in the plugin header. That means WP is already set to update a plugin from wherever it specifies, as long as it uses the same responses.
(This meta ticket is where they check that the header does not exist for the WP repo: #5747 (Block plugins using invalid `Update URI` headers) – Making WordPress.org)

2 Likes
#9

On the other hand, if the directory API needs to be changed, then the best time to do it is now.

It makes sense to me to make it match the WP version as closely as possible, so that the same codepath can be used.

4 Likes
#10

I think it might be good to reuse code/design when adding the CP plugin and theme directory.
If you go into the Customizer and click on Change Theme, you get a screen like below. This provides the ability to choose which repository you want on the left and the list from that repository on the right. (I never used it on a phone, so I don’t know how that looks.)
This same design could be used for the plugin page and theme page outside of the Customizer, although it might make more sense to reduce the size of the list of repositories. They could be submenu items or part of the page.

Customizer-theme-change
Customizer-theme-change1049Ă—787 114 KB

2 Likes
#11

If we have an example of the way the API is returning the data we can change it, I think we had an issue somewhere to do that but I don’t think anyone ever got around to adding an example for me to use as a reference.

Edit: Found it:

1 Like