An Exercise in WordPress Integration, or Why WordPress Sucks

blake — Tue, 08 Dec 2009 08:23:50 +0000

I'd like to prefix my upcoming rant with the fact that WordPress is good at what it does: making basic blogs and publishing content. I use it, many other people use it, it works. Heck, I'm using it right now. But from a technical standpoint, WordPress sucks. I'm going to relate my experience here trying write a quick function to store post output to a file, to be used by a separate application on the same server.

I started off to write a function (let's call it a caching function for simplicity) that stores some HTML from the most recently published post. Sounds easy enough. I should be able to just put a function into the functions.php file of the custom template set I'm using. That's seems to be where the "userland" custom functions go.

So I check the function reference first. Hey, wp_get_recent_posts(). Looks promising, so I give it a shot. It goes ahead and gets the most recent post just fine. Things are ok so far.

A problem appears

Now, I want to output the post exactly as it would appear in the blog, and save that output to a file on disk. Surely there's a basic function that will output a post's content? You know... take the post_content field from the database record and format it properly? Suddenly, the skies darken. Evil laughter booms out. Ha ha ha! WordPress mocks the folly of simplistic functional thinking!

The template files use functions like the_content() and the_title(). Just in case you can't tell from the excellent naming scheme, these actually produce echoed output. Checking out the_content(), we see it dutifully calls get_the_content(), then runs a couple of lines of formatting stuff on the results. So how about using get_the_content() for my caching function? I could run the other few formatting bits manually after that. Should be ok, right? After all, the doc comment for get_the_content() says the following:

/** * Retrieve the post content. *

So, I can go ahead assume it simply retrieves the basic post content then? Ha ha. NO. WHY WOULD IT DO THAT? Instead, it takes a bunch of globals that get set who-the-hell-knows-where, runs through a bunch of crap seemingly unrelated to the content of a post, and does a whole lot of textual modifications to some kind of content. Reading through the function is like jabbing red-hot fire pokeys into your eyes. Here's a portion of it:

>> show as plain text

PHP:



$content = $pages[$page-1];


if ( preg_match('/<\!--more(.*?)?-->/', $content, $matches) ) {


$content = explode($matches[0], $content, 2);


if ( !empty($matches[1]) && !empty($more_link_text) )

$more_link_text = strip_tags(wp_kses_no_null(trim($matches[1])))
$hasTeaser = true;
}

$pages is some kind of global that doesn't seem to have any relation to a post. Then apparently we're looking for HTML comments of , and replacing them with... well, something. I'd hate to think what would happen if I ever wrote a post with an HTML comment in it that happened to hit on whatever random content markers WordPress has decided to use. (Oh wait! That just happened to me while I was trying to publish the above code fragment!) I didn't even bother to look into things like wp_kses_no_null. It probably involves dark rituals with live chicken sacrifice. Why is there so much going on in a function called get_the_content()?

In the end, it seems that get_the_content() will eventually get the content of a post, but only if you set a half-a-dozen or so globals before you call it. And what the hell post is it even getting?

"The Loop"

Digging further, it's clear that the template functions for output are all like that. They don't take any kind of parameters; they just operate on globals! There's no way to take the post data that I just retrieved with wp_get_recent_posts(), and format it using these functions. You have to be in "The Loop" in order to do that. And "The Loop" sucks. It's not a catchy, easy-to-use method of handling posts, despite WordPress's efforts to pass it off as something neat or fun. It's a mish-mash of global functions with random naming and variable schemes (incidentally, just like the rest of WordPress). You can only use "The Loop" if you're accessing WordPress in a "normal", web-requested-and-template-loaded kind of way. It doesn't work if you're outside a template file (such as in functions.php before a template gets loaded).

So back to square one. Unfortunately, it appears that if I want to have the regular blog-formatted output, I need to harness "The Loop" somehow, and clearly you can't do that on your own (ie. outside of a template file) without knowing about every global variable in the system.

After some quick googling, I came across the query_posts() function, which you can use to set up "The Loop". Reading the documentation on it, you can find this little gem:

"The query_posts function overrides and replaces the main query for the page. To save your sanity, do not use it for any other purpose."

To paraphrase: "We've created a public API function that is pretty much useless except in a very specific page-dependent situation. Please enjoy how useless it is. But don't use it."

The fact that there is a "main query" for a page is another indicator of just how global-happy WordPress is, and that in turn gives you an insight into why it has so many security holes. How do you keep track of so many globals across so many functions?

A solution... sort of.

Fortunately, the query_posts() doc page links to the WP_Query docs, which is marginally more helpful, and provides the path for a solution. Using WP_Query sets up the wacky global stuff necessary to use "The Loop", which means we can hack our way through to getting some formatted post content. While technically feasible, you have to emulate a bunch of $_REQUEST parameters to the query() method. I ended up with this:

>> show as plain text

PHP:



function cacheMostRecentPost()


{


$featuredPosts = new WP_Query();


$featuredPosts->query('showposts=1');


while ($featuredPosts->have_posts())


{


$featuredPosts->the_post();


ob_start();


//do output with stuff like the_title() and the_content()


$str = ob_get_contents();


ob_end_clean();


//write $str to cache fragment


}

}
//set up hooks for this file when a post is changed or deleted
add_action('save_post', 'cacheMostRecentPost');
add_action('deleted_post', 'cacheMostRecentPost');

So despite relying on a specific set up of incoming HTTP parameters (as a string) for the most part, at least you can pass paramters to the query if you know the right ones. In this case, "showposts=1" seems to be the total number of posts fetched, and they appear to come back ordered by posting date, most recent first. This works for what I want it to do, but guess what? It doesn't work if you try to run it anywhere that's not one of those action hooks, because "The Loop" overwrites all the globals necessary for doing output later! So I can't use that function, say, at the top of the index.php template file if I wanted to. If I do, thanks to the overwritten globals, WordPress decides that I actually want the "Archive" page instead of the index page(!), and switches templates accordingly. So while I achieved my goal of being able to cache a post to a file with this function, it's certainly not portable, and it's certainly not elegant.

Wharrgarbl

The entire code flow is mind-boggling. Basing the output functions around a bunch of globals reminds me of code someone would have written in PHP 3 a decade ago, or something a very inexperienced programmer would write. Definitely not something you would expect in an application used by what is probably now millions of people. What's wrong with having some data fetching functions, and some output functions? You could, and I know I'm talking crazy here, but you could fetch some data, and then pass it to the output functions. Then (bear with me here), you could probably fetch posts (or whatever) at any time, and get some formatted output at any time, without overwriting some important global that might be used later in the code flow. Revolutionary, I know. Sorry if I went too fast on that. I'll repeat it louder and/or slower for any WordPress core developers that happen to be reading.

So, WordPress? How about something like:

$postObjects = getRecentPostsByDate(1); $output = formatPostContent($postObject[0]);

The mere concept of having individual posts exist inside their own little encapsulated world would make the APIs a hundred times more useful (and easier to understand). You could even keep those crap the_title() and the_content() and the_something_lol_naming_scheme_lol() functions if you wanted. Just make them take parameters. Better yet, put them inside a formatting object, or even the post object itself. $post->the_content() would still work, but it would have context!

The reason this gets me worked up is not that it's so frustrating to use (although that helps). I've had to deal with a lot of frustrating code in my career. It's more the fact that it's this kind of thing that gives PHP programmers a bad name. The code is just bad. The design is random. The API functions are random. The naming schemes are random. Functions don't do what their name (or their doc comment) indicates they should do. Integrating wordpress into another application or site is next to impossible (try it, I dare you), and the other way around, integrating another application or site into wordpress is much more difficult than it should be. Global usage is rampant and ridiculous to follow.

You don't have to look any farther than a single WordPress code file to understand why there have been so many security holes over the last couple of years. And there's a lot of PHP code out there that's the quality of WordPress, or worse.

To re-iterate my opening, if you don't need to get anything special out of it, WordPress does the job. They've filled their market niche well, and it's encouraging that development is ongoing and releases occur often. I've worked with it on occasion over the last few years, and the improvements are obvious, interface-wise especially, and to some extent code-wise as well (the WP_Query object is a step forward). But working with the code is not fun. Even modifying the template files is an exercise in counter-intuitiveness.

I'm sure there are reasons the code is what it is at this point, and I'm equally as sure I don't have the full picture to go with my condemnations. I guess I should just be thankful that I don't have to maintain it.

.Net Mocking Frameworks – Capability Comparison

morgan — Sun, 26 Apr 2009 06:04:40 +0000

I have a couple years of experience of TDD under my belt, but it's only recently that I've felt like I am a relatively decent practitioner of it. I attribute this to forcing myself to take the plunge into mocking, and the knowledge of patterns and loosely-coupled design that I've gained from it.

You see, I work on a pretty large and complex ASP.Net webforms product, and tests were introduced late into the development cycle of the initial release. We favored integration testing with real data sources over actual unit tests. While I did write some tests, I knew that our product was not very testable by design.

Recently we put together a public facing API for programming against the product, that we were able to build from scratch. This was a natural opening to apply test driven practices and start building unit tests from the get-go. Due to the service oriented nature of the data that the product consumes, I soon found myself realizing that I needed mocks in a big way. I gritted my teeth and dove head-first into Rhino.mocks.

Several weeks down the road, it was obvious that Rhino just isn't right for our environment. The learning curve is too steep to win quick success with all our developers (and therefore by extension, our project managers). I began looking for another framework.

This led me on a frustrating research mission to find the differences between frameworks without actually trying them all. Due to a lack of in-depth comparisons of the actual capabilities of the various mocking frameworks, I've ended up putting together this chart. I'm hoping it helps some people. My interest is very high in this arena, so I will be keeping it up to date.

(Just for interest's sake - we ended up choosing Moq, due to the ease of the API. The philosophy of Moq jives perfectly with our relatively fast-paced and efficient development environment. We don't care about purism - we care about getting it done.)

.Net Mocking Framework Comparison

Other Notes

Rhino

Mature, flexible framework

Built on Castle DynamicProxy

Very large array of "syntaxes" leads to extreme confusion when writing tests - documentation mixed for the new 3.5 fluent syntax

Large community of users

Moq

New(ish) framework also built on Castle

Requires .Net 3.5 due to its lambda heavy syntax

No distinction between mocks & stubs, record/playback (joy!!)

Responsive and active developers and community

NMock2

Uses "magic strings" for mocking - makes tests brittle

Confusing product version #'s - Nmock2 is actually a new team that picked up NMock and continued development

TypeMock.Net

Powerful framework that uses redirection at the IL level to create mocks

Expensive ($450/license)

TDD Purists argue that the power of it leads to poorer design

The above observations were gleaned from many web pages, documentation repositories and blog posts, and reflect my limited understanding of each framework. There may be errors. If you think I'm wrong, or you can think of other capability aspects that I've overlooked, please let me know!

Grandmaster Indeed

morgan — Fri, 14 Mar 2008 07:53:04 +0000

Catching up on my reading tonight and I ended up reading this post from end to end. It's a fairly interesting article, and takes a very long road to rehash the old adages of "if at first you don't succeed" and "practice makes perfect" set against a background of nerdly delights and the occasional introspective advisement. However, the form and prose of the post is blogging at it's finest. Just the perfect number of visual aids, with a plethora of interesting and well-sourced links - this post is a marvel just from a writing standpoint. A blogging mini-opus. Kudos.