Kitsuly 1.44.11 closed the WordPress.org preparation branch by fixing the last visible regressions without reopening the security problems that caused them. The two main issues were structural: live account content had been hydrated after the footer, and the owner-site document library no longer matched the four-column PDF experience used on Kitsuly.com.

What changed

Responsive live content was changed from a cloned template model to a single hidden payload that is moved into the active desktop, tablet or mobile slot. Account, checkout and other live commerce interfaces should exist only once because duplicating forms, IDs or payment widgets across hidden responsive trees can create conflicts. Moving the one payload preserved that rule while restoring the correct document order.

The final HTML allowlist was also tightened in a more deliberate way. Semantic wrappers used by Kitsuly — including main, header, footer, nav, section, article and aside — were explicitly preserved so the sanitisation boundary could not flatten the structure that determines where the account content sits relative to the footer.

The Kitsuly.com documentation library was restored as an owner-site-only component with four cards across on desktop, responsive reduction on smaller screens and a modal iframe viewer for the PDF guides. The files continue to come from the local Kitsuly.com WordPress uploads area rather than a remote service used by customer installations.

Build 1.44.11 changelog

• Moved the single live account/checkout/page payload into the active responsive Builder slot instead of cloning it after the page shell.
• Explicitly preserved the semantic document wrappers required for header, content and footer ordering through `wp_kses()`.
• Restored the four-column Kitsuly documentation grid on the owner site.
• Restored the modal iframe PDF viewer plus Open in new tab and Close controls.
• Kept the executable 1.44.11 runtime stable for the final WordPress.org submission package while later packaging changes were limited to readme disclosures and metadata.

This release mattered because the remaining problems were exactly the sort that can appear after a large compliance refactor: the code is safer, but a small structural assumption changes how a real page behaves. The correct response was not to roll back the security boundary. It was to understand why the account content moved and why the document component changed, then fix the narrow integration point.

Why this build mattered

The account issue highlighted why responsive builders need special care with live forms. Rendering three copies for desktop, tablet and mobile may look harmless when two are hidden, but IDs, payment elements, account forms and scripts can still interact. Keeping one live payload and moving it into the active tree is a stronger model because the DOM contains only one real commerce interface.

The documentation issue reinforced a different rule: private owner-site functionality can coexist with a public plugin when the boundary is explicit. The guide library uses same-origin files on Kitsuly.com and does not turn customer sites into consumers of a Kitsuly document service. That preserves the existing site experience without introducing an undocumented dependency for merchants.

What the release meant in day-to-day use

For the merchant-facing store, account content returned to the expected order: header, page content, account interface and then footer. Normal post/page content, checkout and other dynamic pages use the same single-payload idea, which also protects against the earlier regression where live content disappeared when an unsupported carrier element was filtered.

For Kitsuly.com, the documentation page returned to the visual library people were already using. Large cover cards remain easy to scan, while the iframe viewer keeps the reader inside the page. Because the PDFs are copied from local uploads, deleting the temporary content-pack or updating the commerce plugin does not remove the documents themselves.

How it fits into the wider Kitsuly release path

Build 1.44.11 became the final tested runtime for the WordPress.org submission candidate. Plugin Check returned no issues, and the last package sweep compared the executable files byte-for-byte so readme disclosure changes could be made without accidentally changing the working store again.

The release is therefore a useful marker for the end of a difficult but valuable branch: major policy blockers removed, request and REST boundaries tightened, output sanitised, visual regressions repaired and the public package made easier to review. The next releases can return more of the focus to feature development from a cleaner base.

What to take forward

The final candidate process also established an important release habit: freeze the working runtime before packaging. Once the account, documents, Builder and checkout flows were behaving correctly, the submission package was compared against that tested build so later readme edits could not accidentally alter executable behaviour. That separation made the final review step much less risky.

For merchants, that discipline is invisible, but it is exactly the kind of invisible work a commerce platform needs. Stores depend on continuity. A compliance change should not move an account below the footer, erase post content or alter a payment flow without being noticed. Build 1.44.11 turned those last regressions into concrete checks for future releases.