Skip to content

Update WordPress core

Updating WordPress itself is not the same shape of job as updating a plugin. A plugin can be swapped back in seconds. WordPress cannot, and its way back is the full archive the site built before the update.

That archive comes from the daily copy to Google Drive. Once a Drive is connected, ReDock asks each connected site every day to build a full archive of its files and its database and copies it into your own Drive, and the site keeps a record of when it last finished one. The rule below reads that record. Back up every site to Google Drive explains the copies.

So the rule is blunt: ReDock will not update WordPress on a site whose last full backup is more than 24 hours old. That site is refused, and the refusal is a line on the job rather than a failure of it.

  1. On Jobs, choose the WordPress update action and tick the sites.

  2. Read the confirm page. It names every site, says which of them have an archive fresh enough, and lists by name the ones that will be refused.

    A confirm page headed Update WordPress on 3 sites. It names the three sites, says 2 of 3 finished a full backup in the last day and will be updated, and lists under Will be refused one site whose last full backup was 3 days ago. A highlighted paragraph says this replaces WordPress itself on every site named, that ReDock looks at the home page and up to four more pages the way a visitor would before and after, and that it does not put a site back.

  3. Press Queue the WordPress updates. ReDock works through the sites one at a time, in the background. You can watch it and stop what has not started yet.

Each site goes through check before, the update, check after and a verdict, and the job shows what a visitor would have seen on either side of it.

The What a visitor saw panel of a WordPress update job. One site is Done and one page answers exactly as it did before. One is Failed: the home page answered 500 after the update and 200 before, and the row names the archive the site finished that morning as the way back. One is Stopped, because its last full backup is more than 24 hours old.

The tables under each site show the page, what it answered before, and what it answered after, so “it broke” is a reading rather than a feeling.

There is no unattended restore for a core update, on one site or across many.

If a site breaks, the job says so, names the archive to restore from, and emails the workspace owners. Putting the site back is then somebody’s decision, made with the archive in front of them.

A page ReDock could not reach is never counted as broken.

Run again on the sites that did not finish queues a fresh job for those alone, which is what you want once the site that was refused has a fresh archive. With Google Drive connected, the next daily copy makes one. If that copy fails, the Google Drive section of Settings says why, under the site’s row.

The top of a finished WordPress update job. Two of three sites finished, one did not, and the panel says one site had no full backup from the last day so WordPress was not replaced on it. A button offers to run again on the one site that did not finish.


Open Jobs in ReDock Web.