I've been using Cloudflare for years for my handcoded site. Whenever I update, I FTP a new index.html file and I go to Cloudflare's custom purge, where I purge:
https://example.com/
https://example.com/index.html
This week is the first time it hasn't worked, and Cloudflare support is giving me nothing. What happens is, if I go to https://example.com - I get served an old version of the homepage.
When I go to https://example.com/index.html - I get the new version.
I've purged multiple times, used different browsers, used my phone on a different network etc. but I cannot get the plain .com address to show the updated index.html
It turns out it was a bug on Cloudflare's purge single-file from their site UI. They asked for some diagnostic info from https://yourdomain.com/cdn-cgi/trace which helped them fix it.
Related
I am hoping somebody can help me because I am on the verge of frustration tears.
The company I work for has a site hosted on godaddy and has to remain up until I complete the rebuild on hostgator, using the Wordpress theme, Grand Restaurant http://themes.themegoods2.com/?theme=GrandRestaurant
To get around the domain name issue since I cannot change nameservers yet, I had to use the Google Chrome plugin, Virtual Hosts, which has me input the IP and domain, to force access to the site.
Everything was working fine until I needed to use the "content builder." If you look at the Grand Restaurant theme, you can click on Menu. I need to use the "Menu Grid" option in the content builder but it does not work. Whenever I try to add the menu grid, it appears that it is trying to load (showing the gif loading image) yet in never actually loads. I have spent several days and hours going back and forth with host gator and the theme developer.
The theme developer says that the content builder does not work because:
"The WordPress URL and Site URL are set to the domain name. When you are logged in, you are being redirected to the IP, so the browser sees 2 different sites and some functionality ex. AJAX call doesn't allow you to get data from different URLs.
Your WordPress URL and Site URL settings are different from your actual site. You have to change your Domain Name URL and Site URL settings to the IP number."
I did what he said earlier today and it completely broke the site. Spent nearly 2 hours with host gator's tech support to get it back up. All tech support will tell me in regards to the content builder not working is that I need to change the AJAX file to allow the site URL and wordpress URL to be different. I have no idea how to do that!
Any wisdom you all could provide would be greatly appreciated. I have 1700 bakery items that I need upload by the end of July and I do not know what I am going to do if I cannot get the content builder working.
In order for this to work properly you should be using a method of back up and restore. By migrating from one hosting provider to another you could simply deploy the new Wordpress on host gator as a new site and import the Wordpress backup to the host gator with the many different plugins available through Wordpress. The way your trying to complete this is impossible and usually will only work with images and back ups being managed on virtual machines, and VPS. It won't hurt anything on the original up and running site. You mentioned that host gator was able to get the site back up? You shouldn't have to rebuild this if you use a back up and restore method. Everything should fall right into place, you can also test these methods through virtual box, and VMware virtualization products which offer trial versions. Try using a migration method and see if the conflicts still persist with the content builder.
Heres is what I would do if you cannot change the domain over but still use the domain for the dev environment.
Modify your hosts file and use hostgators IP and the company domain as the entry.
Install wordpress to the current company domain by simply entering the domain (Should go to hostgators server since you've added that entry in your hosts file)
With the hosts file modification, you should be able to view the wordpress site thats hosted with hostgator using the live domain name.
This way, when you're launching, theres no need to do any modification on wordpress. Simply change the DNS over, revert your hosts file and the site will swap over seamlessly.
This is for a client so I won't share exact domains but the problem is as follows..
I took over development of a website from a prior developer.
The hosting is Hostgator Business.
The primary domain is primary.com.
There is an addon domain addon.com.
The primary domain document root is /home1/username/public_html.
The addon's document root is /home1/username/addon.com.
www.addon.com had a WordPress installation which the developer had edited instead of using plugins to achieve his goals. The site also needed a complete redesign so I felt it logical to simply wipe the installation and replace it.
So, I deleted all of the WordPress files and uploaded a new copy of WordPress from wordpress.org/latest.tar.gz
Prior to deleting the old installation, the domain loaded files from it's document root perfectly.
After uploading the new installation instead of resolving to addon.com it is instead resolving to primary.com/addon.com
I've never seen this happen before so I'm lost.
There's no errors in any available logs.
All file permissions are correct.. I've triple-checked.
I've tried deleting all files and creating simple index.php and index.html files to see if it would access them ... it doesn't.
This happens in each browser I use on Windows and Linux.
I don't understand it because all I did was swap out the old WP install for a new one.
I went and re-uploaded the old WordPress installation so everything is 100% how it was but it is still going to primary.com/addon.com instead of addon.com.
Has anyone faced this issue before? I usually use Bluehost but even when I've used Hostgator in the past I've never seen this happen.
I double-checked the addon domain settings as well as anything else I could think of and everything appears normal.
I even deleted the addon domain and re-added it with the document root of /home1/username/addon.com and it still goes to primary.com/addon.com in the browser.
I submitted a ticket with Hostgator but they have not replied yet.
I'm sorry if this is long. This is my first time asking for help on here and I wanted to be sure I included everything I could.
Hostgator finally got back to me.
The previous developer had used the one-click WordPress install.
Apparently once someone uses a one-click install the only way it works is if you keep using the one-click install/you cannot do it manually any more.
From all the servers and sites I've setup this makes no sense and is a problem with Hostgator. Support did not really tell me anything other than "you have to use the one click install since the prior developer did". Great service.
Hope this saves someone some hassle.
From this it sounds like you were moving a WordPress site from the primary domain to an add on domain.
Simply moving the files from the primary to the add on domain will not make it work on the add on domain because in the database and throughout the coding of the WordPress site it would all be configured and coded for the primary domain.
It sounds like you would need to update the site home and site url from the primary to the add on domain url.
http://support.hostgator.com/articles/specialized-help/technical/wordpress/wordpress-home-fix
Also I would be suggest using a search and replace type plugin to go through all the internal coding to update the urls and links to the add on domain.
There is more information here as well http://codex.wordpress.org/Moving_WordPress
I'm having a strange problem with a server move. We've recently moved from a development server to the live sever with a website. However upon moving to our new server domain.com, we've developed an issue.
Basically the CSS and the JS aren't loading. Looking at the source code, the issue is clear - no trailing slash at the end of domains, so for example, the favicon URL is this:-
http://domain.commedia/favicon/default/favicon.gif
A google search threw this issue up - Magento Admin CSS and JS paths incorrect after moving server and product pages empty? - and, whilst I've followed these steps, there is still the issue.
Any suggestions will be greatfully appreciated.
Are you 100% sure that your web/unsecure/base_url and web/secure/base_url configurations are correct? Make sure your new site (on the new host) is connecting to the correct database (look in app/etc/local.xml), and verify these values directly in the core_config table. Your urls should have a trailing forward slash /, like http://domain.com/
If you can access the Magento admin, disable all caching under System > Cache Management
Are you using memcached on the new server? Try restarting the memcached service using shell: service memcached restart as it can cache Magento configurations.
Make sure you delete everything under var/cache, and double check that it was deleted.
Disable all 3rd party extensions. They could be affecting the path of your CSS files. you can disable them by removing the XML files under app/etc/modules
I have a domain (www.wozzoncornwall.co.uk) set up and followed Heroku's recommendation not to use a naked domain. I've noticed the site seems to be taking an unusually long time to be indexed by google.....i'm not talking keywords, just searching the site name or domain. I previously had a holding page up for 3-4 months and this was indexed, however, I noticed that when I moved the app to Heroku this was clicking through to the URL without the www, so returning site not found. This isn't even in the index any more, google clearly dropped it due to 'site not found' but i'm concerned this is having an effect on the proper site being indexed. Any thoughts or suggestions?
I would suggest that you use rack-rewrite (assuming Ruby app) to redirect your naked domain to the www (with a true 301 redirect) - but publish/advertise the www entry. You would need to add the naked domain to your application domains and the IP addresses - this is acceptable for simply redirection.
This should transfer the link juice from the none www to the www. If you use Google webmaster tools you can go into the settings and update them of the address change.
I've just moved a Joomla 1.7 site to a new server.
Administration back-end works fine. Configuration.php seems fine. Get "The requested document was not found on this server." for every page other than Home.
Must be talking to the database OK or I'd get an error. Could this be a problem with the PHP?
Thanks,
Andy
Did you clear joomla cache ?
Disable page and/or module caching.
Disable any plugin that optimizes "loading speed".
Try removing SEF URLs (Joomla! and any 3rd party extension).
If you are using a custom .htacess, then use an unmodified joomla one.
Disable some system plugins.
Disable modules in the homepage.
Have you tried using another template (site) ?
You have Seach Engine Friendly URLs enabled in /administrator/ area's global configuration settings. You have probably enabled the option to use the mod_rewrite function which removes the /index.php/ portion of the urls.
It is a requirement of this mode that you have the .htaccess file in place in the root of your site. You probably had this correctly configured on your development server but perhaps forgot to move the file across when you went live. Some FTP programs hide dot files (files starting with a leading dot in the filename) so depending upon how you transferred the files (I'm guessing manually with FTP rather than Akeeba backup or similar) the file may have been missed. Look through your FTP client's options/preferences for an option to show/hide hidden files.
Failing this - the file could be correctly in place - but if you were developing in a sub-folder on your development server you would have set the RewriteBase line to your /sub-folder/
RewriteBase /sub-folder/
Now you've moved to the live server this line could be incorrect. If this is the case, edit the file to Read
RewriteBase /
Chances are it is one or other of these issues - missing .htaccess file or incorrect RewriteBase. A third and nowadays somewhat more unlikely option is that your server doesn't have mod_rewrite enabled - but I think that would result in server 500 errors.
Check whether you are using any modules that is calling database and you have not changed DB details in that module after migration. If admin panel is working fine then I think problem with some modules that are used in front-end. You can do debugging by disabling few suspected modules and check whether your site works fine or not. Else provide some more information about your site so that I can check further.