foto-portfolio/scripts/manage-client.cron

# 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.