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

CC Security Essentials has been designed to work naturally within the WordPress ecosystem.

Whether you’re building a custom plugin, integrating with an existing application or adding functionality for a specific website, the recommended approach is always to extend the plugin through its documented APIs rather than modifying its source code.

Doing so makes your code easier to maintain and helps ensure compatibility with future releases.

Choosing the Right Extension Point

Before writing any code, consider what you’re trying to achieve.

In most cases you’ll want to do one of three things:

If you want to…	Use…
Respond when something happens	An Action
Change a value before it is used	A Filter
Call functionality provided by the plugin	A documented Public API

Choosing the appropriate extension point keeps your code simple and avoids unnecessary complexity.

Avoid Modifying Plugin Files

Although WordPress allows plugins to be edited directly, this is strongly discouraged.

Direct modifications:

are overwritten when the plugin is updated
make troubleshooting more difficult
complicate future upgrades
can introduce unexpected behaviour

Instead, create a separate plugin or add your custom code to an existing custom plugin.

This keeps your work independent of CC Security Essentials and allows both projects to evolve independently.

Working with WordPress

CC Security Essentials follows standard WordPress development practices.

When extending the plugin, your code should do the same.

In particular:

validate user capabilities before performing privileged actions
sanitise all user input
escape output appropriately
verify nonces when processing requests
make text translation-ready
follow the WordPress Coding Standards

Developers already familiar with WordPress will find that extending CC Security Essentials follows familiar patterns.

Writing Defensive Code

Plugins evolve over time.

Although the documented developer API is intended to remain stable, it’s good practice to write code that behaves gracefully if a feature is unavailable.

For example:

check that a class exists before using it
verify that a function is available
allow for additional parameters in future releases
avoid assumptions about internal implementation

This approach helps keep your extensions compatible across future versions.

Performance Considerations

Extensions should avoid unnecessary processing.

In particular:

don’t perform expensive operations on every page request unless necessary
cache information where appropriate
avoid unnecessary database queries
only hook into events that your extension genuinely requires

Following normal WordPress performance practices helps keep your website responsive.

Security Considerations

Extensions should maintain the same security standards as the plugin itself.

Always:

validate permissions before making changes
sanitise incoming data
escape output
avoid exposing sensitive information
follow WordPress security best practices

Remember that custom code becomes part of your website’s overall security.

Accessibility

If your extension adds administrative pages or user interface components alongside CC Security Essentials, we recommend following the same accessibility principles used throughout the plugin.

This includes:

full keyboard accessibility
meaningful labels
appropriate colour contrast
visible focus indicators
compatibility with WordPress accessibility guidelines

A consistent user experience benefits everyone.

Internationalisation

If your extension displays text to users or administrators, it should be fully translation-ready.

This includes:

wrapping translatable strings in the appropriate WordPress localisation functions
providing translator comments where necessary
avoiding concatenated strings that are difficult to translate

This helps your extensions integrate naturally into multilingual WordPress websites.

Testing Your Extension

Before deploying an extension to a production website, we recommend testing it on a development or staging website.

A typical testing process might include:

Install the latest version of CC Security Essentials.
Activate your extension.
Verify the expected behaviour.
Test common administrative workflows.
Check for compatibility with other plugins where appropriate.
Repeat testing after updating WordPress or CC Security Essentials.

Testing early helps identify issues before they affect a live website.

Common Mistakes to Avoid

The following practices are best avoided:

❌ Editing CC Security Essentials directly.

❌ Calling undocumented internal methods.

❌ Depending on undocumented hooks.

❌ Assuming the order in which internal components are initialised.

❌ Modifying plugin database tables directly.

❌ Replacing core plugin behaviour when extending it would achieve the same result.

Instead, build on the documented extension points wherever possible.

Example Extension Structure

A typical extension plugin might look something like this:

my-ccse-extension/
│
├── my-ccse-extension.php
├── includes/
│   ├── class-plugin.php
│   ├── class-hooks.php
│   └── class-admin.php
├── languages/
└── readme.txt

Keeping your code organised from the outset makes it easier to maintain as it grows.

Next Step

The following sections document the supported developer APIs provided by CC Security Essentials:

Actions
Filters
Public PHP APIs (where available)

Each reference includes:

the purpose of the extension point
available parameters
expected return values (where applicable)
example code
version information

Continue with:

Extending CC Security Essentials