Skip to main content

Changelog

Two things ship separately, so each entry says which one it is:

  • Script — the file your site loads from the CDN. Changes reach your site only when you point your script tag at a new version.
  • App — the sync between Webflow and Algolia. Changes take effect on their own; nothing for you to do.

App · 2026-09-22​

Date fields can now sync as timestamps, so you can filter and sort by date in Algolia

New

Date format for date fields​

Webflow date fields have always reached Algolia as text, which Algolia cannot filter, range or sort on. Each date row in the field mapping now has a Date format setting: keep Text (ISO), or pick Timestamp (seconds) or Timestamp (ms) to sync a number instead. Nothing changes until you pick a timestamp. On the page, the year format and the new date format read both, so a field you switch keeps displaying. On a webhook-sync collection, run Force reindex after changing the format so existing records are rewritten too.

Script 1.0.10​

2026-09-09

Recommendation sections were being refused by Algolia and showing nothing. They work again, personalized recommendations included

Fixed

Recommendation sections show results again​

Every recommendation model was failing quietly. The request we sent Algolia was missing a setting it requires, so Algolia refused it and the section hid itself. This affected all six models, from related-products to recommended-for-you, on any section that did not set wf-algolia-threshold by hand. If your recommendation sections have shown nothing since you built them, this is why. There is nothing to change on your side: update to this version and they render. If you do set wf-algolia-threshold, your value is still used. A section without one now behaves as though it were 0, meaning results are not filtered by confidence score.

Personalized recommendations reach Algolia​

recommended-for-you sends a visitor identifier so Algolia can choose records for that person. The identifier was being attached to the request in the wrong place, so Algolia refused it even when your page was set up correctly. It is now sent where the API expects it. A timing problem is fixed alongside it: when your cookie banner granted consent, the section could look for the visitor cookie a moment before it existed and hide itself reporting a missing token. Consent now finishes its setup before the section looks.

<section
  wf-algolia-element="recommend"
  wf-algolia-model="recommended-for-you"
  wf-algolia-index="your_index"
  wf-algolia-user-token="cookie:_ALGOLIA"
></section>

Script 1.0.9​

2026-09-09 · Needs a change to your site.

Search forms inside a Webflow Form Block now need one attribute to keep working, personalized recommendations wait for visitor consent, and search results only link to https addresses

Fixed

An http:// address stored in one of your records now renders as a dead link and logs a warning naming it, for links, images and result navigation alike. A cleartext address is a downgrade your visitor cannot see. The fix is in the record rather than your markup: change the stored address to https://. Your published Webflow site is already served over https, so this only affects addresses your own content points at. Reported by Webflow App Review.

Heads up

Search forms need one attribute to keep working​

If you built a search form by hand inside a Webflow Form Block, add wf-algolia-form="search" to that form and republish. Until you do, pressing Enter submits the form and reloads the page, which discards the query. The script used to take over any form holding a search element, and that was wrong for the forms in between: a contact or newsletter form carries nothing sensitive, so it was taken over and silently stopped submitting. The marker moves that decision to you. Only the exact value search works, and an unmarked form now says so once in the browser console. Anything the app inserted for you is unaffected: inserted experiences are not built inside a form. Reported by Webflow App Review.

<form wf-algolia-form="search">
  <input wf-algolia-element="search-input" type="text">
</form>

The recommended-for-you model reads a visitor identifier from a cookie in order to choose what to recommend, so it now waits for consent the same way Insights event tracking does. Until consent is given, the section stays hidden and nothing is read or sent. Grant it with data-insights-consent="granted" on the script tag if your site already has a legal basis, or call window.WfAlgolia.setInsightsConsent(true) from your cookie banner when the visitor accepts. The section loads the moment consent arrives, so a banner accepted after the page has loaded works with no reload. This applies whether or not you turned on data-insights. Reported by Webflow App Review.

App · 2026-09-09​

New sites now restrict where search results can link, out of the box

Heads up

When you install search on a site from now on, the setting that limits where results may link starts turned on. Results reach your own site plus any addresses you add on the Install page, and nothing else. Your own site is always allowed, so relative links keep working, and email and phone links are never affected. If your records are meant to link outward, to a directory or a job board for example, turn it off on the Install page and save. Sites installed before today keep whatever setting they already had: nothing changes underneath a site that is already live.

Script 1.0.8​

2026-09-04

Addresses you allow search results to link to must now be https

Fixed

When you restrict where search results can send a visitor, the addresses you list must now start with https://. An http:// address is refused when you save it, and one already in a published tag is ignored. A cleartext address is a downgrade your visitors cannot see, and it is not something the restriction should be able to hand out. If you had listed an http address, switch it to https and republish. Reported by Webflow App Review.

Script 1.0.7​

2026-09-03

The app installs and updates the script for you, pinned to an exact version and integrity-checked. Results render under strict CSP and Trusted Types, unsafe link destinations are blocked and can be restricted to your own site, Insights waits for visitor consent, and a search box no longer disables a login or checkout form it sits inside

New

Choose what separates array values shown in one element​

When you do want an array as a single joined string, wf-algolia-separator sets what goes between the values. The default now includes a space, so a,b reads as a, b instead. Empty values in the array are dropped before joining, so a ragged field never renders a stray separator.

<div wf-algolia-text="genres_name" wf-algolia-separator=" · ">

Search results link wherever your records point, which is the whole point for a directory or a job board and not what everyone wants. Set data-restrict-origins="true" on the script tag and results may only link to your own site plus the addresses you list in data-allowed-origins. Your own site is always allowed, so relative links keep working, and turning it on with no list locks results to your site alone. It covers every outbound destination, not just clicks: link fields, image fields, links inside rich text, and facet and stat-tile navigation. Email and phone links are never affected, having no site to belong to. Off by default. Turn it on from the app's install screen rather than by editing the tag. Addresses are exact: there are no wildcards, and one address does not cover its subdomains. Reported by Webflow App Review.

<script ... data-restrict-origins="true"
  data-allowed-origins="https://shop.example.com,https://docs.example.com"></script>

With data-insights="true" the script used to start sending view, click and filter events as soon as results rendered. It now binds its tracking but sends nothing, and writes no Insights cookie, until your consent banner calls WfAlgolia.setInsightsConsent(true). Call it with false to stop again. Events that happen before consent are discarded rather than held back and sent later, so nothing a visitor did before agreeing ever reaches Algolia. Add data-insights-consent="granted" if your site already has a legal basis to track and you want events to flow immediately. Reported by Webflow App Review.

<script ... data-insights="true"></script>
<!-- from your cookie banner -->
<script>WfAlgolia.setInsightsConsent(true)</script>

The app installs the script for you​

Instead of copying a snippet into your site settings, press Install on the dashboard and the app writes the script tag into your site's custom code itself. You still have to publish your site afterwards — Webflow only applies custom code on publish, so until then the script is set up but not live. The dashboard keeps saying so until it can see the script running on your published pages. The app install is now the only way to add the script: a pasted tag cannot be updated or removed by the app, so that path has been withdrawn. Reported by Webflow App Review.

Fixed

Array fields render one element per value in result cards​

A field holding several values, like genres or tags, rendered as one comma-joined string crammed into a single element: action film,comedy film,space opera. Mark the element you designed with wf-algolia-element="array-item" and it is now copied once per value, so each one is a real element your class can style. This already worked on detail pages and result cards were the gap, so if your markup was already written this way it starts working with no edit. The item you designed stays on the page but hidden: it is the template for the next render, so leave it in place. Wrap the list in wf-algolia-element="array-wrapper" when the item sits inside extra styling Divs and the copies need to reach the real list. Without a wrapper they land in the item's own parent.

<ul role="list" wf-algolia-element="array-wrapper">
  <li wf-algolia-element="array-item" wf-algolia-text="genres_name" class="tag">Genre</li>
</ul>

A record field feeding a link or an image is now parsed before it is used, and only safe schemes are allowed through: https, http, mailto, tel and relative URLs for links, and https, http and relative URLs for images. Anything else is replaced with # on a link or left empty on an image, and the reason is logged to the console. This closes a hole where a scheme written with a hidden control character slipped past the previous check while browsers still ran it. Reported by Webflow App Review.

The _ALGOLIA cookie Algolia's tracking library writes carried no SameSite attribute, so browsers applied their own default. It is now rewritten with SameSite=Lax, and with Secure on https, right after it is created. Algolia's library offers no option for either, so this is done from outside it. Separately, data-insights-cookie was described in the attribute panel as taking a cookie name; it is a true/false switch, and the panel now says so. Reported by Webflow App Review.

wf-algolia-user-token only reads Algolia's own cookies​

wf-algolia-user-token="cookie:NAME" would read whatever cookie you named. It now reads only _ALGOLIA or a cookie whose name starts wf-algolia- or wf_algolia_. Any other name is refused, the reason is logged, and the recommendation section hides itself the same way a missing token already did. The documented cookie:_ALGOLIA setup is unaffected. Reported by Webflow App Review.

<div wf-algolia-element="recommend" wf-algolia-user-token="cookie:_ALGOLIA">

Works on sites that enforce Trusted Types and a strict CSP​

On a site sending require-trusted-types-for 'script', the browser blocks every attempt to write HTML that did not come from a registered policy, so results did not render at all. Results are now built as real elements and inserted directly, so there is no HTML string to block: with a strict Content Security Policy and Trusted Types enforced, everything renders and nothing needs adding to your policy. If you added trusted-types wf-algolia for the previous build you can drop it — it is only needed now if you enumerate the policies your page allows and you use rich-text fields. Reported by Webflow App Review.

Content-Security-Policy: require-trusted-types-for 'script'

Highlighted matches and snippets no longer go through an HTML parser​

Highlighted words and snippet text used to be turned into markup by parsing an HTML string, which a strict Content Security Policy can block outright. They are now assembled directly out of text and one element per matched word. Nothing from your records can become a tag or an attribute any more, only text, so there is no longer anything for a sanitizer to catch on this path. You should see no difference except that it keeps working under policies that previously broke it.

Rich-text fields degrade to plain text instead of disappearing​

wf-algolia-html is the one binding that genuinely has to parse HTML, so it is the one binding a trusted-types 'none' policy can stop. Rather than rendering nothing, it now shows the field as plain text and logs one line explaining why. Add wf-algolia to your trusted-types directive to get the formatting back. Every other binding is unaffected.

Embedding the script twice no longer doubles your Algolia bill​

If the script tag ended up on the page twice — custom code in both site settings and page settings is the usual way — both copies ran. That meant two sets of event listeners, two Algolia queries for every keystroke, and two Insights events for every click. The second copy is now ignored and logs a line telling you to remove the duplicate tag. Reported by Webflow App Review.

[wf-algolia] Already initialized on this page — ignoring a second embed of the script.

A search box inside a login or checkout form no longer disables it​

The script took over every form containing an Algolia element: it stopped the form submitting, hid the submit button, and hid Webflow's own success and error messages. That is right for a search form and wrong for anything else, so a search box dropped into a login or a checkout form broke that form. A form carrying a password field, a card or CVV field, or Webflow Ecommerce's checkout markup is now left completely alone: it submits normally, keeps its button, and keeps its messages. Every other form still auto-handles exactly as before. Reported by Webflow App Review.

destroy() now actually cleans up after itself​

WfAlgolia.destroy() used to remove the injected cards and the window.WfAlgolia global and stop there, leaving 46 event listeners, its observers, in-flight Algolia requests and the window.aa Insights global all still running. It now releases all of them. It stays teardown-only: your page is not restored to how it looked before the script ran, so elements the script hid stay hidden. Re-initialising after destroy() is not supported — reload the page instead. Reported by Webflow App Review.

Your site is pinned to an exact version and the file is verified​

Installs used to point at @1, which meant every release we published changed the code running on your live site without anyone deciding to. Installs now name an exact version and carry a Subresource Integrity hash, so the browser refuses to run the file if it is not byte-for-byte what we published. The trade is that you no longer get new versions automatically — which is the point. When one is available the dashboard offers a one-press update, and nothing changes on your live site until you publish. Reported by Webflow App Review.

<script
  src="https://cdn.jsdelivr.net/npm/@candid-leap/wf-algolia@1.0.7/dist/index.js"
  integrity="sha384-…"
  crossorigin="anonymous"
></script>

The App ID is checked before it is used to build a hostname​

data-app-id was read off your script tag and used as-is. It becomes part of the Algolia hostname the script queries, so a malformed value could point requests somewhere you did not intend. It is now checked first: letters and digits only, up to 64 characters, which is every real Algolia App ID. Anything else stops the script with a console message naming the bad value, instead of starting up against the wrong host. Reported by Webflow App Review.

Two script tags on one page no longer disagree about your settings​

Five different parts of the script each searched the page for the loader tag separately. On a page carrying two of them they could pick different ones, so your credentials might come from one tag and data-index from the other, which looks exactly like your configuration being ignored. The script now identifies its own tag once and every part uses that same answer. If it does find more than one, it says so in the console and tells you to remove the duplicate.

Heads up

Array copies now follow your class instead of a forced display​

Copies used to be given display: inline-block directly on the element, which beat the class styling them and could not be overridden from the Designer. Layout is now left to your CSS, so a <li> behaves like a list item and a flex parent works normally. If a detail page relied on that forced inline-block, put wf-algolia-display="inline-block" on the item you designed and the copies pick it up. Everywhere else there is nothing to change.

<li wf-algolia-element="array-item" wf-algolia-text="genres_name" wf-algolia-display="inline-block">

If your records hold links on schemes outside that list, they now render as # rather than as working links. mailto: and tel: links keep working, and so do plain http and relative links, so ordinary CMS content is unaffected. Check the browser console for [wf-algolia] Blocked unsafe URL scheme if a link stops working after you update.

If you have data-insights="true" today and no consent banner calling the new method, events stop being sent. Either call WfAlgolia.setInsightsConsent(true) once the visitor agrees, or add data-insights-consent="granted" to the script tag to keep the previous behaviour.

Showing and hiding now uses classes instead of inline styles​

The script used to write display straight onto elements, which beat your own CSS with no way to override it from the Designer. It now adds wf-algolia-hidden to hide, and wf-algolia-display-flex, -grid, -block and so on to show, and it installs the rules for them itself. If you wrote CSS or a Webflow interaction that keyed off the inline display the script set, it needs to target these classes instead. One behaviour change comes with it: a wf-algolia-display value that is not a real display keyword now warns in the console and falls back to block, where before it was passed through and silently produced a broken layout. Reported by Webflow App Review. 

<div wf-algolia-element="results" wf-algolia-display="grid">

Search inside a password or payment form now needs one attribute​

If you deliberately put a search box inside a form that also has a password or payment field, that form is no longer taken over and pressing Enter will submit it instead of searching. Add wf-algolia-form="search" to the <form> to get the old behaviour back. Only the exact value search unlocks it. The script logs a line naming the form when it refuses one, so check the console if a search box stops responding to Enter after you update. Forms with nothing sensitive in them are unaffected and need no attribute.

<form wf-algolia-form="search">

Disconnect now removes the script; uninstalling from Webflow does not​

Pressing Disconnect in the app removes the script from your site's custom code as well as deleting your data — publish afterwards so the removal reaches your live pages. Uninstalling the app from the Webflow dashboard is different: that revokes our access immediately, so we can no longer edit your site to remove our own script, and it stays in your custom code until you delete it by hand. If you want a clean removal, press Disconnect before uninstalling.

App · 2026-09-02​

You can now restrict where your search results are allowed to link

New

Search results link wherever your CMS records point, which is exactly what a directory or a job board needs. If you would rather they could only reach addresses you have named, the Install page now has a setting for it. Your own site is always allowed, so relative links keep working, and turning it on with nothing listed locks results to your own site. Email and phone links are never affected. Saving sends the change to your site straight away, and it goes live when you next publish.

Script 1.0.6​

2026-08-28

Maintenance release

Heads up

Release notes were not recorded for this version​

This version was published to the CDN on 28 August 2026 without an authored entry in the release manifest, so the app under-reported the newest available version until it was backfilled. The published artifact is recorded here with its integrity hash; the change detail is in the repository history for that date. The release gate now refuses a publish that has no authored notes, so this cannot recur.

App · 2026-08-28​

A record too large for Algolia no longer fails the whole sync

Improved

The size limit now comes from your Algolia plan​

Every account was assumed to have the same 10 KB per-record limit. Plans differ, and on a larger plan that meant trimming text Algolia would have accepted in full. The limit is now read from Algolia itself the first time it rejects a record, remembered for your site, and re-read if it ever changes. Nothing to configure, and if you upgrade your Algolia plan the extra room is picked up on its own.

The sync log says what was skipped and why​

Skipped items are listed with their size and the real limit for your account, instead of a fixed figure that was wrong for anyone not on the common plan. Where a record is only slightly too large, long text fields are trimmed to fit rather than the item being dropped. Lists are never trimmed: shortening one would silently change its filter values, and a filter returning the wrong items is worse than one item going missing.

Fixed

One oversized record no longer stops the rest from indexing​

Algolia rejects an entire batch when a single record in it is too big, and that failure used to end the sync run. One oversized CMS item could stop up to 999 healthy records from being indexed, and every batch after it. The oversized record is now dropped on its own and everything else is indexed. A skipped item keeps whatever is already in your index rather than disappearing from search, so it goes stale instead of vanishing.

Script 1.0.5​

2026-08-21

Six Recommend models, query suggestions, switch and open-ended filters, and a batch of browse and filter fixes

New

Point a section at an Algolia Query Suggestions index and mark it with wf-algolia-suggestions. It lists popular searches instead of records, and picking one fills the search box and re-runs the search rather than opening a page. Works in Autocomplete and in Multi-source, where a suggestions section can sit above your result sections. The suggestions index is created in the Algolia dashboard and is built from real searches, so it stays empty until visitors have searched.

<div wf-algolia-element="autocomplete-section" wf-algolia-index="products_query_suggestions" wf-algolia-suggestions="true">

Recommend now runs all six Algolia models​

Only four models rendered before. A recommend section can now use related-products, looking-similar, frequently-bought-together, trending-items, trending-facets, or recommended-for-you. New options come with them: wf-algolia-threshold, wf-algolia-facet-name, wf-algolia-facet-value, wf-algolia-user-token (a literal or cookie:NAME), wf-algolia-objectids, wf-algolia-query-filters, and wf-algolia-fallback-filters. A section missing something it needs says so in the console and hides itself.

<div wf-algolia-element="recommend" wf-algolia-model="looking-similar" wf-algolia-index="products">

A single switch filter, instead of two radio buttons​

Give a filter group wf-algolia-type="toggle" and a checkbox inside it to filter on one boolean field. On applies field:value (wf-algolia-value defaults to true), off clears it. This replaces the two-radio workaround that boolean fields used to need. The switch reads the filter as well as writing it, so a shared URL opens with it already on, and removing its chip or pressing Clear All moves it back off. Deferred apply works the same as on any other group.

<div wf-algolia-element="filter-group" wf-algolia-type="toggle" wf-algolia-field="in_stock">

Open-ended range filters: minimum only, or maximum only​

A range group needed both a range-min and a range-max input. Either one on its own is now a first-class filter, so you can build a "minimum rating" or an "under $500" control. Two-sided ranges behave exactly as before. Filter chips follow: an open bound renders as 100+ or under 500 where it used to render no chip at all.

<input wf-algolia-element="range-max" wf-algolia-field="price" type="number">

Prefix, suffix, and decimal places on any card value​

wf-algolia-prefix and wf-algolia-suffix used to apply only to values carrying wf-algolia-format, so a plain text binding ignored them. They now wrap any card text, and neither is rendered when the field is missing so you never get a bare currency symbol. New wf-algolia-decimals keeps trailing zeros on prices. wf-algolia-format="currency" is deprecated in favour of number plus a prefix, and still works with a one-time console warning.

<div wf-algolia-text="price" wf-algolia-format="number" wf-algolia-prefix="$" wf-algolia-decimals="2">

Base filters can combine several fields and values​

wf-algolia-base-filter took one field and one value. It now accepts comma-separated values, numbered clauses (wf-algolia-base-filter-field-2, -value-2, and so on), wf-algolia-base-filter-match to combine values inside one field with any or all, and wf-algolia-base-filter-logic to combine clauses with each other. The same parser backs browse pages, facet stats, and static lists. The old combined field:value form still parses and warns once.

wf-algolia-base-filter-field="category" wf-algolia-base-filter-value="shoes,boots" wf-algolia-base-filter-match="or"

wf-algolia-stat="count" reports how many records match a scoped search, and it is the only stat that needs no wf-algolia-field. Adding wf-algolia-link-template makes the tile clickable, substituting {field} and {value} and honouring wf-algolia-slugify. Together they build the "Shoes (42)" tile that navigates to its own category page.

<a wf-algolia-element="facet-stat" wf-algolia-stat="count" wf-algolia-link-template="/category/{value}">

Standalone facet lists respect wf-algolia-sort​

Category lists and menus built outside a browse page offered wf-algolia-sort but ignored it. They now reorder their rows with the same vocabulary as in-browse lists: alpha, count, and Algolia's own order. A new mode, selected-alpha-zero-last, puts the visitor's selections first, then everything with results A to Z, then empty values last so they stay reachable without cluttering the top.

wf-algolia-sort="selected-alpha-zero-last"

Improved

wf-algolia-reset is now wf-algolia-default-option​

The attribute that names a radio group's default choice was called reset, which read like the clear-all button it has nothing to do with. It is now wf-algolia-default-option. wf-algolia-reset still works and warns once, and the clear-all button (wf-algolia-button="reset") is untouched. A radio group with no default now warns, since without one the group cannot be cleared.

<div wf-algolia-element="filter-group" wf-algolia-type="radio" wf-algolia-default-option="all">

Markup mistakes now say something instead of failing silently​

The script has no error reporting beyond the browser console, and several dead ends produced nothing at all. A results panel with no template child now warns before bailing out. So does an unknown wf-algolia-match value (it falls back to or), a recommend section missing its seed, facet, or user token, and a multi-objectID recommend request, which bills per ID. Each warning fires once per element, not once per keystroke.

Fixed

Select filters now fill their options from your data​

A <select> filter group whose template is an <option> produced the right number of options but repeated the placeholder text on every one, and every option filtered on that same placeholder, so a live site produced f_year=Any%20year in its URL. Options now carry the facet value as both their label and their real value. Use {value} in the template option's text to control the wording.

<option wf-algolia-element="filter-template">{value}</option>

The no-results element was hidden only once a search had returned hits, so it was briefly visible on page load. It now starts hidden and re-hides when the query is cleared. Separately, wf-algolia-hideclass was documented on results and no-results but never read by the show and hide helpers, so an element hidden by that class was never revealed. Both are fixed across search, browse, and multi-index search.

Federated all mode always includes your primary index​

On a browse page whose primary wf-algolia-index was not also named by a mode button, the all mode search left that index out of its own results. The primary index is now always part of the fan-out, and it comes first.

Switching index modes keeps your filter selections​

Hiding a filter group when its index was not the active one deleted that group's selection, so switching away and back lost the visitor's choices permanently. Hiding the UI no longer touches filter state, and the selection is repainted when the group comes back.

Sorting no longer drops out of federated mode without saying so​

A sort is a single Algolia replica, so it cannot run across several indices. When a sort was active in all mode, results quietly came from one index while the all button stayed highlighted, with nothing to explain the mismatch. The button now un-highlights to match reality and the console explains that clearing the sort restores federated mode.

Recommend sections no longer stop at the first broken one​

A recommend section missing its model, index, grid, template, or seed aborted every later section on the page. Each section is now handled on its own, so one misconfigured block cannot blank out the rest.

Sorting stops writing ?sort= when URL sync is off​

A wf-algolia-element="sort-group" widget wrote its ?sort= parameter on every click even when wf-algolia-url-sync was off, leaking state into the address bar that nothing else on the page synced. The write now follows the same setting as the rest of the URL sync, read from the sort widget's own scope so a standalone sort still works.

Heads up

Deprecated, still working, and warning once​

Nothing in this release stops working, but five things now warn in the console and should be migrated: wf-algolia-reset becomes wf-algolia-default-option, wf-algolia-match="numeric-min" becomes wf-algolia-type="range" with a min-only input, wf-algolia-format="currency" becomes number with a prefix, the combined field:value base-filter form becomes the split field and value attributes, and wf-algolia-match now takes only or or and (any and all never worked at runtime, despite being offered).

The undocumented multi-section search engine was removed​

A fourth search engine read a wf-algolia-element="results" panel containing wf-algolia-element="section" children. It was never in the attribute reference and the app never built it, and it competed with the other engines over the same markup. Multi-source search rides the autocomplete engine instead. If you hand-built a dropdown on that shape, rebuild it as an autocomplete with one section per index.

Script 1.0.4​

2026-06-19

Rename the field label shown in filter-tag chips

New

Rename the field shown in a filter chip​

Filter-tag chips render a {field} token that prints the raw Algolia attribute name, so a chip could read product_brand: Acme. Put wf-algolia-replace-field on the filter-tag template to substitute wording your visitors understand. The value replaces only the {field} token - the selected value still comes from the facet.

<div wf-algolia-element="filter-tag-template" wf-algolia-replace-field="Brand">

Heads up

Safe to adopt on any 1.x site​

Nothing else changed. Chips without the new attribute keep their existing labels, so upgrading from 1.0.2 or 1.0.3 cannot alter a live page.

Script 1.0.3​

2026-06-19

Maintenance release - the script itself is unchanged

Improved

Security updates to build tooling​

Published alongside repository-wide dependency updates. Those are build-time packages that never reach the browser, which is why the shipped script is unchanged.

Heads up

No functional change​

The browser bundle is functionally identical to 1.0.2. We compared the two published files directly: no attribute, element, or behaviour differs, and the small size difference is only the minifier choosing different internal variable names.

Nothing to do​

There is no reason to move from 1.0.2 to 1.0.3, and no risk in doing so.

Script 1.0.2​

2026-06-11

Facet statistics, always-on base filters, and static lists

New

Show a number about your results with facet-stat​

A new facet-stat element prints one aggregate for a numeric field - useful for From $12 or Highest rating: 4.9. Set the field with wf-algolia-field and pick the calculation with wf-algolia-stat, which accepts min, max, avg, or sum. The element needs an index, inherited from an ancestor carrying wf-algolia-index or taken from your loader script. If the field or the calculation is missing, the script logs a console error naming the element rather than failing silently.

<div wf-algolia-element="facet-stat" wf-algolia-field="price" wf-algolia-stat="min"></div>

Scope a whole page with a base filter​

wf-algolia-base-filter on a browse wrapper applies a filter to every query from that wrapper, including searches and facet refinements. Visitors cannot clear it, which makes it the right tool for a category or collection page that should never show anything outside its section. Use wf-algolia-base-filter-field and wf-algolia-base-filter-value to express it as a field/value pair instead of writing filter syntax by hand.

<div wf-algolia-element="browse" wf-algolia-base-filter-field="category" wf-algolia-base-filter-value="Coffee">

Static lists, and more than one list per page​

Mark a browse wrapper wf-algolia-disable-filters="true" and give it a wf-algolia-filter expression to render a fixed, non-interactive result list - a Related products or Editor's picks row that ignores the visitor's search state. This also unblocks putting several browse wrappers on one page: the first stays interactive and the rest render as static lists. wf-algolia-per-page controls how many items a static list shows.

<div wf-algolia-element="browse" wf-algolia-disable-filters="true" wf-algolia-filter="category:Coffee" wf-algolia-per-page="4">

Fixed

Analytics events no longer rejected on busy pages​

Insights events are kept within Algolia's /1/events payload limits, so click and view tracking survives pages with many results instead of being dropped.

Script 1.0.0​

2026-06-04

First stable release

New

The full attribute-driven toolkit​

First stable release, covering 50 element roles across 84 attributes. Includes search and autocomplete, browse grids, filter groups, filter chips, sorting, pagination, range inputs, hit previews, and recommendation grids - all wired by adding wf-algolia-* attributes in the Webflow Designer, with no custom code.

Hierarchical filters that read cleanly​

Nested categories are stored as full paths like Drinks > Coffee > Espresso, which is unreadable in a chip. Add wf-algolia-label="leaf" to show only the final segment - Espresso - while filtering still uses the whole path.

<div wf-algolia-element="filter-tag-template" wf-algolia-label="leaf">

The scope-facet role passes its field and value down into hit previews, so a mega-menu or category strip can drive a preview panel beside it without extra configuration.

wf-algolia-url-sync="true" mirrors the query, active filters, sort, and page into the page URL, so a visitor can share or bookmark a result set and the back button behaves. wf-algolia-slugify converts a field into a URL-safe slug when building links to detail pages.

<div wf-algolia-element="browse" wf-algolia-url-sync="true">