Issue 252 Article Links Did Not Open

A link to a Knowledge article did not open

Reported and fixed by: PR #252 from Dr4inder, November 2026 · Module: Knowledge · Fixed in: the release after 4.11.0 (changelog #2748)

---

What you saw

1. In Knowledge, open a link to an article: one somebody shared with you, the address bar after a reload, or a link inside another article (?article=23).
2. The page loaded, showed nothing for five seconds, then gave up and showed the list. The article never opened.

It did not happen everywhere, which is why it went unnoticed:

• It needed a top level with no articles on it - every article filed in a folder, which is how a tidy knowledge base ends up - or any language other than English.
• In the Tree layout the article did open, but the sidebar stayed on All articles, and Back to list did not take you to the article's folder.

---

What was actually wrong

The page cannot open an article until its first article list has loaded, so the code that handles ?article= waits for it. It decided "the list has loaded" like this:

// assets/js/knowledge.js - before
const checkAndLoad = setInterval(() => {
    if (articles.length > 0 || document.getElementById('articleList').innerHTML.includes('No articles')) {

That is two guesses, and each one can be wrong:

Guess	When it is wrong
articles.length > 0 - "some articles came back"	The top level is fetched first, and it shows only what is at the top level. If every article is in a folder, an empty list is the right answer, and it looks exactly like "not loaded yet".
The screen says No articles	Only in English. And a top level that holds folders draws the folders, not an empty message, so it fails in English too.

After five seconds a safety timer shows the list, so the page looked as if the link was broken.

There was already a flag that answers the real question. kbArticlesLoaded is set the moment the first fetch comes back, whatever it contains. Nothing was using it here.

The lesson for anyone writing a wait: never ask the screen whether something has finished. The text is translated, the layout changes, and an empty answer is still an answer. Ask the variable the fetch sets.

---

The fix

1. Wait for the load, not for its contents (from the PR)

// Settled, not succeeded - a folder list that failed must not stop the article opening.
if (kbArticlesLoaded && kbFoldersSettled) {
    clearInterval(checkAndLoad);
    Promise.resolve(viewArticle(articleId)).then(() => {
        if (!currentArticle || String(currentArticle.id) !== String(articleId)) { showView('list'); return; }
        kbHomeLinkedArticle();

kbFoldersSettled was added in the review (see below). It is set in a finally, so a folder list that fails still lets the article open.

2. Open the article in its own folder (from the PR, moved in the review)

A link can point anywhere, so after it opens the article, the page selects that article's folder and loads its list behind the article:

function kbHomeLinkedArticle() {
    if (!currentArticle) return;
    const folder = currentArticle.folder_id == null ? '' : String(currentArticle.folder_id);
    if (activeFolder === folder) return;
    if (folder !== '' && !kbFolders.some(f => String(f.id) === folder)) return;
    activeFolder = folder;
    renderFolderTree(kbRootArticleCount);
    loadArticles(document.getElementById('articleSearch').value, activeTagFilters);
}

kbRootArticleCount keeps the All articles count right while the tree is repainted. Before, the only copy of that number was inside loadFolders().

No database change, nothing to run after upgrading.

---

Files changed

File	Change
🔵 assets/js/knowledge.js	the link handler waits on kbArticlesLoaded and kbFoldersSettled; new kbHomeLinkedArticle(); kbRootArticleCount
🔵 knowledge/index.php	knowledge.js?v=68
🟢 knowledge/help.php, lang/{en,de,es}/knowledge.php	one line in Sharing & export: where a link lands
🧪 tests/knowledge-article-links.php	new: 10 checks in headless Chrome

---

Review of PR #252

Verdict: merge, with fixes. The PR found a real bug that only shows on some installs, explained exactly why, and fixed the cause by using a flag that was already there. It came with a test that fails 8 of 8 on the old code. Merged as it was (e069275c0), so the commit stays Dr4inder's. Changes went in on top.

Changed after merging

1. The folder move ran for every article, not just links. The PR put it inside viewArticle(). That function is also what runs when you:

• click a row or card in the list, including a search result
• press Enter on a selected row
• choose Edit from the right-click menu
• click an article link in the AI chat panel

Search from All articles, open a result filed in Networking, and the sidebar jumped to Networking. The list behind the article was reloaded as "your search, inside Networking", so Back to list no longer showed your results. The move now lives in kbHomeLinkedArticle(), called only by the link handler. That is the one place where the list behind the article is not already the one you were using.

TRAP: viewArticle() is shared by every way of opening an article. Anything added to it happens on all of them. Put link-only behaviour in the link handler.

2. It could select a folder you cannot see. An article set not to inherit its folder's permissions is judged on its own access list (includes/knowledge/visibility.php). So someone can be able to read an article whose folder is hidden from them. Selecting that folder would leave a folder that is not in their tree selected, with an error where the list should be. kbHomeLinkedArticle() now moves only to All articles or a folder in kbFolders, the list the server sent for this analyst. Otherwise it leaves the selection where it was.

That check needs the folder list to have arrived, so the link handler now waits for kbFoldersSettled as well as kbArticlesLoaded. It is settled, not succeeded: if the folder list fails, the article still opens.

3. The cache key. The PR used knowledge.js?v=67, which main had already taken (PR #251 used 66, and the PDF change 67), so the browser would have kept the old script. It is now 68.

Checked and left as it is

• The wait no longer reads the screen at all, so translated installs work the same as English ones.
• ?edit=1 links still open the editor after the article, and the folder is selected first.
• Root articles (folder_id null) map to All articles (''), not to the "unfiled" filter ('root'). The top level already shows the unfiled articles, so this is right.

How it was proved

The test, tests/knowledge-article-links.php, runs the real functions from knowledge.js on a bare page in headless Chrome, with a fake server whose top level holds only folders. 10 checks:

• 8 from the PR: in each of List, Cards, Tree and Details, the linked article opens with its folder selected and the right list behind it. Then a link inside it opens a second article in another folder.
• 2 added in the review: a link to an article whose folder is not in the analyst's tree leaves the selection alone, and opening an article from the list does not change the folder.

The control: with the PR's original knowledge.js, the 8 pass and the 2 new checks fail. With the code before the PR, the PR reports all 8 fail.

The real page. A throwaway install, with a parent folder, a child folder and nothing at the top level. The real Knowledge page was driven in a same-origin iframe:

Did	Got
Opened ?article=12 (in the parent)	✅ the article, parent folder selected, its list behind
Clicked the link inside it to ?article=11 (in the child)	✅ the second article, child folder selected, its list behind
The same first step on the code before the PR	❌ nothing for five seconds, then the list, and the address bar cleared

Not proven here: a link in a non-English install was only tested in the fake page (it shows Keine Artikel), not on a translated real install. The fix does not read any text, so there is nothing language-specific left to break.

⚠️ If the browser tests hang on Windows. tests/support/ticket-workspace-browser.php can leave a headless Chrome running when a run is stopped. Once a few have built up, later runs hang, including tests that passed a minute earlier. On the maintainer's machine, closing every chrome.exe whose profile is in %TEMP%\freeitsm_embed_* and running again fixed it. This may also be why #250's test "did not finish". It passes 6 of 6 after a clean start.

---

What this means for you

• A link to a Knowledge article opens the article, whatever your language and however your folders are arranged.
• It opens in the article's own folder, so Back to list shows the articles filed beside it.
• Opening an article from the list or from search results keeps your place, as before.

Related

• Knowledge folders and security and its Developer Guide
• Clicking a folder left the open article on screen - the PR before this one, same area
• Knowledge
• Bugs resolved