# Cron for this installation — one line is enough. # # Cron is OPTIONAL here. This host is assumed not to have it, so the site drives # itself: a public page render builds gallery archives in the background (see # app/archive.php) and an admin page render runs the backup and heartbeat (see # app/manage.php). Everything below is the same work on a dependable timer # instead, and both drivers may run at the same time — the locks they share make # sure only one process ever works on a given archive. # # Two prerequisites: # # 1. set 'cron' => ['enabled' => true] in config/config.php, otherwise # cron.php refuses to run (and says so), # 2. for variant A, the worker key from data/worker-key.json. MAILTO=admin@example.org # --- A. Over the web (no shell needed; works on hosts whose "cron" is really # --- just a URL fetcher). # # One invocation drains everything outstanding: every gallery archive that is # due, the weekly backup, the hourly heartbeat. Never updates. -m 300 matches # cron.max_seconds (240 s) with room to spare; a run that finds nothing to do # costs a couple of file reads. */5 * * * * curl -s -m 300 "https://www.example.com/cron.php?key=YOUR_WORKER_KEY" >/dev/null # --- B. Over the shell. Same file, same jobs. # # Check the PHP binary with `which php`; shared hosts often want a versioned one # such as /usr/bin/php8.2. --quiet suppresses normal output — errors still go to # STDERR, and cron mails those to MAILTO, which is the point. PHP=/usr/bin/php SITE=/var/www/html/foto-portfolio */5 * * * * $PHP $SITE/cron.php --quiet # --- Optional extra: the release check. # # Not background work — a notification. Exit code 2 means "update available", and # cron reports a non-zero exit as mail, which is exactly that notification. The # backoffice checks on its own when the Maintenance page is opened, so this line # is only worth having if you want to be told without looking. 0 8 * * 1-5 $PHP $SITE/manage-client/bin/manage-client.php check --quiet # The individual jobs still have their own entry points, if you would rather give # them an explicit schedule than let cron.php decide what is due: # # */5 * * * * curl -s "https://www.example.com/worker.php?key=YOUR_WORKER_KEY" # 20 3 * * * $PHP $SITE/manage-client/bin/manage-client.php backup --trigger=cron --quiet # 7 * * * * $PHP $SITE/manage-client/bin/manage-client.php heartbeat --quiet # # Updates are deliberately installed by none of this. `update` overwrites files # while the site is live, has no rollback, and may run migrations — that belongs # in front of a human, at Admin -> Maintenance.