Updates

tilspire updates itself in place — the core and every module you run, in one action — and checks every package before anything on your site changes.

How signed updates work #

Every release is checked two ways before it's applied: its checksum must match the value published in the update manifest, and the package must carry a valid signature over its exact bytes. Both checks have to pass.

That combination matters because a checksum alone only proves a file wasn't corrupted in transit — it doesn't prove who produced it. The signature proves the package came from the holder of the release signing key. If either check fails, the update is rejected and nothing on your site changes.

One action updates everything #

Go to System ▸ Updates. When an update is waiting, the page shows the release, what’s in it, and Update this site. Since 1.16.0 that opens the update on its own full screen, in three steps — Check, Update and Result — with nothing else on it, so you always see where you are. Press Update everything in the second step: tilspire downloads and verifies the new core and a package for each module you're entitled to, stages them all, and only then swaps them into place. If swapping the core fails partway through, it is rolled back.

The modules that come with tilspire always carry the same version number as the core, so a site that's up to date shows a single number. The Updates page names a module only when it isn't in step with the rest.

If a licensed module's files have gone missing — removed by a deploy, say — the next update fetches them again.

What happens when you press Update #

Since 1.15.0 every update, whether you start it or it runs on schedule, takes the same four steps:

1. A pre-check, shown before you press anything: the release notes, what will change, whether your PHP, disk space and folders are ready, and whether a backup is recent. A red result stops the update; an amber one asks you to confirm you've read it.
2. A snapshot of your database, encrypted, taken just before anything changes.
3. The update itself, as described above.
4. A health check afterwards, compared with the one taken before.

Keep that screen open while the update runs: it carries on if the page closes, but only that page shows how it ends. Until it starts, Leave without updating takes you back.

If the health check finds a problem, the Updates page offers to undo the update together with the database, for 24 hours. A scheduled update that fails its check undoes itself and emails you what happened.

Automatic updates #

The Updates page also sets what happens without you: Off, Security updates only, or All updates. Automatic updates run from a scheduled task:

php update.php --auto

Run it from your site's root folder, and on Windows set the scheduled task to start there too.

Unless automatic updates are off, that task also applies any database migrations that are waiting, the core's and each enabled module's.

You can also choose a weekly window, a day and an hour, so automatic updates only run when you expect them. Security releases follow the window too; you can always update at once yourself.

Security releases #

A release that fixes a security problem is marked as one in the manifest. Since 1.13.0, an update counts as a security update whenever any security release lies between the version you run and the newest one, even if you never saw that release offered — so a site set to Security updates only installs the newest release, which carries the fix, and the Updates page says which security release it was for. The changelog says which releases were security releases.

Undoing an update #

After an update, the Updates page offers Undo the last update: it puts back the release you had before, one step, from that release's own signed package, which the update kept and which is checked again before anything changes. Pro modules go back with the core. When the update changed the database, undo puts the database back from the snapshot taken before it, for 24 hours; after that the page says why it no longer can. A release you undo is not reinstalled by automatic updates; the next newer release is. Your first undoable update is the second one taken on 1.13.0 or later.

What a release may require #

The manifest can name a minimum PHP version. If your server's PHP is older, the updater says so and leaves your site exactly as it is. Since 1.11.0, tilspire needs PHP 8.1. The manifest always offers the newest release, so a site on an older PHP receives no further updates until its PHP is upgraded.

A release can also name the module versions it needs, and it checks them before it downloads anything.

What gets updated #

An update replaces exactly these paths: core/, migrations/, index.php, .htaccess, the starter theme at site/themes/default/, the modules that come with every package (modules/blog/, modules/assistant/, modules/analytics/), the update entry update.php, and the licence files — LICENSE, NOTICE, TRADEMARK.md, STABILITY.md and licenses/. Pro modules are updated from their own signed packages.

Everything else is yours: your own theme, your configuration, your content and database, your uploads, and any third-party module. See Themes for why copying the starter theme, rather than editing it, is the right way to build your own.

What each part of tilspire promises across 1.x is written down in STABILITY.md, which comes with every release.

Checking by hand #

The stable channel's manifest lives at updates.tilspire.com/stable/manifest.json. From the command line:

php update.php
php update.php --apply

The first only checks; --apply installs an available update, and --undo undoes the last one. See Command-line tools.