So, I started digging around and there is a plugin for WordPress called, aptly enough, WP Mail SMTP.  This plugin is great because it allows me to set SMTP settings for individual sites, and it intercepts wp_mail() calls and sends them with the SMTP settings you give it.

This turned out to be my problem.  The theme my wife uses has a built-in contact form, which was hard-coded to use mail() to send from the form.  This no longer worked for me after I removed the SMTP settings from php.ini – even with the WP Mail SMTP plugin.

I started looking around at what exactly wp_mail() required to function.  Here’s what the WordPress Codex says about what to pass it:

wp_mail($to, $subject, $message, $headers, $attachments);

Looks oddly like what the PHP Manual says about mail():

mail($to , $subject , $message, $additional_headers, $additional_parameters);

I tried changing the hard-coded mail() to wp_mail(), and there you go.

Well, now three months later, they seem to have addressed this issue.  From a post on their support forum (quoting a member there named vlogoution):

I had this problem too, and what’s causing it are the several calls made by Wassup to php’s gethostbyaddr function which does the host lookup. The problem is at its worst if the function can’t find the host name (ie. on a local LAN). To solve it, I basically changed every call to gethostbyaddr in wassup.php to call “gethost”, which I’ve included below. This still uses gethostbyaddr, but it caches the calls on each run with a local cache and by using memcached (if enabled and available with the object-cache.php dropin). Ideally, it would probably be better to code an nslookup (for windows) or host call for linux, but for now this is working for me just fine. Another way would be to cache/store the host lookups in the database for a period of time. Hopefully the author of Wassup will look to include this patch (or some even better variation) in a future release. I believe the poor performance of this one function call is holding back the high potential of this plugin.

(I placed the function just below the “global $wp_version;” statement in wassup.php:

function gethost($ip) {
//much faster cached replacement for gethostbyaddr - http://us3.php.net/gethostbyaddr
global $dns_cache;
if ($dns_cache[$ip]) {
return $dns_cache[$ip];
} else {
if (!$dns = wp_cache_get( $ip, 'dns', 216000 ) ) {
$dns = gethostbyaddr($ip);
wp_cache_add( $ip, $dns, 'dns', 216000 );
}
$dns_cache[$ip] = $dns;
return $dns;
}
}

And so it seems that they have implemented the patch (or some variation thereof) mentioned above to fix the issue.  I’m happy to report that I’m now running Wassup again (and am pretty happy about it).

Full post in the support forum.

In any case, it’s quite annoying when you administer four blogs and all but one detect the updated version.  You see, WordPress is on a 12 hour update-check.  So, you could conceivably be forced to wait for up to 12 hours for your WordPress installation to detect that it needs to be upgraded.  Not anymore!

If you have access to your raw database, you can browse to the wp_options table.  In that table will be a row called update_core.  Delete this row.  Now, I will give this disclaimer (as any good technical advice does): BACKUP! before you do anything to your database.  After you’ve deleted said row, refresh your dashboard (you don’t even have to log out and back in) and look at the top for your upgrade notification.

I’ve seen some message boards that suggest altering this row.  This is bad for a number of reasons, not the least of which is the fact that the update_core data itself is serialized and you can break your installation if you screw up.

Now, I say all of this to say this: WordPress 2.8 is pretty cool.  Check here for a complete list of the new features.  Now, an excerpt:

On June 10th, 2009, WordPress Version 2.8, named for noted trumpeter and vocalist Chet Baker, was released to the public. For more information on this enhancement and bug-fix release, read the Development Blog Announcement and see the Changelog for 2.8.

I like Wassup because it provides good data, but I’m sad to say that I have deleted it.  Now, you can enjoy my blog without waiting 15 minutes for a post to load.

Anyway, here it is.

It gives two options for “speeding” things up: IIS’s Output Caching and WP Super Cache.  Each have their downsides, but maybe one will work for you (and me).

However, I was disappointed to find that WordPress performed poorly at first.  Then, in my tinkering, I figured out (dumb luck, eh?) that if I switch the tables in the WP database from InnoDB to MyISAM, performance increased noticeably.  I’m not sure if this was the “real” reason WordPress was sucking it up, but it seemed to fix it immediately.

Edit March 10, 2008:

I’m not sure how much of a performance boost this gave me.  I’m noticing a slowdown again, so I’m not sure if this did anything at all.  It looked like it was helping when I first made the change, but now I can’t be so sure.  Anyway…

For Michael’s benefit, this can be accomplished by downloading and installing the MySQL GUI Tools.  Open MySQL Administrator and authenticate as root (or as the database user that has full administrative privileges).

In the lefthand navigation pane, select “Catalogs.”  This will open below it a list of the databases you are currently running.  Select the appropriate database, and the table structure will open up in the right side of the window.

Now, you will notice than my “Engine” column already says “MyISAM.”  This was not always the case.  If you want to change the engine, double click a table.

Once you’ve opened the Table Editor, there are three tabs.  You’re looking for the “Table Options” tab.  Here, you can change the Table Engine to something else.

Now, don’t you feel better?