No Arbitrary Code Estimated reading: 4 minutes 4 views Contributors Summary: Antimanual Builder Pro blocks arbitrary PHP, JavaScript, and CSS to improve security, prevent unsafe output, and keep page building predictable. Learn how structured controls, sanitization, and safe imports protect your site while preserving flexible design workflows. No arbitrary code is allowed in Antimanual Builder Pro. The plugin is designed to support structured page building, AI-assisted generation, and controlled imports without exposing a code editor or execution surface for user-supplied PHP, JavaScript, or raw CSS. This approach helps reduce risk while keeping the editing experience flexible and predictable. Pro Tip: Explore the advantages and disadvantages of developing a custom WordPress theme with The Advantages and Disadvantages of Developing a Custom WordPress Theme before deciding whether custom code fits your project. What “No Arbitrary Code” Means In this context, arbitrary code refers to custom scripts or styles entered freely by a user and then stored or executed by the plugin. Antimanual Builder Pro does not provide a UI for pasting raw PHP, JavaScript, or free-form CSS into builder pages. It also does not expose an API endpoint that accepts and runs such code. Instead, the plugin relies on structured inputs, visual controls, and validated content pipelines. Page output is assembled from builder settings, block data, and sanitized imported markup. The Advantages and Disadvantages of Developing a Custom WordPress Theme explains the broader protection model used during save and render operations. What Is Blocked Antimanual Builder Pro does not support these arbitrary code inputs: Custom PHP entered in the builder interface User-authored JavaScript pasted into page settings Free-form CSS fields that accept unstructured styles Inline event handlers such as onclick or onload in imported content Unrestricted script tags or style tags in rendered output This limitation is intentional. It keeps page generation within the plugin’s supported feature set and prevents content from bypassing the controls used for validation, storage, and frontend rendering. How the Builder Handles Styling and Behavior Rather than accepting arbitrary CSS, the plugin generates styles programmatically from builder settings and structured selector-property mappings. Visual controls determine layout, spacing, colors, and typography, and the resulting output is compiled by the system. For interactive behavior, the plugin uses built-in scripts for supported components such as tabs, accordions, and counters. These scripts are bundled with the product and are only activated when the corresponding component exists on the page. Users cannot inject their own JavaScript to alter that behavior. For a practical example of how the import flow stays controlled, see . What Happens During Import Imported content is treated differently from generated builder output. If you bring in your own HTML or ZIP project, the plugin preserves user-owned markup while applying sanitization rules to reduce risk. This means the original structure can remain intact, but unsafe elements are filtered before storage or display. Typical protections include stripping inline script tags, style tags, and event-handler attributes from imported documents. Frontend output is then filtered through a restricted allowlist so that unsupported code does not reach the browser. Imported markup is sanitized before storage Inline scripts and styles are removed from unsafe contexts Event-handler attributes are stripped during processing Frontend rendering uses a strict allowlist Why This Matters for Site Security Blocking arbitrary code reduces the attack surface of the builder. It helps prevent accidental breakage, malicious injections, and conflicts caused by unsupported scripts or styles. It also makes page behavior more consistent across environments, since output is generated from known plugin logic rather than user-authored executable code. This is especially important in team environments where multiple users may have access to the site. A controlled builder workflow makes it easier to govern permissions and maintain predictable publishing standards. Related access details are covered in How to Install the Docy Core Plugin for the Docy WordPress Theme. Best Practices for Safe Page Building To work effectively within the plugin’s security model, follow these recommendations: Use the visual editor and built-in component settings instead of custom code Import only trusted HTML or ZIP files that you control Review generated output after migrations or large imports Avoid relying on unsupported scripts for layout or interactivity Use documented plugin features for design, animation, and dynamic content If you need to troubleshoot generated pages, the section on is a useful next step because it explains how to refine content using supported builder tools. Summary Antimanual Builder Pro follows a script-free, structured content model. It does not allow arbitrary PHP, JavaScript, or free-form CSS input, and it sanitizes imported content before rendering. The result is a safer, more predictable builder experience that still supports advanced page creation through approved tools and controlled imports. ArticlesNo Custom CSS/JS/PHP Input Surfaces Sanitization at Save and Render Time No Arbitrary Code - PreviousSecurity and Data HandlingNext - No Arbitrary CodeNo Custom CSS/JS/PHP Input Surfaces