I recently moved some WordPress sites and came across a WordPress permalinks problem that befuddled me for quite a while. As traffic has increased on the GetCertifiedGetAhead and Blogs.GetCertifiedGetAhead sites, I’ve noticed that pages were sometimes slow in loading. I finally decided to upgrade the account and move to a new server to increase the performance.
In a perfect world, this would be a rather simple process but in reality, it was quite challenging and consumed much of my time this past week. Thankfully, I made it through the hurdles and testing shows that this new site is much quicker. I hope you find it useful.
WordPress Permalinks Problem
If you run a WordPress site and are migrating to a different server, you might find this useful. I’m running my site on a Microsoft IIS server and this information applies if your site is on an IIS server.
My biggest challenge was that the migration broke all the links in the blogs.getcertifiedgetahead.com site. The original installation used a custom permalinks structure of /%postname%/. For example, if you wanted to view the page listing Security+ blogs, the URL looks like this: https://blogs.getcertifiedgetahead.com/security-blog-links/. Unfortunately, this resulted in 404 page not found errors on the new server.
I was able to change the permalinks structure to Post Name, but this added “/index.php” in the URL resulting in a link of https://blogs.getcertifiedgetahead.com/index.php/security-blog-links/. While my site worked with this setting, all external links to the original pages still resulted in 404 page not found errors. This just wasn’t good enough.
The Hunt
I spent hours researching solutions on the Internet. I’m very grateful for Google and all the people that post useful information on the Internet. Many times I’m able to get my answer in minutes, if not seconds. However, this hunt took me on several different paths until I finally found the solution.
One of the primary challenges I faced with this problem is that many of the solutions simply don’t work for the current version of Word Press. I’m running Word Press 3.5.1 and many of the solutions worked on older versions, but not with 3.5.1.
In short, the solution required a change to the web.config file and the options-permalink.php file (located in the wp-admins folder). I ultimately found the solution from a post by Ansh on Webloggerz.com: http://webloggerz.com/how-to-remove-index-php-from-wordpress-url/
Options-Permalink File
Ansh has good instructions on his page related to this fix. I’ll summarize them here:
- Open the wp-admin/option-permalink.php file
- Locate line 81. It looks like this: $prefix = ‘/index.php’;
- Modify line 81 to look like this: $prefix = ”
This should end in two apostrophe characters (”) not a single double quote character (“) - Save the file in the original location.
While I didn’t see the warning on Ansh’s page, I frequently see warnings about not modifying php files directly in Word Press installations. I’m sure there are times when it’s appropriate, and times when it’s not. I modified this php file as a last resort. When I upgrade to a new Word Press installation, it’s very possible this fix will be overwritten and break all my links. This will be one of the first things I check if an upgrade breaks the links.
As another note, this modified the Permalinks page some. It now looks like this:
Before implementing this solution, the Post name link looked like this: https://blogs.getcertifiedgetahead.com/index.php/sample-post/.
Web Config File
Next, the web-config file needs to have some code in it. This is located in the root directory of the web site (typically called wwwroot).
Again, Ansh has good instructions on his page. He even has a sample web-config file you can use as a guide. You can look at it here: http://webloggerz.com/wp-content/uploads/web-config.txt
The primary code you need is this:
<rewrite>
<rules>
<rule name="wordpress" patternSyntax="Wildcard">
<match url="*" />
<conditions>
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="index.php" />
</rule>
</rules>
</rewrite>This code must be within the <system.webServer> </system.webServer> XML tags.
Your web.config file will likely have some additional data in it. You probably won’t need to modify anything else for this solution. I did find that I had a <handlers> </handlers> tag related to php that I needed to remove.
.htaccess File Not Needed
The .htaccess file is not used with an IIS installation. A question I should have asked earlier and didn’t was “What type of server is my Word Press site installed on?” A Microsoft installation with an IIS server does not use .htaccess.
During my hunt, I ran across many web pages that indicated my problem was related to this file. I spent quite a bit of time modifying it and changing it’s permissions to get my site to work. Nothing I did seemed to matter and when I found the ultimate fix, I deleted the .htaccess file.
If your system is running on Apache server or something else, the fixes to the .htaccess file might help you and my solution might not matter at all.
Hosting Provider Won’t Help
One of the important lessons with this experience is that the hosting provider provided next to zero help. Admittedly, their stated policy is that they would set up the sites on the new servers and move the files but I was responsible for getting the sites to work. I certainly didn’t expect so many problems with the move.
I asked several questions, but only received one coherent answer. Instead, my queries were often unanswered, or answered with a form reply. They even modified some of the settings in the control panel that I had configured for testing and troubleshooting, while I was still testing and troubleshooting.
Also, after they moved it, they wanted to remove access to the old site. After three days of troubleshooting, and several unanswered queries, I received an email stating “We cannot keep a site alive on 2 servers indefinitely.” Thanks.
In retrospect, I wonder if I would have been better served by creating the sites on a completely different provider. I could have kept the old sites live while I worked on getting the new sites operational.
Here are some of the other problems I faced.
- Posts on ycda.com and blogs.getcertifiedgetahead.com had funky characters like â€“ “ ’ â€.
This was caused by an incompatibility with the character set. My original wp-config.php file included this line:
define(‘DB_CHARSET’, ‘utf8’);
I removed the line on the new server and the problem disappeared. I have since noticed that the collation set on the new server for the MySQL databases is “utf8_general_ci”
I changed the line to this:
define(‘DB_CHARSET’, ‘utf8_unicode_ci’);
This also eliminated the funky characters, and is a better solution because it accurately identifies the collation. - Database gives this error when I access it through the provider’s control panel:
Your PHP MySQL library version 5.0.51a differs from your MySQL server version 5.5.28. This may cause unpredictable behavior.
I suspected this error was causing some of my problems, and it might still be causing some problems. I still occasionally get errors in the control panel indicating a problem with database connectivity. Unfortunately, my query about this error to the hosting provider has not been answered. - One of the new sites was not created on the new server. While a simple problem to resolve, it just added to the challenge of getting everything moved.
Celebrating Success Today
While I still might have some problems to work through with this, I have enabled the last site on the new server and am celebrating success today. This WordPress permalinks problem was quite a challenge, but thanks to the posts by many other people on the Internet (such as Ansh at Webloggerz.com), I was able to resolve it and the other problems I faced with this move. I might be quiet for a couple of days, but I’m doing well.
