Why Tiki Wiki depends on an external trigger

Tiki Wiki ships a surprising amount of deferred work that never runs during a normal page view. The internal Scheduler executes named tasks on an interval, the mail/notification layer can batch messages instead of sending them inline, full-text search indexes are rebuilt in the background, and housekeeping routines prune old sessions, temporary files, and stale cache entries. None of that happens by itself. A web request only renders the page the visitor asked for, so unless something pokes Tiki on a schedule, those jobs sit idle and you eventually notice symptoms: watch notifications that never arrive, a search index that lags behind recent edits, or a temp/ directory that balloons over weeks.

On a managed server, the operator controls the system crontab, but as an unprivileged hosting user you cannot touch /etc/cron.d or run systemctl. What you do get is the per-account cron facility exposed through cPanel Jupiter (Advanced → Cron Jobs) or DirectAdmin Evolution (Advanced Features → Cron Jobs). That facility runs commands as your account user on a schedule, which is exactly what Tiki's background layer expects. The job is to connect that per-account cron to Tiki's command-line entry points and then confirm the work is actually being consumed.

Tiki exposes two relevant entry points. The modern one is console.php, a Symfony-style command runner living in your document root. The command php console.php scheduler:run walks the Scheduler table and executes any task whose next-run time has passed. Older or alternate flows use tiki-admin.php screens combined with batch scripts under the doc/devtools/ and root directories. For a current Tiki (version 21 LTS through 27), console.php is the reliable surface, and it is the one to build your cron around.

Building the cron job in cPanel or DirectAdmin

First find the correct PHP binary. Shared hosting almost always runs multiple PHP versions through CloudLinux, and the plain php in a cron environment may resolve to an old default that does not match the version your site uses in MultiPHP Manager. Match them explicitly. On cPanel, the versioned binaries live at paths like /usr/local/bin/ea-php82, and CloudLinux also provides /opt/alt/php82/usr/bin/php. On DirectAdmin with CloudLinux PHP Selector the selectable binary is typically /usr/local/php82/bin/php. Confirm the exact path by checking which version your domain is assigned in MultiPHP Manager (cPanel) or the PHP Selector (DirectAdmin), then use the binary that matches.

Create a cron entry that changes into the Tiki root and runs the scheduler. A clean, self-contained command avoids relative-path surprises:

*/5 * * * * /usr/local/bin/ea-php82 /home/USERNAME/public_html/console.php scheduler:run >/dev/null 2>&1

Replace USERNAME and the document-root path with your real values (a subdomain or addon domain will have a different directory, such as /home/USERNAME/wiki/). The */5 runs it every five minutes, which is a sane baseline for notifications and light maintenance. If you prefer to be explicit about the working directory, wrap it:

*/5 * * * * cd /home/USERNAME/public_html && /usr/local/bin/ea-php82 console.php scheduler:run >/dev/null 2>&1

During setup, drop the output redirection temporarily so cron emails you anything the command prints. Remove >/dev/null 2>&1, let it run once, and read the mail that lands in your account. That is how you catch a wrong PHP path, a permissions error, or a Tiki bootstrap failure before it becomes a silent non-event. Once it runs cleanly, restore the redirection so your inbox is not flooded every five minutes.

A frequent failure is the CLI PHP binary lacking the same extensions or settings as the web PHP, because .user.ini values apply to the FastCGI/LSAPI handler, not necessarily to the CLI. If the scheduler needs more memory or longer execution than the CLI default, pass the directives inline rather than editing any server config:

*/5 * * * * /usr/local/bin/ea-php82 -d memory_limit=256M -d max_execution_time=0 /home/USERNAME/public_html/console.php scheduler:run >/home/USERNAME/tiki-cron.log 2>&1

Logging to a file inside your home directory gives you a durable record to inspect in File Manager later. Keep that log out of the web-accessible document root, or protect it; you never want a readable log under public_html.

Registering and verifying scheduler tasks inside Tiki

The cron line only invokes the runner. The actual tasks are defined inside Tiki's admin interface, and this split trips up a lot of people who assume installing cron is the whole job. Log in as an admin and go to Settings → Admin Home → Scheduler, or directly to tiki-admin_schedulers.php. There you create named tasks, choose a task type (a Console command, a Smarty template run, or a custom plugin), set the run frequency with a cron-style expression, and enable it. The Scheduler feature itself must be switched on first under Settings → Control Panels → Performance (or by searching the preference filter for "scheduler").

After you add a task, each run records a status row you can read on the same screen: start time, end time, exit state, and any captured output. This is the single most useful troubleshooting surface in the whole workflow. If your cron is firing but a task shows no new runs, the scheduler is being invoked but the task is disabled, its frequency has not elapsed, or an earlier run is stuck. If the task shows failures, the output column usually tells you why: a missing permission on temp/cache/, an email transport error, or a PHP fatal.

For notifications specifically, Tiki queues watch and workflow mail when batch sending is enabled under Settings → Mail. Those messages are flushed by a scheduler task or by the deferred-mail processing that the scheduler run triggers. If subscribers report missing watch emails while direct test mail works, the problem is almost always that cron is not consuming the queue, not that mail delivery is broken. Confirm the queue is draining before you chase SMTP or DNS. When the underlying issue genuinely is authenticated delivery and sender alignment, our companion write-up on authenticated SMTP, senders, and DNS alignment covers the SPF and DKIM side in detail.

Troubleshooting, log reading, and sensible intervals

When background work stalls, verify the chain from the outside in. Open the cron log you created and confirm the command is executing at all; an empty or absent log means the cron entry never fired, usually because the binary path is wrong or the entry was saved with a stray character. Next, run the exact command once from a cron-equivalent context: many panels offer a "run now" style test, and the status rows in tiki-admin_schedulers.php will update immediately if the runner reached Tiki. If PHP throws a fatal, it also lands in the Tiki temp/Tiki_syslog or the per-directory error_log that PHP writes next to the script; check File Manager in public_html for a fresh error_log after a failed run.

Permissions are the second common culprit. Because cron runs as your account user, the same ownership applies as web requests, so there is rarely a mismatch on shared hosting. But the temp/ and temp/cache/ trees must be writable, and a task that clears cache or rebuilds the search index will fail loudly if they are not. In File Manager, confirm those directories are present and set to 755 (directories) with writable contents; do not go to 777.

On interval tuning, resist the urge to run the scheduler every minute on a shared plan. Each invocation spins up a full PHP process and bootstraps Tiki, which competes with real visitor traffic for the CPU and entry-process limits CloudLinux enforces on your account. A five-minute cadence handles notifications and maintenance comfortably. Heavy, infrequent jobs such as a full search reindex or a bulk import should be defined as their own scheduler tasks with longer cron expressions (hourly or nightly) so they never pile onto the fast loop. For one-off imports of large structures or pages, trigger them from tiki-import.php during low-traffic hours and watch the scheduler status page for completion rather than kicking them off repeatedly. Keeping the fast loop light and the heavy jobs isolated is what keeps background processing reliable without ever touching anything above your hosting account.