This article briefly underlines the breaking changes introduced by this release, as well as its other major non-breaking new features.
Migrating Coveo Cloud Hosted Search Pages
If you want to migrate a Coveo Cloud hosted search page used in production:
Open your page in the Interface Editor, select the Code View tab, and copy the entire code.
Open the new page in the Interface Editor, select the Code View tab, and replace the code with the one you copied in step 1.
Read the list of breaking changes between v1.x and v2.x and fix issues until your new page is working properly.
When satisfied, rename the old page (e.g., to
MyProductionPageBackup), and rename the new page to the old page’s original name (e.g.,
The URL that previously pointed to the old page will now point to the new one.
Eventually, you can delete the old page entirely.
Query Syntax is Now Disabled by Default
This change is only breaking if you didn’t explicitly specify the value of the
enableQuerySyntax option in the
Omnibox component of your search page.
enableQuerySyntax option default value was
true. As a result, unless you explicitly set this option to
false when configuring your search box, the end user could input and submit valid Coveo Cloud query syntax (such as
@myfield=="my value"), which the Search API would then parse and interpret as such.
enableQuerySyntax option to
true in your
<div class="CoveoSearchbox" data-enable-query-syntax="true"></div>
enableQuerySyntax option is also available in the
ResultsPreferences component. You can set this option to
true if you want individual end users to be able to specify, in the Preferences panel, whether to enable query syntax in the search page, or let the
enableQuerySyntax option value automatically decide:
... <div class="CoveoPreferencesPanel"> <div class="CoveoResultsPreferences" data-enable-query-syntax="true"></div> ... ...
The Old Design is Now Entirely Deprecated
This change is only breaking if your search page still uses custom CSS that relies on the so-called “old” design (pre December 2015 Release (v1.0.273)).
If this is the case, you will likely need to properly adjust your styling to the “new” design before you can migrate your search page.
data-design="new" in your
SearchInterface to ensure that the “new” design was used in your search page.
The “old” styling has been entirely deprecated in the v2.2900 release. Therefore, you can safely remove
data-design="new" from your
SearchInterface, as this attribute no longer has any effect at all. Moreover, you should now preferably include the
templates.js files in your search page (whose content is now the “new” design), rather than the
Those obsolete files are still included in the 2.x packages, but you should avoid referencing them in your search page.
The Framework now Uses SVG Icons
This change is only breaking if you’re using customized PNG sprites to display the icons in your search page. If this is the case and you still want to use those sprites, you will need to override some CSS rules.
Since the 2.2900 release, the framework uses scalable vector graphics (SVG) instead. This offers a whole new (and easier) way to customize the look of your search page (see Customizing SVG Icons).
Major Non-Breaking New Features to Leverage
Lazy Component Loading
Using lazy component loading can greatly reduce the loading time of a search page, especially beneficial on mobile devices (see Lazy Versus Eager Component Loading).
Many Result Layouts
Standard Form Controls
Several form controls with “standard” styling, including a check box and a datepicker, are now available to use under the
Coveo namespace (see Using Standard Form Controls).