Every block uploaded to wpTruss is run through the block validator before WordPress registers it. The validator checks a set of governance rules that enforce security, token compliance, and structural correctness.
Blocks that fail a hard error rule are rejected, WordPress never sees them. Blocks that pass but have warnings are registered normally, but the violations appear in the debug panel.
How Validation Is Triggered
Validation runs automatically:
- When a block ZIP is uploaded via Custom Blocks → Blocks tab
- When the plugin boots and scans the
custom-blocks/directory
You can also view previous validation results in Custom Blocks → Debug Panel for any registered or rejected block.
The Validation Result Object
The validator returns a structured result:
{
"passed": true,
"errors": [],
"warnings": [],
"violations": [],
"summary": "Block passed all governance checks."
}
A block with any errors entry does not register. A block with only warnings registers normally. Both are logged.
Comment Stripping
Before scanning JS or CSS files, the validator strips all comments. This prevents documentation text, including words like transition or innerHTML in a comment, from triggering false positive failures. Only executable code is scanned.
Custom CSS and the Validator
The validator scans only the CSS files that ship inside the block folder (style.css and any other .css files). It does not and cannot scan CSS added through WordPress’s own Additional CSS field, Customizer CSS, or any other site-level CSS mechanism. Those are outside the wpTruss block governance scope.
If a developer adds transition: or animation: directly through WordPress Custom CSS (not through a block file), the validator will not catch it. That is a site-level decision and responsibility, not a block-level one.