The first thing I thought when I heard the news was, “Awesome! Now everyone can put BuddyPress on their site if they want it.” The second thought I had was, “Shoot! Average WordPress users won’t want to try BuddyPress if they have to switch their site themes over to the BuddyPress default theme just to try it out.” The third thought I had was, “That can’t be right. I’ll ask Andy.”

As it turned out, you could keep your current theme with BuddyPress if you added a couple of files and made a few file edits. There was even a link on the BuddyPress site to download the necessary files. That still seemed a little clunky, though, so Andy, super awesome guy that he is, went ahead and made a plugin to get you started. The BuddyPress Template Pack can be installed directly from your WordPress admin (Plugins > Add New), and will walk you through the theme additions step by step.*

Now you can use BuddyPress with your single site installation of WordPress, and you can keep your existing theme. Seriously, could BuddyPress have made it any easier for you to add social networking to your site? I know I can’t wait to try it out this weekend, how about you?

* Don’t forget to install BuddyPress itself, or the template pack plugin won’t do anything!

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.

We feel that all software should have a changelog that details, at a high level, what changes have been made in each version so that the user can make an informed decision about when to upgrade and how much testing they should do with their site.

In order to make this an easy and open communication channel we have added support for a Changelog section in the plugins readme.txt file.  This changelog information is then displayed as a separate tab in the plugin directory and also in the back end of your WordPress blog when you view the details on a new version of a plugin.

The new section is formatted as follows:

== Changelog ==

= 1.0 =
* A change since the previous version.
* Another change.

= 0.5 =
* List versions from most recent at top to oldest at bottom.

We would also like to recommend that you also provide meaningful log messages when you commit changes to the subversion repository for your plugin so that people who want to dig further into your changes can see why things are changing (At the moment is seems a large number of plugin authors leave this field blank which isn’t very helpful).