everyone looks so funny
funny peculiar
jerking about and dancing
singing
hallelujah!!

people are funny
they’ll say that everything’s cool
they’ll make you laugh?
then they’ll?disappoint you

Something’s are funny
Funny peculiar 
Don’t know what it is
You don’t either

Where ever we go 
The grass just gets greener
But we both know 
That it won’t last forever

People are funny 
Funny peculiar 
Fussing around
Making plans for the future

I never wanted your honesty 
I just want your electricity
Let it rain down over me
Let it reign all over me

I had a nasty surprise for me tonight when I realized none of my posts were available on my blog (the one you’re looking at now!). I could log into WordPress and see everything but my posts showed a count of zero (scary!). My first thought was to restore my latest backup only to realize my backup didn’t run this week. I did have the backup from last week so I logged into phpMyAdmin and this is where I found the actual problem. When I clicked on the wp_posts table, I received the following error:
#144 – Table ‘./wp_posts’ is marked as crashed and last (automatic?) repair failed
By no means am I a mysql expert. I’m still not sure why this even happened. However, this was actually not very difficult to correct in my case (once I found the cause and a few mysql forums) and I wanted to share the steps I went through to correct this:
1. Sign into your phpMyAdmin account
2. Click on your database name on the left
3. Then click on SQL in the tabs on the top
4. In the query box enter: repair table wp_posts and then click Go. (note: you’ll need to replace wp_posts with whatever table you are having an issue with if it’s not this table)

One of the new things in 3.1 that hasn’t got a lot of discussion yet is the new Advanced Taxonomy Queries mechanism. At the moment, this is still being actively developed, but the basic structure is finalized enough to give at least a semi-coherent explanation on how to use it. Since 3.1 is now going into beta, it’s unlikely to change much.

What’s a Query?

In WordPress land, a “query” is anything that gets Posts. There’s a lot of ways to do this.

• You can use query_posts to modify the main query of the page being displayed.
• You can create a new WP_Query, to get some set of posts to display in its own custom Loop.
• You can do a get_posts to get some limited set of posts for display in some special way.

Regardless of the method, you have to pass parameters to it in order to specify which posts you want. If you’ve used this at all before, then you’ve used parameters like cat=123, or tag=example, or category_name=bob and so forth. When custom taxonomies were developed, you were eventually able to specify things like taxonomy=foo and term=bar and so on.

Querying for Posts

The problem with these is that people sometimes want to specify more than one of these parameters, and not all parameters worked well together. Things like cat=a and tag=b, or cat=a and tag is not b, and so forth. This is because cat and tag are both forms of taxonomies, and the code didn’t handle that well. Sure, some of it worked, for specific cases, but those were mostly there by accident rather than by design. In other words, those cases worked because the system just happened to get it right for that particular instance.

Well, all these old methods still work, but they have been made into a more comprehensive system of generically specifying arbitrary taxonomies to match against. When you specify cat=123, it’ll actually be converting it to this new method internally.

Query Strings are for Suckers

One side effect of this new system is that it doesn’t really work with query strings very well. It can be done, but it’s a lot easier and more sensible if you just start getting into the array method of doing things instead. What’s the array method? I’ll explain:

Imagine you used to have a query that looked like this:

A simple query, really. The problem with it is that WordPress has to parse that query before it can use it. But there is another way to write that query as well:

Essentially, you separate out each individual item into its own element in an array. This actually saves you some time in the query because it doesn’t have to parse it (there’s very little savings though).

The advantage of this is that you can build your arrays using any method of array handling you like. Here’s another way to do it:

Simple, no? But what if you have to deal with the $query_string? The $query_string is that old variable that is built by WordPress. It comes from the “default” query for whatever page you happen to be on. One of the main uses for it was to deal with “paging”. A common method of doing it was like this:

If you use arrays, you have to deal with that yourself a bit. There’s a couple of possible ways to do it. The easiest is probably to just parse the query string yourself, then modify the result as you see fit. For example:

I started out with the $query_string, used wp_parse_args to turn it into an array, then overwrote the bits I wanted to change and performed the query. This is a handy technique I’m sure a lot of people will end up using.

On to Advanced Taxonomies

Advanced Taxonomy queries use a new parameter to the query functions called “tax_query”. The tax_query is an array of arrays, with each array describing what you want it to match on.

Let’s lead by example. We want to get everything in the category of “foo” AND a tag of “bar”. Here’s our query:

Here we’ve specified two arrays, each of which describes the taxonomy and terms we want to match it against. It’ll match against both of them, and only return the results where both are true.

There’s two things of note here:

First is that the “field” is the particular field we want to match. In this case, we have the slugs we want, so we used “slug”. You could also use “term_id” if you had the ID numbers of the terms you wanted.

Second is that the “terms” is an array in itself. It doesn’t actually have to be, for this case, as we only have one term in each, but I did it this way to illustrate that we can match against multiple terms for each taxonomy. If I used array(‘bar1?,’bar2?) for the post_tag taxonomy, then I’d get anything with a category of foo AND a tag of bar1 OR bar2.

And that second item illustrates an important point as well. The matches here are actually done using the “IN” operator. So the result is always equivalent to an “include” when using multiple terms in a single taxonomy. We can actually change that to an “exclude”, however, using the “operator” parameter:

The above query will get any post that is NOT in either the “foo” or “bar” category.

But what about terms across multiple taxonomies? So far we’ve only seen those being AND’d together. Well, the “relation” parameter takes care of that:

This gets us anything with a category of foo OR a tag of bar. Note that the relation is global to the query, so it appears outside the arrays in the tax_query, but still in the tax_query array itself. For clarity, I recommend always putting it first.

Useful Gallery Example

By combining these in different ways, you can make complex queries. What’s more, you can use it with any taxonomy you like. Here’s one I recently used:

This gets any posts in either the gallery category OR that have a gallery post-format. Handy for making a gallery page template. I used the wp_parse_args($query_string) trick to make it able to handle paging properly, among other things.

Speed Concerns

Advanced taxonomy queries are cool, but be aware that complex queries are going to be slower. Not much slower, since the code does attempt to do things smartly, but each taxonomy you add is the equivalent of adding a JOIN. While the relevant tables are indexed, joins are still slower than non-joins. So it won’t always be a good idea to build out highly complex queries.

Still, it’s better than rolling your own complicated code to get a lot of things you don’t need and then parsing them out yourself. A whole lot easier too.

To help with this, please see this worked example for End of Page delivery: eop-example.

Inside the zip file is an HTML page with 2 spots for banners, as well as some fascinating content. At the bottom of the page are 2 invocation tags as well as a call to a javascript function which will reposition the 2 banners to appear above where they are meant to. The javascript file can most likely be kept as-is.

What other things can you do to help speed?

Caching is important. OpenX has built-in caching which limits calls to the database – in a production environment you might want to increase the cache time used by your installation. You might also want to install a caching system for PHP on your server.

Keep in mind what 3rd parties you are using for banners. If you are using external image banners or 3rd party HTML banners, not only must OpenX deliver the banner but the 3rd party must then deliver the image/HTML. Sometimes such external sources can be slow to load and should be kept in mind when analyzing speed.