Make WordPress Core

Opened 16 years ago

Closed 15 years ago

#8660 closed defect (bug) (fixed)

plugin/theme update check fixes

Reported by: dd32's profile DD32 Owned by:
Milestone: 2.8 Priority: normal
Severity: normal Version: 2.7
Component: Upgrade/Install Keywords: has-patch
Focuses: Cc:

Description

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.

Attachments (2)

8660.diff (4.7 KB) - added by DD32 16 years ago.
8660.2.diff (1.5 KB) - added by DD32 16 years ago.
Adds blog url back into user agent for update-requests.

Download all attachments as: .zip

Change History (17)

@DD32
16 years ago

#1 @ryan
16 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

#2 @ryan
16 years ago

  • Milestone changed from 2.8 to 2.7.1
  • Resolution fixed deleted
  • Status changed from closed to reopened

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

#3 @jacobsantos
16 years ago

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.

#4 @ryan
16 years ago

I wish trac could resolve against multiple milestones.

#5 @DD32
16 years ago

  • Milestone changed from 2.7.1 to 2.8
  • Resolution set to fixed
  • Status changed from reopened to closed

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

#6 @johnbillion
16 years ago

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

#7 @DD32
16 years ago

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.

#8 @johnbillion
16 years ago

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

#9 @DD32
16 years ago

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.

#10 @andy
16 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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
16 years ago

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

#11 @DD32
16 years ago

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.

#12 follow-up: @jacobsantos
16 years ago

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?

#13 in reply to: ↑ 12 @westi
16 years ago

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.

#14 @westi
16 years ago

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

#15 @DD32
15 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.