Sanitization And Escaping

This page describes the plugin's sanitisation and escaping approach at a high level. Internal helper names, validator pipelines and exact masking rules are implementation details and are not published here.

Approach

The plugin follows the standard WordPress security guidance:

• Sanitise on input. Every untrusted value is sanitised using the appropriate WordPress API for its type before it is stored or used.
• Escape on output. Every dynamic value is escaped at render time using the appropriate WordPress escaping API for its context (HTML, attribute, URL, JavaScript, JSON).
• Validate, then sanitise, then escape. Validation rejects out-of-range values; sanitisation normalises shape; escaping protects the output context.
• Mask secrets in diagnostics. Diagnostic output never includes plaintext secrets, tokens, authorisation headers or signed-request headers.

For extenders

When writing code that integrates with the plugin (custom templates, theme overrides, hook callbacks):

• Treat every value coming from request parameters, options, post meta or third-party APIs as untrusted.
• Use the WordPress sanitisation API (sanitize_text_field, sanitize_email, wp_kses_post, absint, etc.) on input.
• Use the WordPress escaping API (esc_html, esc_attr, esc_url, esc_js, wp_json_encode) at the point of output.
• Never echo configured secrets or credentials back into rendered output or log lines.

Supported public integration surfaces

When integrating with the plugin, prefer these stable surfaces:

• The plugin admin settings UI.
• The documented shortcodes.
• Theme-level template overrides as described in Template System And Overrides.
• The general Developer Overview for orientation.

Internal class names, option keys, database tables, REST and AJAX endpoints, cron hook names, capability and nonce identifiers, and release / update infrastructure are treated as implementation details. They may change between releases without notice and are not part of the public integration contract.

Stability and change policy

Anything not listed as a supported public surface above is considered an internal implementation detail. Internal APIs, storage layout and security implementation may change between releases. Do not depend on them from third-party code, themes or external systems. Direct database writes are not supported.

Public documentation notice. This page provides a high-level integration overview only. Internal implementation details, private APIs, storage internals and security-sensitive release infrastructure are maintained separately and are not part of the public documentation. Supported integration surfaces are the documented shortcodes, template overrides, settings UI and any extension points explicitly published in this section.