Kitsuly 1.43.99 was a small version number with a deliberately practical goal: make the store’s identity behave like one identity. Logos and favicons appear in many places across WordPress, themes, browser tabs and storefront components, so Kitsuly moved toward WordPress core as the canonical storage point instead of maintaining another disconnected copy.

What changed

The Site Identity controls were connected to WordPress’s existing `custom_logo` and `site_icon` settings. That meant a logo selected through Kitsuly could be understood by WordPress itself, and a site icon could use the same core mechanism WordPress already knows how to output in the frontend and administration environment.

This removed the need for Kitsuly to print a competing favicon tag directly into the document head. Relying on the core site-icon pipeline is cleaner, more compatible with themes and less likely to create two icons fighting for control when another part of WordPress also manages site identity.

The change also improved portability. A store may move between Kitsuly Native mode and an inherited WordPress theme, but the site identity should not disappear just because the rendering layer changes. Storing the logo and icon in the WordPress-standard locations helps those assets follow the site rather than remain trapped inside one plugin screen.

Build 1.43.99 changelog

• Synced Kitsuly Site Logo selection with WordPress core `custom_logo`.
• Synced favicon/site-icon selection with WordPress core `site_icon`.
• Removed the need for a custom direct favicon link in the page head.
• Improved consistency when moving between Kitsuly Native mode and inherited WordPress themes.
• Kept the Kitsuly Site Identity interface while using WordPress as the shared storage layer.

Branding settings often look trivial until they disagree. A merchant should not have to remember that the storefront logo lives in one place, the browser icon in another and the active theme has a third idea of what the site identity should be. Build 1.43.99 reduced that duplication by letting Kitsuly use the core settings WordPress already exposes.

Why this build mattered

The biggest benefit is predictability. WordPress themes and core functions already know how to ask for the custom logo and site icon. By syncing Kitsuly to those values, the same media choice can be recognised by more of the environment. That is a better long-term position than forcing every theme bridge or storefront template to know about a private Kitsuly-only setting.

The site icon is particularly easy to overlook during development because it occupies very little screen space. Customers still see it in tabs, bookmarks, browser history and mobile shortcuts. A missing or inconsistent favicon can make an otherwise polished store feel unfinished, so giving it a reliable source is part of the overall brand experience.

What the release meant in day-to-day use

For merchants, the day-to-day change is simple: choose the identity once and expect it to follow the site. The Builder can still display the store logo as part of the header design, while WordPress handles the core site-level identity. That division keeps design flexibility without duplicating ownership of the same asset.

For compatibility, this also means fewer special cases. A theme that respects `custom_logo` can pick up the Kitsuly-selected logo, and WordPress can output the favicon through its normal hooks. The result is less custom code doing work that core already understands.

How it fits into the wider Kitsuly release path

Build 1.43.99 arrived just before the large WordPress.org compliance branch, so the direction was important. The release reduced unnecessary custom behaviour and leaned on WordPress standards where those standards already solved the problem. The following 1.44.x builds would apply the same principle much more aggressively across security, themes, requests and output.

That is a useful pattern for a WordPress-native commerce platform: own the things Kitsuly genuinely needs to own, but integrate with core when WordPress already has a mature system. Site identity is a good example of where cooperation produces a cleaner result than reinvention.

What to take forward

A shared identity layer also helps when a merchant changes how the storefront is rendered. The logo may appear in a Kitsuly header today and a WordPress theme header tomorrow, but the underlying media choice should remain the same. That continuity reduces the number of branding settings that need to be remembered during a redesign or migration.

Small platform integrations like this are easy to underestimate because they do not create a dramatic new screen. Their value appears later, when a theme, plugin or WordPress update asks for the same core identity data and the answer is already available in the standard place. Build 1.43.99 made that future behaviour more predictable.

That shared identity also simplifies troubleshooting. If a logo does not appear, there is now a standard WordPress value to inspect rather than several independent plugin and theme settings that may disagree. Fewer competing sources make support easier and reduce the chance that a later theme change accidentally restores an old logo or favicon. The result is not only cleaner visually; it is easier to reason about when something needs to be fixed.