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.

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

Redirect GitHub Pages site when transferring repository ownership #492

Open
ldionne opened this Issue Oct 15, 2015 · 6 comments

Comments

Projects
None yet
6 participants
@ldionne

ldionne commented Oct 15, 2015

Right now, GitHub Pages won't be redirected when transferring the ownership of a repository. Hence, all links to <original owner>.github.io/<project> will break instead of pointing to <new owner>.github.io/<project>.

I contacted GitHub's support and here's the reply:

Redirecting pages sites when a repository is transferred is not possible currently, but we might add it in the future. Thanks for the suggestion, I'll add it to the Feature Request List so the team can see it.

In the meantime, you could create a new repository in place of the transferred one that links to the repository's new home. This would eliminate the redirect that we do have on the repository page, but its up to you and your collaborators to decide if removing the automatic redirect on GitHub.com is worth placing manual redirects on GitHub Pages and GitHub.com

Hope this eventually gets resolved.

@kanaka

This comment has been minimized.

Show comment
Hide comment
@kanaka

kanaka May 4, 2017

We have run into a very similar issue and there is no good resolution. We transferred kanaka/noVNC to noVNC/noVNC, but now the site http://kanaka.github.io/noVNC/ has stale data from the original account. Recreating kanaka/noVNC will break all the current redirecting which would be an even worse situation. Can you please put a redirect from http://kanaka.github.io/noVNC/ to http://noVNC.github.io/noVNC or at least make http://kanaka.github.io/noVNC/ return a 404? That would be better than stale date with no good way to fix it (although of course a redirect would be best).

kanaka commented May 4, 2017

We have run into a very similar issue and there is no good resolution. We transferred kanaka/noVNC to noVNC/noVNC, but now the site http://kanaka.github.io/noVNC/ has stale data from the original account. Recreating kanaka/noVNC will break all the current redirecting which would be an even worse situation. Can you please put a redirect from http://kanaka.github.io/noVNC/ to http://noVNC.github.io/noVNC or at least make http://kanaka.github.io/noVNC/ return a 404? That would be better than stale date with no good way to fix it (although of course a redirect would be best).

@samhed

This comment has been minimized.

Show comment
Hide comment
@samhed

samhed May 5, 2017

Searches for "noVNC" gives the old webpage as first hit in all major search engines, which is kind of unfortunate. So yes, at least if you could remove it?

samhed commented May 5, 2017

Searches for "noVNC" gives the old webpage as first hit in all major search engines, which is kind of unfortunate. So yes, at least if you could remove it?

@melvincarvalho

This comment has been minimized.

Show comment
Hide comment
@melvincarvalho

melvincarvalho Mar 14, 2018

Also facing this challenge. Would be interested if anyone has found a work around.

Also facing this challenge. Would be interested if anyone has found a work around.

@samhed

This comment has been minimized.

Show comment
Hide comment
@samhed

samhed Mar 15, 2018

A year later and the stale old website is still up.

samhed commented Mar 15, 2018

A year later and the stale old website is still up.

@kanaka

This comment has been minimized.

Show comment
Hide comment
@kanaka

kanaka Mar 15, 2018

@isaacs since this feature is a long time coming, can we at least have one-off fixes for sites that specifically request this in the meantime?

kanaka commented Mar 15, 2018

@isaacs since this feature is a long time coming, can we at least have one-off fixes for sites that specifically request this in the meantime?

@xolotl

This comment has been minimized.

Show comment
Hide comment
@xolotl

xolotl Apr 30, 2018

FWIW, this just worked for me to move a GitHub pages site from one repository to a different repository under a different organization while using a custom apex domain.

Note that my goal was to move a project pages site to an organization pages site (see documentation), but these steps may work in other cases.

  1. Create a new repository under the target organization (in my case: https://github.com/OpenScienceRoadmap/OpenScienceRoadmap.github.io)
  2. Follow the steps in this guide to move what was a project pages site in a subfolder in the old, source organization/repository to the root of the new, target organization/repository.
  3. Delete the existing CNAME files in both the old, source repository (so it doesn't conflict) and in the new, target repository (presumably because generating a new CNAME there refreshes whatever redirection GitHub has going on behind the scenes).
  4. Visit settings in the new, target repository and add the custom apex domain (in my case: jrost.org) to the field under Options to generate a new CNAME file.
  5. Visit the custom domain and see it working!

Note that this process required no DNS changes because the custom apex domain records were already pointing at GitHub as per this guide.

xolotl commented Apr 30, 2018

FWIW, this just worked for me to move a GitHub pages site from one repository to a different repository under a different organization while using a custom apex domain.

Note that my goal was to move a project pages site to an organization pages site (see documentation), but these steps may work in other cases.

  1. Create a new repository under the target organization (in my case: https://github.com/OpenScienceRoadmap/OpenScienceRoadmap.github.io)
  2. Follow the steps in this guide to move what was a project pages site in a subfolder in the old, source organization/repository to the root of the new, target organization/repository.
  3. Delete the existing CNAME files in both the old, source repository (so it doesn't conflict) and in the new, target repository (presumably because generating a new CNAME there refreshes whatever redirection GitHub has going on behind the scenes).
  4. Visit settings in the new, target repository and add the custom apex domain (in my case: jrost.org) to the field under Options to generate a new CNAME file.
  5. Visit the custom domain and see it working!

Note that this process required no DNS changes because the custom apex domain records were already pointing at GitHub as per this guide.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment