From: Tim Cross <theophilusx@gmail.com>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: Max Nikulin <manikulin@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: [BUG] The documentation webserver gives 404s [9.5.4 (release_9.5.4-3-g6dc785 @ <censored>)]
Date: Mon, 04 Jul 2022 22:27:17 +1000 [thread overview]
Message-ID: <87bku59hpp.fsf@gmail.com> (raw)
In-Reply-To: <875ykdnkmk.fsf@localhost>
Ihor Radchenko <yantar92@gmail.com> writes:
> Tim Cross <theophilusx@gmail.com> writes:
>
>> I do have an alternative suggestion which may help. Given that the
>> 'broken' URLs are actually from external links to old documentation
>> which has been removed, what we could do is create a more informative
>> 404 page. Once users are on the 'real' site, the case issue does not
>> exist. It is only a problem due to outdated URLs on external sites like
>> stack overflow. Instead of just saying 404 Not Found, the page could say
>> the requested URL was not found and is likely a link to old outdated doc
>> documentation. The page could include a link to the main orgmode
>> page. This would be a fairly simple 'fix' that would improve user
>> experience to some degree.
>
> This sounds like a good idea.
> I am not sure if it is feasible, but the 404 page could also provide
> suggestions based on similar existing links. I have something like
> https://list.orgmode.org/orgmode/83tu89b7pr.fsf@gnu.org/ in mind.
>
Sorry, I don't understand the relevance of that link (it seems to be to
a discussion about GC size?).
Yes, you should be able to use JS to examine the URL which failed and
transform it by making the first character of each word in the url
filename upper case. Essentially do what was proposed with the rewrite
rules, but which wouldn't have the same performance hit as it would only
be triggered when incorrect URLs were entered and wold run in the browser.
The only downside is it wouldn't work with non JS based browsers (like
eww). If the server had support for server side scripting (perl, ruby,
etc) it could be done so that it would work with all browsers by doing
the rendering server side.
next prev parent reply other threads:[~2022-07-04 12:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-03 10:01 [BUG] The documentation webserver gives 404s [9.5.4 (release_9.5.4-3-g6dc785 @ <censored>)] Rudolf Adamkovič
2022-07-03 11:50 ` Ihor Radchenko
2022-07-03 12:23 ` Tim Cross
2022-07-03 14:01 ` Ihor Radchenko
2022-07-03 16:48 ` Max Nikulin
2022-07-03 21:30 ` Tim Cross
2022-07-04 12:10 ` Ihor Radchenko
2022-07-04 12:27 ` Tim Cross [this message]
2022-07-04 12:58 ` Ihor Radchenko
2022-07-04 17:24 ` Max Nikulin
2022-07-04 22:37 ` Tim Cross
2022-07-05 2:39 ` Max Nikulin
2022-07-05 2:54 ` Tim Cross
2022-07-05 4:22 ` Max Nikulin
2022-07-05 4:36 ` Tim Cross
2022-07-05 5:11 ` Ihor Radchenko
2022-09-18 9:06 ` Bastien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bku59hpp.fsf@gmail.com \
--to=theophilusx@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.com \
--cc=yantar92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).