Wordpress and .htaccess when using subdirectory installations

You're back! Be sure to follow me on Twitter before leaving.

To me, .htaccess is a necessary demon that I have to live with. Whilst I have a basic understanding of how the file works, the fickleness in which it can break is enough to drive me insane. Yesterday (and part of today) I had that feeling. And here’s a post explaining how it was solved, with a huge credit to Mike Osolinski. I only met Mike through Twitter after an RT from Pete – just goes to show the genuin quality of a strong social media network

The situation as I described was the following:

Client website is static HTML
WordPress is installed within a directory (/news)
Webmaster Tools reporting thirty-six 404 errors from the old website that need redirecting
Adding redirects manually to the .htaccess file is causing 500 errors

So let’s go through each stage as we approached the fix:

WordPress and .htaccess

By default, WordPress uses htaccess to control it’s permalink structure using the code below. You’ll notice that if you set a custom permalink structure, it will ask you to update your .htaccess file, or make it writable.

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

</IfModule>
# END WordPress

By nature, .htaccess is incredibly anal about correct syntax. This means that stray spaces, line breaks and other tiny details can (and will) result in an error. I was using WSFTP Pro v9 for FTP access, and this tries to hide the .htaccess file from you. You can fix that by reading this. Other FTP software may do the same, so it’s worth a search to find out how to show all files.

My FTP software was set to Auto for file transfers, meaning that it automatically chose either ASCII or Binary depending on the file extension. This turned out to be a crucial setting when fixing the errors. To ensure I was uploading the file correctly, I had to set it to ASCII. For whatever reason, WSFTP was not uploading it using the right setting, so this manual change ensured it was. After making this change, the initial test that Mike had sent across had worked. This change was:

redirect 301 /contact.aspx http://www.clientsite.com/contact.html

Although this was just one URL of the 36. It’s also important to know the encoding of the .htaccess file. Whilst I originally was defaulting to UTF-8, Mike had been using ANSI encoding which, for whatever reason, worked! *Simple* I thought – all I had to do was add the other 35 links in the same way…

As you probably guessed, it broke. ARGH! Here’s what Mike suggested was wrong:

Line 14 Indent at beginning of line also 2 301′s on the same line.

There are a number of lines where there is only one url and nothing specified to redirect to, There also seemed to be a line space at the end.

So, no ‘line sharing’, and a few silly errors on my part not giving a destination URL. I skipped through these to go back to them, but clearly I rushed!

To fix the file, and to make sure there were no spaces or any line sharing, I sent Mike the following file. note that the image says permanent in place of 301. This was just a test and didn’t make a difference – you can use either. It’s useful to just highlight all the text and scan the ends of lines for unwanted spaces. I found two from doing this.

So after this had brought up errors, we knew a couple of things:

We had the right idea, because Mike’s first htaccess file worked. So it was something within the redirects themselves that was causing the problem.
We were on the correct FTP setting – ASCII worked, Auto didn’t (which meant Binary didn’t either)

Next was to look at error logs. Peter Lowe mentioned to me that the error logs often give additional information as to why the site would throw up a 500 error. You can normally access your logs through your hosts control panel or request them from the host company. Either way, you should be able to get access to these logs.

Here’s what the logs on my server was throwing up:

In more detail:

[Fri Jan 14 14:08:43 2011] [alert] [client 188.220.6.98] /var/www/vhosts/ADDRESSREMOVED/httpdocs/.htaccess: Redirect to non-URL

Pete was right, the error logs gave some key information that led to the fix. The above statement, ‘redirect to non-URL’ was suggesting that there was an error in the way the URLs were written in the .htaccess file. Pete also mentioned that the destination URL should be absolute meaning the full address should be included. E.g.:

redirect 301 /page.php /page2.html (WRONG)

redirect 301 /page.php http://www.site.com/page2.html (CORRECT)

After completing the following checks, the file now works!

No extra spaces or unnecessary line breaks
ASCII transfer setting on FTP client
ANSI encoding of the .htaccess file
Destination URL must be absolute (the full http://www….) (See here)

These settings may not work for you – there’s a lot of factors to consider. But this post will hopefully give you some ideas to help identify the problem you might have.

Checking your Redirects

A useful method for checking a handful of redirects at once is to:

Copy the URLs from your original spreadsheet download. Because it opens in a spreadsheet, this is easy enough to do.
Next step is to load up URL Opener and paste your list into the box.
Run the URLs and give them a moment to load.
Select through the browser tabs and close them one after another. If you spot an error, move on to the next until you only have erroneous tabs open. Hopefully you’ll find you won’t have any!

Credits to Mike Osolinski who also helps out at Tech Monkeys, a website that helps people out on spyware, viruses, hardware, programming, and more. Oh, and for free! I also want to thank Peter Lowe who helped out at the end with the absolute URL tip.

Tagged as: 301 Redirects, 500 Error, Apache, htaccess, Wordpress

WordPress and .htaccess when using subdirectory installations

Connect

What I’m Talking About…

Tags

My Recent Posts

Twitter Feed