Plugin Directory API integration

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

2 Likes

_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

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.

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

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

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.

2 Likes

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

I wanted to follow up on directory integration because that’s one of the main things that can help people start using CP, especially ensuring plugins can easily update.

I spoke with @wadestriebel about the directory API and he said he can work on modifying data returned to match what CP expects.

@alvarofranz are you still interested in working on this?

1 Like

Sure :slight_smile:

1 Like

What’s the current state on this? As soon as it’s ready I will work on the integration.

(No rush, just wondering!)

Give Wade a bit of time. He’s away dealing with a personal matter this week. But he did confirm he’ll work on it last week, when I asked.

1 Like

So who’s responsible for reviewing plugins these days? I submitted one earlier this week and have heard nothing so far.

As you can see in this topic it’s six months I’m waiting for a review…

As for the plugin review process, all your plugins have been reviewed by now and you should have emails in the respective inboxes with some details.
Let’s keep the communication in said email.

The case of “plugins are not being reviewed” can be considered closed.

3 Likes

Does the API integration include anything to do with language packs?

Prior to WP 4.7, plugins had to call load_plugin_textdomain.

Since WP 4.7, the WP repo is integrated with GlotPress and plugins don’t have to do anything to load translations, although they can still bundle language files and load them.

I’m just wondering how that should work in CP.

The API integration isn’t affected by that change. They made that be an optional step for plugins that are already installed and active on the site. But it doesn’t affect the plugin directory.

Just a thought. I am a minimalist. That said, why not have a Directory inside of CP core admin panel which replaces the plugins’ API altogether. Simpler and hardly ANY code. Maybe try integrating @alvarofranz JSON idea into this.

  • Plugins menu item directs to plugin page.
  • On page would be a LIST of plugins that are available (just a list with Name Descrptn’ Link)
  • Description is less than x words and link is shorten so all info is in ONE line.

Plugins for ClassicPress

Name ----- Description ----- view/download ---- version
Rev Cleaner | Removes old revisions from… | friendly-link-github-maybe | 1.2.21

No popups to show off and promote/cross-promote. Nothing but the minimal amount of info needed. This will also lead to Plugin Author’s to work harder on their presentation page (link to plugin download). This is TRUE Open Source as it takes load off of (us/CP) and puts said load on author.

1 Like

DM me your Github username and I can get you access if you are interested in helping develop it.

1 Like

https://forums.classicpress.net/t/re-plugin-review-team/4088/5?u=tradesouthwest

@anon66243189 has a pretty good solution, or at least a very good start on it anyways.

2 Likes

That page is private.
But yes. He has a solution.

1 Like