Branching Software Chemical Structure Search for WooCommerce

A line notation for chemical structures — CN1C=NC2=C1C(=O)N(C(=O)N2C)C is caffeine. Most catalog systems and suppliers can export it, and PubChem lists it for any compound. It is the one field structure search actually needs.

No. Any valid way of writing a structure works, because RDKit converts every one to a single canonical form before comparing. You do not have to match how anyone else wrote it.

So that searching is instant and costs your server nothing. The index is one file, built once, that shoppers download and search against in their own browser.

The chemistry toolkit is WebAssembly. Running it needs a browser or a Node process, and a WordPress host has neither. Building it in your browser also means your catalog is canonicalised by exactly the same code that will later match against it — which is what makes exact search reliable.

Comfortably into the low thousands of products. Beyond about 10 000 the index file becomes large enough that it should be split into parts, which this version does not do yet.

Results are rendered by your theme's own product template, so if your shop page looks right, results will too.

No. Everything runs on your site and in your shoppers' browsers. The plugin makes no outbound requests at all.

Only products a shopper could reach by browsing: published, not password-protected, and with catalog visibility "Shop and search results". Hidden, draft, private and password-protected products are left out of the index file and are never rendered by the results endpoint, whatever a request asks for. Changing a product's visibility marks the index as needing a rebuild.

Each search stores what was asked — the drawn or typed structure as canonical SMILES, or the CAS number, catalog number or name that was typed — and how many products matched, to the hour, and nothing about who searched: no IP address, account, cookie or browser details. The same visitor repeating the same search within an hour is recorded once. Rows are deleted after the retention period (default 90 days), the table is capped in size, and a suggested privacy-policy paragraph is added under Settings → Privacy → Policy Guide. The Index tab shows the last 30 days: how many searches, by structure or by name, how many found nothing, and the five most-wanted things the catalog does not have.

Each client gets a budget of thirty searches at once and thirty a minute after that, and one request renders at most forty product cards. A search that matches more sends the rest a page at a time behind a "Load more" button, so no single request can ask the store to build more than forty cards however many products matched. Both are filterable (bscs_results_rate_limit, bscs_max_results) for stores that need more.

Deleting the plugin removes its settings, the search log table, its scheduled tasks and the index files it wrote to the uploads folder. The chemistry fields on your products (SMILES, CAS number, formula, weight) are left in place, because they are your catalog data and you may install the plugin again or export them.

Each row is matched to a product by SKU. A matching product is updated; a row with a new SKU creates a simple product. The file only changes the columns it carries: a SKU and SMILES file refreshes structures and leaves CAS numbers, formulas, weights, names and prices as they were. The column names your supplier uses are accepted (CAS No, Catalog Number, Mol Weight and so on). After an import the admin screen asks for an index rebuild, since searching reads the index, not the products.

Structures are set on the parent product, and the parent is what search returns. Per-variation structures are not supported.