Kitsuly 1.44.0 opened a focused WordPress.org compliance branch. Instead of treating review findings as isolated warnings, the build separated features that belonged in a public directory plugin from behaviours WordPress explicitly discourages or prohibits. The aim was to keep Kitsuly’s commerce systems intact while making the WordPress-facing boundaries much more conventional.

What changed

The first pass removed plugin-controlled WordPress theme installation and activation. Kitsuly’s own native theme packs remain part of the commerce platform because they are layout data owned by the plugin, but normal WordPress themes must be installed and activated by the user through Appearance → Themes. That distinction simplified the relationship between Kitsuly and WordPress core.

Custom customer social-login logic that created users or set authentication cookies was also removed from the public build. Registration and login now stay with WordPress core and compatible security plugins, avoiding a parallel authentication path that could bypass safeguards already present on the site.

The build also removed arbitrary Kitsuly custom-CSS input and default public attribution. WordPress already provides established places for site-level CSS, and public “Powered by” credits cannot be injected without explicit permission. Removing both reduced review risk and made ownership of those behaviours clearer.

Build 1.44.0 changelog

• Removed plugin-controlled WordPress theme installation and activation from the public branch.
• Removed custom user-creation and authentication flows used by customer social login.
• Removed arbitrary custom CSS input from the Kitsuly settings surface.
• Removed default public-facing Powered by Kitsuly attribution and similar forced credit behaviour.
• Separated native Kitsuly theme packs from normal WordPress theme management so each system has a clear boundary.

This was intentionally a hard-blocker release rather than a feature release. A public WordPress plugin has to fit the security and ownership model of the platform it runs on. The safest approach was to remove the questionable behaviours at the root instead of adding more conditions around them and hoping a reviewer would accept the explanation.

Why this build mattered

The theme change is a good example. A merchant can still use Kitsuly’s Theme Adapter and native Kitsuly themes, but choosing the active WordPress theme remains a user action. That is a clearer model for both the merchant and WordPress because one plugin cannot silently replace a site-wide presentation layer owned by core.

Authentication follows the same principle. WordPress has a mature login, password-reset and registration system that security plugins can extend. Kitsuly does not need to recreate that system to provide customer accounts. Letting WordPress own authentication reduces risk while Kitsuly continues to own the commerce data and account experience around it.

What the release meant in day-to-day use

For existing stores, the visible change was mostly around the removed edge features rather than the core store. Products, orders, checkout, Builder layouts and native Kitsuly theme packs remained the focus. Customer accounts continued to work, but account creation returned to WordPress’s standard registration flow.

For development, 1.44.0 created a cleaner base for the deeper audit that followed. Once the obvious policy blockers were gone, later builds could concentrate on REST permissions, request sanitisation, output escaping, source documentation and third-party service disclosures without constantly tripping over larger architectural issues.

How it fits into the wider Kitsuly release path

The 1.44.x line became less about adding headline features and more about proving that a large commerce plugin could be both ambitious and respectful of WordPress conventions. That work can feel slower because many changes are invisible on the storefront, but it reduces the chance that the platform’s complexity becomes a liability.

Build 1.44.0 therefore matters as a reset point. It established the rule that public-directory compliance is a design constraint, not a final checklist. The builds that followed would apply that rule to increasingly detailed parts of the codebase.

What to take forward

The compliance branch also forced a useful product decision: distinguish between features that are fundamental to Kitsuly and features that duplicate WordPress core. Native theme packs, commerce data and the Builder are part of Kitsuly’s value. User authentication and WordPress theme activation already have clear owners in core. Respecting those boundaries reduces both technical risk and conceptual confusion.

That does not mean the platform becomes less ambitious. It means ambition is concentrated where Kitsuly can add something meaningful. Build 1.44.0 removed several shortcuts so the public version could stand on a cleaner architectural foundation, which ultimately makes future features easier to defend, test and maintain.

The release also made future review work more efficient because it removed entire categories of questionable behaviour instead of leaving them behind with special exceptions. Once Kitsuly no longer controlled WordPress theme activation or user authentication, later audits did not need to repeatedly prove those paths were safe. That reduced the number of moving parts in the public package and let the following builds concentrate on the areas Kitsuly genuinely needed to implement itself.

There was also a product-management benefit in drawing these boundaries clearly. A merchant can now understand that Kitsuly manages the commerce experience while WordPress still owns site-wide theme activation and authentication. That separation reduces surprise. The plugin can integrate deeply without pretending to be the operating system underneath WordPress, which makes upgrades and support easier to explain.