I’ve been knee-deep in WordPress the last month or so, building the new theme for contexts.org (mostly) from scratch. (One caveat to that: I borrowed the comments.php from the Prologue theme. That’s my least favorite part to theme, for some reason.) Ultimately, I guess I do like WordPress. I was able to do what I wanted to do, after all. However, after awhile I began assembling a list of gripes about WP.
The primary theme running through all my gripes is inconsistency.
For example, if you want to get a path to a directory, do you end with the slash or not? The TEMPLATEPATH constant gives you /path/to/wp/wp-content/themes/yourtheme. So no slash. ABSPATH gives you /path/to/wp/, slash included.
Say you want the title of a particular post, do you want it to echo or do you want PHP to just return the result and leave it to you to print? Well, WP has two functions, one for each of these occassions: the_title() echos the title, get_the_title() just returns it.
Now you can question the wisdom of creating multiple functions just for this purpose, but it’s generalizable, right? Just add “get_” to the front of the function and it works?
the_content() and get_the_content()? Check.
the_permalink() and get_the_permalink()? Oh, no. It’s get_permalink() there.
What about the_date() and get_the_date()? No, there is no get_the_date() because the_date() takes an TRUE/FALSE argument to decide whether or not it should echo.
And sometimes there’s no choice at all: previous_posts_link() has no “don’t echo” option, so you have to use the ob_start()/ob_get_contents()/ob_end_clean() trick.
And then there’s categories vs. tags. This is a purely conceptual distinction, right? The underlying data structure is pretty much identical. Of course, the functions behave completely differently. the_tags() and the_category() take completely different arguments even though you’d expect them to be almost identical. ((Ok, categories can be hierarchical while tags cannot, so that would justify an extra argument for the_category(), but they’re more different than that.))
The point isn’t that any of these are all that awful on their own, it’s that they make even the simple act of theme development—let alone plugin development—a pain. Every function requires a lookup because there are no safe generalizable rules to learn, at least none I can figure out. Add in the fact that the documentation is itself incomplete and inconsistent and you have some real headaches in store for yourself.
This inconsistency is completely consistent, by the way, with PHP itself: strip_tags() vs. stripslashes(), etc. I recently read an article by Rasmus Lerdorf, creator of PHP, where he explained some of these things:
As to function naming itself, I tended to steal/borrow ideas from other languages and APIs I was familiar with. This means that PHP has functions such as strlen( and substr(), which would look silly if written as str_len() or sub_str(). I added things like stripslashes(), which, because of the length, is often written as StripSlashes() to make it easier to read. At the same time, I mimicked low-level database APIs, with functions such as msql_connect()—miniSQL was the first database to be supported by PHP—which used underscore naming. People familiar with these various sources were quite at home with the naming in PHP. PHP was never so much a standalone language as it was an interface between the Web server and all the various back-end tools you wanted to hook into the Web server. Consequently, when people look at PHP today as a standalone language without taking its context into account, it can appear somewhat inconsistent.
(Here’s the link, but it’s currently dead. Thanks Oracle! And thanks Google: it’s still in Google’s cache.)
In other words, there’s a social history of the language, and the languages it’s based on, that explains the “somewhat inconsistent” behavior. The same is true of much of my gripes with WordPress, I suspect. Tags were originally only available via a plugin, so I suspect that has something to do with the inconsistencies between how tags vs. categories are treated. And what if, in the next release of WordPress, the developers decided to go through and purify everything for maximum consistency? A lot of themes and plugins would break, and that would bad, too. It’s not like the developers are idiots, it’s just about picking some priorities over others.
A few episodes back, FLOSS Weekly interviewed David Heinemeier Hansson, the creator of Ruby on Rails. He claims he took the complete opposite approach with Rails: start with a clear vision of how things should work and then consistently apply that vision throughout the whole system. Sounds pretty damn appealing to me right now. Unfortunately, I have no real reason to learn Rails right now. I have a WordPress blog, my job is running a WordPress MU site, and I’m just now getting into a side project using Drupal, which I am looking forward to. Plus, oh yeah, I’m trying to finish a dissertation in sociology and all this is officially “just a hobby.” So, PHP it is for now.