When Kubrick was bundled with core back in 2005, it was a cutting edge theme. Custom header, rounded corners, clean design… if you were using WordPress back then, let’s face it, you were impressed. Time moves on, though, fashions change, new styles become old standards, and what was once cutting edge suddenly seems old-fashioned and out of date.

So, a new bundled theme in 2010? We think it’s a good idea. Something nice and light that can serve as a good example theme, include newer theme-based features, and look nice (and current) on a public site. We’d like to introduce a new default theme with version 3.0, which is anticipated to come out in mid-2010 (hence the name), and think it would be good for it to blend well aesthetically with WordPress itself.

I’d been advocating moving toward Elastic, the theme framework/WYSIWYG theme editor that was one of our Google Summer of Code student projects, but after some discussion I agreed with the guys that while Elastic is awesome and should be promoted as a community development project, it’s heavier than a default theme needs to be. The default theme doesn’t need to be a full-featured framework, it just needs to work well, look awesome, have good code and be a good starting point for beginning themers. We were thinking of a fairly minimalist design that would make it easy to customize.

As for the code, there’s a question of if it will really be a new theme, or if it will be a re-styled and updated version of Kubrick.  We don’t know the final answer to that yet, because the ultimate decision will be made with the community’s input, but we believe all new markup is the way to go. What do you think? Without venturing into theme framework territory, are there features you think a new default theme should have? Some people have been talking about it on Trac over the past year, if you wonder what’s been tossed around so far. I thought about posting a poll here (you know how I love posting polls to gauge opinion), but in this case I think a discussion thread might be better, so that each vote can explain the reason behind it. So, have an opinion on what a new default theme should include? Weigh in at the forums.

If you’ve been waiting for your moment to pitch in, it’s now. First we need tech savvy testers to upgrade their blogs and kick the tires, make sure everything is rolling like you expect it to. Here’s a list of all the fun and geeky new stuff in 2.9 to try out. Second, and more importantly, we need everyone to test out their plugin compatibility.

If you’re a user of plugins, there’s a groovy new compatibility feature on the plugin directory where you can vote on whether a plugin is compatible with a version or not and it’ll get registered in the new plugin compatibility checker. This is as a replacement to the old wiki-based lists we’d do before. To see it in action check out this Akismet plugin page, as you can see 14 people have already registered that it’s compatible with 2.9.

If you’re a plugin author, of course you should update your “Tested up to:” in the readme.txt for your plugin.

If all goes according to plan, WordPress 2.9 will be out before the end of the week. You can download the release candidate here.

For more details on the changes since Beta please review the revision log on Trac, and happy testing!

Last week, I posted about the fact that Trac would be quiet for a few days while the core commit team met in person for the first time to talk about some goals for WordPress in the coming year. That prediction wound up being a little inaccurate, as having everyone together inspired a Trac sprint to get us closer to shipping 2.9. As of this morning there are only 11 tickets left against the 2.9 milestone. Yay! I’m sensing a Release Candidate in the near future.

I’d planned to write a summary post to encapsulate the discussions we had over our 3 day meetup, but to be honest, all-day (and night) every-day meetings creates a ton of things to summarize, and the post would be a novella. So instead of one long post, I’m going to split it up into a series and post a summary of the discussion on one or two topics per day until I’ve posted them all. Think of it like a WordPress advent calendar. For today’s post, enjoy the video above and I’ll list the topics we covered to give you an idea of what will be included in the upcoming summary posts.

Topics: Direction for the coming year(s), canonical plugins, social i18n for plugins, plugin salvage (like UDRP for abandoned plugins), WordPress/MU merge, default themes, CMS functionality (custom taxonomies, types, statuses, queries), cross-content taxonomy, media functions and UI, community “levels” based on activity, defining scope of releases, site menu management, communications within the community, lessons learned from past releases, mentorship programs, Trac issues, wordpress.org redesign, documentation, community code of conduct.

You can see why I didn’t want to try to cram it all into one post, right?

Just to make sure it’s clear in everyone’s minds, I want to reiterate that these discussions were just that: discussions. They were not secret meetings ending in hard and fast decisions. The idea was to 1) get the core commit team on the same page in order to improve workflow efficiency and communication, and 2) come out of the meetup with a long list of things we know we want to work on in the coming year, and from there to work with the broader community to determine priorities/strategies before starting the work of getting it all done. As I finish off 2009 by posting summaries of the meetup conversations, I hope you’ll all plan to start 2010 with enthusiastic participation in one or more of the projects that will take these conservations from concept to reality.

Canonical plugins would be plugins that are community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution. These plugins would be GPL and live in the WordPress.org repo, and would be developed in close connection with WordPress core. There would be a very strong relationship between core and these plugins that ensured that a) the plugin code would be secure and the best possible example of coding standards, and b) that new versions of WordPress would be tested against these plugins prior to release to ensure compatibility. There would be a screen within the Plugins section of the WordPress admin to feature these canonical plugins as a kind of Editor’s Choice or Verified guarantee. These plugins would be a true extension of core WordPress in terms of compatibility, security and support.

In order to have a system like this, each canonical plugin’s development community would probably need similar infrastructure to WordPress itself, including things like Trac, mailing lists, support forums, etc. These things will be worked out within the development community over the coming months, but in the meantime, we really need a better name for this. Many people have no idea what canon/canonical means (clearly, they are not Dr. Who fans!), and having to define the word distracts from discussing the core ideas behind the concept. So, we thought we’d do a community poll to see what people think we should call canonical plugins. We brainstormed a few dozen ideas yesterday and whittled it down to our top handful. Based on the definition of canonical plugins given above, which of these terms do you think best describes them? I’m including a short description of our thoughts on each.

Standard - Implies that these are the standard by which all other plugins should be judged, as well as the idea of them being the default plugins.
Core - Makes the close relationship to core WordPress development very clear, and has the implication of bundled plugins (even though we don’t need to actually bundle them now that the installer is right in the admin tool).
Premium – Identifies these officially-supported plugins as best-in-class and of the highest value, and could potentially disambiguate the word Premium as it is currently being used in the community (to refer to anything from commercial support to licensing terms to actual code quality).
Validated - Focuses on the fact that the code is reviewed for compatibility with core and for security.
Official – Makes it plain that these are the plugins officially endorsed by the core team as being the best at their functions.
Canonical – Maybe once people get used to it, canonical wouldn’t confuse so many people?

Cast your vote in the poll below to have your opinion considered during the decision-making process. And if you can think of a word that we haven’t listed here that you think is better, please submit it in the poll! The poll will remain open until 11:59pm UTC Thursday, December 10, 2009.

WordCamp New Zealand: Wellington, New Zealand, August 8-9, 2009

WordCamp Huntsville: Huntsville, Alabama, USA, August 15–16, 2009

WordCamp Los Angeles: Los Angeles, California, USA, September 12, 2009

WordCamp Philippines: Makati City, Philippines, September 19, 2009

WordCamp Portland: Portland, Oregon, USA, September 19-20, 2009 (Last year’s PDX WordCamp was awesome, IMO.)

WordCamp Seattle: Seattle, Washington, USA, September 26, 2009

WordCamp Birmingham: Birmingham, Alabama, USA, September 26-27, 2009

WordCamp Netherlands: Utrecht, Netherlands, October 31, 2009

WordCamp NYC: New York, New York, USA, November 14-15, 2009 (Logo contest in progress!)

WordCamp Mexico: Mexico City, Mexico, November 20, 2009

If any of these are within a reasonable distance to you, consider attending. WordCamps are a great way to meet other WordPress users, find collaborators, and expand your t-shirt collection*. I know I’ll be hitting at least a few of these; WordCamps are also a great way to get user feedback to take into consideration while we’re making decisions about what to include in core.

You can always find an up-to-date list of upcoming WordCamps at WordCamp Central. You can also try searching for WordPress groups at Meetup.com to find more regular monthly gatherings in your area.

*Most WordCamps include an event t-shirt in the registration fee.

Many of the security improvements to the new versions of WordPress in the last couple of years were complete reworks of how various systems were handled. Porting those changes to the 2.0.x branch would have been a monumental task and could have introduced instability or new bugs. We had to make hard decisions between stability and merging in the latest security enhancements. Additionally, far fewer people stayed on the 2.0.x branch than we anticipated. I take that as a testament to the new features in WordPress and perhaps even more the features offered by plugins, many of which don’t support older versions of WordPress!

I’m disappointed that we weren’t able to keep the branch maintained until 2010, but since one of the big reasons for that failure was the massive scope of our security improvements for the newer versions of WordPress, 2.0.x doesn’t die in vain!

These are the features that we’re asking people to vote on (in alphabetical, not prioritized, order):

Additional Media Filters: In the uploader, you can currently upload an image from your hard drive, link to an image from a URL, or select an image from the Media Library. This proposed feature would add links in the Media Library pane that would allow you to filter images to those that had been used most recently, used most often, and/or marked as a favorite. These filters would be available on the Media Library screen as well.

Basic Image Editing: Enable cropping, resizing and 90-degree rotation of uploaded images.

Better Media Settings: Enable the creation of more default media settings controlled in the Settings section, and allow settings to be overridden  during the individual media upload process as needed.

Bulk Media Import API: Develop an API to allow for bulk media importing by plugins or importers.

Custom Image Sizes: Instead of hardcoded thumbnail, medium, large, etc. image sizes, custom image sizes would allow you to configure the maximum dimensions for each of the sizes.

Easier Embeds: Make it easier to embed third-party content such as YouTube videos, etc. Similar to Viper’s Video Quicktags plugin.

Media Albums: Ability to create and edit photo albums that can stand alone (as opposed to galleries being tied only to a post), including photostream functionality.

Media Metadata: Enable the use of categories and tags on media files.

Photostream: Create a Flickr-style photostream that simply displays images in a chronological stream (as opposed to grouping in galleries).

Post thumbnails: Choose an image to appear as a thumbnail with your post/article/excerpt.

Revised Media UI: Redesign the uploader UI to make uploading and editing media files a simpler, more user-friendly process.

These descriptions are repeated in the beginning of the voting survey, so if you forget what something means you’ll be able to scroll up to remind yourself. Only the first question (pick your top choice) is mandatory. This survey isn’t very long. Question two lets you assign a general high/low priority to each of the 11 feature suggestions, while question 3 asks you to rank the 11 features in order of priority from 1-11. A text box or two allow you to make additional suggestions, and that’s it. The survey is anonymous, and will be open all week, until Friday, July 10, 2009 at 11:59 PM UTC.

No JavaScript? Take the survey here.

Results of the survey will be used to help developers decide which features to focus on for version 2.9. The 2.9 anticipated feature list will be posted here later in July, after the priority has been determined. How many contributing developers are available to code various features will play a large part in the decision-making process, so if you’ve ever thought of contributing code to WordPress development, now’s a great time to get involved. Developer chats are held each Wednesday in the IRC channel (irc.freenode.com #wordpress-dev) at 9 PM UTC (5pm Eastern, 2pm Pacific).

* – Other non-media features that were discussed either were determined to be better held for a future version for technical reasons, or were so widely desired that they were accepted for the 2.9 roadmap without requiring a vote.