Fix blank redirect stubs for unmapped fragments

[hanzei]

Why

Visiting a redirect-stub URL with an anchor that wasn't explicitly mapped returns a blank page. For example, http://docs.mattermost.com/configure/environment-configuration-settings.html#database renders nothing — the old configure/… path is a redirect stub, and #database was never added to its fragment map, so the JS logged unknown redirect: database and left the user staring at an empty page.

Redirect stubs (generated from redirects.py via source/_templates/redirect.html) only redirected fragments explicitly listed in redirects.py. Any other fragment hit the else branch and blanked out. The // TODO: redirect the user to a 404 page was also still unimplemented.

Changes

source/_templates/redirect.html:

1. Broader fallback for unmapped fragments. When a fragment isn't explicitly mapped, redirect to the page's base destination (the - default entry) and carry the original fragment over — anchor names are generally preserved across a page move, so …#database / …#mobile-security now land on the real section instead of a blank stub. Fixes the whole class of unmapped-anchor links.
2. Resolved the // TODO. When no redirect can be resolved at all (no matching fragment and no base entry), the user is sent to /404.html instead of a blank page.
3. Own-property lookup. fragment_redirects is a plain object, so fragment in … also matched inherited members (#toString, #constructor, …), passing a non-string to redirectTo(). Switched to Object.prototype.hasOwnProperty.call.
4. Extracted the leading-/ → absolute-origin handling into a small redirectTo() helper, and log the fallback at console.debug (not warn) so routine redirects stay quiet.

source/redirects.py:

5. Removed 233 now-redundant fragment redirects. With the fallback in place, any entry whose target is exactly <base-target>#<same-fragment> is redundant — the fallback produces the identical destination. Kept untouched: fragments on pages with no base entry (the fallback can't reach them → they'd 404), fragments pointing to a different page, and fragments whose anchor was renamed at the destination. (2166 → 1933 entries.)

Verification

• Verified in a browser against the PR preview: both direct navigation and the redirect path land #database exactly 150px below the fixed header (matching section[id] { scroll-margin-top }), stable across the full page load. Works in Chrome and Firefox. (There's a pre-existing Edge-only quirk where a long page's late reflow leaves the anchor slightly high — unrelated to this change and out of scope.)
• redirects.py re-imports cleanly; 0 redundant entries remain; the 34 no-base fragment entries are preserved.

🤖 Generated with Claude Code

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 6901cbe4-de32-4b63-865b-b955a55786f8

📥 Commits

Reviewing files that changed from the base of the PR and between 888741e and 3bd9417.

📒 Files selected for processing (2)

• source/_templates/redirect.html
• source/redirects.py

💤 Files with no reviewable changes (1)

• source/redirects.py

🚧 Files skipped from review as they are similar to previous changes (1)

• source/_templates/redirect.html

---

📝 Walkthrough

Walkthrough

The redirect template now uses a helper for fragment-based navigation, falls back to base-page redirects with preserved fragments, and sends unresolved fragments to /404.html. The redirect map also updates many documentation redirect targets and anchor entries.

Changes

Redirect navigation updates

Layer / File(s)	Summary
Fragment redirect flow source/_templates/redirect.html	The fragment redirect path now delegates direct mappings to a helper, appends the original fragment to base-page redirects when needed, and redirects unresolved fragments to /404.html.
Administration and help redirects source/redirects.py	Redirect entries change for command-line tools, eDiscovery, config settings, deployment pages, and messaging help pages.
Messaging redirects source/redirects.py	Redirect coverage changes for channel settings, theme colors, formatting, mentions, sidebar organization, searching, status, file sharing, and related messaging pages.
Onboarding, welcome, and playbooks redirects source/redirects.py	Redirect entries change for onboarding, shared channels, subscription, playbooks, welcome pages, and the end-user guide.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarizes the main fix: handling unmapped redirect fragments to avoid blank pages.
Description check	✅ Passed	The description is directly about the redirect-stub fragment fix and matches the changes in the PR.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch redirect-fragment-fallback

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@source/_templates/redirect.html`:
- Around line 31-33: The fragment lookup in redirect.html is using the
fragment_redirects object with an in check, which can match inherited properties
and lead redirectTo() to receive a non-string value. Update the fragment lookup
in the redirect logic to use an own-property check on fragment_redirects before
calling redirectTo(), and apply the same safe pattern to the DEFAULT_PAGE
fallback so only real redirect entries are used.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: eaa314dd-ad17-4381-943a-5cbfa6eeecd3

📥 Commits

Reviewing files that changed from the base of the PR and between 6e6ca68 and 888741e.

📒 Files selected for processing (1)

• source/_templates/redirect.html

[github-actions]

Newest code from mattermost has been published to preview environment for Git SHA 888741e

[github-actions]

Newest code from mattermost has been published to preview environment for Git SHA c03e13c

[github-actions]

Newest code from mattermost has been published to preview environment for Git SHA 3bd9417

[hanzei]

These are not needed any longer. The new code handles them automatically.

[esethna]

Thanks @hanzei. Can you confirm that it's intentional you have removed so many redirects? Spot checking a few seem to be causing missed subsection redirects, for example: /administration/ediscovery.html#mattermost-restful-api

Also I noticed that mistyped or invalid URLs now are leading to a 404 page vs current behaviour of at least landing them at the home docs.mattermost.com. For example https://docs.mattermost.com/admin (page does not exist)

Is there a safer way we can make this change to avoid blank pages without potential regressions?

[esethna]

Friendly ping @hanzei ^