Customizing Log Displays and Notifications

Once events are recorded, coreActivity offers separate hook groups for the Logs table, notification emails, and cleanup. These hooks serve different purposes: changing a table’s display does not edit a stored log entry or remove its data from notification emails.

For callback registration, arguments, and the logging lifecycle, see Controlling Activity Logging with Hooks. Add the examples to a custom plugin or must-use plugin, and register them before the relevant hook runs.

Change a Logs table field

The Logs table has paired filters for field content and row actions. For example, coreactivity_logs_field_render_object_name filters the displayed object content, while coreactivity_logs_field_actions_object_name filters its action links. Each receives the current value, the log entry, and the table instance.

This example adds a label to objects representing REST routes:

add_filter( 'coreactivity_logs_field_render_object_name', function ( $render, $item, $table ) {
    if ( $item->object_type === 'route' ) {
        $render .= ' <strong>' . esc_html__( 'REST route', 'my-site' ) . '</strong>';
    }

    return $render;
}, 10, 3 );

The object-name field is passed through a permitted-HTML filter after this callback. Markup or attributes outside its allowed list can be removed. Escape any dynamic content for its output context; row-action links are a separate array and need their own correctly escaped URLs and labels.

Other fields have similarly named filters, including event content and IP row actions. There are also dynamic field-content and field-action hooks for columns handled by the default renderer. Check the individual reference: not every column is processed by the same renderer or uses identical escaping.

Control the optional metadata column

coreactivity_logs_meta_column_keys filters the component and event mapping of metadata keys used by the table. For an individual entry, coreactivity_meta_column_show filters the keys selected for the optional metadata column, and coreactivity_meta_row_skip filters keys omitted from the expandable metadata row. Both entry-level hooks also receive the entry and table instance.

These are presentation controls. They do not prevent a value from being stored. The metadata column itself must be enabled in the Logs display settings. See Activity Logs and Log Data and Retention.

Customize notification email data

There are separate email filters for daily digests, weekly digests, and instant notifications. Each receives an array containing the subject, message, email recipients, replacement tags, events, and period. Return the complete modified array.

For example, prepend a short label to the daily digest subject:

add_filter( 'coreactivity_daily_digest_email', function ( $notification ) {
    $notification['subject'] = '[Operations] ' . $notification['subject'];

    return $notification;
} );

The plugin applies these filters before replacing tags in the subject and message and before sending to the recipient list. The email filter runs only when the relevant notification is being prepared; configuring a callback does not enable the notification. See Activity Notifications for setup.

For side effects rather than changes to email data, use the actions for daily digests, weekly digests, and instant notifications. They receive $events, $from, and $to before email delivery. The daily and weekly event data contain counts; the instant notification contains log entries. Date boundaries are GMT/UTC and can be empty where supported.

Observe cleanup

coreactivity_cleanup_completed runs after a manual cleanup attempt and passes the retention interval, number of selected events, and removal result. coreactivity_cleanup_auto_completed runs after automatic cleanup and passes the configured retention in months and the removal result.

Use these actions to observe cleanup, not to veto it: they run after the cleanup routine. Review Log Data and Retention before changing a site’s retention policy.