There are a couple of spots that I always keep handy when looking for information about WordPress’ query handling. Consider this Gist an addition to my list:
WordPress Query Comprehensive Reference
Which helpful, recent resources do you use for information about WordPress’ query? I prefer to hit the Codex (WP_Query and query_posts) and also just dig directly into wp-includes/query.php.
Fun fact of the day: about 37% of WordPress downloads are for non-English, localized versions.
So as a plugin or theme author, you should be thinking of localization and internationalization (L10N and I18N) as pretty much a fact of life by this point.
An excellent post from Otto on improvements to make and pitfalls to look out for when performing i18n on your WordPress theme.
My coworkers at Automattic and I frequently discuss the speed with which we’re able to onboard new themes into the WordPress.com theme directory.
Our top priority as the Theme Team is to make sure that all of our users feel like they have a theme that fits them perfectly; in order to meet that goal we’re focused on bringing a variety of themes into WordPress.com through a few primary channels: the WordPress.org theme directory; premium theme shops; and Automattic (in-house) themes.
It’s often the case that each conversion—that is, making a theme’s code WordPress.com-safe and ready—will take us anywhere between one week and one month, depending on the complexity and quality of the code. In a perfect world, though, we’d be able to snap our fingers and have every single awesome-looking theme available on WP.com right now.
Paul Irish on HTML element widths being inclusive of padding at all times. That is to say if I define my box as 200 pixels wide then it should stay at a total of 200 pixels, no matter what I use for its padding value.
The money shot is as follows:
* { /* apply a natural box layout model to all elements */
-moz-box-sizing: border-box;
-webkit-box-sizing: border-box;
box-sizing: border-box;
}
Also, an interesting read on using * and its impact on performance.
You might get up in arms about the universal * selector. Apparently you’ve heard its slow. Firstly, it’s not. It is as fast as h1 as a selector. It can be slow when you specifically use it like .foo > *, so don’t do that. Aside from that, you are not allowed to care about the performance of * unless you concatenate all your javascript, have it at the bottom, minify your css and js, gzip all your assets, and losslessly compress all your images. If aren’t getting 90+ Page Speed scores, its way too early to be thinking about selector optimization.
As with most CSS, there’s no one-size-fits-all choice for this. At times it makes sense (it’s used on the WordPress.com Theme Showcase, selectively though) and at other times it doesn’t.
I like it, though.
Head over to Irish’s site to weigh in or drop a comment here with your thoughts.