plugin/theme update check fixes

[DD32]

I just noticed that the plugins update check was being run on every request to the plugins page, Because the list of plugins that were being sent to the API server was never fully complete, if a plugin was detected that had changed in position 5 (of say 30 plugins), only the first 5 plugins were being checked for an update. (Thats the changes to the location of the break in the loops, Might be an idea to apply that to the 2.7 branch as well?)

In adition, I've streamlined a bit more of the code, It now checks every hour if the user visits the admin page for themes or plugins, or updates every 12 hours otherwise. This wont be a problem for most situations, And helps users who are visiting the plugins page since they know theres an update thats just been released.

The patch also removes header fields which are taken care of by the HTTP API, as well as using the specific _post() or _get() functions instead of the generic _request() (Which defaults to _get())

Finally, The themes update check is run on the themes & update page loads to bring it into line with the plugins update check.

[ryan]

(In [10221]) Plugin and theme udpdate check fixes. Props DD32. fixes #8660 for trunk

[ryan]

Let's try it out in 2.8 for awhile and then consider for 2.7.1.

[jacobsantos]

I think a new ticket should be created in order to keep the history of what tickets were fixed in what version instead of backdating tickets. Just my opinion. There are disadvantages doing it my way also.

[ryan]

I wish trac could resolve against multiple milestones.

[DD32]

Actually.. Looking at it, I dont think a backport will be required, I have a slight feeling my initial issue was a code modification of mine that went wrong...

[johnbillion]

-1 for part of this.

I like the fact that the act of visiting the Plugins page checks for updates on all my plugins, regardless of when it last checked. It's like an easy way of forcing an update check. Handy for when developing plugins etc.

[DD32]

It was never designed to check for plugins for every page hit to the admin, And despite my opening statement, That doesnt occur, It turned out to be some dodgy code of mine elsewhere.

This ticket has helped you in that regard, update checks now run every 1 hour on hits to the plugins page instead of every 12 hours.

[johnbillion]

I suspect then that the behaviour I'm seeing is the automatic update check that occurs if a pluign has recently changed?

[DD32]

I suspect then that the behaviour I'm seeing is the automatic update check that occurs if a pluign has recently changed?

Ah yes, If a plugins version has changed, or a unknown plugin has been added or removed, the update check will be spawned again.

[andy]

This is not acceptable as it stands in [10221]. The new HTTP connection code does not include the siteurl (or any unique id based on siteurl) in the user agent, which breaks the api's version stats aggregation. This could be changed in the new HTTP code, or only in the update checks (passing the user agent header as it was before).

[DD32]

Adds blog url back into user agent for update-requests.

[DD32]

This is not acceptable

oops, Sorry, I kind of thought the HTTP api sent the blog url.. attachment 8660.2.diff added. adds the custom user agent back into the update requests.

[jacobsantos]

Andy, WTF? are you sending the URL/URI as user-agent instead of Referer?

I know it was the original implementation, but is there a reason referer wasn't used instead?

[westi]

Replying to jacobsantos:

Andy, WTF? are you sending the URL/URI as user-agent instead of Referer?

I know it was the original implementation, but is there a reason referer wasn't used instead?

Well it isn't a referrer really.

As part of the User-Agent makes sense as it is the User Agent if you see what I mean.

[westi]

(In [10238]) Set the user-agent like we did before. See #8660