WordPress.org

Make WordPress Core

Opened 18 months ago

Closed 7 months ago

#22205 closed enhancement (maybelater)

Plugin updater - Optimize API Request

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

Description

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

Attachments (1)

update.php.patch (648 bytes) - added by logikal16 18 months ago.

Download all attachments as: .zip

Change History (14)

logikal1618 months ago

comment:1 scribu18 months ago

  • Cc scribu added

comment:2 toscho18 months ago

  • Cc info@… added

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

comment:3 logikal1618 months 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) {
  ["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"
  }
}
Last edited 18 months ago by logikal16 (previous) (diff)

comment:4 toscho18 months 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.

comment:5 logikal1618 months ago

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

comment:6 nacin18 months 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 — 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.

comment:7 logikal1618 months ago

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.

comment:8 nacin18 months 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.)

comment:9 logikal1618 months ago

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?

comment:10 dd3218 months ago

#19775 was marked as a duplicate.

comment:11 dd3218 months ago

#19775 was marked as a duplicate.

comment:12 SergeyBiryukov17 months ago

  • Version changed from trunk to 3.4

comment:13 dd327 months 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.