FAQ

Does it need Craft Commerce?

No. Commerce is a soft dependency. Compare sets can be entries or categories, and a content site with no shop uses every feature except the price, SKU, stock and add-to-cart rows.

With Commerce installed, Products and Variants become available as set types and those four rows appear.

What can it compare?

Commerce products, Commerce variants, entries, and categories. One element type per set, as many sets as your edition allows.

The point of the design is that a row does not know what it is reading. The same "Custom field" row draws a laptop's processor, a sofa's fabric and a case study's industry.

How is this different from the WooCommerce compare plugins?

Those compare products, so their table is a fixed list of known product properties. Craft content is whatever you modelled it to be, so Compare's table rows are resolvers — each one reads itself off whatever element it is handed.

The practical difference: you define the table once, in the control panel, and it works for a product type and an entry section without two implementations.

What is "difference highlighting" comparing, exactly?

A normalized value, never the rendered markup. $10.00 and $10 are the same price. Yes and yes are the same answer. Two relation fields holding the same three entries in a different order are the same answer. A date compares by day, not by second.

Comparing rendered HTML instead would report all of those as differences — which is precisely the noise the "differences only" view exists to remove.

Blank counts as a value. "One of these has no warranty and the others do" is a difference worth showing.

Do visitors' lists survive?

Yes. A guest's list lives in the database under a random cookie token — not in the cookie itself — and lasts 30 days by default. Sign in and it merges into your account, where it never expires. Add three products on a phone, sign in on a laptop, they are there.

If both a guest list and a saved user list exist, the saved one wins and the guest's items are appended up to the cap.

Does it work with cached pages?

Yes, and this is designed for rather than hoped for. Compare buttons live on product cards, which live on pages cached by {% cache %}, Blitz or a CDN.

The runtime therefore never trusts the HTML it was rendered into. It fetches /compare/session.json for a fresh CSRF token and the visitor's real state, then reconciles the buttons. A cached page and an uncached page behave identically.

Does it work without JavaScript?

Yes. Every compare button is a real <button> inside a real <form> posting to a Craft action. The runtime intercepts it and turns it into a fetch; with JavaScript off it submits and reloads. There is one piece of markup, progressively enhanced.

Can I use my own front end?

Yes. Turn off Load the bundled front end and drive the JSON endpoints — every one the bundled runtime uses is public and documented. Or keep the runtime and just override the table markup with templates/compare/_table.twig.

What does it load on my pages?

One small stylesheet and one small script, both plain, both self-hosted, and only on pages that actually render a compare control. No jQuery, no framework, no CDN, no outbound requests of any kind.

What data does it store? Is it GDPR-relevant?

Element IDs, a random guest token, and — for signed-in visitors — a user ID. No IP addresses, no user agents, no fingerprinting. Insights are element IDs and timestamps.

Guest lists are deleted after their configured lifetime. A signed-in user's list is their data and is deleted with their account.

The guest token cookie is strictly functional: it identifies a shopping aid the visitor asked for by pressing a button, and it is only ever set at the moment they press it — a visitor who never uses Compare never receives a cookie.

What are Insights?

A Pro report of what visitors actually compared: which items were added most, which appear in the most comparisons, and — the useful one — which items get put next to each other.

That last one is your competitive set as customers see it, which is rarely how the catalogue is organised. It is stored as pairs, so the report is a straightforward aggregate rather than a guess.

Can visitors share a comparison?

On Pro, yes. "Copy link" mints a URL at /compare/shared/<token> that shows exactly what the sender saw. Opening one does not overwrite the viewer's own comparison.

Can it be printed?

Yes, and it is treated as a real deliverable rather than an afterthought — the chrome is removed, sticky positioning is turned off (a sticky header repeats on top of the content on every printed page), and the borders survive. The standalone page at /compare is what people bookmark and take to the shop.

How many items can be compared at once?

Three on Lite, up to ten on Pro, configurable per set. Three is not arbitrary: it is what fits a phone screen and what almost every real comparison table on the web uses.

What happens if my Pro licence lapses?

The table narrows rather than breaking: it drops to three columns and Twig template rows are skipped. The page keeps working, and nothing stored is changed — lists, sets and rows are all untouched, so renewing restores everything.

Can other plugins add row types?

Yes — Rows::EVENT_REGISTER_ROW_TYPES. A reviews plugin can add a "Rating" row without Compare knowing reviews exist.

What does it cost?

Lite is free: one compare set, three items, every core row type, guest and user lists, the bar, the modal, the standalone page, printing, and the full Twig and JSON API.

Pro is $79, then $29/year to keep receiving updates: unlimited sets, up to ten items, difference highlighting, Twig template rows, shareable links and Insights.