Plugin updater - Optimize API Request

[logikal16]

When checking for plugin updates, the POST to api.wordpress.org 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().

wp-includes/update.php:146

[toscho]

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

[logikal16]

@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) {
  ["akismet/akismet.php"]=>
  array(11) {
    ["Name"]=>
    string(7) "Akismet"
    ["PluginURI"]=>
    string(31) "http://akismet.com/?return=true"
    ["Version"]=>
    string(5) "2.5.6"
    ["Description"]=>
    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."
    ["Author"]=>
    string(10) "Automattic"
    ["AuthorURI"]=>
    string(40) "http://automattic.com/wordpress-plugins/"
    ["TextDomain"]=>
    string(0) ""
    ["DomainPath"]=>
    string(0) ""
    ["Network"]=>
    bool(false)
    ["Title"]=>
    string(7) "Akismet"
    ["AuthorName"]=>
    string(10) "Automattic"
  }
}

[toscho]

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.

[logikal16]

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

[nacin]

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 — api.wordpress.org handles it just fine, and it is okay if this HTTP request handles a lot of data, as it is done behind the scenes.

[logikal16]

Points taken, with a few follow-ups:

1. Which fields are used by api.wordpress.org?
2. When determining the plugin, it makes sense for api.wordpress.org to use the plugin slug, since it's unique to WP.org 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.

[nacin]

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.)

[logikal16]

Thanks for the explanation.

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

[dd32]

#19775 was marked as a duplicate.

[dd32]

#19775 was marked as a duplicate.

[dd32]

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.