Make WordPress Core

Opened 12 years ago

Closed 11 years ago

#22205 closed enhancement (maybelater)

Plugin updater - Optimize API Request

Reported by: logikal16's profile logikal16 Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.4
Component: Upgrade/Install Keywords: has-patch
Focuses: Cc:


When checking for plugin updates, the POST to includes ALL information about each plugin (e.g. Description, Name, Title, Author, etc). This is unnecessary.

This patch strips out non-essential data from the array returned by get_plugins().


Attachments (1)

update.php.patch (648 bytes) - added by logikal16 12 years ago.

Download all attachments as: .zip

Change History (14)

#1 @scribu
12 years ago

  • Cc scribu added

#2 @toscho
12 years ago

  • Cc info@… added

Aren’t the other data used? If so that patch would increase the risk of collisions.

#3 @logikal16
12 years ago

@toscho - I can't speak for how the API itself works, but the plugin slug (parsed from the array key) and version number should only be needed.

Below is a sample of what gets returned by get_plugins():

array(1) {
  array(11) {
    string(7) "Akismet"
    string(31) ""
    string(5) "2.5.6"
    string(481) "Used by millions, Akismet is quite possibly the best way in the world to protect your blog from comment and trackback spam. It keeps your site protected from spam even while you sleep. To get started: 1) Click the "Activate" link to the left of this description, 2) Sign up for an Akismet API key, and 3) Go to your Akismet configuration page, and save your API key."
    string(10) "Automattic"
    string(40) ""
    string(0) ""
    string(0) ""
    string(7) "Akismet"
    string(10) "Automattic"
Last edited 12 years ago by logikal16 (previous) (diff)

#4 @toscho
12 years ago

The description is probably not needed, but I had collisions in the past (pseudo-update notices for the wrong plugin), and anything that helps avoiding that should be sent. At least Author and AuthorURI are good candidates.

#5 @logikal16
12 years ago

Any updates? This is a relatively small fix that could save a tremendous amount of bandwidth.

#6 @nacin
12 years ago

We use quite a bit of these fields. Description we don't use, but it is harmless. This isn't really an area where we need to optimize things — handles it just fine, and it is okay if this HTTP request handles a lot of data, as it is done behind the scenes.

#7 @logikal16
12 years ago

Points taken, with a few follow-ups:

  1. Which fields are used by
  2. When determining the plugin, it makes sense for to use the plugin slug, since it's unique to and can't be tampered with (unlike "Title" or "Name"). How does the API currently identify a plugin?
  3. For sites with dozens of plugins, the request size isn't negligible.

While this isn't urgent by any means, it's a low-hanging-fruit that would conserve resources at both ends of the API request.

#8 @nacin
12 years ago

The only stuff in comment:3 we don't currently use in any way is "Network" (true/false), TextDomain and DomainPath (both short strings), and Description.

The API uses a set of heuristics involving a number of fields (anything I didn't mention above). This is why I wouldn't want to reduce the data sent — with enough data available to us, we can continue to make it smarter in the future. (At most, the Description field is unnecessary and is probably the most bytes in a request, but that doesn't mean we can't do fuzzy matching on that, either.)

#9 @logikal16
12 years ago

Thanks for the explanation.

I'd love to help improve the API (and see how it works). Could the code be made publicly (or semi-publicly) available?

#10 @dd32
12 years ago

#19775 was marked as a duplicate.

#11 @dd32
12 years ago

#19775 was marked as a duplicate.

#12 @SergeyBiryukov
12 years ago

  • Version changed from trunk to 3.4

#13 @dd32
11 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to maybelater
  • Status changed from new to closed

Closing as maybe later for now, as stated above, most of the fields here (especially the heavy ones) are mostly used already, or are candidates for future usage.

If we change the way plugin upgrades are detected, we can loop back on this.

Note: See TracTickets for help on using tickets.