Sanitization at Save and Render Time​

Summary: Antimanual Builder Pro sanitizes content at save and render time to protect imports, AI-generated pages, and frontend output. This dual-layer process removes unsafe tags, attributes, and scriptable input while preserving usable structure, ensuring reliable rendering and safer content handling across the builder workflow.

Antimanual Builder Pro applies sanitization at save and render time to keep imported content, AI-generated pages, and stored assets safe for frontend delivery. This dual-layer approach helps preserve valid page structure while filtering out unsafe tags, attributes, and scriptable input surfaces before content reaches visitors.

The goal is not to block normal page building. Instead, the plugin allows predictable content handling for administrators and editors, while reducing the risk of arbitrary code execution, unsafe imports, or content differences between stored data and rendered output.

How the Sanitization Pipeline Works

Sanitization is enforced in two stages. First, when content is saved, the plugin filters the incoming markup and removes unsafe elements. Second, when content is rendered, the frontend output is passed through a strict allowlist again to prevent any legacy or unexpected code from being served.

• Save time: imported markup and editor input are cleaned before storage.
• Render time: output is filtered again before it is displayed on the site.
• Result: content remains usable, but unsupported code is stripped out.

This belt-and-suspenders model is especially important for imported documents and AI-assisted workflows, where content may originate from external sources and require additional validation.

What Gets Removed or Restricted

Antimanual Builder Pro does not expose input surfaces for arbitrary PHP, custom JavaScript, or free-form CSS as part of the import pipeline. Unsafe markup is reduced through an allowlist-based approach, and event-handler attributes are removed before content is saved or displayed.

• Inline script tags are stripped.
• Inline style tags are stripped where they are not permitted.
• Event-handler attributes such as onload or onclick are removed.
• Unsupported tags are blocked by the render allowlist.

For imported pages, the plugin preserves the usable structure of the original document while filtering risky elements. That means headings, sections, text, and layout remain intact, but dangerous code does not persist into the stored page data.

Why Save-Time and Render-Time Checks Both Matter

Running sanitization only once is not enough for a system that supports imports, migrations, revisions, and AI-assisted output. Content can change over time, and older data may still exist in storage. By validating again at render time, the plugin protects the frontend even if older content was saved before stricter rules were introduced.

The render pipeline is the single chokepoint for frontend output, so all theme modes and template paths use the same filtering logic. This keeps the allowed tag set consistent and avoids silent differences between what is saved and what is shown to visitors.

For related setup and security details, see The Advantages and Disadvantages of Developing a Custom WordPress Theme and .

How This Affects Imports and AI Workflows

When you import HTML or ZIP content, the plugin applies sanitization before storage and again before display. This is designed to support real-world migration tasks without giving imported files unrestricted access to the browser or server environment.

AI actions follow the same controlled pattern. Content is sent to external AI providers only when you explicitly trigger an AI feature, and the resulting output is still processed through the same safe rendering pipeline before it appears on the site.

• Imported markup is normalized before it is saved.
• Unsafe attributes and tags are removed consistently.
• Frontend rendering uses a shared allowlist for predictable output.

Developer Notes and Shared Allowlists

In the underlying builder architecture, save-time sanitization is aligned with the shared render allowlist so stored content and rendered content follow the same rules. This reduces the risk of content drift and ensures that the builder does not behave differently depending on who edited the page or which code path handled the request.

The render pipeline also centralizes related operations such as shortcode resolution, dynamic content handling, and artifact stripping. If new rendering behavior is added in future updates, it should be integrated into that shared pipeline rather than duplicated elsewhere.

For implementation context, review Optimizing WordPress: Disabling Forum and eCommerce Features While Retaining Helpdesk Functionality and How to Install the Docy Core Plugin for the Docy WordPress Theme.

Best Practices for Administrators

Although the sanitization system is automatic, administrators should still follow safe import and editing practices. Start with smaller test imports, review migrated pages after generation, and confirm that any third-party assets or custom functionality are compatible with the plugin’s security model.

• Test a small HTML file before importing a large project.
• Review generated pages after AI-assisted creation.
• Verify that assets, media links, and layout elements render correctly.
• Use administrator-level access for import and configuration tasks.

These practices help you take full advantage of the builder while keeping site data controlled, predictable, and safe to publish.

Summary

Sanitization at save and render time is a core protection in Antimanual Builder Pro. It ensures that content is filtered before storage, validated again before output, and kept within a controlled allowlist at every stage. This approach supports secure page generation, safer imports, and more reliable frontend rendering.