Skip to main content

Logs and diagnostics

Start with read-only checks. Record the command, time, route, user scope, status code, and relevant log lines before changing configuration.

Runtime checks

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

system:plugins and system:themes report installed state and manifest or boot diagnostics. Use media:usage when investigating whether a managed file is still referenced. Use deploy:audit when application files may have drifted from the release manifest.

Server logs

Check both layers:

  • the web server access and error logs
  • the PHP-FPM or configured PHP error log

The exact destinations belong to host configuration. A site can keep application logs under logs/; the release includes samples/server/tinymash.logrotate as a starting point for rotation.

Do not place logs below public/. Restrict their permissions and retention. Logs must not record passwords, session cookies, Markdown Sync tokens, secret-link bearer paths, private page bodies, or uploaded source content.

Suppress or redact /s/<token> paths in access logs. The Nginx sample sends secret-link exchange routes directly to the front controller with access logging disabled; apply an equivalent policy on other servers.

HTTP checks

When a browser reports an unexpected HTML response to an administration request, inspect the response status and content type. A login page returned after session expiry is not JSON and must be handled as an authentication failure, not displayed as a parser error.

Check redirects without automatically following them when diagnosing route or canonical-URL problems. Verify public, logged-in, private, and secret-link behavior separately; they intentionally use different cache and authorization rules.

File integrity

php8.4 bin/tinymash.php deploy:audit /var/www/tinymash

The local deploy manifest detects ordinary missing, changed, unknown, or unsafe managed files. It is not a cryptographic release signature: an attacker able to replace both application files and the local manifest can forge a matching inventory. Use a separately obtained manifest when adversarial tampering is in scope.