I recently moved a website for a client from one hosting company to another hosting company.  The entire blog was broken though.  Every time I clicked a link or tried to visit a post it resulted in a “Page not Found”.  From looking at the URL, it was obvious that it was using Permalinks.

Since the site was failing to display these pages using permalinks, the problem was with the .htaccess file.  Sure enough I opened it up and the .htaccess file was empty.  So while the most common problem is the the htaccess file is forgotten and not moved, in this case on the previous host it just didn’t exist.

Unfortunately, I didn’t have access to the clients Wordpress Admin so I couldn’t regenerate the htaccess file.  Instead I had to go look for it on another Wordpress installation.

For those of you that might not have access to easily look this up (and for my own reference later), here is what the .htaccess file should look like (2 versions):

Version 1: (root installation)
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

Version 2: (subdirectory such as in this case “blog”)
# BEGIN WordPress
RewriteEngine On
RewriteBase /blog/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php [L]
# END WordPress

So just make sure you have that file out there and actually have the proper information in the file so that it works.

In a previous article, I wrote about why you might consider CAPTCHA to be a bad method of protecting your blog from Spam. I’m not going to go into depth on that topic again, I’ve linked to it if you want to read it. The general theory is if you value your visitors communication then you should not make it harder for them to communicate in an attempt to block Spam. Instead there are many other ways to prevent it behind the scenes.

So the first method I would do, and always do on every blog I create whether it’s for a client or for myself, is install Akismet. Wordpress comes with it, it’s very light weight, powerful and effective. Since Wordpress already comes with it installing it is just a matter of going to your plugins and clicking “Activate”. There is one additional step and that is for you to go to Wordpress.com register a username only, and get your API Key.

Once you have your API Key, just enter it into your Akismet settings and you are all finished.

You’ll find Akismet is very effective. I don’t see it miss very much spam, and I rarely see a false positive. When you log into your Admin from now on, right there on the dashboard you’ll see your site stats and a link to your comment Spam. With one click you can delete it all. And it is very easy to scroll through it looking for false positives.

One thing to note though, spammers are crafty. They’ll add comments about how correct the post was and how beneficial it was to them and that they are going to bookmark it for all eternity. But if you look their name will be Viagra, and their web address will be something selling viagra. It’s all just a ploy to try and get that comment approved and get some kind of link to their site. Make sure you watch for real posts from real people that have something real to say.

Protecting email addresses and contact forms.

The next piece you should be aware of is that just by being online you are going to be subjected to spam. So as a rule of thumb I never put email addresses on a website. Spiders, and spam bots come along scraping the web of email addresses. The only reason to put your email address out there in my opinion is if you really are out of Viagra and you haven’t gotten any emails from sources you can buy it from lately.

But keep in mind it is important to make it easy for visitors to contact you. Instead of posting your email address it can be just as effective to just put up a contact form. In my opinion it is even more effective. By putting a link to your email there are many visitors that can’t click it to send you an email. By clicking it their computer will try to open the default email client and send you mail. What if they use webmail? The link won’t work, they’ll need to copy and paste. What if they are at a friends computer or coffee shop? Well I guess if they don’t use webmail they’ll need to remember you website or your email address and email you when they get home.

Having a contact form means that without leaving your site they can just type in an email and hit submit and off it goes. They just sent you an email. This is a much better form of providing a point a contact in my opinion.

It is very important to use the proper contact form. The contact form can’t allow header injection, it should check the referrer of the form post to see if the post came from your own site. These are just basic programming aspects, and if they are in place they will ensure that even if you get the occasional spam from the form it was probably manually submitted because a spammer was looking for a hole, chances are they won’t find one and they’ll move on to easier targets.

A nice Contact Form that is well programmed and secure that I use on many of my sites is produced by Dagon Design.  And naturally, in my opinion you should turn the CAPTCHA off.

In conclusion, it is my opinion that with just a little bit of work you can block or make it much easier to deal with the majority of Spam coming through your website. And this is the way it should be. YOU should be dealing with the spam, your VISITORS should NOT be having to jump through hoops just to communicate. Let me know what you guys think.

I actually don’t get this question very often. The question I often hear is, “Can you help me get CAPTCHA set up on my site/blog/etc?”. Usually people just want it but a lot of times they don’t think about whether or not its a good idea.

Think about it this way. If you didn’t know cops exist, and you wanted to drive to work. You know it takes maybe 20 minutes at 60 miles per hour, so naturally it will only take 10 minutes if you go 120 miles per hour, right? Well, then you’ll discover the cops, and hopefully you won’t discover the high speed crash.

This is kind of how CAPTCHA can be for your blog, website, and more. Naturally the negatives aren’t as harsh as being arrested or a high speed crash, but they might be pretty serious for a business.

The main reason someone would consider using CAPTCHA on their blog to begin with is probably to try and prevent spammers. You open a website, and over time you’ll notice that as your site gets found online the spam starts flowing in. It’s a bitter sweet feeling. If the bots can find you, then people will start finding you, but you don’t really want the spam bots on your site.

Normally to alleviate the extra work of dealing with all the spam many will use a CAPTCHA image in their form to prevent these automated bots from posting. But if you have a website then I’m sure you’ve visited another website. Have you ever visited a site with CAPTCHA and had difficulty posting anything because you can’t read the letters?

If you can read the letters then most bots can actually be programmed these days to read them as well. So these letters are usually very hard to read. Do you want to risk a potential contact getting frustrated and leaving the site?

A while back I found a study that a developer had created. This particular developer tested CAPTCHA on 50 websites he was maintaining for his clients. I can’t find the link to it right now or I’d post it for you. The first 3 months he had 25 sites with CAPTCHA and 25 sites without, for the next 3 months he reversed it. So he had the results of a pretty decent study.

He found on average on his well visited sites, that about 7% of the form submissions were spam, if I remember correctly. Now on the months that CAPTCHA was in place he would see that all of spam failed to submit the form properly, but the interesting part was that an additional 4-5% of form submissions were also failing. These were new unique visits as well, a total of 11-12% of failed submissions, compared to only 7% spam on the months with no CAPTCHA.

Maybe in the beginning of your site when Spam is high and human visitors are low, comparatively, then you can afford to take this risk. But even considering the time you save if you have a start up website I would think that every single contact would be important. Can you really afford to loose 1 out of every 20 visitors because they can’t get past your CAPTCHA?

Now if your offering or their reason for posting is so very compelling that they feel a strong need to do so, then they might fight through it. But the less compelling the reason for posting, the easier the person will give up. I don’t know if I want to take the risk of loosing 5% or even more. I think I’ll just find other ways of dealing with the Spam.

I helped someone finish up a site move earlier today.  They had already moved the files and the database over.  All I needed to do was help set up the files, import the database, make sure the permissions were proper and double check any final configuration settings.

When I was finishing it up I always check the permissions of the .htaccess file.  It’s one file that is easy to miss.  On a fresh install it doesn’t even exist so I normally create it and make sure it has writable permissions since Wordpress is fully capable of setting up the .htaccess file for you if you change the permalink settings.

In this case, the file was missing, the person who had moved the files didn’t move this particular file.  It does happen on occasion.  In Linux anything that starts with a period is a hidden file.  If you download via FTP you might not see it by default.

But on this site I didn’t even think about it not being moved.  I was busy at the time and I had checked the site and it was showing up so I assumed good to go.  I did however create the file and give it writable permissions.  I figured some people don’t use the permalink setup, but in case they ever did in the future it’s set up so Wordpress can write it for them.

Well you know what they say about assumptions.  Naturally, I found out later none of their post links were working.  A quick check on the site and sure enough it was trying to use permalink but the .htaccess was empty so it wasn’t working.

Luckily this was an easy fix.  I had already created the file and made it writable.  I logged into their admin, went to permalink settings, turned the settings off, saved, turned it back on how they had it, saved, and good to go.  The site was back to working.

Lesson for me, don’t assume.  Lesson for others, make sure you move those hidden files.  Those little buggers are hiding after all.

Previously I wrote a post about taking responsibility for your 404 errors.  Today I want to spend a little bit of time going over what I’ve done to change my own 404 error page.

You can see on the right what the default template and the default 404 error page looks like.  Needless to say it leaves a lot to be desired.

Wordpress actually makes it very easy to program an improved 404 error page.  Yoast.com had an interesting article on a few changes to make an attractive 404 page. I had a couple small issues with the code he shared but I still really liked the general idea.  I made a few changes which seems to work better for me.

However you decide to design your error pages, keep in mind that they are important.  Doesn’t matter if you are using a Wordpress blog, and eCommerce website, you don’t want to loose the traffic for visitors that might be coming into your site from an invalid link.

Editing your 404 Error Page is really simple.  For most templates you simply need to edit the file named 404.php  So here’s where I went with it:

## Pull Query Variables and check for exact match ##
$s = htmlentities(strip_tags($_SERVER['REQUEST_URI']));
$s = str_replace(‘/’,”,$s);
$s = preg_replace(‘/(.*)\.(html|htm|php|asp|aspx)?$/’,'$1′,$s);
$posts = query_posts(‘post_type=any&name=’.$s);

## If no posts match perform search ##
$s = str_replace(‘-’,’ ‘,$s);
if (count($posts) == 0) {
$posts = query_posts(‘post_type=any&s=’.$s);
}

## Display results of either direct match or post search ##
echo ‘<ol>’;
if (count($posts) > 0) {
echo ‘<li>Were you looking for <strong>one of the following</strong> posts or pages?’;
echo ‘<ul>’;
foreach ($posts as $post) {
echo ‘<li>’;
echo ‘<a href=”‘.get_permalink($post->ID).’”>’.$post->post_title.’</a>’;
echo ‘</li>’;
}
echo ‘</ul>’;
}
echo ‘If not, don\’t worry, here are a few more options:</li>’;
echo ‘<li><strong>If you typed in a URL&hellip;</strong> make sure the spelling, cApitALiZaTiOn, and punctuation are correct. Then try reloading the page.</li>’;
echo ‘<li><strong>Look</strong> for it in the <a href=”/sitemap”>sitemap.</a></li>’;
echo ‘<li><strong>Start over again</strong> at my <a href=”/”>homepage</a> (and please <a href=”/contact-jason”>contact me</a> to say what went wrong, so I can fix it).</li></ol>’;

Here’s a quick graphic to show you how you might find the 404.php page from the admin of your Wordpress site:

As you can see here from the code I took the Request URI from the server variables.  I clean it removing the starting slash as well as the ending extension.  I then take and process to see if I can find a name match, if not I remove dashes and do an actual keyword search.

My final result builds a page which includes the above results if there were any.  In addition I add in a possible fix, links to site map and home page, as well as a link to my contact page.

I still want to add the ability for a visitor to just perform a search right there on the 404 page, which technically they can in my header, but we’ll see what I put together who knows.

Most of you know that installing Wordpress is a pretty easy and straight forward job, and if you don’t know it already just try it out once or twice and you’ll see how easy it is.  But if you’ve been around the block you’ll also know that different hosting environments and situations can throw some different scenarios at you.

Not too long ago I came across a problem that I haven’t seen before.  The situation was installing Wordpress in a hosting environment with a Plesk Control Panel.  Although this situation could arise in multiple other environments, I just hadn’t encountered it because I normally prefer to stick to VPS and VDS hosting without a control panel, and I really stay away from purely shared hosting like it’s the plague.

After installing Wordpress any time I tried to upload media (with the setting to organize by date) into the Wordpress system I would get the error:

Unable to create directory /var/www/vhosts/[mydomain]/httpdocs/wp-content/uploads/2009/11. Is its parent directory writable by the server?

The part that threw me off was that I had created the uploads directory, I gave the directory 777 permissions so that Apache could create files and folders beneath it, and I actually found that the installation would create the “2009″ directory, but nothing any further.  If I went ahead and created the “11″ directory and gave it write permissions then it could write uploads, but once the next month came around same problem again.

To top it all off, I first came across this problem in front of a client that I was teaching some hosting tricks.  So now I was just looking like an idiot.

Turns out the problem was related to Safe Mode.  My own bad habits persisted when normally setting up domains so I would turn Safe Mode off in my own VPS hosting, but when teaching the “correct” way I recommended leaving Safe Mode on.  Well if your scripts are owned by your domain user, and then naturally running under the Apache User, then Safe Mode won’t create objects underneath a path that has mixed ownership.

It will allow the first directory to be created “2009″, but then the next won’t be allowed.  So the easy solution is to turn off Safe Mode.

Some people probably won’t think this is the best option.  The same people don’t like to set public folders to 777.  But if you are on VPS hosting with a Plesk CP inside your container and it’s just your container you are good to go.  No one else has access to your system but you in the first place.

Of course if you are on or providing shared hosting for many customers, this might not be ideal.  With Shared Hosting you will be giving access to those folders to other customers in the same shared environment.  It would be more ideal to just change the ownership of all the Wordpress files to “Apache:Apache” or whatever user:group that apache is running as.  Then you can leave Safe Mode on, and folder permissions to be writable only need 755.  Keep in mind that this only works if you are the provider, if you are just hosting on a shared system you won’t have the ability to do this.

If you’ve been online for very long you’ve probably clicked at least one link or visited some page that resulted in a 404 error.  I even went and asked a friend of mine, who is probably the most internet illiterate person I know, about 404 errors.  She immediately responded with oh yeah 404 I see that pop up sometimes, it means the page can’t be found or something right?  I just go back or leave immediately and try to find what I need elsewhere.

This is part of the problem I see everywhere.  When I do see a 404, the majority of the time, I usually notice that the error page is blaming me for going to a page that no longer exists.  And probably more than 90% of the time all I did to get there was click a link from some other website.  So how exactly is it my fault again?

Are you blaming your visitors for getting a 404 error?  And more importantly is it really their fault?  And even if it is their fault, is it better to take the blame and help them move to a page that does exist, or just go ahead and leave a default error page up and loose that visitor to the rest of the internet?

Personally, I feel responsible for all 404 errors that someone might get on my site.  The time the visitor might have clicked a link from Google that no longer exists.  Maybe they clicked a link from another blog where the other blogger typed the link wrong.

I should have been redirecting any pages I deleted to a suitable replacement.  Or I should be watching for incoming links to my site and if they are wrong redirecting them to appropriate pages.  The idea is that I feel I should be as proactive as possible to prevent 404 errors when possible, and when I fail to do so it is my fault.

There of course are some 404 errors that you can never find or be proactive to take care of, such as a visitor manually typing an address on your pages and ending up at a 404.  But even in this case I don’t want to just blame them and loose a visitor.  Instead I’d rather accept the blame and try to help that person the best I can to move into a legitimate page on my site.

So what are your thoughts?  Most people over look this area of their site, and maybe it’s not a huge issue, but when fine tuning your site it is something often overlooked.  How would you better your 404 error page?

So here’s a fun story about some wasted time.  I configured feedburner a while back to use as the RSS Feed for the site.

I like the way Feedburner looks compared to the default RSS Feed.  The social icons are better, you can get better statistics out of the system.  Plus, it’s owned by Google.  Never hurts to supply Google with as many links to your site as possible (don’t quote me on that, I really doubt it actually matters).

A lot of times, I like to be a log junkie.  I sit back and hunt through my site logs on occasion.  I like to look for errors with the site, and fix them before they cause to many issues. Sometimes I even find malicious bots trolling the site and I can block them or deal with them at least.

Anyway, I noticed that there were several attempts to hit the Wordpress RSS feed that is the default.  The systems ( a Google Gadget, something from Yahoo, etc. ) were hitting the site on a regular basis.  It’s not that they were getting old information, but it was quite a few subscribers that weren’t getting the legitimate feed, and thus I wouldn’t see the proper tracking.

I started scouring the Google Search for a method to redirect the feed via a redirect in the htaccess file.  I didn’t want to use a plugin and create additional overhead when it can be done so easily with the htaccess.  And I didn’t want to spend the time to write it myself, when I’m sure it was out there several times over.

I found a code block from Perishable Press:
# temp redirect wordpress content feeds to feedburner
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} !FeedBurner [NC]
RewriteCond %{HTTP_USER_AGENT} !FeedValidator [NC]
RewriteRule ^feed/?([_0-9a-z-]+)?/?$ http://feeds.feedburner.com/wordpress-master/feed [R=302,NC,L]


Naturally if you are going to use this code make sure you change out my feedburner address for your own.

The problem was that after I added it to my htaccess it didn’t work.  I just popped it in really quickly, wasn’t paying attention at all.

After spending a lot more time than I wanted to spend on it, researching alternatives online.  I finally started reading comments.  There are several posts out there that all use this code, but none solved my problem.

Reading the comments, someone mentioned that the code has to be before the permalink rewrites that Wordpress uses.  Doh, I’m an idiot.  If I would have just spent two seconds to actually look at the code I would have realized it.  But instead I tried to save time and just do it quickly.

I guess in this case trying to NOT “reinvent the wheel” I cost myself a lot of unnecessary time.  Especially on something this simple that I could have just written myself.  Oh well, live and learn.