How do I stop my Github webpage from redirecting to an expired CNAME URL? I know it takes time, but my Github page has not stopped redirecting even after 1.5 days! I am asking to find out if there's any step I missed (all I did was delete the CNAME file). If there's no step I'm missing, how long does it usually take to stop redirecting? I really need my page to be available soon since it is recruiting season. Please help!
You can clear the custom domain field. Let it remain empty. Then click the save button. Then clear cache of your browser or open in another browser / incognito mode. You will see the difference.
You could achieve this by following 2 steps,
Delete the CNAME file from git folder (git rm CNAME), and have your git updated.
From your domain provider, remove any DNS settings (Custom CNAME) that you have for the specified domain.
These are the steps, I followed to get it working correctly.
You should clear your browser cache. Because your browser has saved memory to redirect to the cname site every time you open the github page link.
Another solution is that you can open the github page link with another browser.
Related
I searched for this one, but found nothing ...
My old site is: cs.abc.edu/~cs4096
My files were at: cs4096#cs.abc.edu/public_html
My personal site: myname.com
My Github Pages site: myname.github.io
When a user requests cs.abc.edu/~cs4096 they are served cs.abc.edu/~cs4096/index.html and so on.
Via the ISP hosting myname.com, I setup a CNAME pointing teaching.myname.com to myname.github.io .
I want references to the old site, including pages below the top index.html, to be sent to teaching.myname.com where through the magic of DNS CNAME the URL goes to the myname.github.io site. In other words, users still go to the cs.abc.edu/~cs4096 but they are served from github.io.
The teaching.myname.com -> myname.github.io bit is working fine. It’s the initial redirect/rewrite that is failing. The problem is that the ~cs4096 is included in the URL when it is passed to myname.com .
That is, this
http://cs.abc.edu/~cs4096
ends up as
http://teaching.myname.com/index.html~cs4096
instead of
http://teaching.myname.com/index.html
and this
http://cs.abc.edu/~cs4096/Schedule
ends up as
http://teaching.myname.com/index.html~cs4096/Schedule
instead of
http://teaching.myname.com/Schedule
And, if you wonder WHY I’m doing two “redirects” here, it is because want the automatic rebuild of github pages that I can’t get at abc.edu or myname.com .
Thank you all
Never mind ... I abandoned this idea and used an HTML Redirect. It will mess up “Back” in the Browser, but it works.
I have retriggered a failed Travis-CI build for a public open source project yesterday. The build succeeded, however, the badge still shows "build failing", both on GitHub and on Travis-CI.
Is there anything I can do to refresh it?
The previous answer is so close! Github wouldn't be involved at all, all they do is link to the image with html. And I know from experience that Travis updates it basically immediately. It's actually browser side caching!
Your browser doesn't request the new image because it already has it. This is actually how all images work on the web. You can rest assured the correct build status is showing for new visitors to your repo.
If you need that green badge to show up for your own peace of mind, just hit Ctrl+F5 to purge the cache.
Not sure about Travis-CI, but I know GitHub aggresively caches images. Once the cache goes stale you'll see the correct badge. Other than waiting there's not much you can do.
Command+Shift+R in Chrome on Mac solved this issue for me
As #icodesometime answered, it's more to the client's browser caching problem, dealing with the CDN's cookie.
If you get even passing the TravisCI and reloading doesn't take effect, such as hitting F5 or Shift + reload or Control + F5 etc. in Chrome, then try:
Open Developer tools
Right-click on the reload/refresh button and select "Empty Cache and Hard Reload"
I just discovered that you can "bust" the GitHub cache by just adding insignificant content to the URL query string. So while "https://img.shields.io/travis/numpy/numpy/master.svg" might be cached, "https://img.shields.io/travis/numpy/numpy/master.svg?x=1" probably isn't. Or add "&x=1" at the end if there is already query string content. Works for me for every badge type. Note that you will want to change the value in that query string every time you need to bust the cache.
I am eager to know why localhost.com (without www) redirects to google.com. I also noticed that www.localhost.com gives a 404 page not found. I checked this in Firefox, Chrome and Internet Explorer all does the same. I checked the domain name records and it shows it belongs to Tucows and I am pretty sure Google doesn't own it and I know we can use http redirect to change it to a www or non-www version as the site owner wishes.
Interesting answer posted by Ken Watford, Google employee: http://www.quora.com/Why-does-http-localhost-com-redirect-to-Google
He claims someone bought the domain when the web was still young and kept it ever since, but he does not say who.
It looks like others have had the results as you, check out the links below.
Try here:
http://answers.yahoo.com/question/index?qid=20111105050333AATP1r5
or here:
http://forums.phpfreaks.com/topic/146474-localhost-redirects-to-googlecom/
I think localhost.com should be owned by google as I tried pinging it and it showed the ip of google.com.I still don't know why the DNS records shows tucows as the owner.
I have been searching this from long and finally i found complete solution after going through different answers.
As far as #pradeep's answer is concern, he is right that localhost.com is purchased and points to particular IP so it is redirecting.
But we can override domain names in Windows platform for our local development PC via hosts file residing in C:\Windows\System32\drivers\etc as per #Faysal's answer.
Open hosts file as administrator and enter following line
127.0.0.1 localhost.com
But doing such also did not solve my problem. So i found final solution which will work in chrome browser.
In chrome you have to clear all dns cache via opening following url
chrome://net-internals/#dns
And here clear all cache and finally you will be redirect localhost.com to your local server's home page.
If you are using the Windows platform, then go to your %windir%\System32\drivers\etc and copy the host file to %userprofile%\Desktop. Open it with any text editor and remove the # sign from the front of 127.0.0.1 localhost. Save it and paste it back. Check if the problem is solved.
localhost.com is a website. It does not point to your local IP, instead it most likely has an A record pointing to Google's IP. It practically is Google, and I can prove it.
When the site worked if you connected using HTTPS then it would give a certificate error, the reason being that the certificate is signed to google.com but localhost.com is connecting.
I think the site has now been removed though.... I hope that solves it. It can cause some confusion since localhost points to 127.0.0.1.
(To make this simpler - I've re-posted the first part of this question as a separate question, which has now been answered:)
Umbraco - Incorrect alternative link to document
Here's the full, original question:
On our website, we have the following structure:
sitename
-Global
-English
-UK
-English
for the Global > English page, the links to the page are showing as:
Link to document
/global/en/
Alternative Links
http://english
so the 'Link to document' is correct, but the alternative link isn't. On the UK > English page, I just get the correct 'Link to document'
On our development version, I've just turned on the useDomainPrefixes = true option in the umbracoSettings.config of of the site, and I've added a hostname for the top level 'sitename' node. Now I get the following as page links for the Global > English page:
Link to document
http://english/
Alternative Links
http://hostname/http://english/
http://english
I get the correct links for the UK > English page, showing the correct hostname in the URL like this:
Link to document
http://hostname/global/en/
I've tried re-publishing the entire root node (sitename), however I get an unusual timeout error. I've increased the timeout for the app pool, and for the session and the umbraco timeout in the web.config, however this is a different error probably related to the proxy server contacting the web server.
Is republishing the entire site the only fix? I've tried only publishing the sitename > Global node, which completes successfully, but doesn't fix the issue.
This is sometimes caused by setting the domains for the content nodes incorrectly. If you've right clicked and selected "Manage Hostnames" then you can get issues like this.
Remove all hostnames and see if everything works with UseDomainPrefixes=true.
I would reinstall from scratch and rebuild the site if the worst happens and you really cannot fix.
I developed a site for a client before a domain name was chosen. As a result, the URLs for the site pages look like:
http://host.mynost.net/~tempname/index.php?id=8
A domain name has now been purchased but if I click on any Wayfinder links it still uses the old path as above instead of, say:
http://domainname.com/index.php?id=8
I assume this is configured in the config.inc.php file, but I am unsure of what to change.
Can anyone point me in the right direction? Thanks!
You need to change $modx_base_url= '/' in /core/config/config.inc.php and if that is not enough - manually clean /core/cache/ folder.
Four years later, I've dealt with the same thing for a few months, and was incredibly frustrated.
An updated answer to this issue would be navigating to Settings (icon) > Context, then choosing Key > web (right click) > Update Context > Context Settings.
Change http_host (ex. localhost) and site_url (ex. http://localhost/).
Now, from the top menu Manage > Clear Cache as well as Manage > Clear Cache > Refresh URIs.
It was like finding a pot of gold.
I have a web on some super-old Modx version which I needed to temporarily set up for viewing, and I ran into this issue.
The way I changed the base URL is in the database:
table: modx_context_setting
key: site_url
This outlines how to move modx to a new location ~ which is essentially what you have done.
http://rtfm.modx.com/display/revolution20/Moving+Your+Site+to+a+New+Server
genereally you can get away with updating the config.inc.php & clearing the cache, but it's a good idea to go through the system setting table in the db looking for old paths, some packages do store path info in there.