2 results found

1. Search Management

   Add support to see actual graphlql queries in Search Management/Performance view. Now it shows only names of the queries.

   2 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  ·  Graph  ·  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. Computed fields in Contracts

   Role: Developer working with Optimizely CMS 13 and Optimizely Graph.

   Problem:
   I am implementing search across multiple content types (pages, media etc.) using Optimizely Graph.
   A common requirement is to expose consistent search fields across different content types, for example SearchTitle and SearchDescription, while allowing each content type to derive those values from its own properties and fallback logic.

   The current limitation is that computed fields cannot be exposed through Contracts. While computed fields can be defined on concrete content types and avoid storing redundant search data, they cannot be used to create a unified schema across multiple content types.

   For search scenarios, fields such as SearchTitle and SearchDescription are really search projections rather than editor-managed content. To expose these fields through a Contract today, they must be persisted in the content model, even though they are derived projections rather than actual content.

   Desired outcome:
   Ideally, it should be possible to create a unified search schema backed by computed fields, without having to persist derived values in the content model.
   This would allow developers to expose consistent search fields across pages, media and other content types while keeping the content model free from search-specific properties and publish-time population logic.

   Role: Developer working with Optimizely CMS 13 and Optimizely Graph.

   Problem:
   I am implementing search across multiple content types (pages, media etc.) using Optimizely Graph.
   A common requirement is to expose consistent search fields across different content types, for example SearchTitle and SearchDescription, while allowing each content type to derive those values from its own properties and fallback logic.

   The current limitation is that computed fields cannot be exposed through Contracts. While computed fields can be defined on concrete content types and avoid storing redundant search data, they cannot be used to create a unified schema across multiple content types.

   … more

   2 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  ·  Graph  ·  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