Last updated: 10th July 2026 for CC Security Essentials version 1.0

CC Security Essentials Actions Reference

Introduction

WordPress actions allow developers to run custom code when particular events occur within CC Security Essentials.

Unlike filters, actions do not modify a value. They notify custom code that the plugin has reached a particular stage or that a particular event has occurred.

The actions documented on this page can be used to:

initialise an integration at the appropriate point;
respond after the plugin’s protection modules have loaded;
add concise information to selected administrator interfaces;
react when REST API Protection blocks a visitor request.

Only the actions documented on this page form part of the supported developer API.

The plugin contains a small number of additional actions used by its internal administration interface. These are deliberately not documented and should not be relied upon by third-party code.

Action Index

Plugin Lifecycle

Action	Purpose
`ccse_before_init`	Fires before plugin modules and administrator integrations are registered.
`ccse_modules_loaded`	Fires after all core and filtered modules have registered their hooks.
`ccse_admin_loaded`	Fires after administrator integrations have registered.
`ccse_loaded`	Fires when plugin initialisation is complete.

Administrator Interfaces

Action	Purpose
`ccse_dashboard_widget_after_core`	Adds content after the core WordPress dashboard widget output.
`ccse_overview_after_score`	Adds content after the core Protection Score on the Security Overview.

REST API Protection

Action	Purpose
`ccse_rest_visitor_request_blocked`	Fires when REST API Protection blocks a signed-out visitor request.

Plugin Lifecycle

`ccse_before_init`

do_action( 'ccse_before_init', $plugin );

Purpose

Fires before CC Security Essentials adds its default options, prepares its module registry or registers its administrator integrations.

This is the earliest documented point at which an extension can respond to the plugin’s initialisation.

Parameters

Parameter	Type	Description
`$plugin`	`CaterhamComputing\SecurityEssentials\Plugin`	The main plugin instance.

Example

add_action(
    'ccse_before_init',
    function ( $plugin ) {
        // Prepare services needed by the integration.
    },
    10,
    1
);

When to Use It

Use this action only when an integration genuinely needs to prepare something before the plugin’s modules register their WordPress hooks.

Most integrations should use ccse_loaded instead.

Notes

At this point:

default options have not yet been added;
protection modules have not registered their hooks;
administrator integrations are not yet available.

The supplied plugin instance should be treated as context. Do not rely on undocumented properties or methods.

`ccse_modules_loaded`

do_action( 'ccse_modules_loaded', $plugin );

Purpose

Fires after all core and filtered modules have registered their WordPress hooks.

This includes compatible modules added through the documented ccse_modules filter.

Parameters

Parameter	Type	Description
`$plugin`	`CaterhamComputing\SecurityEssentials\Plugin`	The main plugin instance.

Example

add_action(
    'ccse_modules_loaded',
    function ( $plugin ) {
        // Initialise functionality that depends on registered modules.
    },
    10,
    1
);

When to Use It

Use this action when an integration depends specifically on the plugin’s protection modules having completed their hook registration.

Possible uses include:

completing module-dependent setup;
registering integration behaviour that must run after the protection modules;
confirming that a module supplied through ccse_modules has been initialised.

Notes

This action fires during both visitor-facing and administrator requests.

It does not mean that the plugin’s administrator integrations have loaded. Use ccse_admin_loaded for administrator-specific integration work.

`ccse_admin_loaded`

do_action( 'ccse_admin_loaded', $plugin );

Purpose

Fires after CC Security Essentials has registered its administrator settings and Site Health integrations.

This action is intended for administrator-only integrations that depend on the core plugin’s administration hooks being available.

Parameters

Parameter	Type	Description
`$plugin`	`CaterhamComputing\SecurityEssentials\Plugin`	The main plugin instance.

Example

add_action(
    'ccse_admin_loaded',
    function ( $plugin ) {
        // Register administrator-only integration behaviour.
    },
    10,
    1
);

When to Use It

Use this action when custom code needs to initialise after the plugin’s administration functionality has registered.

For example:

preparing an administrator-only integration;
registering related administration notices;
attaching behaviour that depends on the plugin’s administrator hooks.

Notes

This action fires only when WordPress reports that the current request is an administrator request through is_admin().

It should not be used for visitor-facing functionality.

The action may also fire during some administrator-side AJAX or background requests because WordPress can treat these as administrator requests.

`ccse_loaded`

do_action( 'ccse_loaded', $plugin );

Purpose

Fires after CC Security Essentials has completed its initialisation.

This is the recommended lifecycle action for most integrations that simply need to begin operating once the plugin is ready.

Parameters

Parameter	Type	Description
`$plugin`	`CaterhamComputing\SecurityEssentials\Plugin`	The main plugin instance.

Example

add_action(
    'ccse_loaded',
    function ( $plugin ) {
        // Initialise the integration.
    },
    10,
    1
);

When to Use It

Use ccse_loaded when an integration:

needs to confirm that CC Security Essentials is active and initialised;
does not need to alter the earlier module-registration process;
should operate during both visitor-facing and administrator requests.

Notes

This action fires after ccse_modules_loaded.

During administrator requests, it also fires after ccse_admin_loaded.

The supplied plugin instance should not be used to call undocumented methods.

Lifecycle Order

During a normal visitor-facing request, the lifecycle actions fire in this order:

ccse_before_init
    ↓
ccse_modules_loaded
    ↓
ccse_loaded

During an administrator request, they fire in this order:

ccse_before_init
    ↓
ccse_modules_loaded
    ↓
ccse_admin_loaded
    ↓
ccse_loaded

Choosing the Correct Lifecycle Action

Requirement	Recommended Action
Prepare something before modules register	`ccse_before_init`
Run after protection modules have registered	`ccse_modules_loaded`
Perform administrator-only integration setup	`ccse_admin_loaded`
Initialise a general integration after the plugin is ready	`ccse_loaded`

For most general integrations, use ccse_loaded.

Administrator Interfaces

`ccse_dashboard_widget_after_core`

do_action(
    'ccse_dashboard_widget_after_core',
    $score
);

Purpose

Fires after the core content in the CC Security Essentials WordPress dashboard widget.

Extensions can use this action to add concise, relevant security information to the existing widget without replacing the plugin’s core summary.

Parameters

Parameter	Type	Description
`$score`	`array<string,int>`	The current weighted Protection Score data.

The score array contains:

Key	Type	Description
`earned`	`int`	Weight earned from protected checks.
`total`	`int`	Total available weight.
`percent`	`int`	Calculated Protection Score percentage.

Example

add_action(
    'ccse_dashboard_widget_after_core',
    function ( $score ) {
        if ( ! is_array( $score ) ) {
            return;
        }

        $open_items = my_plugin_get_open_security_items();

        if ( 0 === $open_items ) {
            return;
        }

        ?>
        <hr>
        <p>
            <strong>
                <?php esc_html_e( 'Custom security review', 'my-plugin' ); ?>
            </strong>
        </p>
        <p>
            <?php
            printf(
                esc_html(
                    _n(
                        '%d custom security item requires attention.',
                        '%d custom security items require attention.',
                        $open_items,
                        'my-plugin'
                    )
                ),
                absint( $open_items )
            );
            ?>
        </p>
        <?php
    },
    10,
    1
);

Appropriate Uses

This action is suitable for adding:

a brief integration status;
a concise custom security result;
a link to related administrator information;
a summary from a complementary security component.

Avoid

Do not use this action to:

reproduce the full dashboard of another plugin;
add large settings forms;
display disruptive warnings;
insert unescaped or untrusted content;
replace the plugin’s existing dashboard summary.

Output and Security

Content added through this action is rendered directly within the dashboard widget.

Callbacks are responsible for:

escaping all dynamic output;
checking capabilities before displaying privileged information;
avoiding sensitive information;
keeping the output compact and accessible.

Notes

This action runs whenever the dashboard widget is rendered.

Callbacks should not perform expensive processing or make slow external requests.

`ccse_overview_after_score`

do_action(
    'ccse_overview_after_score',
    $checker,
    $score
);

Purpose

Fires immediately after the core Protection Score section on the Security Overview page.

Extensions can use this action to add their own security summary while leaving the core essential-protection score unchanged.

Parameters

Parameter	Type	Description
`$checker`	`CaterhamComputing\SecurityEssentials\Status\StatusChecker`	The Status Checker instance used by the Overview.
`$score`	`array<string,int>`	The current weighted Protection Score data.

The score array contains:

Key	Type	Description
`earned`	`int`	Weight earned from protected checks.
`total`	`int`	Total available weight.
`percent`	`int`	Calculated Protection Score percentage.

Example

add_action(
    'ccse_overview_after_score',
    function ( $checker, $score ) {
        if ( ! is_array( $score ) ) {
            return;
        }

        $summary = my_plugin_get_security_summary();

        if ( '' === $summary ) {
            return;
        }

        ?>
        <div class="card" style="max-width: 900px; margin-top: 20px;">
            <h2>
                <?php esc_html_e( 'Additional security summary', 'my-plugin' ); ?>
            </h2>

            <p><?php echo esc_html( $summary ); ?></p>
        </div>
        <?php
    },
    10,
    2
);

Appropriate Uses

This action is suitable for:

presenting an additional security summary;
reporting the state of a complementary integration;
displaying a focused explanation related to custom checks;
linking to relevant configuration or diagnostic information.

Avoid

Do not use this action to:

alter or obscure the core Protection Score;
imply that custom checks form part of the core score unless they have been integrated through the documented status and weighting filters;
display unrelated promotional material;
duplicate the complete administration interface of another plugin.

Status Checker Instance

The $checker object is supplied for context.

Developers should avoid calling undocumented methods on it. Where possible, use the plugin’s documented helper functions and filters instead.

Output and Security

Callbacks render their output directly on the administrator page.

Custom output must:

be escaped appropriately;
follow WordPress capability requirements;
use meaningful headings and labels;
remain keyboard accessible;
avoid disclosing sensitive security information unnecessarily.

Performance

The Overview may be visited regularly by administrators. Avoid expensive queries or remote calls during page rendering.

REST API Protection

`ccse_rest_visitor_request_blocked`

do_action(
    'ccse_rest_visitor_request_blocked',
    $route,
    $method,
    $status,
    $code,
    $message,
    $request
);

Purpose

Fires when REST API Protection blocks a request from a visitor who is not signed in.

This action allows an integration to respond to a blocked request without replacing or changing the core visitor restriction.

Possible uses include:

privacy-conscious security logging;
organisation-specific diagnostics;
policy reporting;
local security monitoring;
counting blocked requests within a controlled retention period.

Parameters

Parameter	Type	Description
`$route`	`string`	The requested REST API route.
`$method`	`string`	The uppercase HTTP request method.
`$status`	`int`	The HTTP status code returned for the blocked request.
`$code`	`string`	The WordPress REST error code.
`$message`	`string`	The visitor-facing REST error message.
`$request`	`WP_REST_Request`	The complete WordPress REST request object.

Example

add_action(
    'ccse_rest_visitor_request_blocked',
    function ( $route, $method, $status, $code, $message, $request ) {
        if ( ! $request instanceof WP_REST_Request ) {
            return;
        }

        // Perform lightweight, privacy-conscious processing here.
    },
    10,
    6
);

Recording a Minimal Local Event

The following example records only the route, request method and event time.

It deliberately limits the stored history. A production logging system should also provide appropriate access controls, deletion tools and retention settings.

add_action(
    'ccse_rest_visitor_request_blocked',
    function ( $route, $method ) {
        $events = get_option( 'my_ccse_rest_events', [] );

        if ( ! is_array( $events ) ) {
            $events = [];
        }

        $events[] = [
            'route'  => sanitize_text_field( $route ),
            'method' => sanitize_key( strtolower( $method ) ),
            'time'   => current_time( 'mysql', true ),
        ];

        // Retain only the 50 most recent events.
        $events = array_slice( $events, -50 );

        update_option( 'my_ccse_rest_events', $events, false );
    },
    10,
    2
);

When the Action Fires

The action fires only when all of the following apply:

REST API visitor restriction is enabled;
the request is made by a visitor who is not signed in;
the request is not permitted by the compatibility allowlist;
no integration has allowed the request through ccse_rest_public_request_allowed;
CC Security Essentials blocks the request.

It does not fire for:

authenticated REST API requests;
publicly allowed route prefixes;
requests explicitly permitted by an integration;
REST requests blocked by another component before CC Security Essentials processes them.

Privacy and Data Retention

The request object may contain information that is personal, private or security-sensitive.

An integration using this action should:

collect only the information it genuinely needs;
avoid storing the complete request object;
avoid recording request bodies unnecessarily;
avoid retaining authentication information;
establish an appropriate retention period;
restrict access to authorised administrators;
provide deletion or clearing facilities where appropriate;
ensure the website’s privacy information remains accurate.

Performance

Automated systems may generate large numbers of blocked requests.

Callbacks must therefore remain lightweight.

Avoid:

synchronous external API requests;
sending an email for every blocked request;
unbounded option or database growth;
expensive processing on every event;
writing complete request objects to logs.

Where substantial processing is required, record a minimal event and defer further work through an appropriate WordPress background mechanism.

Writing Action Callbacks

Use the Correct Number of Arguments

When an action supplies more than one parameter, specify the number your callback accepts:

add_action(
    'ccse_rest_visitor_request_blocked',
    'my_callback',
    10,
    6
);

If the accepted-arguments value is omitted, WordPress passes only the first argument by default.

Keep Callbacks Focused

Each callback should perform one clearly defined task.

Small callbacks are easier to:

understand;
test;
remove;
maintain;
troubleshoot.

Validate Supplied Values

Although action parameters originate from the plugin, integrations should still confirm that complex values have the expected type before using them.

For example:

if ( ! $request instanceof WP_REST_Request ) {
    return;
}

Escape Administrator Output

Actions that render interface content do not automatically escape custom output.

Use the appropriate WordPress escaping function for each context, including:

esc_html();
esc_attr();
esc_url();
wp_kses_post() where limited HTML is intentionally permitted.

Check Capabilities

Before exposing privileged information or performing administrator actions, verify the current user’s capabilities.

For example:

if ( ! current_user_can( 'manage_options' ) ) {
    return;
}

Avoid Exceptions and Fatal Errors

An action callback should fail safely if a dependency is unavailable or supplied data is unexpected.

Custom code attached to an action must not prevent the plugin or the remainder of WordPress from loading.

API Stability

The actions documented on this page are treated as supported extension points for the CC Security Essentials 1.x release series.

Where practical:

action names will remain unchanged;
parameter meanings and types will remain stable;
existing actions will not be removed without prior deprecation;
significant changes will be documented in release notes.

Developers should not rely on undocumented actions, private methods, internal classes or assumptions about the order in which individual internal components are constructed.

Best Practices

When using these actions:

choose the latest appropriate lifecycle action;
keep callbacks efficient;
validate supplied objects and arrays;
escape all custom administrator output;
collect as little security-event information as necessary;
apply appropriate data-retention limits;
avoid modifying the plugin’s source files;
avoid calling undocumented methods on supplied objects;
test integrations on a development or staging website;
test both signed-in and signed-out behaviour where relevant.

Continue with:

CC Security Essentials Actions Reference

Introduction

Action Index

Plugin Lifecycle

Administrator Interfaces

REST API Protection

Plugin Lifecycle

ccse_before_init

Purpose

Parameters

Example

When to Use It

Notes

ccse_modules_loaded

Purpose

Parameters

Example

When to Use It

Notes

ccse_admin_loaded

Purpose

Parameters

Example

When to Use It

Notes

ccse_loaded

Purpose

Parameters

Example

When to Use It

Notes

Lifecycle Order

Choosing the Correct Lifecycle Action

Administrator Interfaces

ccse_dashboard_widget_after_core

Purpose

Parameters

Example

Appropriate Uses

Avoid

Output and Security

Notes

ccse_overview_after_score

Purpose

Parameters

Example

Appropriate Uses

Avoid

Status Checker Instance

Output and Security

Performance

REST API Protection

ccse_rest_visitor_request_blocked

Purpose

Parameters

Example

Recording a Minimal Local Event

When the Action Fires

Privacy and Data Retention

Performance

Writing Action Callbacks

Use the Correct Number of Arguments

Keep Callbacks Focused

Validate Supplied Values

Escape Administrator Output

Check Capabilities

Avoid Exceptions and Fatal Errors

API Stability

Best Practices

Related Articles

`ccse_before_init`

`ccse_modules_loaded`

`ccse_admin_loaded`

`ccse_loaded`

`ccse_dashboard_widget_after_core`

`ccse_overview_after_score`

`ccse_rest_visitor_request_blocked`