Author information block seems to be broken

This little patch does the trick.
The bug came from the fact that the query retrieving user profiles, didn't take all public fields.

I've looked at the patch, changes "in" to "IN" and removed trailign DOS newlines, and can confirm that it works.

changing status

Is using IN() equivalent to using OR or is one faster than the other?

Cvbge and I think that it is equivalent in this case. it is unsure whether it is faster, but IN () is usually regarded as being fast:
http://mysql.com/in

I'm not a DB expert, but I got a little experience on Oracle (great you can answer ;) but I think it should happen pretty much the same), so IMVHO, I think that they're doing the same, in fact, looking at Oracle explain plan, it's exactly the same between a OR and a IN clause. They both do the same explain plan using "INLIST ITERATOR" in fact, the cost is the same, but explain plan tells me that it takes slightly less bytes to achieve it...
Ok sorry if very off topic and useless, but I thought it worthes to mention that.

Back to our query, I think whatever we put OR or IN clause, we shouldn't expect speed problem with this, as it's very little the change. If we do care about it, I think we should add an INDEX on this column. Also, I think IN clauses in this case (using 2 or more coma separated values) is much clearer than writing a lot of OR.

Committed to HEAD.

Looks like MySQL rewrites OR to IN() internally.