Writing code for BuddyPress: It’s all about community by Stas Sușcov
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.
[...] Recent Highlight: Writing Code for BuddyPress [...]
[...] Today’s 12 days of WordPress and BuddyPress comes from Stas Sușcov: “Writing code for BuddyPress: It’s all about community by Stas Sușcov” [...]