Skip to main content
tinymash
  • Screen mode

Troubleshooting

Start with the smallest read-only check that matches the failure.

php8.4 bin/tinymash.php system:status
php8.4 bin/tinymash.php system:plugins
php8.4 bin/tinymash.php system:themes

system:status confirms the runtime paths and core state. Plugin and theme diagnostics report activation, manifest warnings, and plugin boot errors.

A page fails or looks stale

Check the PHP and web-server logs first. Confirm that the request reaches public/index.php and that the document root is public/. If content changed but the old output remains, run cache:clear, reload the exact route, and check for a reverse-proxy cache outside tinymash.

A 404 may be correct: confirm publication state, author visibility, parent-page state, plugin activation, and the requested path. Use System > Content > Link integrity for unresolved local links and routes.

A write or upload fails

Check Filesystem and permissions. The installation owner and PHP-FPM user need the documented access to data/, users/, and tmp/. Look for files created by root, a full filesystem, a read-only mount, an open_basedir restriction, or a missing runtime directory.

For temporary-file or cache failures, confirm that every PHP-FPM pool has its own writable temporary root. Check its owner and confirm that cron uses the same operating-system user as the pool. After changing the path, reload PHP-FPM and make one normal request before retrying the command.

Do not loosen the complete installation to world-writable permissions. Correct the owner and the affected path.

Scheduled work does not run

Check the user's crontab, the PHP binary path, command output, and housekeeping:status. Scheduled publication needs content:publish-due; web-cron fallback does not activate due content. Plugin queues may use housekeeping or a dedicated plugin command.

See Scheduled work for the recommended entries.

Import, export, or backup fails

Keep source files and output outside public/. Check free space, PHP extensions, upload limits, execution time, and the command's --help page. Large imports should use the CLI. Do not rerun a replacement import until its preview and target are understood.

Before a restore, confirm that a current backup can be inspected, that its copy exists outside the installation, and that the required release and third-party extension code are available. See Backup and recovery.

Recovery check

Keep a short record of:

  • the current release and PHP version
  • the installation owner and PHP-FPM user
  • the active cron entries
  • the location and age of the latest offsite backup
  • the last successful restore test
  • required third-party themes and plugins
  • web-server, TLS, SMTP, and HTTP Basic configuration held outside tinymash

After recovery, check sign-in, one public page, one author space, media delivery, scheduled work, mail, active plugin routes, and the PHP log before reopening normal traffic.