Upgrade to 1.0.0-rc796

Search runs on Loupe 1.0 — rebuild the index

If you use pushword/search, run pw:search:index after updating.

Loupe 1.0 records term positions globally per document instead of per attribute, so the index layout changed. An index built by 0.13 is not migrated when it is read, and it does not fail either: searches keep answering, from a layout the matcher now reads differently. Nothing signals the mismatch, which is why the rebuild is worth running rather than waiting for a symptom.

php bin/console pw:search:index

Skipping it is not fatal, just expensive at the wrong moment: the next incremental reindex — any page saved from the admin or the API — detects the stale layout and rebuilds that whole host from the documents it already stores, inside the request that saved the page. Running the command yourself puts that cost where you can see it.

Two improvements come with the upgrade:

• Compound words are searchable by their parts in English and German. tooth now finds toothbrush, and the whole word stays searchable as before.
• Excerpts prioritize match context instead of taking the first occurrence, and are capped at five fragments per attribute.

pages_list always filters on the current locale

Only affects a host serving more than one language. A slug: or page: term used to switch the locale filter off for the whole search; it no longer does.

The intent was that naming a page means wanting that page, whatever its language. The implementation was a substring test over the entire expression, so it went further than the intent: in slug:tour-du-mont-blanc OR tmb, the tmb tag also stopped being locale-filtered and the list mixed languages. Any prefix ending in slug: — a customslug: of your own — triggered it too.

If a list was deliberately reaching a page in another language, it now returns nothing for that term. Point it at the page of the current language, or render the list from a template that knows which language it wants.

pages_list searches are parsed, and gain template:, parent:, tag:

AND and OR can now be mixed, provided parentheses say which comes first — (a AND b) OR c. Ungrouped, the search is refused rather than read one way or the other. Neither changes an existing search: mixing them did not work before (the AND half was searched as a tag name), and parentheses were part of the tag name they sat in.

Two things to check on your site.

If you have a tag literally named template:…, parent:… or tag:…, a search for it now means the new prefix instead. Rename the tag, or accept the new meaning. Other namespaced tags — type:product and the like — are untouched, and stay tag searches permanently.

If you have a listener on PagesListSearchEvent rewriting the search with a regular expression, check its character class. It receives the raw string before parsing, so a \S+ now swallows a closing parenthesis:

// (product:ABC OR product:DEF) captured "DEF)" — including the parenthesis
preg_replace('/product:(\S+)/', 'customProperty:productCode:$1', $search);
// use a class that stops at the delimiter
preg_replace('/product:([^\s)]+)/', 'customProperty:productCode:$1', $search);

Structural mistakes now raise SearchException instead of being read as a tag: an unclosed parenthesis, an empty (), a trailing operator. An unknown prefix is still never an error — the engine cannot tell a namespaced tag from a typo, so pw:pages-list:lint finds the searches that match nothing by running them.