Kitsuly 1.44.9 addressed an important lesson from the WordPress.org hardening work: security boundaries can be correct and still expose presentation assumptions in a visual Builder. After generated storefront HTML began passing through stricter WordPress `wp_kses()` filtering, some legitimate Builder styling was removed, causing text colours and other presentation details to fall back unexpectedly.

What changed

The regression was traced to WordPress’s safe inline-CSS list. Kitsuly generates controlled styling for visual components, but properties such as `-webkit-text-fill-color`, display behaviour, opacity and transforms were not all preserved by the default filter used during the final HTML sanitisation pass.

Rather than backing out the escaping work, the fix extended WordPress’s safe-style list only for the bounded presentation properties Kitsuly itself generates. Values still pass through the WordPress CSS safety filter, and the public build does not reintroduce a free-form custom-CSS field.

The storefront also gained a text-colour inheritance safeguard so ordinary nested elements such as paragraphs, spans and emphasis tags inherit the colour chosen in the Builder unless a more specific child style deliberately overrides it. That restored visual parity without weakening the content boundary.

Build 1.44.9 changelog

• Added a prefixed safe-style compatibility filter for Builder presentation properties used by Kitsuly-generated markup.
• Restored text-fill, display, opacity, transform and related visual behaviour removed by the stricter `wp_kses()` pass.
• Added text-colour inheritance protection for normal nested content inside Builder text elements.
• Kept arbitrary user-supplied custom CSS disabled in the public WordPress.org branch.
• Re-ran PHP, JavaScript and compliance-pattern checks after the styling fix.

This release is a good example of why visual parity needs real-store testing after security changes. A static code review can confirm that output is sanitised, but it cannot tell whether a brand’s light text has just become dark on a dark section. The correct solution has to satisfy both requirements: the markup remains constrained, and the merchant’s deliberate design remains visible.

Why this build mattered

WordPress’s safe-CSS system is intentionally conservative because inline style attributes can become an injection path. A visual Builder legitimately needs more presentation properties than a typical blog post, but that does not justify disabling the filter. The safer approach is to name the exact properties the Builder generates and let the rest remain disallowed.

That keeps the trust boundary understandable. Merchants can still choose colours, spacing, transitions and positioning through structured controls, while the plugin generates the CSS. They are not pasting arbitrary code into a textarea. The Builder remains expressive because the application knows what each control means.

What the release meant in day-to-day use

For merchants, the practical effect was immediate: published pages could once again match the colours and visual treatments shown in the Builder. That is essential because a no-code editor loses trust quickly if the preview and the live page disagree in basic styling.

For development, the release created a better compatibility layer for future Builder components. New visual controls can be checked against the safe-style allowlist deliberately, rather than discovering after release that a browser-facing property disappeared during output sanitisation.

How it fits into the wider Kitsuly release path

Build 1.44.9 arrived late in the compliance branch, after Plugin Check and manual-review work had already tightened requests, REST permissions and output. The remaining challenge was preserving the richness of a visual commerce platform inside those safer boundaries.

The release did not attempt to choose between security and design. It treated the regression as evidence that the integration layer needed to be more precise. That approach would continue in the final builds as account content, post content and the documentation library were restored through narrower structural fixes rather than by removing sanitisation.

What to take forward

The fix also demonstrated why a visual builder needs its own compatibility tests. Security tests can confirm that unsafe markup is rejected, while design tests confirm that approved settings survive the same boundary. Both are necessary. A secure page that ignores the merchant’s chosen colours is not a finished result, just as a beautiful page that accepts arbitrary code is not a safe result.

Build 1.44.9 therefore added a more precise contract between the Builder and WordPress sanitisation. Kitsuly declares the presentation properties it needs, WordPress still filters the values, and the merchant continues to work through structured controls. That is a stronger long-term model than bypassing sanitisation whenever a design regression appears.

The same principle applies to future animations and interaction controls. If a new Builder option requires a CSS property that WordPress does not currently allow through the safe filter, it can be reviewed and added deliberately instead of bypassing the boundary. That makes each new capability explicit and testable. The visual system remains capable of growing, but the list of accepted presentation behaviour stays understandable to developers and reviewers rather than becoming an unrestricted escape hatch.

This also makes regression testing more concrete. A release can deliberately check dark sections, gradient text, transformed components, responsive visibility and hover states after sanitisation changes. Those tests are now part of maintaining the Builder contract rather than emergency checks performed only after a visual problem reaches the live site.