Something I have wanted to do for the longest time on Gitr’s WoW Blog is to change the permalink structure to reflect the post title name, but it’s way too late to do that with how many blogs and SEO links are directly linking posts using the default structure.
UPDATE: I just checked a link to my site from another blog using the old permalink, and it still works! It knows both addresses.
Here is a guide to updating your structure, because it was a total pain in the butt for me. I’m not a server genius, but I’m not stupid, either. I hope this is helpful for you, and I’ll try to be as plain as possible.
My first step was Googling for how to do it and kept getting all kinds of info about ch_mod and server permissions and writing to your .htaccess file. It was all very confusing. Everything I did kept causing an Internal Server Error. Please feel free to ask me how I did it, but I highly doubt I can solve anything outside the scope of my experience in this ordeal.
- Go to http://www.keyboardface.com/IIS-Permalinks/. Download the files he offers to help. I had no idea what server software I was running so I guessed I had IIS, whatever that is. I think this might work no matter what using my method, though.
- Go to your domain hosting site and see if there is a place in the control panel to edit your Error 404 page. I have GoDaddy, and it was easy. If your blog is in a subdirectory, make sure you put the file in the root file of your blog. My blog is in the root folder of its domain, but it is a domain settled in a folder on my host, so I had to /directory/errorpage.asp to get it to the right location in the control panel.
- Upload the htaccess.php and errorpage.asp to your blog/domain root folder.
- Change your Permalink setting in your WordPress Dashboard. Options/Permalinks/Custom. Enter the code: /%category%/%postname%/ for the best SEO configuration, or whatever else you want. Save the settings.
- Make sure you don’t have an .htaccess file in your blog or domain folder. This was the last straw for my problem. As soon as I renamed that file, everything worked like a charm.
Enjoy your new structure and reap its SEO benefits.
Whoa dude! Be careful with what you’re doing!
First off, you should be able to determine the web server your site uses by checking with your web host. Many sites run on the Apache webserver, while others do run on IIS. Knowing which your server uses is important. GoDaddy sells plans using either.
You mentioned chmod and .htaccess. A quick explanation: chmod is a program that you use to change the permissions on files on the server. In a web server environment, the permissions control what scripts the server executes as well as what files can be read, served, and edited and by whom. This means that files with the wrong permissions will not be processed (a visitor will see the programming code) or will not be served (500 Internal Server Errors anyone?).
In many cases where you want to handle redirects like this, you’d use rewrite rules to redirect to the pages new location on the fly. This is essentially what you managed to accomplish: when a request comes in for a page that doesn’t exist, the error page looks to see if it can find the page at a new location (a location that WordPress supplies once you tell it how you’ve renamed your pages).
Honestly, I’d say you were lucky to get this working the way you did. WordPress is a PHP application (that is, PHP is the programming language it’s written in) and your error page is an ASP page (that is, it’s written in ASP). My experience is that you normally don’t find both languages configured on the same server, but I am a total NOOB when it comes to both IIS and ASP. Give me a good old LAMP stack any day (Linux, Apache, MySQL, and PHP/Perl/Python).
Finally, a word of warning: renaming your .htaccess file can have negative consequences for some users depending on how their web site is configured by their provider. I definitely don’t recommend messing with it unless you know what you’re doing. In some instances, it can contain information regarding what directories should be password protected, and in other cases it can contain important rules about how your web server processes your pages. If you do need to touch it for some reason, renaming it as you recommend is the best way to go so you can put it back if something bad happens.
Whoa dude! Be careful with what you’re doing!
First off, you should be able to determine the web server your site uses by checking with your web host. Many sites run on the Apache webserver, while others do run on IIS. Knowing which your server uses is important. GoDaddy sells plans using either.
You mentioned chmod and .htaccess. A quick explanation: chmod is a program that you use to change the permissions on files on the server. In a web server environment, the permissions control what scripts the server executes as well as what files can be read, served, and edited and by whom. This means that files with the wrong permissions will not be processed (a visitor will see the programming code) or will not be served (500 Internal Server Errors anyone?).
In many cases where you want to handle redirects like this, you’d use rewrite rules to redirect to the pages new location on the fly. This is essentially what you managed to accomplish: when a request comes in for a page that doesn’t exist, the error page looks to see if it can find the page at a new location (a location that WordPress supplies once you tell it how you’ve renamed your pages).
Honestly, I’d say you were lucky to get this working the way you did. WordPress is a PHP application (that is, PHP is the programming language it’s written in) and your error page is an ASP page (that is, it’s written in ASP). My experience is that you normally don’t find both languages configured on the same server, but I am a total NOOB when it comes to both IIS and ASP. Give me a good old LAMP stack any day (Linux, Apache, MySQL, and PHP/Perl/Python).
Finally, a word of warning: renaming your .htaccess file can have negative consequences for some users depending on how their web site is configured by their provider. I definitely don’t recommend messing with it unless you know what you’re doing. In some instances, it can contain information regarding what directories should be password protected, and in other cases it can contain important rules about how your web server processes your pages. If you do need to touch it for some reason, renaming it as you recommend is the best way to go so you can put it back if something bad happens.
Also: It seems as though commenting on your blog is throwing a bunch of PHP errors. I’m not sure what’s causing it, but you might want to take a look.
Also: It seems as though commenting on your blog is throwing a bunch of PHP errors. I’m not sure what’s causing it, but you might want to take a look.
Jason,
Thanks for stopping by. I guess it’s always better to be lucky than good. I had no idea this is a brash maneuver.
I did notice, in the end, though, that this method actually re-created the .htaccess file itself. I’m not sure why, but the method I read on the above link stated that the ASP reads the WordPress settings to create it.
I looked in the vars.php file and saw both IIS and Apache code when I was researching, but the Apache code did not have the 1,0 or whatever that I was reading about replacing, so I made an edjumacated guess that I had IIS. Knowing that I checked that out, how harebrained was my method?
I’ve been getting comment errors ever since I switched to GoDaddy. Is that a common GoDaddy issue? I originally thought it was my theme, but I’ve changed themes several times. Some get eaten, some give errors, and it’s pissing people off.
Thanks for your insight, Jason.
Jason,
Thanks for stopping by. I guess it’s always better to be lucky than good. I had no idea this is a brash maneuver.
I did notice, in the end, though, that this method actually re-created the .htaccess file itself. I’m not sure why, but the method I read on the above link stated that the ASP reads the WordPress settings to create it.
I looked in the vars.php file and saw both IIS and Apache code when I was researching, but the Apache code did not have the 1,0 or whatever that I was reading about replacing, so I made an edjumacated guess that I had IIS. Knowing that I checked that out, how harebrained was my method?
I’ve been getting comment errors ever since I switched to GoDaddy. Is that a common GoDaddy issue? I originally thought it was my theme, but I’ve changed themes several times. Some get eaten, some give errors, and it’s pissing people off.
Thanks for your insight, Jason.
It does recreate the .htaccess file. What I was getting at with my warning is that by renaming the file (I think in your case because the server didn’t have permission to edit the old one, but did have permission to create one) you might have lost configuration directives that were set by your hosting provider (the script looks at WordPress to create rewrite rules, but doesn’t look at the old .htaccess file to grab legacy rules).
I’m not sure what the vars.php file is… Is this part of the WordPress install, or somewhere else?
I can’t say where the errors are coming from as I actually blew right by them. I then couldn’t get them to occur again. I’ll see if I get them this time and if I do I’ll let you know if I can think of anything that might be causing it.
It does recreate the .htaccess file. What I was getting at with my warning is that by renaming the file (I think in your case because the server didn’t have permission to edit the old one, but did have permission to create one) you might have lost configuration directives that were set by your hosting provider (the script looks at WordPress to create rewrite rules, but doesn’t look at the old .htaccess file to grab legacy rules).
I’m not sure what the vars.php file is… Is this part of the WordPress install, or somewhere else?
I can’t say where the errors are coming from as I actually blew right by them. I then couldn’t get them to occur again. I’ll see if I get them this time and if I do I’ll let you know if I can think of anything that might be causing it.
The error is being thrown by the plugin you use to let people subscribe to a comment thread by email. It’s saying that on line 438 there’s a problem with the data in the array. The other errors are being thrown because of the first error (when writing certain types of headers, you can’t write anything before you write them and in your case you’re writing an error to the screen).
I’d say you should look for an update to that plugin. If that doesn’t help, check the plugin’s forum or developer site.
The error is being thrown by the plugin you use to let people subscribe to a comment thread by email. It’s saying that on line 438 there’s a problem with the data in the array. The other errors are being thrown because of the first error (when writing certain types of headers, you can’t write anything before you write them and in your case you’re writing an error to the screen).
I’d say you should look for an update to that plugin. If that doesn’t help, check the plugin’s forum or developer site.
Yes, vars.php is part of the WP wp-includes files. I disabled the subscriber plugin until I get a chance to get a new one. Thanks for that help. I’ve had that header error before when I royally screwed up a theme, so I’m glad it’s likely plugin-related.
As to the .htaccess again, I knew what was in that one because I created it from scratch myself earlier and knew it was nothing important, so yes, I’d advise people to know what’s in it first and simply rename it and leave your FTP connection open if something breaks to put it back as it was.
Yes, vars.php is part of the WP wp-includes files. I disabled the subscriber plugin until I get a chance to get a new one. Thanks for that help. I’ve had that header error before when I royally screwed up a theme, so I’m glad it’s likely plugin-related.
As to the .htaccess again, I knew what was in that one because I created it from scratch myself earlier and knew it was nothing important, so yes, I’d advise people to know what’s in it first and simply rename it and leave your FTP connection open if something breaks to put it back as it was.