WordPress.org

Make WordPress Core

Opened 2 weeks ago

Last modified 11 days ago

#50437 new enhancement

Add leniency to the overdue check for plugin and theme auto updates

Reported by: johnbillion Owned by:
Milestone: 5.5 Priority: normal
Severity: normal Version: trunk
Component: Security Keywords: needs-patch
Focuses: Cc:

Description

The Automatic Updates column on the Plugins listing screen shows a message if a pending update for a plugin is overdue. There should be some time leniency before the message gets shown, to avoid a false positive if the cron event simply hasn't fired yet.

For example, I loaded my Plugins screen and was shown a message saying that an update was overdue by 1 second. Let's add leniency to this message so it doesn't show up within, for example, one minute of the scheduled update time.

I'm not sure if this same message is shown for themes, I've not tested it yet.

Attachments (1)

Screenshot 2020-06-20 at 11.01.16.png (22.5 KB) - added by johnbillion 2 weeks ago.
Screenshot

Download all attachments as: .zip

Change History (7)

#1 @johnbillion
2 weeks ago

  • Summary changed from Add more leniency to the overdue check for plugin and theme auto updates to Add leniency to the overdue check for plugin and theme auto updates

#2 @pbiron
2 weeks ago

That's a good idea.

We can add a filter, with something like 30 seconds or 1 min as the default. I'll do a patch later today/tomorrow.

#3 @peterwilsoncc
2 weeks ago

The site health component uses the following for considering cron jobs late and missed:

Default:

  • late: 0 seconds
  • missed: 5 minutes

DISABLE_WP_CRON set to true, ie for sites using a custom cron runner:

  • late: 15 minutes
  • missed: 1 hour

Consistency with late/missed considerations between the auto-updates and site health would be useful, if late is modified for these screens I think it would be useful to do the same for the site health component.

#4 @johnbillion
13 days ago

I feel like those settings are the wrong way around. If a site has DISABLE_WP_CRON and they're using a custom cron spawner, then the event timing accuracy should increase and therefore the tolerance should be lower, not higher.

#5 @peterwilsoncc
13 days ago

The discussion around timing occurred in #47223.

The theory I used at the time was that logging in to the dashboard should trigger a loopback firing any ready events, whereas using crontab the frequency isn't known. This ticket shows the timing needs some tuning.

This ticket was mentioned in Slack in #core by pbiron. View the logs.


11 days ago

Note: See TracTickets for help on using tickets.