RESOLVED WONTFIX

Status

()

--
trivial
RESOLVED WONTFIX
9 years ago
6 years ago

People

(Reporter: justdave, Assigned: justdave)

Tracking

Details

(URL)

Attachments

(1 attachment)

The link for the QuickSearch docs in the release notes is 404.  Presumably it's set up as a relative link so it'll work when viewed from within a Bugzilla installation, but it's broken on www.bugzilla.org.  Not sure the best way to deal with this...  perhaps a 302 redirect to somewhere that it actually exists?
I could probably fix do-release.pl to fix these URLs somehow or another.
Severity: normal → trivial
> The link for the QuickSearch docs in the release notes is 404.  Presumably it's
> set up as a relative link so it'll work when viewed from within a Bugzilla
> installation, but it's broken on www.bugzilla.org.  Not sure the best way to

fwiw on one installation I see a link from <bzroot>/docs/en/html/query.html to <bzroot>/docs/page.cgi?id=quicksearch.html which doesn't work either.

Comment 3

8 years ago
In Bugzilla, I get the link:
https://bugzilla.mozilla.org/page.cgi?id=quicksearch.html

Can we get the link fixed on the page, or create a copy of the page so the link is active?  Thank you.
(In reply to comment #3)
> Can we get the link fixed on the page, or create a copy of the page so the
> link is active?  Thank you.

  No, the old release note pages won't be fixed. We would only fix this on the newer ones.
We could always put a 301 redirect from the broken URL to the correct one that replaced it in the .htaccess on the website, right?
(In reply to comment #5)
> We could always put a 301 redirect from the broken URL to the correct one
> that replaced it in the .htaccess on the website, right?

  It's not that the issue is there's this one URL, it's that the way the release notes are generated, they expect to be part of a Bugzilla installation. There are numerous URLs that have this problem in the release notes.
Aren't the release notes committed separately on the website from where they go in the source that gets distributed?  Which means they could be corrected in place on the site without breaking the older distributed versions.  There's the whole "make the website user-friendly" aspect to this, too.  That the page is originally built as part of the source distro, intended for display within the Bugzilla tree, doesn't really matter since the page displayed on the site isn't checked out of the source tree anyway (it's only a copy of it).
  Sure--if somebody wants to write the code to make it happen, it's reliable, doesn't add any complexity to the release process, and doesn't require a ton of review time, I would be happy to see it happen. I'm not against the result, I'm only saying that I don't think the effort would be worth the benefit.
Created attachment 547598 [details] [diff] [review]
patch

OK, here you go.
Assignee: website → justdave
FWIW, this is a permanent one-time future-compatible fix, there's nothing additional to the release process.
Comment on attachment 547598 [details] [diff] [review]
patch

  Cool, I was thinking something like this might be good. :-)

>Index: src/.htaccess
>+RewriteEngine On
>+RewriteCond %{QUERY_STRING} =id=quicksearch.html

  Actually, we should just match all *.cgi requests within the releases/ directory. (That would solve all the problems.)

>+RewriteRule releases/(\d+\.\d+)[^/]*/page.cgi$ http://landfill.bugzilla.org/bugzilla-$1-branch/page.cgi?id=quicksearch.html [R=301]

  For what it's worth, for security reasons, the bugzilla-$1-branch installs go away when they reach EOL, so there will still be broken links for older releases.
Attachment #547598 - Flags: review-

Comment 12

6 years ago
Since 3.6 is now EOL, I can't see any value in fixing this.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.