Have you ever had one of those days where it seems like everything should work, but you just can’t get anything to happen? That was me today. In order to move my hosting to another one of my domains, I had to remove the websites attached to the target domain, make the switch, then re-upload the websites. Easy enough… or so I thought.
After restoring the sites from the backups, they didn’t work. Nothing changed except the primary domain on the hosting. There were four sites hosted on the account, but I’m only going to talk about three of them. The fourth one was a test space for a site that I no longer work on. First, I’d like to mention that I use GoDaddy for a host. I know, it’s my fault for going with what’s widely considered among the tech community as a difficult hosting company, but it’s what I’ve been using forever and what I’m familiar with.
The Game Site
I wanted to fix my gaming site first. It should have been the easiest. I got an error, and it was descriptive. It couldn’t connect to the database. So I go through the motions, check the connection info, purposely make it wrong to see if a different error comes up, and make sure it’s not an error in the syntax. After testing the connection over and over, I realized that it was as simple as removing the port designation from the database location. I just took backups of the site, so it must have been working before, but now it decided that it was wrong to be there. But that’s fixed, so on to the next site.
The Business Site
Next up was the business site. This is one of two WordPress sites in the account. This one was imported to the host, whereas the other was created on the hosting account. Again, just took a backup before the changeover, and after restoring it, it’s not working. The error I got, I’ve had before, and couldn’t remember how to fix it. Basically, the error says that the connection to the site was refused. If you look at the server logs, you can see that there is an error trying to serve the page, usually caused by a bad configuration. This one was saying that the fastcgi was not able to be loaded. So after changing my ini file and trying to update the php version on the server, I was getting nowhere. I could server non-php files, so I knew it had to be something with the configuration and then I remembered. The web config didn’t have the correct rewrite rules. After adding the rewrite rules, the site worked just fine. So now to the last site.
The Personal Site
This was the one that really through me for a loop. The site was working even after the changeover because it was on a different domain and didn’t need to be removed. So after I fixed the business site and it stopped working, I was totally confused. I was getting the same error that the business site was getting. The weird thing was if I chose a specific file, like index.php, it would work fine. So I went through the same steps I took with the business site and when I got to the web config fix, it started working! Yay, all the sites working again! Except they weren’t. Going back to the business site, it had stopped working. That’s when I realized that the host was trying to serve both of the WordPress sites using the same web config. I knew you had to use a special web config to host multiple WordPress sites on the same server, because the rewrite rules send default requests to whatever the default website is. I didn’t know how to create the rewrite rules that keep everything on it’s own domain, so I found one online. It mostly worked, but I found a better solution.
Application Pools
When you install WordPress on an IIS host, it creates a new application pool. This means that it only pays attention to the configuration in the files of that site and ignores any other directories. What was happening with the WordPress sites was that it was using the main domain’s web config to handle wildcard requests. Moving the personal site to it’s own application pool allowed it stay within the same domain even though the request didn’t have a specific file to load.
I ended up moving the gaming site to it’s own application pool as well, just to make sure. Perhaps this will help someone, or maybe it will help me when I migrate the sites and have to do this all again.