WordPress quickly became the blogging software of choice for bloggers everywhere, unseating MoveableType the previous title holder. It did this much because MT was too difficult for most to use. It’s templating system and class structure was much more elaborate and thus complicated. It didn’t help too that it was written in Perl, a programming language with very concise sytanx like $foo =~ /[Ff]uck[!].Off?/ able to scare off all but the most bold programmers. WordPress on the other hand, can be picked up by anyone with limited programming experience in an afternoon’s time. The problem is, however, that the developers of WordPress are unfortunately amatures themselves, with little or no concept of object oriented (“OO”) design. WordPress 2 is technically OO, but the class structure is a joke and essentially one big container. There are a handful of mega-classes like WP and WP_Query, which drive the entire application. All do a fine line of bluring the difference between function and object oriented code. Everything else is functional and relies on a global variables such as $wp, $wpdb, and $wp_query, which if anything should be a singleton instances, local in scope. Trying to extend anything is impossible without modifying their code. Their idea of templating is doing “includes” on different php files with formatting and additional logic. There’s no seperation between the presentation layer and the data layer.
Bluring the line b/w OO and functional programming, look at WP::query_posts
function query_posts() {$this->build_query_string();
query_posts($this->query_string);}
and the global function query_posts
function &query_posts($query) {global $wp_query;
return $wp_query->query($query);}
I don’t mean to lambast the WordPress developers personally, but this is just humorous. It doesn’t utilize any constructs of PHP designed to handle this kind of thing (E.g. statics and singletons) — and that’s only if you support their overall flow/execution. Granted static methods were introduced in PHP5, but static variables have been around since PHP4.

PHP5 OOP must haves
We’re always taught when learning OOP to be a strict as possible when declaring methods/members as public, private and protected. For some reason though, when programming PHP we’re in this mode that since it’s a scripting language “let’s not adhere to better practice”. Well, atleast I kind of fall for this and going by all of the other peoples code that I’ve read it’s not too uncommon. The project I’m working on has reaffirmed that there is no excuse for sloppy programming.
When writing OO PHP5, always start by making all properties private or protected. Declare the overloading/accessor methods for __set, __get, and __unset. Throw as many exceptions as possible and things will debug themselves with little or not effort on the programmer.
Asside from protecting your privates, this method aids in profiling your code too. Since by moving your assignments and gets into a function call, they can now be counted by a PHP profiler such as apd.