WordPress.org

Make WordPress Core

Opened 8 years ago

Closed 4 years ago

Last modified 4 years ago

#20002 closed feature request (duplicate)

Update plugins_api to accept multiple slugs when querying 'plugin_information'

Reported by: DJPaul Owned by: nacin
Milestone: Priority: normal
Severity: normal Version: 2.7
Component: WordPress.org site Keywords:
Focuses: performance Cc:

Description

When querying plugins_api() with 'plugin_information', the second argument takes a parameter 'slug' on which to find the plugin. Please may the API be updated to optionally accept an array of slugs, so that you can query for multiple plugins in the same HTTP request?

Change History (22)

#1 @SergeyBiryukov
8 years ago

  • Milestone changed from Awaiting Review to WordPress.org

#2 @willmot
7 years ago

  • Cc tom@… added

#3 @willmot
7 years ago

Any chance the code for the plugin API could be open sourced so that people can submit patches for things like this?

The API for browse happy has been open sourced, http://code.svn.wordpress.org

#4 follow-up: @Otto42
6 years ago

  • Milestone WordPress.org deleted
  • Resolution set to wontfix
  • Status changed from new to closed

There's no core reason to do this at the moment, and the API calls are intended for core use only.

At some future point, we may make an API that is public and thus designed for public consumption instead of being heavily fixated on how core works, and then would be a perfect time to implement something like this. But not yet.

#5 in reply to: ↑ 4 ; follow-up: @johnbillion
6 years ago

Replying to Otto42:

There's no core reason to do this at the moment, and the API calls are intended for core use only.

Actually core would benefit from this on the Updates screen. When there are multiple plugin updates available, the 'plugin_information' API call is performed for each plugin individually.

#6 in reply to: ↑ 5 @nacin
6 years ago

  • Milestone set to WordPress.org
  • Resolution wontfix deleted
  • Status changed from closed to reopened

Replying to johnbillion:

Actually core would benefit from this on the Updates screen. When there are multiple plugin updates available, the 'plugin_information' API call is performed for each plugin individually.

I have no words. Let's fix this.

#7 @nacin
6 years ago

  • Owner set to nacin
  • Status changed from reopened to accepted

#8 @samuelsidler
6 years ago

  • Milestone changed from WordPress.org to 3.7

#9 @nacin
6 years ago

  • Milestone changed from 3.7 to Future Release

#10 @johnbillion
6 years ago

#21763 was marked as a duplicate.

#11 @johnbillion
5 years ago

  • Focuses performance added
  • Type changed from enhancement to feature request
  • Version set to 2.7

Any chance of someone on the api.wordpress.org team tackling this for 4.0? It would speed up the Updates screen considerably.

#12 @Otto42
5 years ago

I actually already have a fix for this written, but it will need a core modification to use the change.

It is backward compatible, so I'll bring it up with @nacin in a bit.

#13 @Otto42
5 years ago

Additional: The reason I initially forgot about this was because of potential load issues on .org. There needs to be some kind of limit to prevent somebody from, say, making an info request for 1000 plugins at once. A small limit.

#14 @willmot
5 years ago

Additional: The reason I initially forgot about this was because of potential load issues on .org. There needs to be some kind of limit to prevent somebody from, say, making an info request for 1000 plugins at once. A small limit.

+1

We'd love to use this on wpremote.com to bulk pull plugin information for every plugin we are tracking across the 50K odd sites we are monitoring.

This ticket was mentioned in IRC in #wordpress-dev by helen. View the logs.


5 years ago

#16 @toddlahman
5 years ago

Will this make it into WordPress 4.0?

This ticket was mentioned in IRC in #wordpress-dev by ocean90. View the logs.


5 years ago

#18 @johnbillion
5 years ago

Otto42: Is this something the API team could look at for 4.1?

This ticket was mentioned in Slack in #core by sergeybiryukov. View the logs.


5 years ago

#20 @chriscct7
4 years ago

  • Milestone Future Release deleted
  • Resolution set to invalid
  • Status changed from accepted to closed

#21 @SergeyBiryukov
4 years ago

  • Resolution changed from invalid to duplicate
Note: See TracTickets for help on using tickets.