Click to expand
Scheduler for Tiki (cron jobs) An internal scheduler was added in Tiki17, so that only one cron job needs to be defined in the system crontab, and all actions to be run a scheduled times can then be defined within Tiki UI.
In the quick admin module, and in the main application menu under "Settings" section ("https://example.org/tiki-admin_schedulers.php").
You can list scheduled tasks
You can edit one scheduled task
Syntax for the scheduled run time is similar to the syntax used in system crontabs in GNU/Linux and equivalent operating systems:
Use CRON format to enter the values in “Run Time”: Minute, Hour, Day of Month, Month, Day of Week Eg. every 5 minutes: */5 * * * *
See https://en.wikipedia.org/wiki/Cron for details on Cron formats. For example:
* * * * * | | | | | | | | | | | | | | +---- Day of the Week (range: 1-7, 1 = Monday) | | | +------ Month of the Year (range: 1-12) | | +-------- Day of the Month (range: 1-31) | +---------- Hour (range: 0-23) +------------ Minute (range: 0-59)
The master cron job must be run quite frequently to check if Tiki Scheduler must launch another operation.
Here are some examples (adjust to your server path and use case)
* * * * * php /var/www/html/console.php scheduler:run
*/30 * * * * php /var/www/html/console.php scheduler:run
www-data, apache, nginx etc The examples above all use ConsoleCommandTask, but it isn't the only Task type the Scheduler supports, TikiCheckerCommandTask (used by the default "Tiki Check" preset task) is another built-in one, and the Scheduler is designed to be extensible beyond console.php commands. In particular, under the advanced Security preferences there is an option that lets a scheduled task run a raw shell command directly, not wrapped in console.php at all. Check tiki-admin.php?page=security on your own instance (filter the preferences for "scheduler" or "shell") to confirm the exact label and default state for your version, since this is exactly the kind of setting that should stay off unless you specifically need it. With it enabled, a scheduled task effectively becomes a cron job that lives inside Tiki's own interface, with logging and a UI, instead of a raw line in /etc/crontab.
We'd rather be conservative here: enable shell-command tasks only on instances you fully administer, keep the list of who can create scheduler tasks (tiki_p_admin_schedulers permission) tight, and prefer the standard console.php commands whenever one already does the job. The full, current list of available commands is always worth checking in the Console documentation, since new ones are added with almost every release.
To give a sense of scale, here is a non-exhaustive list of what's realistic to automate in a stock Tiki instance, no custom code required, built directly from the current console.php command list:
| Task | How to set it (console.php command) | Remarks |
| Rebuild the search index | index:rebuild | Heaviest but most reliable; good nightly default |
| Optimize the search index | index:optimize | Lighter alternative between full rebuilds |
| Generate the XML sitemap | sitemap:generate | Keeps search engines in sync with new content |
| Send notification digests | notification:digest | Requires users to be subscribed to digest mode |
| Send daily user reports | daily-report:send | Tiki's Daily Reports feature |
| Flush the mail queue | mail-queue:send | Only relevant if outgoing mail is set to "Queue" |
| Batch-import dropped files | files:batchupload 1 | Great for automated exports landing via SFTP |
| Clear Tiki caches | cache:clear | Safe to run daily; regenerates on next page load |
| Remove expired tokens | tokens:clear | Housekeeping, no visible effect for users |
| Remove expired login cookies | users:remove-cookies | Complements tokens:clear |
| Recalculate tracker math fields | tracker:recalc | Only needed if trackers use computed fields |
| Refresh incoming RSS feeds | rss:refresh | Useful if you aggregate external feeds |
| Delete old system logs | log:delete | Pairs well with a defined retention policy |
| Sync calendar subscriptions | calendar:sync | For calendars pulling external ICS feeds |
| Update Tiki via version control | vcs:update | Best reserved for staging, not production, unattended |
| Back up instance files | backup:files /path/to/backup | Needs a writable destination path, see above |
| Back up the database | database:backup /path/to/backup | Pair with backup:files for a full nightly snapshot |
| Check installed packages | package:update | Review before enabling unattended on production |
As with backup:files, a few of these (database:backup, files:batchupload) expect a path or gallery ID as an argument rather than running bare; the pattern from above applies: test the exact command by hand once, then wrap it in a scheduled task with that same, working syntax.
Using the Tiki Scheduler and a Console command, once you have set your master Cron Job (see above) you can automatically rebuild your Unified Index to assure your Tiki freshness. In this sample we also generate logs so we can investigate in case there were an issue.
in the event of job execution failure, it is possible to send an email to the admin to inform them of the failure. the reasons for the failure will be visible in the logs. if the process subsequently succeeds, another email can be sent to keep them informed.
To avoid the email being sent to all admins, you can specify the email addresses that will receive the notifications in the scheduler_users_to_notify_on_healed and scheduler_users_to_notify_on_stalled preferences. Note: this will only work if both fields are filled in. Otherwise, all admins will receive an email.