Maintaining applications

This article is for you as the administrator: how to keep the WordPress sites, Joomlas, Nextclouds and other applications on your servers up to date without visiting them one by one. How a customer updates one installation is in Installing and looking after applications and Your WordPress sites; this one is about the policy, the window, the bulk actions and what to do when something went wrong overnight.

How it fits together

An application update always happens the same way: first a restore point (files plus database), then the update, then a check of the site, and when the check fails, automatically back to the restore point. That holds for a customer's click, a bulk action of yours and the nightly round alike.

Two things decide what happens by itself:

• The policy per installation: Nothing, Security updates only (the default) or Everything. For WordPress separately for WordPress itself, plugins and themes.
• The timer per server: whether the server carries that policy out at night, and in which window. It is off by default; the server profiles for shared hosting and WordPress switch it on with the window 05:00–07:00.

Where new versions come from: the build server fetches releases from their makers, checks their signature or hash and puts them in a signed application catalogue. Your servers fetch that catalogue every six hours. An application is therefore never updated straight from the internet.

Switching a server's timer on

1. Open Accounts, pick an account on that server and go to Applications (/accounts/:account/apps).
2. Below the list, administrators see the block Unattended website updates. Switch on Carry out each installation's policy automatically, choose the Window and click Save.

The block also shows when the next round runs and how many installations on that server carry each policy. The window is separate from the operating system's maintenance window: that one may restart the machine, and a restart in the middle of an update is exactly what you do not want.

The nightly round skips installations with the reason in the History: an installation with the policy Nothing, an installation whose restore point is switched off, an installation whose setup was never finished, and under Security updates only a jump to a new major number.

Big version jumps

Joomla 5 to Joomla 6 is not an update but a move: the database changes with it and the extensions have to have made that step too. Under the policy Security updates only such a jump never happens by itself. The waiting release stays on the installation's card; choose it together with the customer, at a moment that suits you both, with Update to ….

Joomla and Nextcloud have their own updater. CoreCP switches it off while the installation's policy is not Nothing, so two parties never update at once. Set the policy to Nothing and that updater stays as it was; CoreCP does not switch it back on by itself.

Security notices about applications

• WordPress plugins and themes: the build server reads Wordfence's vulnerability list every hour and your servers fetch it signed. If a plugin on a live site is on that list and the policy is Security updates only or Everything, it is updated in the next window. If the policy is Nothing, the hole stays open and the customer is told.
• Joomla and Drupal: the advisories of Joomla (VEL) and Drupal arrive as a finding on Components & security (/components), just like the findings about server software.

If a nightly update fails, or a site was put back to its restore point, the account overview says so the next morning and the customer gets a mail. Which notices you receive yourself is set under Notifications.

Many installations at once

On Applications you tick installations and click Update. On WordPress (/accounts/:account/wordpress) that is Update everything, and Policy for every site gives the ticked sites — or, with nothing ticked, all of the account's WordPress sites — the same policy in one go. Every installation in such a bulk action gets its own restore point and its own check; one failed installation does not hold the others back.

For every installation on a server at once, use the terminal: there you choose --all on deliberately, so "everything" never happens because a filter was left out.

Putting one back

A restore point is kept for the last five changes. For applications you put one back under Restore points with Put back. The WordPress screen itself has no put-back button: it points to the site's restore points under Applications, and in the terminal it is corectl wp restore.

To know beforehand that the safety net works, use Prove the rollback in the installation's overview at a quiet moment: the update really runs, the application is broken on purpose and the restore point is put back.

From the terminal

On the server:

corectl app list                                   # every installation on this server
corectl app auto --auto enable --window 05:00-07:00
corectl app update-all --dry-run                   # what the next round would do
corectl app policy <installation> --updates security
corectl app update <installation> --dry-run
corectl app snapshots
corectl app restore <restore-point> --instance <installation>
corectl app bulk update --all on --dry-run on
corectl app bulk policy --account customer1 --updates security
corectl wp updates                                 # waiting WordPress updates
corectl wp bulk policy --all on --core minor --plugins security --themes security
corectl wp snapshots
corectl wp restore <restore-point>

See also

• Installing and looking after applications — installing, updating and the policy per installation.
• Your WordPress sites — safe updates, policy per plugin and going back.
• Components and security — findings about the software on your servers.
• Operating-system maintenance and maintenance mode — the server's own maintenance window.