Skip to content

Releases: smartcloudsol/flow

Flow v1.1.10 – Gallery support and shared WPSuite styling

01 Jun 15:12

Choose a tag to compare

This release adds the new Gallery block, improves initial paint timing with later mounting, and brings shared WPSuite Theme CSS plus pattern override support to Flow.

What changed

  • Added schedule-after-initial-paint mounting so Flow UI can yield the main thread sooner during initial render.
  • Added the Gallery block with modal-aware start-position support.
  • 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 whole pattern.

Why this matters

  • Flow pages can start rendering with less main-thread pressure.
  • Gallery is especially useful together with Flow Modal because opening triggers can control which image the modal gallery should start from.
  • Shared WPSuite styling reduces repeated CSS and makes cross-plugin visual consistency easier.
  • Pattern overrides make reused synced patterns more practical in real content setups.

Upgrade notes

  • No mandatory migration is required.
  • If you use shared frontend styling for WPSuite components, move reusable rules into WPSuite Theme CSS.
  • If you use Flow Modal together with Gallery, you can now control the opening image from the trigger side.

Flow v1.1.8 – Frontend loading performance improvements

30 May 13:22

Choose a tag to compare

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.

Flow v1.1.8 – Plugin check output escaping fixes

28 May 16:36

Choose a tag to compare

This release adds explicit escaped output handling in two Flow rendering paths so the plugin package passes WordPress plugin security checks more cleanly, without changing the intended runtime behavior.

What changed

Added explicit escaped output handling for modal block.
Added explicit escaped output handling for the Flow Patterns shortcode admin column markup.

Why this matters

Prevents WordPress.Security.EscapeOutput.OutputNotEscaped-style plugin check failures during release packaging.
Keeps the fix narrowly scoped to output hardening, with no expected behavior change for modal content or shortcode copying.

Upgrade notes

Recommended maintenance update if you run WordPress plugin checks or prepare Flow for release packaging.
No configuration or content changes are required.

Flow v1.1.7 – Modal pending-state and header polish

28 May 16:11

Choose a tag to compare

This release tightens up the Flow modal runtime and its documentation after the recent modal editor and action-system work. It focuses on clearer async action feedback, cleaner modal header spacing, and more explicit modal API guidance for integrators.

What changed

  • Added a generic pending-state hook for async modal actions so the active trigger can be styled while an awaited handler is running.
  • Fixed modal header spacing so extra room is only reserved when the built-in close button is actually rendered.
  • Expanded the modal API documentation with dismiss lifecycle coverage, role-based modal actions, and async action handler behavior.

Why this matters

  • Async modal actions now have a stable, markup-agnostic pending signal that works with core Button blocks and custom triggers alike.
  • Modal headers no longer waste space when the built-in close button is hidden.
  • Integrators have clearer guidance for dismiss handling, default action roles, and pending-state styling without relying on Mantine-specific UI assumptions.

Upgrade notes

  • Recommended update if you use Flow modals with async actions or custom modal headers.
  • No content migration is required.
  • If you style modal triggers yourself, you can now target the pending state through the active trigger attribute added by the runtime.

Flow v1.1.6 – Modal editor and runtime polish

27 May 16:58

Choose a tag to compare

This release tightens up the new light-DOM modal block after the 1.1.5 launch. It focuses on better Gutenberg integration, more predictable modal action handling, more stable full-height layouts, and a smoother editing workflow for modal sections and action buttons.

What changed

  • Improved class-based modal trigger detection for Gutenberg button wrapper markup.
  • Dismiss and default modal actions now run more consistently across close button clicks, overlay clicks, Escape, and other close paths.
  • Full-height modal layouts are more stable, including sticky header/actions behavior, background scroll locking, and Group/Stack-converted slot wrappers.
  • The modal editor now seeds safer default header/body/actions sections and adds toolbar actions to insert or replace those sections.
  • Modal action behavior editing now lives on the selected core/button toolbar, with clearer current-state feedback for primary, secondary, and dismiss roles.

Why this matters

  • Stock Gutenberg buttons behave more reliably as modal triggers without extra markup workarounds.
  • Close-related automation is more predictable because dismiss handling is centralized across modal close paths.
  • 100%-height modal layouts stay usable even after block conversions or slot restructuring in the editor.
  • Editing modal structure is faster because header, body, and actions management is now directly available from the modal toolbar.

Upgrade notes

  • No manual migration is required.
  • Existing modal content should continue to work.
  • If you are testing locally and do not see the updated modal behavior immediately, clear any cached plugin assets in the browser or WordPress environment.

Flow v1.1.5 – Modal runtime, smarter endpoint interpolation, and safer API-backed fields

26 May 09:22

Choose a tag to compare

This release rounds up the work since 1.1.4 around the new modal surface, custom endpoint control, API-backed field loading, and backward compatibility for existing saved Flow blocks.

What changed

  • Added the new Modal top-level block with a light-DOM native dialog runtime, class/data/hash triggers, and browser helpers on WpSuite.plugins.flow.modals.
  • Expanded custom form submission so forms can use GET, POST, PUT, or PATCH, add optional browser-side endpoint headers, and interpolate endpoint paths and header values from WordPress, location, query, global, and current form-field context.
  • Expanded API and autocomplete-backed select, radio, checkbox-group, and tags fields so endpoint URLs, headers, and parameters all support runtime interpolation.
  • Fixed repeated option-endpoint refetch loops for API-backed fields when dynamic params or headers depend on current form values such as email.
  • Added smartcloud-flow:options-request-error for host-page integrations and improved field-level API error rendering so users see a readable message instead of raw JSON.
  • Improved multi-choice UX with clear-all support for API-backed checkbox groups, consistent pointer affordance on checkboxes, and hidden-field wrapper styling that no longer affects runtime gaps.
  • Added legacy Gutenberg deprecated save definitions for older serialized Flow field and container payloads so previously saved blocks no longer fall into block recovery after serializer normalization changes.
  • Expanded plugin, shortcode, JavaScript API, and knowledge-base documentation for modal usage, custom endpoint settings, interpolation, and runtime error handling.

Why this matters

  • Host pages can now build preference centers and other dynamic forms with richer request control without custom proxy glue just to vary method, headers, or query params at runtime.
  • API-backed fields are more stable in production: fewer accidental request storms, clearer recovery hooks, and cleaner end-user errors when an endpoint rejects a request.
  • Existing saved Flow content is safer to upgrade because older serialized markup shapes are now accepted through Gutenberg deprecations instead of forcing recovery.

Upgrade notes

  • Recommended update if you use modal-driven UX, custom submit endpoints, or API-backed field options.
  • If you have host-page integrations, prefer smartcloud-flow:options-request-error and use detail.message for user-facing UI while keeping responseText for diagnostics only.
  • If you had older saved Flow blocks showing Attempt Block Recovery, re-opening them under 1.1.5 should validate against the new deprecated save compatibility layer.

Flow v1.1.4 – Content-root pattern support in admin

24 May 12:46

Choose a tag to compare

This release expands the Flow Patterns admin view so reusable content-root patterns can be discovered and copied alongside form patterns.

What changed:

  • Flow Patterns now includes reusable blocks that contain either a Flow Form block or a Flow Content Root block.
  • The shortcode column now shows the matching copy-ready shortcode for each pattern, including content-root entries.
  • The WordPress.org readme now mentions Flow Content Root reuse outside Gutenberg and the related Elementor/widget path.

Why this matters:

  • Content-root based reusable blocks are now visible in the same admin workflow as form patterns.
  • Copying the right shortcode is faster because the admin column reflects the actual renderable root block.
  • The readme now better reflects the current shortcode and widget surface.

Upgrade notes:

  • No configuration changes are required.
  • Recommended update if you embed Flow patterns outside Gutenberg or need copy-ready content-root shortcodes.

Flow v1.1.3 – Form-scoped field defaults

23 May 09:15

Choose a tag to compare

This release adds a form-scoped JavaScript default-value API to Flow and updates the frontend runtime so rendered forms consume stored defaults by formId. It also publishes the documented helper methods on WpSuite.plugins.flow and refreshes the related developer documentation.

What changed

  • Added form-scoped field-default storage in Flow core, keyed by formId instead of a single page-level default map.
  • Published browser helper methods on WpSuite.plugins.flow for setting, clearing, and reading per-form field defaults.
  • Updated the Flow frontend runtime so rendered forms resolve and apply stored defaults by formId.
  • Refreshed the Flow JavaScript API and field-default documentation to match the new API surface.

Why this matters

  • Prefill values no longer bleed between multiple Flow forms rendered on the same page.
  • Host-page scripts can target a specific form reliably.
  • The documented browser API now matches the actual runtime behavior.

Upgrade notes

  • Recommended update if you prefill Flow forms from JavaScript or render multiple forms on one page.
  • Direct integrations should use the form-scoped helper signatures and pass formId to default-value actions and selectors.
  • No admin configuration changes are required.

Flow v1.1.2 – Form sync and runtime fixes

22 May 15:58

Choose a tag to compare

This release focuses on reliability across both the admin/editor and the frontend runtime. It fixes WordPress 7.0 Site Editor form sync issues, restores reliable submit validation, improves custom endpoint handling, and aligns design token selectors with the actual runtime markup.

What changed

  • Fixed admin-side form sync so Flow now resolves the correct numeric source entity in WordPress 7.0 Site Editor, including template and template-part contexts.
  • Improved sync metadata handling for editor-backed post types, which makes form sync saves more reliable from the admin UI.
  • Fixed required and email validation so submit now checks the current field values reliably, including minimal or unlabeled fields.
  • Fixed custom endpoint handling so absolute URLs are no longer treated as Flow-relative paths.
  • Added runtime interpolation support for endpoint strings, including tokens such as {{location.origin}}, {{query.foo}}, {{wp.postId}}, {{wpsuite.apiBaseUrl}}, and {{global.MyApp.forms.submitUrl}}.
  • Aligned Flow design token selectors with the emitted runtime class names so theme overrides apply more reliably to submit buttons and field controls.
  • Updated the documentation for runtime interpolation and shortcode/widget usage.

Why this matters

  • Forms embedded in Site Editor template areas can sync and save reliably again.
  • Newsletter and other inline forms now block invalid email submissions as expected.
  • External endpoints are easier to configure in environment-aware or page-context-aware setups.
  • Design-token-based frontend styling behaves more predictably.

Upgrade notes

  • Recommended update if you use Flow inside WordPress 7.0 Site Editor, templates, or template parts.
  • Recommended update if you use custom endpoint URLs or page-context-based endpoint configuration.
  • No manual migration is required.

Flow v1.1.1 – Fixed backend form sync and aligned Flow design token

22 May 13:20

Choose a tag to compare

Flow v1.1.1 fixes backend form sync in WordPress 7.0 Site Editor and template part contexts, and aligns Flow design token selectors with the runtime class names so theme overrides apply more reliably.

What changed

  • Fixed backend form sync source ID resolution in WordPress 7.0 Site Editor and template part contexts.
  • Fixed sync metadata requests to guard against invalid source IDs and use the current editor entity metadata more reliably.
  • Fixed Flow design token selector/runtime class mismatches so theme overrides apply more reliably to action buttons and field controls.

Why this matters

Flow backend sync depends on a stable numeric source record for storing and updating backend form metadata. WordPress 7.0 changed how Site Editor entities are exposed, and this update restores reliable sync behavior for those editing contexts.

This release also fixes a selector mismatch in the Flow design token layer, so themeOverrides now apply more consistently to runtime controls and buttons.

Upgrade notes

No configuration changes are required.

If you use backend sync in the Site Editor or with template parts, update to 1.1.1 and re-save the affected content.