FAQ v6.1.4

Release Date: August 11, 2026 Tags: ADMIN, CONTENT, SEARCH, RELIABILITY, PERFORMANCE, BUG-FIXES

Overview

One filter on the admin FAQ list could never match anything. Picking a tag emptied the table and set the three counters above it to zero, so the screen reported that the tag had no questions instead of reporting a failure. The questions were there the whole time and none of them were changed or lost, but if you have ever concluded from that screen that a tag was unused, read Upgrade Notes.

Alongside it, a reorder that failed answered with an internal server error naming a database transaction state instead of saying the reorder had failed, and the list of site pages an FAQ can be attached to is now held for a minute rather than rebuilt on every request.

Requires Core v6.6.3.

Update Instructions

pnpm updator

Nothing to configure, and no setting changes.

Upgrade Notes

• The tag filter answered every tag with an empty table, and the counters agreed with it. Any decision taken from that screen about which tags are in use — retagging questions, or writing a fresh answer because the existing one appeared to be missing — was taken against a blank list. Re-check any tag you believed was unused once you have updated; the questions carrying it are untouched and appear again immediately.

Changed

The list of pages an FAQ can be attached to

• Changed that list to be held for one minute rather than rebuilt on every request. Producing it means walking the whole of the site's page tree folder by folder, and the admin screen asked for a fresh walk each time somebody opened it. The list itself is unchanged, and a page newly added to the site appears in it within a minute. A walk that fails part way through is never held, so a transient disk error cannot stick.

Fixed

Filtering the FAQ list by tag returned nothing, for every tag

The tags offered in the admin's advanced search are supplied by a different route than the list itself, so every tag genuinely in use appeared there and looked selectable. Choosing one emptied the table. The same filter also feeds the active, inactive and total counters above the table, so all three fell to zero at the same moment — which reads as a truthful "no questions carry this tag" rather than as a filter that failed. The tags on a question are stored as a structured value, and the comparison the filter built was being quoted and escaped as though it were structured data too before it reached the database, so it could only ever have matched a question whose tags were literally that quoted text. Nothing matched, for any tag, on any install.

• Fixed the tag filter, which now compares against the stored tags as plain text and returns the questions that actually carry the tag. The counters follow the same filter, so they report that tag's real active, inactive and total figures instead of zeros. Choosing several tags narrows to the questions carrying all of them.

A failed reorder reported the platform's plumbing instead of the failure

When a reorder went wrong, the message that reached the screen was not the one the reorder itself raised. The cleanup step that follows a failure ran unconditionally, including when the reorder's database work had already closed itself out — either because the new order had gone through and something after it stumbled, or because the attempt to commit it was itself what failed. Cleaning up something already closed fails in its own right, and that second failure is what surfaced: an internal server error naming a database transaction state, which tells an operator neither what went wrong nor whether the reorder took effect.

• Fixed the reorder answering with a database transaction state instead of the failure that actually occurred. Cleanup now runs only when there is something left to clean up, so the screen reports that the reorder failed. Whether the new order was saved before the failure depends on where it stopped, so re-open the list after seeing this error — an order that had already gone through is left in place, and nothing about the reorder's own behaviour changed here beyond the message.