Migrating IPS site to new domain: Font Awesome issues

[Brainy S.]

What is the best way to set up a new install of IPS for an existing (live) community site (based on another CMS) that I want to have minimal change-over and downtime when I finally redirect the old domain name to the new hosting and the new ready-to-go-fully-configured IPS system?

I thought just having no domain on the new site, then once the domain is transferred that IPS would be "ok" with being on a domain name where previously it was on an IP-address only.

I wanted to test this out. So using a newly registered throwaway domain, I tried this fake "switchover" dress rehearsal.

For the 99% of it, IPS was fine! But the Font Awesome icons...of all things, is literally the only thing that broke. Specifically, AdminCP lost all its font awesome icon ability. The browser console shows the error of the webpage trying to load the font awesome icon from the previous IP-based URL which it shouldn't even know about. I can't see any place IPS  stores the whole Font Awesome resource links, I only see the one LOCAL reference in fonts.css, not the full hard-coded URL of the previous IP-based address I'm actually getting.

So obviously that didn't work. Is there any way to fix that? (anyone know where the full reference lives?)

If not, I can start from scratch. In that case what IS the proper way to achieve what I'm trying to do? (i.e. setting up an IPS install in advance before the domain name is configured) 

Would installing IPS fresh on the throwaway domain name this next time provide any better switching survivability (versus switching from an IP address only)?

I have a half-dozen people helping this pre-launch process. If it was just me, I'd be fine doing a local HOSTS file and have the server lie to itself that it is serving up the live domain, but most of these people are using their school library computers where they don't have access to HOSTS, or using iOS devices.

P.S. Here is what I get in the console:

Failed to load resource: The certificate for this server is invalid. You might be connecting to a server that is pretending to be “<IP ADDRESS>” which could put your confidential information at risk.
  
https://<IP ADDRESS>/public_html/applications/core/interface/font/fontawesome-webfont.woff2?v=4.7.0

Obviously an IP address can't have HTTPS, which makes me hopeful that maybe this would work with the pre-install based on the throwaway domain???

[Nathan Explosion]

Assuming the site URL has been changed in the config file, go to the support tool in the ACP to clear the site cached files.

[opentype]

Quote

https://<IP ADDRESS>/public_html/applications/core/interface/font/fontawesome-webfont.woff2?v=4.7.0

That looks wrong. The “public_html” is usually a part of a server path, not a public URL. 

By the way: you are allowed one development URL. You could use that to prepare the move. 

[Brainy S.]

32 minutes ago, Nathan Explosion said:

Assuming the site URL has been changed in the config file, go to the support tool in the ACP to clear the site cached files.

 

31 minutes ago, opentype said:

That looks wrong. The “public_html” is usually a part of a server path, not a public URL. 

By the way: you are allowed one development URL. You could use that to prepare the move. 

Thanks, both these were helpful for the problem now (cleared cache) and for juggling things for the move to come.

[Marc]

If you are physically moving the tested site to another server, then take a look at the guidelines here. You can however selectively use the information you need from this to switch from dev to live

The main things to remember when doing this are the following

• If you are converting the other system, do a test first. This will save you having issues on the day you do it for real, and you will know what to expect
• Use -TESTINSTALL at the end of your license key, to use your test key instance. That way you dont have any issues with switching to your live domain. You just move it and set your live license key
• Any issues at all, go to ACP->Support (top right) and see that page to see if there is anything showing up, and (as already mentioned) use clear cache
• Make sure if you are moving from a subfolder, you change any .htaccess files (and indeed ensure you move that, as I have seen people miss that where its hidden)
• When changing your conf_global.php file, back it up, then change it. That way if you make a mistake, you can repeat that process. I have seen many times someone accidentally delete or add something that breaks the site on moving items

One thing you can do to speed up the process, is if you are moving from one location to another with the physical files, make a copy of all the files in advance. Then you can just replace those which have been added or changed.