.Recently I had to move a recruitment site I was working on from staging to live.
There will always be some minor issues when moving a site from staging to live, so be prepared to fix many things. Click To TweetI didn’t expect as many as there were. I made some mistakes and screwed some things up, and I wanted to discuss it. Namely, which mistakes I made and how I fixed them. Perhaps that could help you when moving your site over.
From My Server to Staging to Live
The project began with me building this site on my server on the subdomain staging1-clientname.headstudios.com.au. I then moved it to staging2-clientname.headstudios.com.au, when I was granted access to the client’s server. I moved it to staging1.myclient.com.au and finally, I moved the site live to myclient.com.au.
Whenever I would move the site, I would copy the files over and change the database ‘options’ table to have the new site. Here’s where it all went wrong:
Mistake #1: Know the Location of the Live Site
When I first got access to the client’s server, I opened it to find out the website I was working on was already in WordPress, apparently, due to the file structure of the public_html folder. So here I was thinking, “Well, that’s strange. They’ve asked me to convert this site to WordPress, but it’s already in WordPress.”
I was a bit confused. It didn’t matter, though. My job was to finalize some changes to my site and then push it live. In fact, I didn’t even bring it up with the client.
When it was time to push my site live, I took all the WordPress files in the public_html folder and put them into ‘live-backup.myclientname.com.au’ or something similar – found the database it refers to and I changed the URL there. I then moved my site live, changed the URL in the options table for my website and, the old site was still there.
Don’t make assumptions
So I find out that the name servers were pointing to Amazon’s cloud, or somewhere else, and that the site that was already there was an older version of the client’s site. So I switch the name servers over to point to my client’s hosting and took note of the nameservers prior. Voila, my site appeared.
But now, there was a problem.
I didn’t know where to see the old site to refer to it.
There is a tick I tried of changing my computer’s hosts file for that particular domain and changing the IP there, but nothing happened.
I had lost the client’s site!
Thankfully later, I was able to get a direct URL link there. What I have learned is that in the future, I should know where it’s hosted and not assume it’s on the client’s server. A plugin I recommend is ‘WhatRuns’ from Chrome. It will tell you what CDN or other technologies are being run on the site and can sometimes tell you if the site is hosted elsewhere.
But the best thing to do is simply to ask.
Mistake #2: Not Changing Internal Links
While the top and bottom links, and any links that are hardcoded into the theme can be easily set up to be based on the domain the theme is currently running on, I have not found a way to change the URL of the internal pages to be set dynamically.
In other words, if I create a WordPress Page for my site which is on staging1.clientname.com.au, let’s say which points to ‘staging1.clientname.com.au/about/our-vision’, when I move the site to a new server that domain wouldn’t change.
It was embarrassing when the client told me that all the internal links were pointing to the staging site! On the live site!
I fixed this easily with the following code:
UPDATE `wpgw_posts` SET post_content = REPLACE(post_content, ‘https://staging1-clientname.headstudios.com.au/’, ‘https://www.clientname.com.au/’) WHERE `post_content` LIKE ‘%https://staging1-clientname.headstudios.com.au/%’;
When using the code above, make sure to change ‘wpgw_posts’ with the correct posts table with your designated WordPress prefix. Also, change ‘clientname’ to your client’s updated URL and the old staging URL’s.
Mistake #3: Not Removing Dummy Data
Whenever you’re working on a site, you might test a feature by adding some dummy data. However, it is easy to forget about this extra data and launch the live version with the said dummy data. This happened with the recruitment company and some of the Jobs in the Jobs Board, which were not real at all. And here it becomes important to use a good recruitment applicant tracking system.
Keeping dummy data is probably a common mistake. In the future, though, I will mark all my dummy data with the word ‘dummy123’. That way, I can easily find all posts that have that word and remove them before launching by searching. I would also have a note on the client’s file of where to search for dummy data before pushing live (custom post types, etc.).
Mistake #4: Missing Feed Data
When you build your site, you will rely on data that is pushed to its feed from outside sources. When moving the site from one staging environment to the next, in the time that you tell those sources to update their data, new data could have been pushed to an older version of the site.
Because this was a recruitment website, there was a Job Board that had data pushed from a recruitment portal. Every time I needed to change the URL, I had to inform the portal company. And when the site finally went live, there were not enough jobs.
In the future, I will ensure I have a note of all data feeds running to the site, and I will call them to confirm that the amount of data currently on the website matches what they have. A better way would be to ask any feed coming to your site to push ALL their data live before taking the website live. You can then delete the old data if this is an option and will ensure no information is missing.
Mistake #5: Check the Site on Mobile Even if the Site Is Responsive
When I checked the site on my desktop computer, I resized the browser and saw that it was responsive. It lead me to assume it would be responsive on mobile, too. However, after it went live, I checked on mobile and saw that there was microscopic text and it was rendering the desktop site instead of the responsive website.
This was fixed by adding the following code to the header:
<meta name=”viewport” content=”width=device-width, initial-scale=1.0, user-scalable=yes”>
Right underneath the title.
Summary
So, those are the five significant mistakes I made together with how I plan to correct them in the future. I hope you have learned something from my mistakes. Good luck!
If you have any questions about this post or any other WordPress topic simply head over to my website for – www.headstudios.com.au – and fill out the contact form and I can get back to you. Thanks for reading! I work in all industries from compensation lawyer sydney to the medical field.