Troubleshooting

Work down this page in order — the first three sections cover most of what gets reported.

Nothing called "FAQ" is in the admin menu

It is not there. The menu entry is Knowledge Base, under Extensions → Business Tools, and it points at /admin/faq.

On the Extensions screen the row is titled Knowledge Base & FAQs. In every error message, licence response and log line the addon is knowledge_base. The word "FAQ" appears in the URL, the permission keys and the table names, and nowhere in the navigation.

If the Knowledge Base entry is missing entirely, the extension is not activated: open /admin/system/extension and activate it there.

A 403 mentioning knowledge_base or 39166202

The licence for this addon is not valid. knowledge_base is its internal name and 39166202 is its CodeCanyon item id — neither string appears in the admin menu, which is why this reads like an unrelated fault.

Check the licence at /admin/system/license. If the core licence itself is invalid the message is different — "License not activated", "License has expired" or "License has been revoked" — and every addon is affected, not just this one.

Outbound HTTPS to the licence host is required. A blocked egress rule takes days to become visible because of the grace period, so a 403 that appears "for no reason" days after a firewall change is usually this.

An article will not save

Every validation failure comes back as a single 400 listing all of them at once. The bounds:

The two that surprise people are the lower bounds. Fees? is too short to be a question and Yes. is too short to be an answer. Both are deliberate.

A category containing a /, an & or an accented character is rejected by the character-set rule. So is a tag.

The image disappeared on save

The image field is validated as a URL, not cleaned as text. It is dropped — silently — if it is any of:

• Not site-relative (/…) and not http(s)://…
• A javascript:, data:, vbscript: or file: URL
• Longer than 191 characters, which is the column width

A long signed URL from an object store will exceed 191 characters routinely. Upload through the form instead of pasting an external link.

The AI buttons return an error

Almost always the missing key. With DEEPSEEK_API_KEY unset, every helper returns 500 with DeepSeek API key is not set, and the only advance warning is one line in the backend log at boot. No screen anywhere shows the integration's status, and the buttons render whether or not a key exists.

DEEPSEEK_API_KEY="sk-…"

Restart the backend after adding it.

If the key is present and calls still fail:

• A 400 stating two character counts is an input bound, not an outage — topic 500, question 2,000, content 20,000. Nothing was billed.
• The answer helper failing on a large library is expected. It puts every published article into one prompt with no cap, so past a certain library size it stops fitting. Answer by hand and use generate for the drafting.
• A DeepSeek API error in the response is passed through from the provider. Check your balance and the key's validity in their dashboard; nothing in this product meters or caps spend.

See AI-assisted authoring.

The search report is empty

Three separate causes, in the order to check them.

You are upgrading from before v6.0.9. Recording used to be conditional on a user id that a public route can never have, so nothing was recorded for seven months. There is no historical data to recover; the report starts accumulating from the day you upgrade.

You are testing the wrong search box. Only the help-centre search on /faq records. Filtering the admin list, or using the search parameter on the article list, records nothing.

Your queries are too short. Only queries longer than three characters are recorded. BTC, KYC and 2FA leave no trace at all.

Recording is fire-and-forget and logs its failures. If it has genuinely broken, there will be a FAQ warning line naming the query it could not record.

The trending-searches block does not appear on /faq

It renders nothing when there is nothing to show, which is correct behaviour on a fresh install. It draws the last seven days of recorded queries and excludes any that returned no results. So a new install, an install where everybody searches in three characters or fewer, and an install where every search fails all look identical here.

Check the admin dashboard's search block first — if that is empty too, the cause is in the section above.

An asker says they never received an answer

Answering writes the answer, then attempts two deliveries: an email to the address on the form, and an in-app notification only if that address matches a registered account. The form takes an arbitrary address, so the asker and the account that submitted are not necessarily the same person.

Both are best-effort and run after the answer is committed, so a mail failure never loses your work — it is written to the backend log as an ADMIN_FAQ error naming the question id and the address.

Questions are missing from the queue

If you are on a build before v6.0.7, they may genuinely be unreachable. The queue loaded a flat first hundred rows with no pagination and no filter, and split them into tabs in the browser. Past a hundred questions, the oldest pending ones fell off the end — absent from the Pending tab, invisible to the search box, and reachable by no URL.

Upgrade, then check the Pending tab sorted oldest first.

On a current build the list is paginated and both the search and the tab counts run server-side, so the badges cannot disagree with the list.

Unpublished articles are still readable

Fixed in v6.0.9. Before that, the list hid them but the detail endpoint served them in full to anyone holding a direct link.

On a current build, unpublishing holds on every door: the list, search, the category list, the related-article panel and the article URL itself, which answers 404 rather than 403. If you unpublished something sensitive on an older build, assume it was readable for as long as that build was running.

Enabling a page republished things I had unpublished

Working as built. Enable page sets status to true for every article on that page path in one statement — the per-article status is not remembered, so drafts sitting on a page come back live along with everything else.

Use per-article status for anything you want to stay unpublished, and keep drafts on a page path you never bulk-enable.

Deleting a page removed more than I could see

Also working as built, and worth stating plainly: Delete page and Enable/Disable page match on the page path alone. Narrowing the list by category, tag or search does not scope them.

The section's count badge is the true number of rows the action will touch — it is computed across the whole table, not from the rows on screen. Read it before confirming.

A category vanished

Categories are not records. They are a SELECT DISTINCT over a text column, so a category exists exactly as long as at least one article uses it. Moving the last article out of it, unpublishing that article, or deleting it removes the category from every list.

The same rule makes Trading and trading two different categories, with two tabs, and nothing warns you.

My integration works in development and breaks in production

Almost always the JSON columns. tags and relatedFaqIds are native JSON on MySQL — the driver returns a parsed array — and LONGTEXT on MariaDB, where it returns a raw string. The API normalises both, but code reading the tables directly sees whichever the server underneath produces.

Handle both shapes. The same applies to COUNT results, which some drivers return as strings.

Nothing on this page describes my problem

Check the backend log for lines tagged FAQ and ADMIN_FAQ — every route in this addon writes its steps and its failures under one of those two modules. Then read the release notes for your version; several behaviours documented here changed recently, and the notes state precisely what a given build did.