3 results found

1. Visual Builder forms are incomplete when fetched with @optimizely/cms-sdk

   Visual Builder forms are incomplete when fetched with @optimizely/cms-sdk

   In Optimizely SaaS CMS, Visual Builder forms work in the editor, but the content JS SDK (@optimizely/cms-sdk) does not return everything needed to render them on the site.

   When a Form Container is placed on an Experience, the SDK query does not go deep enough to include the fields inside the form (step → row → column → elements). Form Container properties set in CMS — Title, Description, Submit URL — are also missing from the response.

   As a result, forms cannot be implemented with the SDK as-is. We had to patch the SDK locally so the same content query returns the full form.

   Steps to reproduce:

   1. Activate Forms in CMS (SaaS) and create a Form Container with at least one step, row, column, and form elements (e.g. Textbox, Submit).
   2. Set Form Title, Description, and Submit URL on the Form Container.
   3. Add the form to an Experience.
   4. Fetch the Experience with @optimizely/cms-sdk (getContentByPath / standard composition query) and render it.

   Expected: The SDK returns the full form: layout, all form elements, and Form Container properties (Title, Description, Submit URL), so the frontend can render and submit the form with no extra query.

   Actual: Form elements inside columns are missing. Title, Description, and Submit URL are not returned. Only structure metadata (e.g. displayName) is available.

   Impact: Teams using the official content JS SDK cannot ship Visual Builder forms without patching the SDK or writing a custom Graph query. That is not a supported, upgrade-safe path.

   Request:

   1. Make the SDK composition query deep enough for the form structure: experience → form → step → row → column → elements.

   2. Return Form Container properties (Title, Description, Submit URL, confirmation messages) on the form node, the same way other component properties are returned.

   3. Document the supported way to render and submit SaaS Visual Builder forms with @optimizely/cms-sdk.

   Visual Builder forms are incomplete when fetched with @optimizely/cms-sdk

   In Optimizely SaaS CMS, Visual Builder forms work in the editor, but the content JS SDK (@optimizely/cms-sdk) does not return everything needed to render them on the site.

   When a Form Container is placed on an Experience, the SDK query does not go deep enough to include the fields inside the form (step → row → column → elements). Form Container properties set in CMS — Title, Description, Submit URL — are also missing from the response.

   As a result, forms cannot be implemented with the SDK as-is. We had to… more

   3 votes

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Forms  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

2. Subject: Feature Request / Support Ticket: Support query-only parameters (?key=val) in External Link input to allow local domain control in

   Ticket Details

   Product / Feature: Optimizely Web Experimentation (Visual Editor / Link & CTA Configuration)

   Request Type: Feature Request / Product Enhancement (Follow-up to support phone call)

   Target Component: Visual Editor — External Link Input Field

   Context & Background

   Per our recent discussion with Optimizely phone support, we confirmed that the External Link input field currently auto-prepends http:// whenever an input is not formatted as a fully qualified, absolute URL.

   Support advised us to submit this formal ticket to request functionality that permits entering query parameters only (e.g., ?utm_content=Homepage-hero) into the External Link input field without the system forcing http:// in front of it.

   Problem Statement

   Current Validation Logic: The external link field requires a fully qualified domain. If we enter only query parameters (?utmcontent=Homepage-hero), the editor auto-prepends http://, resulting in a broken output URL: http://?utmcontent=Homepage-hero.

   Current Workaround: To avoid broken links, we are currently forced to hardcode the entire absolute URL (e.g., https://example.domain.com/?utm_content=Homepage-hero) directly into the external link field.

   Why This Is Problematic: Hardcoding the full URL in the visual editor breaks environment portability. We manage our destination domains dynamically in our local codebase so that links correctly resolve across Development, Staging, and Production environments. Hardcoded URLs in Optimizely override or bypass this local domain logic and require manual editing every time code moves between environments.

   Current Behavior vs. Desired Behavior

   Detail

   Current Workaround (Full URL)

   Current Behavior (Params Only)

   Desired Behavior (Feature Request)

   Input in External Field

   https://example.domain.com/?utm_content=Homepage-hero

   ?utm_content=Homepage-hero

   ?utm_content=Homepage-hero

   Rendered / Output Link

   https://example.domain.com/?utm_content=Homepage-hero

   http://?utm_content=Homepage-hero (broken)

   ?utm_content=Homepage-hero (or relative path preserved)

   Domain Control

   Hardcoded in Optimizely Visual Editor

   Broken protocol

   Handled dynamically/locally in application code

   Business & Engineering Impact

   Multi-Environment Promotion: Without parameter-only support, experiments configured against a development or staging domain cannot be promoted to production without manual updates to the Visual Editor CTA configurations.

   Local Code Governance: Our engineering team needs to maintain authoritative control over the destination domain and path directly within our codebase, while allowing experimenters to append campaign and tracking parameters (utm_*) via Optimizely.

   Risk of Broken Links: If an editor or marketer inadvertently strips the domain prefix in the editor, users encounter invalid http://? links in production.

   Requested Action & Next Steps

   Feature Request Submission: Please submit an official feature request / enhancement request to the Optimizely Web product team to adjust the validation logic of the External Link field, allowing strings starting with ? or relative paths to pass through without prepending http://.

   Recommended Interim Workaround: While this functionality is under consideration, what is Optimizely’s recommended best practice for appending query parameters dynamically to existing CTA links in code (e.g., using variation JavaScript to modify link.search or link.href rather than using the Visual Editor's external link field)?

   Ticket Details

   Product / Feature: Optimizely Web Experimentation (Visual Editor / Link & CTA Configuration)

   Request Type: Feature Request / Product Enhancement (Follow-up to support phone call)

   Target Component: Visual Editor — External Link Input Field

   Context & Background

   Per our recent discussion with Optimizely phone support, we confirmed that the External Link input field currently auto-prepends http:// whenever an input is not formatted as a fully qualified, absolute URL.

   Support advised us to submit this formal ticket to request functionality that permits entering query parameters only (e.g., ?utm_content=Homepage-hero) into the External Link input field without the system forcing http://… more

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Forms  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating

3. Need the ability to set the TinyMCE Toolbar height

   CMS (SaaS) does not currently expose an explicit height/width setting for the rich-text editor. Unlike CMS PaaS (where the editor size can be set in code via the TinyMCE Configuration API), SaaS is configured entirely through the content-type contract, and the only editor setting available for a rich-text property is the toolbar preset.

   As a developer worried with the user experience, I would like to have the ability to set the text area's height, at least.

   1 vote

   Vote Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   New  ·  0 comments  ·  Forms  ·  Delete…  ·  Admin →
   How important is this to you?

   Nice to have You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Submit Rating