Clearly, this sort of “nofollow” is lessens the value to advertisers who think they are paying for the both link juice and traffic, but get traffic only.

This type of cloaking is fairly easy to do. But, I want to warn any ninja bloggers out there: it’s also it’s easy to catch!

How can advertisers detect cloaked no follows?

There are two ways: One is quick, and will often work; the second takes more time, but is more effective.

Here’s how:

1. Visit pages using User Agent Switcher and Search Status:
   Search Status makes “nofollow” links easy to detect by highlighting them in pink. User Agent Switcher lets switch your “user agent” to “Googlebot” and surf the web seeing it the way the Googlebot does (at least usually.)

   Used together, you should be able to catch most publishers who cloak to show “nofollows” only to the Googlebot. If you use both, you will usually see all cloaked nofollows will be shown in pink when you set your user agent to Googlebot. They will not be pink when you set your user agent to default.

   Unfortunately, this method is not foolproof, because a) Spam plugins like Bad Behavior will notice you aren’t really the Googlebot and refuse to show you the pages. This is an entirely legitimate way for a publisher to protect their page. b) Some “clever” publishers may cloak by detecting IP in addition to user agent. This could foil detection using the User Agent Switcher.

   Luckily, you can always rely on method 2:

2. Check cached page at Google: Periodically, while the your contract is in place, visit Google and check the cached copy of all pages with paid links. Obviously, if the Googlebot is shown “nofollows”, it will cache a page containing nofollows. So, this method is foolproof.

Will I be writing a cloaking plugin?

I’m tempted to write a cloaking extension to NoOldSpamLinks plugin. It would be great for traffic. But, I’ve decided against it.

I’m all for letting bloggers control their nofollows. I think bloggers should be able to do whatever they prefer with their links within the law and contractual obligation.

But, I’m afraid I can’t bring myself to help bloggers show “follows” to advertisers who pay for them, and “nofollows” to Google. If you want to sell “nofollow” links, negotiate that with the advertiser; then show the nofollows to both the public and Google. If you as a blogger want to cloak to show nofollow to Google, and “follow” to your paying customers, I’m not telling you how to do it!

If this happened to Justin, you can bet it could happen to you! Luckily there are steps you can take to could protect yourself both from getting hacked, or failing that, at least discover if you have fallen victim of this sneaky hack!

How to protect yourself

1. Periodically change passwords you use to access by FTP. This is generally done at the account web host gives you. If you don’t know how to do this, ask your host!
2. Protect your wp-admin area using htaccess. Hacking into wp-admin is a common tactic. I discussed the steps you can take to protect that area of your blog in Blog Security: htaccess block.
3. Periodically look at your pages through Google’s eyes:
   • Install the FireFox User Agent Switcher
   • Create a Googlebot user agent.
     Do this buy pulling down “Tools” -> User Agent Switer ->Options ->Options.
     Next click “User Agents” then “add”.
     An entry box will appear. Enter Googlebot 2.1 for “Description” and “User Agent”. Don’t worry about the other boxes; leave them blank.
     Save these settings.
   • Switch to the Googlebot user agent by selecting “Tools->User Agent Switcher”. You’ll now see “Google bot 2.1″. Select that.
   • Turn off BadBehavior (or the next step will fail.)
   • View your blog. If should look the same when viewed with the Googlebot user agent and when viewed normally. If you see something horrible, you have been hacked. (Sorry, I don’t tell you how to fix that here. The ‘fix’ will depend on precisely what the hacker modified. )
   • Reactivate BadBehavior (to protect you from malicious ‘bots.
   • Head on back to “Tools->User Agent Switcher” and pick “default”.
4. Back up everything: Just in case protecting your ftp and wp-admin areas fails, be sure to periodically back up your blog templates, database, and Wordpress files (including images etc.) Backing up won’t prevent you from being hacked, but it lets you recover if someone does hack you. I back up my database daily using WordPress Database Backup.

   I back up the whole blog by saving the entire domain as a zip file and emailing to myself from time to time. (No, not every day.)

Hey, it’s Saturday. That’s as good a time to back up as any. Good luck and safe blogging!

(Which maybe means if you get your security tips from knitting blogs, you an avoid getting hacked the way Greywolf was in January of 2007?)

Anyway, since I know this can happen to anyone, I’m going to describe what the hackers do, and then describe two things you can do to increase security against these hacking attempts.

One will require you to deal with ‘.htaccess’ manually, but results in the most convenient set up while working at home. The other involves using a brand new plugin available at Ask Apache. That plugin is almost perfect. However, it could be improved. Because I got an error when trying to leave comments at “Ask Apache”, I’m going to suggest improvements to the plugin. (The developer asked!)

If he or she takes the suggestions to heart, this will be a truly awesome plugin. (It’s already very useful.)

So, now onto the meat of the article.

What do hackers do?

To amuse themselves, hackers load your login screen. Then they running a script that guesses the “name” and “password” in the login screen. The script just keeps guessing over and over and over. Eventually, they get in.

Once into admin, they replace the front post of your blog with one of their own; they frequently point to a page announcing they hacked you.

Luckily, most these hackers are out for fun and don’t really do much else but they could! Once they break into your admin area, they can do anything the you could do with your blog– including deleting all the files. They could change your email and password. They can do an awful lot.

So, you really don’t want to let this happen.

Because savy SEO types were hit this year, WordPress may have done some work to make this more difficult for hackers. But, frankly, if you can get in, it’s possible for someone to get it. All WordPress can do is make it take longer to guess your user name and password.

So, it’s still prudent to protect your admin area, using a stronger block than WordPress can provide.

How To protect Your wp-admin File: Very Secure Method.

To protect your blog from being defaced, you need to write a small text file that looks sort of like this.


Order allow,deny
Allow from 131.215
Allow from uiuc.edu


If this file is given the name ‘.htaccess’ and loaded into your wp-admin directory for your blog, the server will block everyone except a) people with IP’s that begin with 131.215 or b) people with IPs resolving to uiuc.edu from accessing anything in your wp-admin directory.

This includes the login screen! See how this keeps hackers out?

But I bet you aren’t at the University of Illinois and your IP doesn’t start with 131.215.

How do you set this so you can get in?

Now, you need to edit the lines to match your IP or your ISP. For example, if you access your blog through aol.com, you will edit “uiuc.edu” to read “aol.com”. Then people at uiuc.edu are blocked from the log in screen, but anyone with IPs supported by “aol.com” can access the login screen. Also, you’ll also want to discover your IP address and edit 131.215 to match your IP.

Note: Your IP is actually longer. It has 4 sets of three digit numbers like this: 123.456.543.211

If you enter 123.456 everyone whose IP starts with 123.456 can get in. If you enter the full number, only those with 123.456.543.211 can get in. There are advantages to both.

Also, if you notice your ISP gives resolves to a subdomain (like say, “aol.com” gives you “ca.aol.com” ), if you the subdomain, you’ll get more protection than using “aol.com”.

I have multiple users. Can I add them?

You can add as many exceptions at you like: just start with ‘Allow from’ and add the suitable ending. So add the IP address for your work place or any other places you might wish to access from.

I have approximately 10 “Allow from” lines in my .htacess file.

Save the file

After editing, save the file as ‘htaccess’ with no dot. That way you can see it on your pc or mac!

Next, ftp this file to your wp-admin directory (aka folder) of your blog. (Don’t put it in the root of your blog.)

Next, verify you are in the correct directory and change the name to ‘.htaccess’. (The dot is important.) Verifying that you are in the correct folder is important because you do not want to overwrite any pre-existing ‘.htaccess’ files in the root directory! If you do, you will screw up your blog permalinks. (You can fix that, but it’s work.)

Next: visit the admin panel of your blog as you would to write a post. If you can’t get in that means you have a typo in the IP address or the domain name of your ISP. Fix the typo in the ‘.htaccess’ file and overwrite the old one. Once it’s ok, you can access your blog!

How well does this work

This protection gives great security. The only problem is you might need to access with some other IP address when you go on vacation or travel for work a lot. I bet you don’t know you hotel’s IP address!

The other difficulty is your IP address may not be static. For example, it might be 123. 456.789.123 today and 123.456.789.124 tomorrow. If you wrote your file giving permision only to 123. 456.789.123 you’ll get in today but be blocked tomorrow.

However, by using the domain name (i.e. aol.com) or just the first six digits, you get around that problem.

That leaves vacation!

But I dotravel and I don’t know my hotel’s IP address!

Well, if you travel a lot, instead of using IP protection, you can set up a secondary password protection scheme.

I could tell you how to write this, but actually, a very nice person has written Htaccess Password Protect plugin!

The developer just published this and asked for suggestions. (I’m going to make some.)

The plugin is already useful. You can use it password protect access to your login screen without fiddling with htaccess. To do so, first visit the Ask Apache. Get the plugin. Upload; activate. Under “options” in your “Wordpress admin” area, find “AskApache”.

For now, use the “password only” option. Select a “Ask Apache” username and password– if you have any brains, both should be different from your Wordpress username and password. Type those into the appropriate boxes. Then enable password protection by clicking. (Do not add the IP protection unless you are absolutely, positively sure your IP is static. Mine is not. It changes about every 2 weeks.)

When you click, the plugin will create an .htacess file that will password protect your wp-admin file.

Now, when you try to log in, you will first see a password screen similar to the one shown. When you see this screen, enter “Ask Apache” user name and password you created, then click.

Now, the Wordpress access login screen will show up! So, what have you done? You’ve doubled bagged your wp-admin area.

Does this seem silly and a bit inconvenient? Well, it’s a bit inconvenient, but it’s not silly.

Plus, the developer has asked for suggestions. I have some and if they are implemented, this plugin will give awesome protection that is both more convenient and flexible. And if you keep an eye out, you an get this after it’s improved.

Recommendations to developer:

To help bloggers with dynamic IP’s, or who access from multiple locations, modify the ‘IP’ portion of your protection to permit the user to include multiple IP’s, truncated IPs and domain names.

That is, let me enter 123.456, then let me enter 234.421 as well. Then also let me include both uiuc.edu and aol.com.

Once you’ve done that, permit bloggers to select
a) password only (which is good while on vacation)
b) IP only (more convenient when not on vacation) or
c) password and IP (for the truly paranoid!)

But most of all: Kudo’s for thinking of this!

Of course it would!

So, I decided to modify the string I send using WordTwit: This involves adding code to WordTwit. But what should I send to Twitter?

Examining twitter, I noticed I get to enter 140 characters. I also noticed the url gets changed into a tinyurl that takes up to 28 characters– which I will round up “just in case”. I’m guessing (only guessing) that to get tags to show, I need to keep the title, tags and any extra characters to less than 110 characters. (That leaves room for the 30 character tiny url.)

So, I did a bit of coding to chop long titles down to 40 characters and slap on some categories at the end of the the message . I only add categories if they fit inside the 110 character budget.

The only way to test this is to post, so I’m doing that. We’ll see if this shows at Twitter! Here’s sort of what my Twit should look like if it works:

The difficulty was mostly due to a bug in PHP 5.2.2. The bug causes Wordpress’s xmlrpc.php file to break down. For some reason I don’t quite understand, aLinks uses the xmlrpc.php. (Why aLinks uses this is a mystery. )

The fix was easy. I added this line to the top of xmlrpc.php in my blog directory.

$HTTP_RAW_POST_DATA = file_get_contents("php://input");

By “top”, I mean I placed it immediately after the <?php. ( If you cut and paste from a blog, retype the double quotes. These are sometimes replaced with slightly different quotes which will not work. Just retype.)

I found both the solution and a description of the problem at hughesfamily.net.au and red-sweater.com.

Does this problem affect more than aLinks?

Yes. The ‘xmlrpc.php’ file contains some functions associated with pinging. So, if you are noticing difficulties receiving pings (which I was) you may be having problems with this file. (Presumably, my problems will be cured now.)

Do I have to fiddle with my xmlrpc.php file to fix the bug?

No. WP 2.2.2 includes the work around for the PHP 5.2.2 bug. When you upgrade, things will be fixed.

Thanks Lord Matt for noticing that aLinks was getting all bogged up trying to ping and ping and ping and…. Now I think I have the problem licked.

Tricia sent out an ABP about this at the PPP forums, so I went and visited Tricia’s Musings. After loading the page, I used the “view source” button on my browser, scrolled to the bottom and found the last few lines in the html. I read this:

</body>
</html></center>
<!-- Dynamic Page Served (once) in 3.866 seconds -->


3.886 seconds? That’s a lot. I just checked BigBucksBlogger; it took 0.73 seconds to serve the page without Cacheing. It took 1.07s with Caching. (More on caching later.)

Tricia is using WP-Cache, but almost 4 seconds is a major amount of time to serve one page. (Mind you, this number isn’t exactly the cpu. But it is proportional to cpu, so big numbers are bad.)

Anyway, Tricia is using lots of resources; it’s probably due to one very badly written plugin. Which? I have no idea.

Now I bet, you are asking me exactly what Tricia and Anabella asked: How can you tell how much time a page uses? And how can you tell if a plugin is a hog?

How to Tell How Much Time it Takes to Serve a Page

On Wordpress blogs, you can print out the amount of time it takes to serve a full page by adding this to your after your footer is loaded.

<?php printf(__(’%s seconds’), timer_stop(0, 2)); ?>

Where ever you place this bit of code, it will print the time lapsed since you first requested the page. By putting it in the footer, you can see the full time required.

Many templates include this command, but wrap it in comment tags. That hides it from visitors, who generally don’t care. But since I know most Templates show this, I knew that if I read Tricia’s source I would be likely to find the time required to serve the page.

Some templates don’t include the command; mine didn’t. But you can add the code easily. Just go to “presentation” open up the main index template and slap that php in! (Do the same for single posts if you want the time to appear in those too.)

I added it to my template and if you scroll down, you’ll see the time appears.

Note: don’t expect the time to to say 0.7 seconds. If you load my page several times, and I’m not caching, you’ll see the number varies a bit– in fact quite a bit. But you aren’t going to see 4 seconds as I saw at Tricia’s site! If I’m caching, you’ll probably see the same time listed every time you reload the page and you’ll see more than 0.7 seconds. That’s because when I cache, the page takes about 0.7 pages to “create” and a little more to cache it. But once it’s cached, it takes zero cpu to for the next hour. That’s because instead of creating a page, the cached page is served for that hour; that takes zero CPU. For heavily visited blogs, caching saves CPU.

How can I tell if a plugin is a CPU hog?

You can add the code to your footer, deactivate the plugin and turn the cache off. Reload your page two or three times and see how much time it takes to load. Now activate the plugin, reload two or three times. See how much time it takes with the plugin activated.

If the page load using the plugin is much larger than without, that plugin is a hog. Turn it off. Find something else!

Couldn’t you give me something easier and more efficient to use?

Yes. This could all be made easier if I wrote you a plugin that did this:

• Recorded the time it took to generate the header.
• Recorded the time it took to exit from “the_loop”. (That’s Wordpress lingo for finishing delivering all the posts. Most templates deliver the sidebar after that.
• Recorded the time it took to finish creating the footer
• Displayed all that in a visible table at the end of the footer.

With this data, not only would you know how much time it took to run each plugin, but you’d also have data that would help you figure out if the cpu hogging plugin is something you use when loading content, creating the sidebar or generating the footer. This really helps because many, many of the CPU hogs are inefficiently written comments plugins. A few operate elsewhere. It’s easier to figure out which is which if you know where the cpu gluttony is taking place.

My Question to You

It would take me time to do this. How many people out there have problems with CPU resources? ‘Cuz if it’s a lot of you, I’ll be happy to write it (especially if after you use it, you blog about my mad plugin-writin’ skillz!)

So, how many of you want this? Only one? The it would be better if you just looked at the footer? Millions and zillions? I’ll write it tomorrow! Let me know.

What does the plugin do: This plugin lets the user create a blacklist of links which will be tagged “nofollow” after 10 days. The “nofollow” is added in the articles themselves and comments.

Reasons why you might want to use it:

• There may be site you once liked linking and giving page-rank juice, but now you’d like to make the links nofollow so the search engines count those votes for the site. You can now make all back-links to that link on posts older than 10 days “nofollow”. Once you do, you will stop contributing to that site’s high page rank. Any new links you post to that site will remain “follow” for 10 days.
• If you are running the “DoFollow” plugin, you may be getting regular site visitors who post borderline comments. They may not be bad enough for you to want to delete the comments, but you may want to “nofollow” that particular link, thus depriving it of link juice. Now you can. Those link will automatically nofollow when the post associated with the comment is more than 10 days old.

To use the plugin:

• Download NoOldSpamLinks Ver. zero.3
• Save it with the extension ‘.php’.
• Upload to your plugin directory; activate. The plugin is ready to accept links.
• To add links, visit your Wordpress admin panel. Click “Options”; find “NoOldSpamLinks” in the submenu. Click. You will be asked to add a link. Add one (the http:// is not required.) Click add.

As with all plugins: Back up your database before installing. (You should backup regularly anyway.) Also, if you have a problem using any plugin with recent installations of Wordpress, just delete the plugin from the plugin directory.

Let me know if you have any trouble.

So, you figured, “Charge me for links? I’ve been giving him free links! It’s my freely given links that gives him his PR=6! If he’s charging people, I want to take them all back!”

Hey, if you were a bit put out by Chow’s action, you are in good company!^{(1, 2, 3, 4 5, 6 and 7)}

Unfortunately, you may also have thought it was too much of a hassle to go back through your old blog articles and find all the links to that hungry capitalist blogger (or the Democrat or Republican!) So, you did nothing.

Well, no more!

Today, after a few conversations at forums, I was inspired to write first plugin. I call it “NoOldSpamLinks”; it’s for WordPress blogs. No, it’s not thoroughly tested. I finished it, and tested it at my blog. It works at my blog. It doesn’t do anything very fancy, so presumably it will work at yours.

(Would you like proof that the plugin works? Visit my first post. It’s more than 10 days old; you’ll see the ‘nofollows’. )

If you install NoOldSpamLinks in your plugin folder and activate it, it will change all links to JohnChow’s blog that are older than 10 days to ‘nofollow’.

I bet you are wondering why 10 days? Well, that’s my evil scheme!

By giving follows for a brief time, you can be sure that the your blog will be listed as linking to those domains on services like Technorati because they won’t be able to tell the difference between your link and other links. That will ensure a person who is looking for reactions to the blog post you link can find your post. But, if you prefer a different period of time, you can change that.

Don’t have anything against John Chow, but know another site you’d like to delink? You may also edit the domain names on your blacklist. Add or subtract, but do make sure there is at least 1 domain in the list. Otherwise, deactivate the plugin.

1. Get the plugin by clicking NoOldSpamLinks. The page should open: Copy the code and paste it into a text editor. Name it NoOldSpamLinks.php. Save.
2. If you wish to customize, find the number of days, and change it from 10 to the time you prefer. Find the list of domains, delete or add as you wish. Save the edited file.
3. Upload to your plugins directory and activate. You can check and see that all old links pointing to your list of domain names are now set to ‘nofollow’.

You know… it’s too bad this is a new blog with only 10 visits a day. I’d love zillions to learn of this, install it and see how fast a PR6 can fall!

Remember, I told you how to remove the Kontera ads automatically from sponsored ads by editing your Wordpress template? Editing the template lets you conveniently run Kontera ads on a blog runs sponsored ads. But, to use that trick, you need to create a “Sponsored” category.

Some advertisers won’t let you show the post is sponsored, which means you can’t let that category display on that sponsored post.

So, what’s a gal to do? Edit her template some more!

My knitting blog, which has been accepted in PayPerPost, used to show every tag including the “Sponsored” tag. But I changed that by looking up the appropriate WordPress template tags and coding a bit of logic to suppress display of the “Sponsored” category in a list of tags.

Below, you’ll find PHP code to create a string of tags that omits the category ‘Demo’ (rather than ‘Sponsored’); the tags will display this way:

Depending on the blog content, the context links can be really aggravating to blog visitors! If you don’t control them properly, you could lose regular readers or never attract them in the first place!

I thought about this problem and decided I would prefer to keep the Kontera ads out of the most recent blog articles, but allow them show up in archives. It’s a compromise that lets my regular subscribers get a less ad intensive experience, but shows ad links to visitors who wander to the blog by way of search engines.

So, I wrote some PHP code that lets me run Kontera ads, but:

1. Keeps ads out of all posts that are less than 20 days old.
2. Keeps ads out of all sponsored posts that are less than 60 days old. (At my knitting blog, sponsored ads are in “category 60″.)
3. Doesn’t slow down to load the Kontera Javascript when I’m not showing any ads at all!

If you visit the main page of my knitting blog you’ll see no Kontera ads. If you visit an older article in the archives you may see ads, (though not many because knitting doesn’t generate a huge number of words that get linked. If you want to see mega-Kontera linkage visit my diet blog!)

You can change dates and category numbers to match your needs and the TOS of any programs in which you participate.

So, now for the code!

This is the code you want to wrap around the part of your template that actually creates the content of the post. If your blog template in sell organized, you’ll find it in a file called “post.php” called from your main template file. The code to add is shown in red font:

Code:

<!--  close the span tags-->
<?php echo(<'/span>'); ?>


This is a footer code to speed loading in cases where the span tags are preventing Kontera ads from appearing on the full page:

<php
global $sponsored_supress_Kontera;

<!-- Kontera ContentLink™ -->
Stuff the javascript for the Kontera ads in here.
<!-- Kontera ContentLink™ -->
}
?>

Bonus tip: While searching for blogs that complained about not being able to control Kontera ads, I found this trick at John Chow’s blog: to avoid Kontera ads in the headings inside <h1>, <h2>, and <h3> tags or bold text inside <b>, and <strong> tags you can add this line to your contera javascript:

var dc_isBoldActive= ‘no’ ;

So, you might as well do modify the Kontera ad while you are adding the extra PHP code!

Do all of three things, and you can run Kontera where you like, and avoid a “junky” look!

Update:
I wrote the Kontera Control plugin to do this all for you. Now you can use pulldown menus instead of coding.