Bulk updates across websites

The Updates page collects pending core, plugin, and theme updates from every connected website and groups them by item. Items with a known vulnerability come first, by severity, followed by the ones waiting on the most websites. For each item you see which websites have it, which version it moves from and to, and whether any website can’t update it yet.

Websites that aren’t ready for updates have their own list with the reason. A version that has already failed verification on some website stays flagged for 60 days, so you don’t start it again blindly.

Before anything starts, digiWatcher shows a confirmation dialog listing the websites and versions. Then every website goes through the same steps:

1. Prepare. digiWatcher checks the site from outside: uptime, home page content, and the agent’s response. It won’t update a site that is already broken.
2. Update. For a plugin or theme the agent first sets the original files aside. WordPress itself then runs the update, just like the Update button in the admin area.
3. Verify. After a short pause digiWatcher checks the site again and compares it with the state before the update: whether it’s up, whether the home page returns an error, is nearly empty, or shows new error messages, and whether the agent still responds. A maintenance page is tolerated for 12 minutes at most.
4. Confirm or roll back. If the site is fine, the set-aside files are deleted. If it got worse, digiWatcher puts the original files back.

Websites in a batch get the same update one after another. If it ran on all of them at once, every site would get a broken version before the first one could report that it failed.

If a version fails verification on one website, the remaining websites in the batch don’t get it. The job shows which website it failed on. If the package merely couldn’t be downloaded or unpacked, that says nothing about the version, and the batch carries on.

In case a new plugin version takes the whole site down with a fatal error, the agent has a safety brake: a small must-use plugin that WordPress loads before anything else and that can restore the original files even on a crashed site. If even that rollback fails, the job ends in a state that needs your attention, the website is blocked from further updates, and your alert contacts get an alert.

A rollback restores files, not the database. If the new plugin version migrated data during the update, that change stays. WordPress core has no restore point; there WordPress restores its own files after a failed update, and the confirmation dialog warns you about it.

For each website you can turn on a rule and pick the hour it runs. The options are Security fixes only, Patch versions, or Fixes and new features. A major version never goes through on its own, and neither does a version that has already failed verification. An automatic update goes through the same steps as a manual one.

Updates run on behalf of the person who turned the rule on. If that person loses the permission, the rule starts nothing and digiWatcher tells you to turn it on again.

• The digiWatcher Agent plugin is connected on the site and up to date. The agent updates itself unless the site has that turned off.
• A plan that includes the WordPress agent; the pricing page shows which ones do.
• Updates are enabled both in digiWatcher and in WordPress. Write access stays off until the site’s administrator turns it on in the plugin settings or with a connection code.
• WordPress on that hosting can write files directly, without FTP details.
• The site doesn’t run as a WordPress multisite network.
• The Owner starts bulk updates. Operators see pending updates but don’t start them.
• The safety brake needs a writable mu-plugins folder. Without it, updates still work, but digiWatcher warns you up front that a rollback after a fatal error won’t be possible.

The app shows which requirement each website meets. Step-by-step instructions are in the manual chapter Updates and care.

• The agent never installs new plugins, doesn’t upload ZIP files, and doesn’t edit files. It can only update what is already on the site.
• It only updates to the version WordPress’s own update source offers. If WordPress doesn’t offer a new version of a plugin, digiWatcher doesn’t update it.
• It doesn’t undo database changes and has no restore point for WordPress core.
• It doesn’t work on a multisite network or on hosting where WordPress needs FTP details to write files.

Why the agent has such narrow permissions is explained on the safe WordPress agent page. For the bigger picture, see managing many WordPress sites.