Upgrading tinymash

Do not copy a new release over the existing application tree. Files removed by the new release can otherwise remain executable.

Update in the admin

Sites running 0.99.2 or later can install compatible signed releases from System > Updates. Review the available version, then choose Download and check. tinymash verifies the release and checks whether this installation can accept it without changing the site.

If all checks pass, choose Install update and enter your current password. tinymash creates a verified private backup before replacing application files. Changed application files, unsupported extensions, missing PHP support, insufficient space, or unsafe permissions stop the update before files are replaced.

Live Update requires PHP cURL, Sodium, and ZIP. If one is unavailable, the update page names it and does not offer the download action. Use a clean sibling upgrade when the host cannot provide the required extensions.

Keep the update page open while the named steps run. Reloading it resumes the same transaction. If installation stops before the updated site accepts writes, the page offers the safe recovery action available for that stage. A host operator can inspect or continue the same transaction from the installation root:

php8.4 bin/tinymash.php update:recover status
php8.4 bin/tinymash.php update:recover resume
php8.4 bin/tinymash.php update:recover rollback

Rollback is available only before the updated site reopens for writes. After that point, restore a verified site backup into a compatible clean release instead of replacing application code alone.

The updater accepts only a newer compatible release on the installed major version line. Operator-installed plugin or theme code also blocks Live Update. Use the reported correction or the manual procedure below.

Sites on 0.98.2 or earlier must use the manual procedure to reach 0.99.2. The manual procedure is also recommended when moving from 0.99.1, because that version starts an update with its original recovery worker.

Manual sibling upgrade

Prepare the new release in a separate directory beside the current installation. Switch directories only after the new release has a copy of the site's data and all writers have stopped.

Before the upgrade

Read the release notes and migration instructions.
Create and verify a site backup.
Extract or build the new release in an empty sibling directory.
Add compatible third-party themes or plugins required by the site.
Preserve host configuration outside the tinymash runtime separately.

Inspect the old installation

Run the preparation command from the new release root:

php8.4 bin/tinymash.php upgrade:prepare /path/to/old-tinymash --dry-run

Review missing extensions, changed managed files, discarded runtime paths, and unmanaged local paths. The command copies authoritative site state; it does not copy third-party extension code, caches, logs, temporary files, web-server configuration, or arbitrary local directories.

Copy the site state

Stop PHP-FPM, cron, queues, and other writers for the old installation. Then run:

php8.4 bin/tinymash.php upgrade:prepare /path/to/old-tinymash

For an unattended run, confirm the stopped writers explicitly:

php8.4 bin/tinymash.php upgrade:prepare /path/to/old-tinymash \
  --confirm-writes-stopped --no-interaction

Do not use --allow-missing-extensions unless the missing active plugins or selected themes have been reviewed and their absence is intentional.

Switch and verify

Rename the old directory aside.
Move the prepared release into the live path.
Restore ownership and permissions.
Reload PHP-FPM and restart scheduled writers.
Run system:status, cache:clear, and deploy:audit.
Check sign-in, public pages, author spaces, media, scheduled work, feeds, and active plugins.

Keep the old installation and verified backup until the upgraded site has been checked. Once new content is written, the old directory alone is not a complete rollback source.