Logs & Scheduled Tasks

The CMS keeps three logs, all visible only to admin users:

Developer Log — PHP errors and warnings from the website and CMS, at Admin Menu > Developer Log.
Audit Log — a record of who did what in the CMS Admin, at Admin Menu > Advanced Settings > Audit Log.
Task Log — output from scheduled background tasks, a submenu of Admin Menu > Scheduled Tasks.

Log tables are excluded from CMS database backups, so restoring a backup doesn’t overwrite or roll back your logs.

Developer Log

The Developer Log records any PHP errors or warnings raised by the website or the CMS. The Admin Menu > Developer Log nav entry shows a count badge with the number of logged errors, styled red whenever the count is above zero.

What gets logged

The CMS installs its own PHP error handlers, so the log captures:

Runtime errors, warnings, and notices, from both CMS pages and your website viewers.
Uncaught exceptions, with a full backtrace.
Fatal errors caught at script shutdown.
Messages logged from code with CMS::log($message, $debugData).

Errors silenced with the @ operator are not logged, except user-triggered E_USER_* errors, which are logged regardless. Deprecation notices are skipped when Hide Deprecation Notices is enabled on the Security Settings page.

Each entry captures the error message, URL, filepath and line number, backtrace, and a snapshot of the request environment ($_GET, $_POST, $_REQUEST, $_COOKIE, $_SESSION, and $_SERVER) at the time of the error. Errors raised by command-line scripts have no URL and are tagged CLI in the list.

Two limits keep the log manageable: at most 25 errors are logged per page load, and only the most recent 1,000 or so entries are kept (older records are pruned automatically once the count grows well past that).

One category of error can’t be captured: parse errors and other fatal errors that occur before the CMS code runs. When PHP’s display_errors is off, the list page shows a notice explaining that these appear as “500 Internal Server Error” responses and are only recorded in the server’s own error logs.

Reviewing errors

Three buttons at the top of the page switch between views:

Errors: The main list, newest first, 100 entries per page. The Date / When column shows a relative date (hover for the exact timestamp) and the Error Details column shows the error number and message, the filepath and line number, and the request method and URL. Advanced search supports keyword, error number, filepath, and line number.
By File: Errors grouped by filepath, most recently reported first, with a per-line breakdown of each file’s errors. Each row has show (filter the main list to that file) and clear (delete that file’s errors) links.
Latest: Opens the most recent error directly.

Clicking an entry opens a read-only detail page. Error records can’t be modified or created by hand. The backtrace is rendered with clickable file:line links, and an “Advanced Technical Details” section holds the captured request variables, any debug data passed to CMS::log(), and the raw log data.

To clear the log, use the Clear Log link in the notice at the top of the list, or the per-file clear links in the By File view.

Email alerts

The Email PHP Errors option on the Security Settings page (also shown under Email Settings) emails the admin when PHP errors are detected. The alert uses the CMS-ERRORLOG-ALERT email template, lists up to 25 errors from the past hour (deprecation notices excluded), and is throttled to at most one email per hour. Errors are logged either way; this option only adds the notification.

Audit Log

The Audit Log records user activity in the CMS Admin: who did it, from what IP address, and when. It appears as an indented submenu at Admin Menu > Advanced Settings > Audit Log whenever Advanced Settings is selected. There are no settings for it; logging is always on.

Events recorded by the CMS include:

Logins, both successful and failed, including the login source.
Records added, updated, deleted, and reordered, and category records moved.
Uploads added, deleted, and reordered, and files added from the Media Library.
Schema changes: fields created, modified, and deleted; tables created, renamed, and dropped; indexes created and dropped.
Website and database backups created, restored, and downloaded.
Admins logging in as another user.
CMS version changes and clearing of the audit log itself.

Plugins can record their own events by calling auditLog_addEntry($event, $additionalData, $source, $isWrite). The $isWrite flag marks state-changing events, which show in the Write column.

Clicking an entry opens a read-only view with the full event details: the URL, event source, browser user agent, linked user details (username, table, and record number), and any additional data as formatted JSON. Editing and erasing individual audit records is disabled. The Clear Log link at the top of the list empties the log, and that action is itself recorded as a new audit entry.

Scheduled Tasks

Scheduled tasks (also called background tasks) let plugin code run automatically at set times for jobs like maintenance and email alerts. The status page lives at Admin Menu > Scheduled Tasks. Tasks are registered by plugins calling addCronJob(), so cron setup is only needed when a plugin requires it. A menu warning icon appears whenever cron.php hasn’t run in the past hour.

How tasks run

Tasks are dispatched by cron.php in the CMS directory, which your server should run every minute via a cron job or scheduled task, passing the site’s hostname as an argument so the correct settings file is loaded:

* * * * * /path/to/php /path/to/cmsb/cron.php example.com

The Scheduled Tasks page includes step-by-step setup instructions for Plesk, cPanel, Linux (crontab), and Windows Task Scheduler, with the exact command pre-filled for your server.

There is no page-load fallback: if no server cron job is configured, tasks simply don’t run. For testing, you can trigger a run through the browser with the run now >> link (which loads cron.php directly); this requires an admin login and warns that web servers may terminate long-running tasks.

Each run works through every registered task and executes the ones that are due:

Schedules use cron expressions supporting *, single numbers, lists (15,30,45), and ranges (1-5).
A task that was due while cron.php wasn’t running is caught up with a single run on the next execution.
No task runs more than once per minute, and a database lock prevents a task from starting while its previous run is still going (logged as “Skipped, still running from last time”).

Plugins register tasks with addCronJob():

addCronJob('myPlugin_dailyReport', 'Daily Report', '0 6 * * *');  // 6:00am daily

The function’s return value is stored as the log entry’s Summary, and anything it prints is captured as its Output.

Warnings and disabling tasks

The Admin Menu > Scheduled Tasks nav entry turns red with a warning icon when tasks are disabled or haven’t run in the last hour, and the status page shows a matching warning message. This is the main signal that a server cron job is missing or has stopped working.

The Disable Tasks toggle at the top of the page stops all scheduled tasks from running until it’s turned back off. While disabled, cron.php exits without dispatching anything.

Status page

Below the setup instructions, the page shows:

Status — when tasks last ran, the run now >> link, and a log summary with entry, error, and maximum record counts plus a clear all link.
Scheduled Tasks — a table of every registered task: function name, activity, last run, and its cron expression.
Recent Activity — the last 10 Task Log entries.

If a task fails, an email alert is sent to the admin using the CMS-BGTASK-ERROR email template, throttled to at most once an hour.

Task Log

The Task Log lists one entry per task execution. It appears as an indented Task Log submenu (with a count badge) under Admin Menu > Scheduled Tasks whenever Scheduled Tasks or the log itself is selected.

Date/Time: When the task started.
Activity: The task’s activity name as registered with addCronJob().
Summary: The value returned by the task function. Shows “Running…” while a task is in progress and “Returned errors” if the task exited early.
Completed: “Yes” or “No”. A “No” on a finished task means it failed partway through.
Function: The PHP function that was executed.
Runtime: Execution time in seconds.

Opening an entry shows the full captured output. New records can’t be added by hand. The log is trimmed automatically to the cronLogLimit setting in your settings file (default 1,000 records, oldest removed first), and can be emptied with the Clear Log link at the top of the list or clear all on the status page.

Documents CMS Builder 3.83