Skip to main content
tinymash
  • Screen mode

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 and compatibility result, then choose Update and confirm with the current password. tinymash verifies the signed release, checks the installation for changed managed files and unsupported extension code, downloads and audits the package, and creates a verified private backup before replacing application files.

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. Changed managed application files, operator-installed plugin or theme code, missing runtime support, insufficient space, or unsafe permissions block the update before application files are replaced. Use the reported correction or the manual sibling 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

Before the upgrade

  1. Read the release notes and migration instructions.
  2. Create and verify a site backup.
  3. Extract or build the new release in an empty sibling directory.
  4. Add compatible third-party themes or plugins required by the site.
  5. 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

  1. Rename the old directory aside.
  2. Move the prepared release into the live path.
  3. Restore ownership and permissions.
  4. Reload PHP-FPM and restart scheduled writers.
  5. Run system:status, cache:clear, and deploy:audit.
  6. 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.