Category Archives: WordPress

mail vs. wp_mail

Posted on by
Reply

I was working on my wife’s WordPress site tonight after she told me her contact form wasn’t working.  I had been using the SMTP settings in php.ini to handle email across all the websites I support.  But, I decided to stop using that because all emails were be coming from the same account, regardless of domain.

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.

Wassup Returns

Posted on by
Reply

Back in March, when I was just switching to my, then, new IIS server, I had some issues with a plugin called Wassup.  More specifically, the plugin was causing some major performance issues and caused my blog to take several seconds to load.

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.

WordPress Upgrade

Posted on by
Reply

As anyone remotely familiar with WordPress 2.7 will know, 2.7 introduced a very cool feature: the automatic upgrade.  This is cool for a few reasons.  First and foremost, it prevents the blog owner from having to manually copy the new version over to their web server.

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.

Wassup

Posted on by
Reply

So, it seems (after much trial and error) that one of my plugins was the cause of my speed issues.  Wassup is a statistics plugin, and was causing major performance issues.

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.

Speedup WordPress on IIS 7.0

Posted on by
Reply

Here is a nifty article on speeding up WordPress.  I’m still not terribly thrilled with the performace on IIS.  I’m not sure if it’s the PHP Engine or the database backend now.  I’ve noticed that php-cgi.exe spikes at 100% when viewing some pages.

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

MyISAM vs. InnoDB

Posted on by
1

So, recently, I’ve switched my blog (and the whole domain, consequently) to IIS.  I used to have my domain hosted over at Host Gator (highly recommended if you don’t have the resources to host your own content), but recently have switched to IIS running 2008 x64 on a virtual guest at work.  So far, I like it.

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… Continue reading →