Gatey 2.4.0 – Shadow DOM isolation and shared WPSuite styling

This release moves the Authenticator and Account Attribute blocks into the Shadow DOM, improves initial paint timing, and adds shared WPSuite Theme CSS plus pattern override support.

What changed

• Authenticator and Account Attribute now render inside the Shadow DOM.
• Added schedule-after-initial-paint mounting so frontend UI can yield the main thread sooner.
• Added support for shared WPSuite Theme CSS in supported shadow-root UI.
• Added pattern override support so synced patterns can override selected original block attributes without duplicating the full block setup.

Why this matters

• Gatey UI is now better isolated from theme CSS leakage in both directions.
• Shared WPSuite Theme CSS provides a supported way to style reusable component chrome across WPSuite plugins.
• Pattern overrides make synced Gatey setups easier to reuse across pages and patterns.
• Later mounting can improve early paint behavior on affected pages.

Upgrade notes

• This is a breaking styling change.
• Any Gatey styling that previously relied on site-level CSS reaching Authenticator or Account Attribute must be moved into WPSuite Theme CSS or the block-level themeOverride attribute.
• Review custom CSS after upgrading if you previously styled Gatey directly from theme or site CSS.

Gatey 2.3.2 – Frontend loading performance improvements

This release improves frontend loading behavior across WP Suite pages.

• WP Suite runtime scripts and shared vendor assets are now loaded from the page footer and use deferred execution where safe. The lightweight WpSuite bootstrap remains available early without forcing heavier dependencies into the page head.

• The result is a cleaner initial rendering path, less render-blocking script work, and better performance characteristics for Gutenberg-based pages and static exports. No configuration changes are required.

Gatey 2.3.2 – Fix Authenticator redirect loop and frontend CSS

This release restores missing Authenticator frontend CSS from the block view script, fixes a site-specific redirect loop that could occur after returning from sign-in on some WordPress setups, and adds optional login/logout diagnostics to help troubleshoot remaining edge cases.

What changed

• Restored the Authenticator frontend CSS rules that were missing from the block view script, including the .sr-only helper used to visually hide the optional "Powered by" attribution.
• Improved sign-in redirect handling by normalizing current and target URLs before redirecting, preventing self-redirect loops when equivalent URLs were represented differently.
• Added optional Gatey login/logout debug logging in the WordPress backend to capture request context, user roles, configured redirect settings, and resolved next URLs without logging raw bearer tokens.

Why this matters

• Fixes environment-specific redirect loops caused by absolute vs relative URLs, trailing slash differences, query strings, or sites where the sign-in page and return target effectively resolve to the same page.
• Makes it much easier to diagnose remaining site-specific WordPress login issues if they still occur.

Upgrade notes

• Recommended update for sites using Gatey sign-in redirects or WordPress login integration.

Gatey 2.3.1 – Pattern list and shortcode copy fixes

This release tightens the Gatey Patterns admin view and aligns the copied shortcode with the shortcode handler.

What changed:

• Gatey Patterns now lists only reusable blocks that actually contain the Gatey Authenticator block.
• The copied shortcode now uses [gatey id="..."], matching the runtime shortcode parser.
• The WordPress.org readme now explicitly documents the saved-pattern shortcode format.

Why this matters:

• Admin users no longer see unrelated reusable blocks in the Gatey Patterns list.
• Copying a shortcode from wp-admin now produces a working embed without manual correction.
• The shortcode reference in the readme now matches the actual plugin behavior.

Upgrade notes:

• No configuration changes are required.
• If you use copied Gatey shortcodes, prefer the id-based form going forward.

Gatey 2.3.0 – Customized Authenticator foundation

This release updates Gatey’s customized Authenticator foundation and refreshes WordPress compatibility metadata.

What changed

• Moved the customized AWS Amplify UI React packages to the @smart-cloud npm scope.
• Gatey now uses the @smart-cloud/aws-amplify-ui-react package family for the customized Authenticator experience.
• Reduced reliance on locally patched upstream frontend packages.
• Updated the plugin metadata to mark compatibility with WordPress 7.0.

Why this matters

Gatey uses a customized version of the Amplify Authenticator foundation to support its WordPress-specific authentication screens and integrations. Publishing those customized packages under the Smart Cloud scope makes dependency ownership clearer and future updates easier to manage.

Upgrade notes

No configuration changes are required.

This update is recommended for all sites, especially if you maintain custom builds or track Gatey’s bundled frontend dependencies.

Gatey 2.2.2 – Improved Cognito JWT verification

This maintenance release improves Cognito JWT verification reliability and hosting compatibility.

What changed

• Replaced the previous Cognito-specific token verification dependency with a small Gatey-owned verifier.
• Switched JWKS retrieval to the WordPress HTTP API, improving compatibility with hosts where PHP URL file access (allow_url_fopen) is disabled.
• Added WordPress transient caching for Cognito JWKS responses.
• Added a one-time JWKS refresh path when token verification fails due to a possible signing key mismatch.
• Kept cryptographic JWT verification delegated to the maintained firebase/php-jwt library.
• Improved error handling and WordPress.org plugin-check compatibility.

Upgrade notes

No configuration changes are required.

This update is recommended for all sites, especially WordPress installations on restrictive shared hosting environments.

Gatey 2.2.1 – Improved site settings persistence

• Updated project dependencies.
• Improved site settings persistence so saving plugin-specific settings no longer overwrites the global reCAPTCHA configuration accidentally.

Gatey 2.2.0 – TypeScript 6 and WordPress typing update for admin and blocks

This release modernizes Gatey’s admin and block packages for newer TypeScript and WordPress typing expectations.

What changed

• Updated Gatey packages for TypeScript 6 compatibility.
• Aligned admin and block code with newer WordPress typings.
• Fixed typing regressions affecting development and build stability.
• Standardized the InfoLabel / openInfo pattern across nested settings editors.
• Improved consistency of help-drawer behavior in the admin UI.

Why it matters

This update makes Gatey easier to maintain against newer WordPress and TypeScript tooling, while also improving internal UI consistency in the admin settings experience.

Impact

• No configuration changes required
• Improves build and editor stability
• Makes nested admin help-drawer behavior more consistent

Gatey 2.1.10 – Authenticator remount fix

This release fixes Authenticator-specific mounting behavior.

What changed

• Adjusted Authenticator mounting so Authenticator screens can fully remount when needed.
• Corrected issues introduced by the previous mount hardening changes in cases where full screen remounting is part of the expected behavior.
• Improved reliability of Authenticator screen transitions and re-rendering.

Why it matters

Unlike simpler frontend components, Authenticator screens require full remounting in certain flows. The earlier mount-hardening changes were too strict for this behavior. This update restores the required remount logic while keeping the overall initialization more robust.

Impact

• No configuration changes required
• Recommended for all Gatey users
• Important fix for Authenticator screen behavior

Gatey 2.1.9 – Safer frontend mounting and shared race-condition hardening

This release improves frontend initialization reliability.

What changed

• Improved frontend mounting so components cannot mount multiple times in parallel on the same element.
• Unified the shared race-condition protection into a common helper.
• Reduced the chance of duplicate frontend initialization in edge cases.

Why it matters

In some cases, frontend race conditions could allow duplicate parallel mounts on the same target element. This update makes initialization more deterministic and improves overall frontend stability.

Impact

• No configuration changes required
• Improves frontend stability
• Reduces duplicate initialization issues