[imorland]

Fixes: no issue filed. Follow-up to #5321 and #5328.

Changes proposed in this pull request:

A review of OpenSearch, and driving it in headless Chromium against a dev forum, turned up searches from the address bar that went wrong, a forum Chrome never added, and suggestions that missed obvious titles.

Searches from the address bar:

• Spaces and true/false. Browsers send a space as + (Chromium escapes {searchTerms} with EscapeQueryParamValue(…, true)), and Mithril's query parser keeps the +. ?q=hello+world showed hello+world in the search box, and sorting or loading more searched for it; only the first page, rendered by the server, was right. Mithril also turns true and false into booleans: a search for true threw in searchToQuery and left the discussion list empty, and one for false was ignored. GlobalSearchState now reads q from the address with URLSearchParams.
• An address that doesn't change. The description's search address depended on the homepage, but browsers keep the one they were given: after the homepage changed, searches landed on a page that ignored them. It is now /opensearch/search?q=, which redirects to the discussion list wherever it is, with spaces as %20.
• The homepage at its own address. With /all as the homepage, /all?q=… (an engine saved while another page was the homepage) fell back to / without the query. The frontend now moves the address to the root and keeps the query, with or without a trailing slash.

The description:

• Chrome's size limit. Chrome ignores a description over 50,000 bytes (max_body_size in TemplateURLFetcher). An uploaded .ico was embedded as it was: a 60KB one made the document 81KB, and Chrome added nothing. Images that don't fit are left out, and Chrome then shows /favicon.ico. An .ico also declares its own size rather than 16×16.
• Control characters in the title or description made it ill-formed. They are left out.
• DOM rather than XMLWriter, which core doesn't require and some distributions package separately. DOM is an install requirement already.
• No image work per request. The favicon was read, resized and encoded on every request. The images that fit are cached for a day, as data: URIs, by where the favicon is stored, which changes when it is replaced.

Caching:

• /opensearch was public, max-age=3600, and the forum adds the visitor's session cookie and CSRF token to it. A shared cache that honoured public could hand one visitor's session to others. It is private now, and so are /manifest and the /favicon.ico redirect, which had the same problem before OpenSearch.

Suggestions:

• The query is echoed as typed. Chrome drops a response whose first element differs from the input, so a trailing space dropped them. A q that isn't text suggests nothing.
• Only the first 8 words are matched. Each word added two LIKE conditions, so a guest could build a query SQLite refuses with a 500.
• Words are completed after punctuation: "solv" finds "[Solved] …", "fibre" finds "carbon-fibre". The database finds words at the start of a title or after a space; when there are fewer than 8, it finds up to 100 recent titles containing the words, and where they start is checked in PHP, ignoring case and accents as MySQL, MariaDB and PostgreSQL do.
• On SQLite, whose LIKE folds ASCII only, accented words match in any case ("über" finds "Über…").

Reviewers should focus on:

• Chrome's "tab to search" can't be turned on by a site. Chrome adds an engine from a description only on a page whose path is /, and since TemplateURLData::ActiveStatus it adds it as inactive (is_active=0). Inactive engines can't be used for keyword search (CanBeUsedForKeywordMatching) until someone activates them under "Inactive shortcuts" in chrome://settings/searchEngines. Headless Chromium 156 stored the forum with the right search and suggestion addresses and is_active=0. Forums in a subfolder are never added automatically.
• Choosing a suggestion searches for its title; Chrome and Firefox ignore the addresses in the response.
• The suggestion matching was tested on SQLite only. Accent-insensitive matching on MySQL, MariaDB and PostgreSQL follows from their collations and ILIKE; the PHP check now agrees with them.
• OpenSearchDescription takes a cache repository in its constructor, and searchPage() is public.

Necessity

• Has the problem that is being solved here been clearly explained?
• If applicable, have various options for solving this problem been considered?
• For core PRs, does this need to be in core, or could it be in an extension?
• Are we willing to maintain this for years / potentially forever?

Confirmed

• Frontend changes: tested on a local Flarum installation. (Headless Chromium against a dev forum: 19 checks, including Chrome adding the forum with a 60KB .ico.)
• Frontend changes: tests are green (run yarn test in js/).
• Frontend changes: tests have been added, or are not appropriate here.
• Backend changes: tests are green (run composer test).
• Backend changes: tests have been added, or are not appropriate here.
• Where applicable, changes are suitable for all supported database drivers (MySQL, MariaDB, PostgreSQL, SQLite). (Tested on SQLite only.)
• Core developer confirmed locally this works as intended.
• The description above is written by me and describes what this pull request actually does.