Over the weekend I finally had a chance to dive in to theme and plugin development.
Overall, I found WordPress to be very easy to work with, I didn’t find myself running into any dead-ends like I have with other platforms and CMSes. I thought I’d share my impressions in the form of a pros v cons list.

Cons

• WP is not model-view-controller framework, as far as I can tell from first brush there’s nothing MVC about it. I’ll admit, I’m not really sure how this would improve theme/plugin development or the application as as a whole. I do think that the WordPress codebase has a lack of structure and organization; MVC is a great way to organize a project.
• WP is not object oriented. With the exception of the database wrapper, I didn’t come across any objects. Poking around WordPress themes and plugins reveals a bunch of global wordpress functions, things like ‘add_filter() ,’ ‘wp_enqueue_script().’ Everything you’d need to do in wordpress is a function. Exposing everything as a global function leads to the potential problem of of introducing a bug by creating a function with the same name an existing wordpress function (minor annoyance) and again, leads to code that’s hard to follow and disorganized. Function names aren’t always clear, some functions accept a call back, other return a value, etc.
• WP does not use a template engine, all template variables, functions and statements are included as inline PHP tags. Inline PHP is impossible to read, hard to follow, leads to spaghetti and generates even uglier HTML. Additionally, template engines such as Smarty add useful features like robust caching options. I did find a plugin to add smarty support, may be worth investigating.
• I really feel like these first three issues are pretty close to PHP’s worst practices. The overall lack of structure tends to generate sloppy, hard to read, amateur-looking code; the sort of thing that RoR snobs like to make fun of.
• Finally, I suspect WordPress might be highly inefficient (but I haven’t done the research). Specifically the way plugins are allowed to add handlers and filters to various points in the application workflow seems like a problem. If every plugin has to be scanned for on every page load…well that’s just not going to scale well. Each installed plugin (hypothetically) increases processing time.

Pros

• In spite of, or possibly because of issues I mentioned, extending WordPress is fairly simple and easy to pick up.
• The documentation at wordpress.org is pretty great! On par with php.net‘s own documentation.
• With such a large userbase, almost every plugin you could possibly want is already written for you.
• It’s stable. It doesn’t go down randomly. It’s not buggy.

Admittedly a lot of the shortcoming I found are based on a lot of assumptions and only a basic knowledge of WordPress. Also, I will concede that “your code is ugly” is a fairly superficial criticism that doesn’t inherently mean anything. So, in conclusion, I am not anti-wordpress. I like it as a very-extensible blogging platform, but I’m still a little skeptical about is pontential usefulness as a general-purpose CMS or some sort of website framework.

If you’re a wordpress guru, I’d like to hear you input. Tell me why I’m wrong.

To implement these rules:

1. Replace “mobiledirectoryhere” with the path to your mobile site. If your mobile site is located in a subdirectory, use the full URL (including “http://”) and you can omit the first RewriteCond.
2. Then copy & paste the ruleset into the site’s .htaccess file or the main apache configuration.

Rationale

Since the last time I wrote about mobile browser detection and redirection in 2009 the mobile device landscape has changed once again. Smartphones dominate the mobile browsing landscape and feature phones are almost not existant in server logs.

The old redirection rules I posted attempt to redirect every mobile phone under the sun. At this point in 2011, it’s probably safe to completely ignore ancient phones and simplify your Apache rules in the process.

Since my original posts on mobile redirection in .htaccess files I’ve gotten some comments and emails asking for step-by-step guidance on exactly how to “install” these rules. I hope this post will answer some of those questions.

Before you continue reading, if you have php installed on your server, you may want to consider Andy Moore’s php based detection solution.

The Basics

First off, some basic requirements. You’ll need:

• Apache/Linux Hosting. Microsoft’s IIS has a completely different method for handling this sort of thing.
• FTP access.
• Apache mod_rewrite enabled. Depending on the type of hosting you have, it may be difficult to determine if you have this module installed and it may be impossible to enable if you don’t. If the steps below simply don’t seem to work, there is a good chance you don’t have mod_rewrite installed. Ask your tech support.
• Mobile site in a subdirectory, eg. www.yourdomain.com/m/. This set of rules I’ve posted will not work with a mobile subdomain.

The Steps

1. Download mobilerules2.1.txt.
2. Open the file in your favorite text editor, replace the 2 instances of “mobiledirectoryhere” (without quotes) with the directory name you are using for your mobile site. Save it.
3. Open FTP client, enable ‘view hidden files’ – files beginning with a dot are hidden on linux. This option is typically buried in a “view” menu or something to that effect. Results may vary.
4. Navigate to your site’s webroot (probably ‘htdocs’ or ‘www’).
5. • If there is already a .htaccess file present in the directory. Download it, open it in your favorite text editor. Copy & paste the contents ofmobilerules2.1.txt into the file. Save it, upload it.
   • If there is no .htaccess file present. Upload mobilerules2.1.txt as is, rename it to .htaccess.
6. Your Done. Test it from a mobile device.

If you have any questions please leave a comment.

Note: This script treats all opera mini, iphone and android the same as other phones and browsers. Leave some comments if you’d like me to address this.

To scale at Digg they followed a set of practices very similar to those used at eBay. No joins, no foreign key constraints (to scale writes), primary key look-ups only, limited range queries, and joins were done in memory. When implementing the comment feature a 4,000 percent increase in performance was created by sorting in PHP instead of MySQL. All this effort required to make a relational database scale basically meant you were using a non-relational database anyway. So why not just use a non-relational database from the start?

[via High Scalability]

SELECT name FROM artists ORDER BY TRIM( LEADING "a " FROM TRIM( LEADING "an " FROM TRIM( LEADING "the " FROM LOWER( name ) ) ) )

[thanks metafilter]

Unexpected side effects of some new code that tries to keep data geographically close to its owner caused another data center in Europe to become overloaded, and that caused cascading problems from one data center to another. It took us about an hour to get it all back under control.

This sounds exactly like the types of bugs I create. The fact that Google makes these sorts of mistakes, even though they do a lot more testing and have bigger teams, etc; makes me feel good about my programming skills.

My original post was based on a PHP script by Andy Moore. It’s worth noting that he has continued to update his script and now has a fancy little generator to help you create a PHP based redirect ruleset. Check out detectmobilebrowsers.mobi for more info.

His solution will probably work for a lot of applications, but there are 2 main reasons I prefer using Apache’s rewrite rules to redirect mobile browsers:
1) Application independent. By putting the rules in the root .htaccess file you can easily redirect traffic across multiple directories, independent of any webapp that might or might not be running in those directories.
2) Faster. Placing the rewrite rules in apache’s httpd.conf file is potentially faster, than running the regexp in a php script for every request.

Enough of that, here’s the updated ruleset.

# don't apply the rules if you're already in the mobile directory, infintine loop
# you'll want to test against the host if you're using a subdomain
RewriteCond %{REQUEST_URI} !^/mobiledirectoryhere/.*$
# if the browser accepts these mime-types, it's definitely mobile, or pretending to be
RewriteCond %{HTTP_ACCEPT} "text\/vnd\.wap\.wml|application\/vnd\.wap\.xhtml\+xml" [NC,OR]
# a bunch of user agent tests
RewriteCond %{HTTP_USER_AGENT} "sony|symbian|nokia|samsung|mobile|windows ce|epoc|opera" [NC,OR]
RewriteCond %{HTTP_USER_AGENT} "mini|nitro|j2me|midp-|cldc-|netfront|mot|up\.browser|up\.link|audiovox"[NC,OR]
RewriteCond %{HTTP_USER_AGENT} "blackberry|ericsson,|panasonic|philips|sanyo|sharp|sie-"[NC,OR]
RewriteCond %{HTTP_USER_AGENT} "portalmmm|blazer|avantgo|danger|palm|series60|palmsource|pocketpc"[NC,OR]
RewriteCond %{HTTP_USER_AGENT} "smartphone|rover|ipaq|au-mic,|alcatel|ericy|vodafone\/|wap1\.|wap2\.|iPhone|android"[NC]
# put your rewrite rules here


Text Version

As you can see, the user agent list is a fair bit less verbose. I’ve been testing the ruleset on a very busy site, based on over 250k mobile site hits this set of rules is causing a lot fewer false positives, while not missing any significant number of mobile browsers.

Run-time languages don’t have compilers.