OhRyan.ca

About a month and a half ago The Big Webshow featured WordPress creator Matt Mullenweg, listening to the interview it became really clear that WP is trying to position itself as a website “operating system.” While there are probably other platforms much more capable of the task, WordPress’ ubiquity is sort of pushing it in that direction regardless. Since that interview I’ve been meaning to take a closer look at WordPress.

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.

The following set of rewrite rules will redirect all Android, Blackberry, iOS, Windows and WebOS devices to a specific mobile directory on your website. Additionally, it will redirect Google’s mobile crawler – according to Google search spam czar Matt Cutts this is perfectly acceptable and even somewhat encourage.

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.

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]

When ordering lists of names or titles it’s sometimes desirable to exclude articles or other words from the order clause (eg. you want “The Burning Hell” to show up before “Great Lake Swimmers” in a list ordered by name). Early on in my career I must have assumed it was not possible and never bothered to look into again because I don’t recall ever ordering a list like this.
Anyways. Here’s how you do it:

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

[thanks metafilter]