Nevermind the semantic differences between ‘post’ and ‘entry’ in relation to blogging, there’s a much more real problem in determining which of the two to go with when you’re designing a theme framework like K2.
WordPress uses ‘post’, and so of course it makes sense when designing classes for the title of a post to name it ‘post-title’ and for the content to be named ‘post-content’, right? Well until you want to add support for the hatom microformat, which has chosen ‘entry’ to denote an article (oh, there’s another one) and so uses ‘entry-title’ and ‘entry-content’.
Which one to choose? Yes, you could go with both, but that’s rather inelegant, and feels a bit like sitting between two chairs.
I chose to go with the hatom naming and trust that people can figure it out on their own, even though it pains me a bit to not conform to the ‘mother’ platforms naming conventions, I think the gain of hatom compatibility is worth it.
Eric mentioned something that I think is worth re-communicating here.
K2 hasn’t always been the most frequently updated theme in the official sense of us putting out releases. We’ve often poured changes into the repository and fed people the latest nightlies if they wanted to stay up-to-date. And by doing so we ‘trained’ everyone to think of the nightlies and subversion in general as place for (mostly) stable updates.
And we try to keep it that way.
The new course is to instead be more rigorous with actual releases and in turn ween everyone off of using the nightlies and subversion for production purposes. This is important, because we’re already in the midst of some sweeping changes, and they will mean broken sites if you rely blindly on subversion or nightlies.
Just a word of advice: Today I revamped our HTML structure, our columns functionality, added several new widget areas (while renaming the old ones), and a lot more. All of these changes are currently in the subversion repository, feel free to check them out, however understand that if you already have a site up and running, these changes are not likely to play well with any widget setups, styles or child themes. It is as usual best to stick with actual release for live sites.
There will be more on this soon, but consider this both a warning and a heads up, if you want to adapt your child theme or style for the next major release of K2. These changes, which massively simplify K2 and were previously planned for v1.2, but will instead find their way into v1.1, are meant to make K2 easier to get around.
The short-term downside is that there will be some extra work adjusting existing styles and child themes; but it’s definitely worth it (and should have been done a long time ago).
Even though K2 has been stable and in a sense feature complete for a very long time, a 1.0 release has yet to happen. That’s about to change. That’s right, the temperature is dropping rapidly in hell, crafty engineer pigs are working on wings and propulsion systems and the US war efforts have seize… Two out of three isn’t bad.
I’ve gone through all the new issues in the issues database over the last few weeks and updated most of the ones that were floating around unassigned. Many of the open bugs have already been fixed, but there is still a substantial list of issues in need of more information from the reporters.
Beyond that, if you know of any issues, large or small, that aren’t already in the issues list, please take a minute to let us know so we can figure out what to do with it in relation to 1.0. In an effort to get the 1.0 happening sooner rather than later, I may be somewhat brutal in assigning new issues to the 1.1 milestone, but that doesn’t mean they won’t be dealt with. However, as you may have noticed, K2 development has a tendency to happen in short concentrated sprints. This is one, and if you want something noticed and fixed, now is a good time.
Check out the changelog for recent changes, grab the latest nightly and take it for a spin.
For our brave and tireless translators. I love you. But more than that, I hope you can find the time to update your localizations for 1.0. In return, my promise is that for 1.1 one of the main pushes will be to get the localizations into the trunk and support them with an easy language selector from the options page (also known as issue #793).
As usual, you can use the support group for communications and the localization home to upload your .pot files.
Yep, in black and white.