Dugg? No problem with WordPress

An old post I wrote on a spoof MMORPG named “Outside” was Dugg not too long ago and I was quite pleased to find that my server and the blogging software (WordPress) that I use was handling the load extremely well. Quite obviously I was getting more hits in a day than entire months:

Blog stats after getting Dugg


My setup is a Virtual Private Server (VPS) with 256MB RAM hosted at SliceHost and this blog is served off Nginx and PHP FastCGI processes to handle PHP scripts. The wonderful (because it just works and is really easy to setup) WP-Cache WordPress plugin keeps a cache of pages that’s swept at logical times (i.e. whenever there are any updates or comments).

I may be a Rails/merb fanboy, but this awesome piece of blog software that can stand up to the Digg Effect with ease is great. WordPress FTW!

BarCamp Singapore Jan 2007

I just got back from BarCamp Singapore a few hours ago. I was only vaguely familiar with the Rules of BarCamp prior to this, and actually only found out about the event from Choon Keat (of RssFwd fame - check it out if you haven’t already) 2 days ago.

Anyway, props to the organizers for putting this together (especially the free BarCamp t-shirts from Yahoo!). Personally, I felt the icebreaker game took up too much time that could have been used for the sharing sessions - the tech track of sessions were crammed up towards the end of BarCamp.

BarCamp Singapore logo


Notably, Harish Mallipeddi, who interned at Bezurk for a couple of months, shared with us an introduction to Django together with some working code on a site he is working on. I didn’t know a whole lot about Django before and was impressed that there is a “free” admin application for Django applications. We (Choon Keat, Harish, and I) had a small debate over Django’s templating system (briefly, Django has it’s own templating system for its views, whereas Rails ERB is basically Ruby code mixed in HTML). To this day I am still convinced that PHP is already a templating language despite my old Smarty card-carrying days. Relating back to the Django templating system, Choon Keat and I didn’t like the idea of having to learn to use a templating language when the base language itself (Ruby or Python) would suffice. Obviously Python syntax wasn’t suitable for web designer consumption so Django had to come up with its own templating language.

Michael from PetrolWatch showed us some flashy scriptaculous effects on his site and demoed the Ruby on Rails-inspired CakePHP. It’s a nice framework if you had to use PHP and performance is a concern (it’s true, Rails apps run more heavily than PHP scripts, and the difference in performance is very clear in servers with minimal resources). But the lack of a good testing framework was discouraging. Still, I must say I’d have used it (or a similiar framework) if Rails didn’t exist or if I was tied to using PHP for web development.

Choon Keat showed the non-believers the power of Rails’ script/console as well as the flexibility of Ruby in allowing developers to make their own extensions to existing classes (aka “who needs hooks from God?”). I probably should have stepped in and showed some basic Rails migrations stuff that would have impressed (hopefully) the Django and CakePHP fanbase (all 2 of them) - but my laptop was running out of battery (and I was shy).

Oh and I saw a good number of Macs there, and at least 3 laptops running a Linux distro of some sort. Cool.

Ryan Boren, one of the developers of WordPress (which powers this blog), has an interim update on what’s going on behind the scenes in WordPress development and the new features in WordPress 1.3. Pages, themes, enclosures, and a richer plugin API are some things to look forward to. (2)

LiveSearch hack for WordPress

I found this old link on LiveSearch that I’d wanted to implement here but never got around to doing so until now. It’s really quite a bit of a hack right now, with most of the code coming from the LiveSearch page on the Bitflux Blog wiki and with direct calls to PHP’s MySQL functions to get it to work with WordPress.

Instead of replacing the default WordPress search box, I decided to add another one instead (that you can see right now on the left just below the “standard” search box) and label it a “LiveSearch” box. I do this because livesearch.js seems to crash Firefox randomly on occasion (as mentioned on Bitflux blog). Besides, it’s hardly fully done, as it currently only does simple SQL LIKE matching on post titles, and the CSS is somewhat inelegant.

Anyway, what I did was to add livesearch.js to the WordPress index template, and added the LiveSearch form.

<form id=”livesearchform” method=”get” action=”http://blog.codefront.net/livesearch.php”>
<input autocomplete=”off” id=”livesearch” name=”q” onkeypress=”liveSearchStart()” type=”text” />
<input id=”submitted” name=”submitted” value=”yes” type=”hidden” />
<div id=”LSResult” style=”display: none;”><div id=”LSShadow”></div></div>
</form>

Next, I hacked out a livesearch.php script (source listing for livesearch.php) that performs the relevant query on WordPress’ wp_posts table (may be differently named on your installation) and returns an XML document containing the matching post titles and their URLs. The tricky part was to map the matching post titles to their URLs (since I’m using SEO-friendly permalinks). All it took was to include the wp-blog-header.php file and have the get_permalink(ID) function return the correct URL.

The other tricky part involved preventing searches in the LiveSearch box from going to the livesearch.php page, because that’d return an XML page that the user would hardly know how to proceed from. Adding a hidden form field was a quick hack, but it works just fine and redirects the user to the search results page that WordPress spews.

// If the LiveSearch form was actually submitted (as opposed to being requested
// via a XMLHttpRequest, we redirect to the standard WP search page.
if( isset($_GET[’submitted’]) && $_GET[’submitted’] == ‘yes’ ) {
header(’Location: ‘ . get_settings(’siteurl’) . ‘/?s=’ . $_GET[’q']);
exit;
}

Well, that’s it for now. It feels really like a hackjob but it works just fine. Perhaps someone could roll this up into a WordPress plugin or we could get LiveSearch as a feature in WordPress in future (as Serendipity already does).

MT Friend or Foe hack

Ever since Movable Type started to have the comments redirection feature (since version 2.66), comment authors’ URLs have been redirected via a simple redirection script that prevents them from appearing directly on blog entries. This (partially) solved the problem of comment spammers because links from comments no longer benefit from backlinks that add to their PageRank. However, legitimate commentors also have their URLs redirected, which to me seems just quite a bit unfriendly.

Neil Turner has worked around this with his aptly named Friend or foe hack for MT. A simple but still neat bit of PHP (and a good example of MT’s excellent template tags). If you use MT and want to “reward” your legitimate commentors, you won’t want to miss this.