Kitsuly 1.44.6 was the broadest manual-review sweep in the WordPress.org compliance branch. Earlier releases had removed the obvious policy blockers and tightened individual areas. This build treated the reviewer email as a specification and checked the entire public package for the same patterns rather than limiting changes to the example lines that had originally been reported.

What changed

Request handling was centralised so normal feature code no longer reached directly into raw GET, POST, REQUEST, COOKIE, SERVER or SESSION superglobals. Typed helpers handled common text, keys, numbers, URLs, arrays and validated uploads, which made it easier to see where data entered the plugin and what kind of value the caller expected.

REST routes were re-audited so every route had an explicit permission callback. Administrative routes use capabilities, logged-in storefront mutations use the appropriate nonce context, and public payment, booking, return, shipment or webhook routes rely on the order/session token or signature that makes the request legitimate rather than a blanket public callback.

The package documentation was expanded as well. External services received clearer disclosures, human-readable source information was documented, the abandoned-cart recovery marker moved to an expiring transient, and the plugin metadata was aligned more closely with the Kitsuly identity used by the submitting account.

Build 1.44.6 changelog

• Removed direct raw request-superglobal reads from feature code and routed inputs through typed helpers.
• Re-audited all custom REST routes and removed blanket `__return_true` permission callbacks.
• Expanded readme disclosures for controller, shipping, analytics, AI, social and other external-service connections.
• Documented maintained human-readable source for the JavaScript assets highlighted during review.
• Changed abandoned-cart per-message send markers from permanent options to expiring transients and rechecked prefixing across WordPress-facing identifiers.

A manual review becomes much harder when the codebase is large because fixing the example is not enough. A reviewer may show one unsanitised request, one public REST route or one direct output call, but the real requirement is that the pattern is understood and addressed everywhere. Build 1.44.6 was therefore built around repeatable audits rather than one-line corrections.

Why this build mattered

The request helpers are a good example of why centralisation helps. Without them, every feature decides independently how to read a value, which makes inconsistent sanitisation almost inevitable over time. A small typed boundary does not remove the need for validation inside the feature, but it gives the codebase a common starting point and makes future review easier.

REST permissions follow the same logic. Some storefront actions must work for guests, but “guest accessible” should not mean “unprotected”. A checkout finalisation request can be public in the WordPress capability sense while still requiring a valid checkout token. Distinguishing those concepts keeps public commerce flows usable without treating every endpoint as trusted.

What the release meant in day-to-day use

For merchants, most of this work should be invisible. A store should not feel different because a request moved from a raw superglobal to a sanitised helper. That invisibility is part of the goal: security and compliance changes are strongest when they remove risk without adding friction to the legitimate workflow.

For maintenance, the value is significant. Future features have clearer patterns to follow, service disclosures are easier to keep complete and storage decisions are less likely to create slow-growing database problems. The code becomes easier to reason about because security expectations are expressed consistently rather than scattered across hundreds of methods.

How it fits into the wider Kitsuly release path

Build 1.44.6 became the base for the final Plugin Check cleanup and manual submission preparation. Later 1.44.x releases still found presentation regressions caused by stricter output filtering, but those fixes could be made without reintroducing the security problems this sweep removed.

That distinction matters. Hardening a large visual plugin can expose assumptions in rendering code, but the answer is not to abandon the hardening. The answer is to restore the intended behaviour through narrow, reviewable compatibility rules. The final releases in the branch would do exactly that.

What to take forward

The broader value of the sweep was confidence. Each major category from the review could be checked again after a later change, which reduced the chance that a visual or functional fix quietly reintroduced an earlier compliance problem. That repeatable checklist became especially important once presentation regressions appeared near the end of the branch.

Large plugins benefit from this kind of discipline because no single developer can remember every security assumption indefinitely. A named request boundary, a known REST permission pattern and a documented external-service section give future work something concrete to preserve. Build 1.44.6 turned the reviewer feedback into those repeatable expectations.

A final benefit was that the sweep produced a much clearer distinction between a false positive and a real architectural issue. Some automated findings can be justified when the code is doing something legitimate, but others are signals that the pattern itself should change. Working through the full list forced each case to be classified deliberately. That discipline matters because suppressing every warning is not the same as fixing the underlying problem, and reviewers can usually tell the difference.