Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

x/website: offline tour broken links #59914

Open
crisman opened this issue May 1, 2023 · 3 comments
Open

x/website: offline tour broken links #59914

crisman opened this issue May 1, 2023 · 3 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. website
Milestone
website/backlog

Comments

@crisman
Copy link
Contributor

crisman commented May 1, 2023

While trying to fix offline tour links other go.dev resources (golang/tour#1463 & golang/tour#1473) I put in golang/website#213 which updated URLs to work offline by adding https://go.dev/ prefixes.

I later noticed this commit:

commit f81f4f7f21d45f2e62f8dbcf84e0fd5d7b2785a3
Author: Russ Cox rsc@golang.org
Date: Fri Jan 14 12:53:28 2022 -0500

_content: remove some https://go.dev/ prefixes in links

The site is served at both go.dev and golang.google.cn.
In China, only golang.google.cn can serve, so we try to use
relative links to avoid pointing users to the copy they can't access.

Periodically we have to remove prefixes that have crept in.
This commit applies today's round of that.

Which points out a third place these URLs need to work and a reason and policy to use relative URLs.

I think we need the local tour binary to get a handler update to allow for redirect of /pkg/, /blog/, /doc/, /talks/, /cmd/, & /.

There is already a handler for / which redirects to the tour start point which might should stay that way.

Does anyone see an issue with adding redirect handlers to the offline tour?

Does anyone have a input on changing or not of the / handler?
@gopherbot gopherbot added this to the Unreleased milestone May 1, 2023
@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 3, 2023
@cagedmantis
Copy link
Contributor

cc @golang/tools-team

@findleyr findleyr modified the milestones: Unreleased, website/later May 10, 2023
@jamalc
Copy link

jamalc commented Jun 5, 2023 •
edited

@crisman, I'd like to get a clearer picture of what this update involves. My understanding is that the tour is served by cmd/golangorg in the x/website module. Can you point me to the local tour binary?

🤦 I see it now. We should include those handlers in the tour binary but keep the / handler in place.

@crisman
Copy link
Contributor Author

crisman commented Jun 5, 2023

Rereading my original post, perhaps a bit more detail on my last question:

Does anyone have a input on changing or not of the / handler?

The current internal/tour/local.go starts a local http server and then a browser sent to (by default) http://127.0.0.1:3999 which then (in the / handler) is redirected to http://127.0.0.1:3999/tour/.

An option would be to change the url to add a suffix if "/tour/" and then the default action for the / handler could be to redirect to https://go.dev/ which would allow the top left GO link on every tour page to work.

The down side is that if we make that change then a user manually visiting http://127.0.0.1:3999 (which they may have in memory or a bookmark) would not get the local tour, but the main go site.

I like the idea of changing the url & the / hander. Does anyone have any reasons to add to the for or against lists for changing the / handler?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. website
Projects
None yet
Milestone
website/backlog
Development

No branches or pull requests
6 participants
@cagedmantis @crisman @adonovan @gopherbot @jamalc @findleyr