No Custom CSS/JS/PHP Input Surfaces​

Summary: Antimanual Builder blocks arbitrary CSS, JavaScript, and PHP input surfaces by design. This documentation explains how the plugin generates safe output, sanitizes saved content, and keeps page building controlled. Use supported editor settings and built-in blocks for customization without exposing your site to unsafe code.

Antimanual Builder does not provide any input surface for custom CSS, JavaScript, or PHP. This is an intentional security design choice that keeps page creation controlled, predictable, and safe. Instead of accepting arbitrary code, the plugin generates approved output from structured settings, predefined block logic, and sanitized import workflows.

This means you can build and customize pages visually, use supported options from the editor, and rely on the plugin’s built-in behaviors without exposing your site to unrestricted code execution. If you are looking for a way to inject raw styles or scripts directly into the builder, that option is not available.

What “No Custom CSS/JS/PHP Input Surfaces” Means

The plugin does not include a code editor for authoring custom CSS, JavaScript, or PHP. It also does not expose a REST endpoint that stores or runs user-supplied code. In practical terms, there is no place in the interface where raw code can be pasted, saved, and later executed by the page renderer.

Instead, Antimanual Builder relies on controlled editor inputs and programmatic generation. Styles are derived from block settings and structured selector-property mappings, while interactive behavior comes only from hard-coded scripts that ship with the plugin. For a broader overview of this architecture, see Spider Themes Helpdesk.

How the Plugin Handles CSS

Custom CSS is not accepted as free-form text. Page styling is generated from editor-controlled values and a structured style map that maps selectors to properties. This approach gives the builder enough flexibility to create polished layouts while avoiding unrestricted stylesheet injection.

• Styles are generated from approved block settings.
• Free-form CSS text is not stored or rendered.
• Unsafe inline style patterns are removed during sanitization.
• Import and save operations preserve structure without allowing arbitrary style execution.

If you need advanced presentation control, use the supported design settings in the builder rather than trying to insert raw CSS. This keeps the output consistent across pages and reduces the chance of conflicts with theme or plugin updates.

How the Plugin Handles JavaScript

Antimanual Builder does not offer a JavaScript input field and does not persist user-authored scripts. The only JavaScript that runs is the built-in code required for supported interactive elements such as tabs, accordions, counters, and similar components. These scripts are included only when the corresponding block is present on the page.

This design prevents unsupported scripts from being injected into the page editor or saved through plugin APIs. It also helps ensure that interactive features remain predictable and compatible with the rest of the system. If you are evaluating supported editing capabilities, review .

How the Plugin Handles PHP

There is no PHP input field in the user interface and no API route that accepts or executes PHP code supplied by users. The plugin is built so that PHP remains part of the internal application layer, not an editable content layer. This separation is important because PHP execution would introduce unnecessary risk in a content builder.

As a result, page authors can configure layouts and content, but they cannot embed executable server-side logic directly into builder content. That keeps the editor focused on presentation and content management rather than code execution.

REST Sanitization and Save-Time Filtering

All save endpoints are designed to strip unsupported code-related parameters such as customCss and customJs. The plugin also removes inline style and script patterns, along with event-handler attributes, before data is stored or rendered. This protects the application from unsafe input that could otherwise persist in the database.

Sanitization is applied both at save time and at render time. That double-layer approach helps ensure that unsafe markup does not bypass validation during page creation, import, or display. For related handling of imported content, see Introducing Docly Documentation WordPress Theme 2.0.0.

What You Can Use Instead

Although raw code injection is not supported, the plugin still provides practical ways to customize your pages. Use the visual editor controls, supported blocks, component templates, and built-in import workflows to shape layout and behavior within the system’s safe boundaries.

• Adjust block content and structure through the editor.
• Use supported design controls for spacing, typography, and colors.
• Reuse saved components and templates for consistent design.
• Rely on built-in interactive blocks for common UI patterns.

Best Practices for Safe Customization

To keep your workflow stable, avoid expecting the builder to behave like a general-purpose code editor. The plugin is intentionally restrictive, which helps reduce security concerns and keeps generated pages easier to maintain. When you need deeper customization, place that logic in the appropriate WordPress theme or plugin layer rather than inside builder content.

• Use builder settings for visual customization.
• Do not expect raw CSS, JavaScript, or PHP fields in the editor.
• Review import content carefully when migrating existing pages.
• Keep code-level changes outside the content layer.

Summary

Antimanual Builder is built to avoid arbitrary code input surfaces by design. It does not allow user-supplied CSS, JavaScript, or PHP, and it sanitizes content to prevent unsafe execution paths. This creates a controlled editing experience that supports page building while protecting site integrity and rendering consistency.