Want to celebrate in style? WPMU.org had a colourful infographic to go with the release of 3.1.

Fancy discovering more about the music behind WordPress? 3.1 is code named Reinhardt after Django Reinhardt and WPMU.org provides the music with Daily Tip: Jam Out with WordPress 3.1′s Namesake, Django Reinhardt.

Creating a custom functions plugin for end users by Justin Tadlock is an interesting method of adding custom code to a theme or even themes.

Linking to all image sizes in WordPress also from Justin Tadlock shows how you can do similar to sites like Flickr and show links for all image sizes. A useful trick for image based sites.

Killer hacks to enhance WordPress editor does what it says on the tin by Cats who Code.

Improving WordPress Privacy is a different look at what you can do to keep that site you are working on under wraps by Roget Johansson at 456 Berea Street.

We’d like to take this time to say thank you to everyone involved in the 12 days event and those wish them a Merry Christmas. We’d also like to wish our readers and users a Merry Christmas and a Happy New Year.

We will have more blog posts in 2011 when we’re back after a holiday break.

Today’s 12 days of WordPress and BuddyPress comes from James Goodbrad. Supporting WordPress: Common Tales from the Trenches brings a different take on things from the view of someone that daily supports WordPress.

We’ve got 2 days left of our 12 days of WordPress and BuddyPress we’re running with wpmu.org so be sure to check back for more.

Today’s 12 Days of WordPress and BuddyPress is brought to us by Stas Sușcov and let’s meet him in his words:

I’m the WordPress Romanian Localization Team driver, Ubuntu Website Team WordPress hacker/maintainer and WordCamp Bucharest speaker. I was also a Google Summer of Code 2010 student for BuddyPress, which resulted in BuddyPress Courseware component. My blog.

I remember last summer, when I just start playing with BuddyPress, and how much fun it was. Challenges were overwhelming, even so, now I would hardly do it other way. So this is a post about how to get started writing code for BuddyPress (be that core patches or plugins). and how to not get stuck at early stages.

From my experience, the community is everything, but that’s not enough when you decide to contribute to a project. There are interesting aspects that can scare a newcomer, like:

• Conceptual aspects and application design
• Quality of documentation
• Codebase quality and used technologies
• Availability of examples (existing contribution)

Let’s take it one by one.

BuddyPress is still WordPress.

I met a couple of WordPress contributors, that got scared about BuddyPress, thinking of it as something totally new and different. Ok, this is wrong, at least at first view.

BuddyPress was never a pilot project for WordPress, it started as a bunch of hacks (plugins), and evolved into what it is now thanks to it’s community and contributions. The guys that contributed and do it now, were WordPress developers initially!

The main differences between WordPress are the hook names, and some API extensions (here to mention the URL mapping, groups and profiles addons like xprofile). All of it, along with WordPress functionalities(post types and options API) should be enough for you to write applications of any complexity level. So If you think you need to alter the database for you plugin, rethink the adopted design/concept for it, because it’s wrong (I’m almost 110% sure).

From my experience (and I was one of the early adopters of this workflow when writing BuddyPress apps), I found post types along with it’s metas data structure, as almost perfect for the most common tasks you will need for a plugin! To convince you, here are some of the reasons you should consider, that come bulk with such a strategy: caching, database optimization from the very beginning, no need to alter database if your plugin grows. So be smart, and plan your plugin carefully.

In the end, writing a BuddyPress plugin, will just make you a more hacker than you already are :)

Whatever you decide to write for WordPress/BuddyPress, document it!

Be that PHPDoc inline documentation or old school readme.txt, write it down. Writing plugins for BuddyPress is pretty the same as writing them for WordPress. Having a documentation around will help you maintain your codebase along the whole plugin life-cycle which can last years!

Newcomers should know that BuddyPress is still a wild beast, and though guys put efforts into creating both: a solid community and a WordPress level codebase, some parts of code may just miss documentation! Once such a problem strikes you, ask for help, and the help will come, just head on to forums or codex.

Code is poetry, at any age or experience.

Don’t forget this! Both WordPress and BuddyPress are using imperative and sometimes object-oriented programming. This made a couple of my friends to criticize it badly, but that should not be a reason for you to do the same!

BuddyPress is a complex system! For it’s main components like groups and messages, the code is written as classes, which is great, mainly because if you want to modify some component workflow, all you need to do is extend the base class and overwrite the method you don’t like. But heading on with the OOP way everywhere is wrong. Usually users don’t do such complex things, and forcing them to adopt such a workflow, will just drive the contributions away. Not to mention the template tags, which are bare functions that hook into something and allows you making a paragraph out of a list a snap!

So blaming BuddyPress for coding styles it’s wrong, mainly because being flexible for developers (of any level), sometimes it’s more important than being flexible to end-users! With some help, BuddyPress contributions can come from young programmers to experienced developers, and patches are always welcome!

So how do I start.

Good examples are always a good start for any coding you plan. BuddyPress developers took this seriously, and put efforts into helping newcomers understand the plugins workflow and adapt easily.

On codex, there’s a dedicated page for how to write a component. It’s a bunch of code that gave me a real boost when I wrote my first plugin (basically a small modification of the skeleton component), and you should also check it if you want to write something quickly!

More experienced developers, can write their code independently of that. The approach is the same, and it’s up to you. Remember, we’re very-very flexible in terms of code, and the hooks are your best friend!

Final thoughts

I really hope this article will help newcomers cover some of the unusual questions they could ever stumble upon and didn’t know where to get answers. If you didn’t observe, every thought I wanted to explain, more or less brought me to the community. Also, I just wanted to remind everyone that my experience with BuddyPress as part of the community was really special. I was taught and helped a lot, and the people I met here that did all the above are just awesome!

So I hope to see you soon, contributing to BuddyPress.

Today’s 12 days of WordPress and BuddyPress comes from Jeffrey Pearce. Post Formats, Tumblog, and Content Separation can be found over at wpmu.org.

Don’t forget to check every day for a new 12 days post.

It’s over to Paul Gibbs for today’s 12 days of WordPress and BuddyPress.  Lets meet Paul first in his own words from his profile at BuddyPress.org:

” I’m a Core Developer on BuddyPress. I enjoy speaking at WordCamps, crafting code, and helping people.

I provide consultancy on projects and design custom plugins for your site;

contact me at paul@byotos.com, in #buddypress-dev on freenode, or on twitter as @pgibbs.”

A powerful tool in a WordPress developer’s arsenal is the ease and flexibility of creating a widget. Introduced in WordPress 2.8, the WP_Widget widget class abstracted most of the complexity involved in writing a widget, giving developers a framework to build on and prevent time being needlessly spent on, for example, building custom option panels. Widgets remain a great way for a PHP developer to become familiar with the WordPress platform and API features such as actions and filters.
BuddyPress’ Groups component has a similar extension architecture to widgets and we’re going to look at how existing WordPress developers, who haven’t written for BuddyPress before, can get started.

Introduction to BuddyPress components

BuddyPress is a single plugin, but internally it is subdivided into distinct parts, almost into separate plugins, which BuddyPress calls components. The core components are Activity Streams, Blog Tracking (for multisite), Forums, Friends, Groups, Private Messaging and eXtended Profile (xprofile). A plugin developer working on BuddyPress would either extend one of the core components or create a new component. An example of extending the Private Messaging component would be to add support for file attachments to messages, and a new component would be best for brand new functionality, such as a photo album.

At the moment, the Groups component has the best API for developers, so we’re going to be looking at John James Jacoby‘s BP Edit Group Slug plugin as an example. Download it and look at its source code whilst reading this article. The BP Edit Group Slug plugin allows you to change the group’s slug, which is part of the group’s permalink. You might want to use this if you decide to rename the group after creating it and want to update the permalink too.

Hooking into BuddyPress safely

Like with widgets, a group extension requires you to extends BuddyPress’ BP_Group_Extension class. To tell BuddyPress to load your group extension, use bp_register_group_extension(). However, be aware that John’s plugin is slightly out of date about how third-party plugins should hook into BuddyPress; the correct way is documented on the BuddyPress codex. We advise creating a loader.php file and putting in the following:

// Only load code that needs BuddyPress to run once BP is loaded and initialised.

function my_plugin_init() {

require( dirname( __FILE__ ) . '/my-plugin.php' );
}
add_action( 'bp_include', 'my_plugin_init' );

All of your code which is dependant on BuddyPress can then be put into the my-plugin.php file. This will make sure your plugin won’t break someone’s website if they were to deactivate BuddyPress before deactivating your plugin.

About BP_Group_Extension

In your class, there are six functions which you can choose to implement.

• BP_Group_Extension::create_screen() — implement the HTML for the create screen, as seen when users create a new group.
• BP_Group_Extension::create_screen_save() — handle saving of options from the create screen.
• BP_Group_Extension::edit_screen() — implement the HTML for the edit screen, as seen when the group admin(s) edit their group.
• BP_Group_Extension::edit_screen_save() — handle updating of options from the edit screen.
• BP_Group_Extension::display() — implement the HTML to display output from your group extension in the group.
• BP_Group_Extension::widget_display() — invoked when the user is on the front page of a group (by default, the activity stream page).

You are not required to implement all of these functions in your class. For example, as John’s plugin is only used for the group admin(s) to change the permalink, there is no need to display anything to regular visitors. In addition to these methods, there are a few helpful class properties:

• $enable_create_step, $enable_nav_item, $enable_edit_item — booleans. Set these if you want to display your extension on the create/edit screens, or add a nav item. Optional (all default to true).
• $create_step_position, $nav_item_position — integers. Use to change the order of where your extension displays on the create scree and the navigation bar. Optional (defaults to 81).
• $name, $slug — strings. The title of your grope extension, and the slug for its permalink. Both required.
• $nav_item_name — string. Set to use this instead of $name in the navigation bar. Optional.
• $visibility — string. Controls whether this extension will be visible to non-members of a group? Options: “public” or “private” (defaults to “public”).
• $display_hook — string. ADVANCED. Defaults to ‘groups_custom_group_boxes’.
• $template_file — string. ADVANCED. Defaults to ‘groups/single/plugins’.

$display_hook and $template_file are two advanced options which will give you more control over which template is used when you display() your group. You don’t need to worry about these as the defaults will be appropriate most of the time.

Where to get help

Using John’s plugin as an example, I suggest that you spend an afternoon over this Christmas period learning to implement your own group extension and seeing what you can come up with. If you need any help, please leave a message on the BuddyPress Community site where I’ll be happy to help you learn how to develop with BuddyPress. Merry Christmas!

Today’s 12 days of WordPress and BuddyPress is brought to you by Jared Williams: ‘How to make a sidebar widget to display recent custom posts by Jared Williams’.

Don’t forget to check back here and at wpmu.org each day for a new post in this exciting series.

Today’s 12 days of WordPress and BuddyPress is brought to you by Ozh: ‘WordPress Query Overview: How a Page is Translated To a MySQL Query’.

Ozh is a regular member of the WordPress community and we’re pleased to have him join our 12 day celebration.

Don’t forget to check back again tomorrow for more 12 days with a post on this site to do with BuddyPress.

13 Fantastically Creative BuddyPress Site Designs

10 new Plugins to Improve Your BuddyPress User Experience

20 Plugin Replacing Tutorials, Tips, Snippets and Solutions for WordPress

Best Free Textures and Patterns of 2010

Should Themes or Plugins do your SEO