[PR #1373] [MERGED] docs: fix dead relative links on the creating files page #1340

New issue

Closed

opened 2026-10-18 14:18:58 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 14:18:58 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/open-webui/docs/pull/1373
Author: @silentoplayz
Created: 9/2/2026
Status: ✅ Merged
Merged: 9/2/2026
Merged by: @silentoplayz

Base: main ← Head: docs/creating-files-link-fix

📝 Commits (1)

749c2e5 docs: fix dead relative links on the creating files page

📊 Changes

1 file changed (+4 additions, -4 deletions)

View changed files

📝 docs/features/open-terminal/use-cases/creating-files.md (+4 -4)

📄 Description

Summary

The four relative links on the Create Documents & Files page are dead when clicked. This adds the file extension to each one, which is the form Docusaurus resolves at build time.

Clicking Files shown in the chat message on that page currently lands on /features/open-terminal/use-cases/file-browser, which does not exist. The correct target is /features/open-terminal/file-browser, and that is exactly what the href in the HTML says.

Docusaurus renders the correct href for the server-side pass. The hydrated router then re-resolves the original relative path against the page URL rather than the file path, so a click navigates somewhere the markup never pointed:

../file-browser   ->  /features/open-terminal/use-cases/file-browser
./file-analysis   ->  /features/open-terminal/use-cases/creating-files/file-analysis

Adding the extension fixes it because the link is then resolved at build time and the router never re-resolves it. 109 links in this repo already use that form.

-Long documents open at whichever page you ask for. See [Files shown in the chat message](../file-browser#files-shown-in-the-chat-message).
+Long documents open at whichever page you ask for. See [Files shown in the chat message](../file-browser.md#files-shown-in-the-chat-message).

No linked issue. This corrects links on the page added in #1370.

Checklist

I have reviewed the relevant documentation and matched the existing style.
This PR meets Open WebUI's contribution standards: it is accurate, relevant to users, narrowly scoped, maintainable, and not promotional content, advertising, lead generation, SEO placement, or a request to list a product, service, provider, integration, gateway, tool, or company primarily for visibility.
I understand that PRs that do not meet these standards may be closed without review and will not be merged. Repeated, low-quality, off-topic, promotional, or intentionally misleading submissions may result in the contributor being blocked from future participation in Open WebUI repositories.

Notes for reviewers

Reproducing it on the current site

Open https://docs.openwebui.com/features/open-terminal/use-cases/creating-files/
Left click Files shown in the chat message
It renders Page Not Found

Worth knowing before checking: hovering, middle-clicking, and pasting the URL all work, because each of those uses the href, which is correct. Only a plain left click reproduces it.

That is also why the build does not catch this. onBrokenLinks is set to throw and passes, because it validates the rendered href. Setting onBrokenMarkdownLinks to throw would fail the build when an extension-form link loses its target, which is the check that catches this class of problem.

Verification

I ran npm run build and clicked all four links on the built site. Every one lands correctly, including the anchor:

Link	Lands on
Files shown in the chat message	`/features/open-terminal/file-browser#files-shown-in-the-chat-message`
file browser	`/features/open-terminal/file-browser`
Analyze Documents & Data	`/features/open-terminal/use-cases/file-analysis`
The File Browser	`/features/open-terminal/file-browser`

Scope

I kept this to the one page. The same pattern affects other pages across the docs, and I am reporting those separately with the full list rather than widening this PR.

This PR was prepared with AI copilot assistance. I have thoroughly reviewed and manually tested it.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/docs/pull/1373 **Author:** [@silentoplayz](https://github.com/silentoplayz) **Created:** 9/2/2026 **Status:** ✅ Merged **Merged:** 9/2/2026 **Merged by:** [@silentoplayz](https://github.com/silentoplayz) **Base:** `main` ← **Head:** `docs/creating-files-link-fix` --- ### 📝 Commits (1) - [`749c2e5`](https://github.com/open-webui/docs/commit/749c2e56e6badcbcc383d622409fc15de4cc0247) docs: fix dead relative links on the creating files page ### 📊 Changes **1 file changed** (+4 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `docs/features/open-terminal/use-cases/creating-files.md` (+4 -4) </details> ### 📄 Description ## Summary The four relative links on the Create Documents & Files page are dead when clicked. This adds the file extension to each one, which is the form Docusaurus resolves at build time. Clicking **Files shown in the chat message** on that page currently lands on `/features/open-terminal/use-cases/file-browser`, which does not exist. The correct target is `/features/open-terminal/file-browser`, and that is exactly what the `href` in the HTML says. Docusaurus renders the correct `href` for the server-side pass. The hydrated router then re-resolves the original relative path against the page URL rather than the file path, so a click navigates somewhere the markup never pointed: ``` ../file-browser -> /features/open-terminal/use-cases/file-browser ./file-analysis -> /features/open-terminal/use-cases/creating-files/file-analysis ``` Adding the extension fixes it because the link is then resolved at build time and the router never re-resolves it. 109 links in this repo already use that form. ```diff -Long documents open at whichever page you ask for. See [Files shown in the chat message](../file-browser#files-shown-in-the-chat-message). +Long documents open at whichever page you ask for. See [Files shown in the chat message](../file-browser.md#files-shown-in-the-chat-message). ``` ## Related issue or discussion No linked issue. This corrects links on the page added in #1370. ## Checklist - [x] I have reviewed the relevant documentation and matched the existing style. - [x] This PR meets Open WebUI's contribution standards: it is accurate, relevant to users, narrowly scoped, maintainable, and not promotional content, advertising, lead generation, SEO placement, or a request to list a product, service, provider, integration, gateway, tool, or company primarily for visibility. - [x] I understand that PRs that do not meet these standards may be closed without review and will not be merged. Repeated, low-quality, off-topic, promotional, or intentionally misleading submissions may result in the contributor being blocked from future participation in Open WebUI repositories. ## Notes for reviewers **Reproducing it on the current site** 1. Open `https://docs.openwebui.com/features/open-terminal/use-cases/creating-files/` 2. Left click **Files shown in the chat message** 3. It renders Page Not Found **Worth knowing before checking:** hovering, middle-clicking, and pasting the URL all work, because each of those uses the `href`, which is correct. Only a plain left click reproduces it. That is also why the build does not catch this. `onBrokenLinks` is set to `throw` and passes, because it validates the rendered `href`. Setting `onBrokenMarkdownLinks` to `throw` would fail the build when an extension-form link loses its target, which is the check that catches this class of problem. **Verification** I ran `npm run build` and clicked all four links on the built site. Every one lands correctly, including the anchor: | Link | Lands on | |---|---| | Files shown in the chat message | `/features/open-terminal/file-browser#files-shown-in-the-chat-message` | | file browser | `/features/open-terminal/file-browser` | | Analyze Documents & Data | `/features/open-terminal/use-cases/file-analysis` | | The File Browser | `/features/open-terminal/file-browser` | **Scope** I kept this to the one page. The same pattern affects other pages across the docs, and I am reporting those separately with the full list rather than widening this PR. This PR was prepared with AI copilot assistance. I have thoroughly reviewed and manually tested it. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-18 14:18:58 +00:00