Hi Jean,
h-mag.com was initially setup as a wordpress template. After setting up and installing BuddyPress, I imported each of the components one by one and began modifying the parent theme’s CSS and restructuring the HTML to match the functionality of the original wordpress theme. There are not shortcuts, just a lot of tedious work and trial and error.
@Simon, I guess my question is how you deal with upgrades to BP or your WP theme (if it wasn’t purely homegrown)? It sounds like you were modifying HTML of the parent which I thought was a no-no for upgradeability??
That site is so beautifully, I’m sure many inquiring minds want to know.
Upgrades and updates are a pain, I use the BuddyPress Trac to review changes between minor versions when upgrading and apply them one by one while ensuring that any modifications made by me stay intact.
My motto is that you should let your theme dictate the look and the UI of your BuddyPress site and I’ve modified every single directory to match the look of my theme. Upgrading to 1.2 in January will require a lot of work and I’m actually considering starting from scratch, but I love doing it – it’s like taking your Xmas toys apart and figuring out how they work.
Happy Holidays 
I hear you. I just know I won’t have the time for this level of upgrading. I’m hoping I can disengage the Buddypress functionality from the BP template files (as should be the case for any true framework). Then, I could get full upgradeability of the theme framework (Hybrid) and just have to modify the BP functionality added via functions in the child.functions.php (based on functions available already from BP) and/or create custom BP templates myself.
I’m hoping that’s less work.
Someone ought to figure this WP framework vs. BP framework thing out. I’ll be checking out Ron’s work on Buddymatic and here he has one for Hybrid too.
It’s pretty much the process Simon describes.
The only way BuddyPress is going to upgrade without being a pain is if you either use one of the bundled BuddyPress themes as a parent, or use another framework that is kept up to date.
If you build a theme from scratch built on a copy of another theme, or do not create a child theme from a parent that is kept up to date, you are going to have a bad time.
This will always be the case, since BuddyPress is a tight combination of plugin code and theme code.
Forgive me for not having dug through the code as much as I should before commenting. I will do that before I go much further. However, one of the things that Ptah Dunbar and Justin Tadlock have made me think hard about is separation of appearance from functionality.
The goal would be for Hybrid to handle all the WP functionality in a theme “framework” (which I consider ‘less’ than a parent theme). Of course, he would bundle some templates as a starting point, but the core would be in the “functionality” files. For the developer, what is key is the knowing the custom functions, hooks and css rules built into the framework.
OK, now BP comes along. It is adding “functionality” that will hopefully “appear” somewhere. Because Hybrid is the parent, I’d want to put the BP files in the child. Again, BP would ideally be a separation of function from appearance (Andy above suggests that separation is not that good, but I’ll dig through at some point). BP functionality would be placed in the child (e.g. functions.php, .js, etc). Where those functions didn’t conflict with Hybrid, they would just be additional functionality.
Now, the BP templates would go in the child too. They would be hacked into oblivion, but as long as the functions are the same, omitted or supplemented by my own, it shouldn’t matter. When BP is upgraded, I’d have add the new functions/js, but that shouldn’t break my site unless they conflict with existing ones. The painstaking part would be looking through the templates and understanding how the new functions are used and porting what I want and leaving behind what I don’t.
Hybrid would be automatically upgradeable and the functionality part of BP would almost be automatically upgradeable. The painstaking part would be adding the functionality to my existing – custom child theme.
What am I missing?
The bp-default and bp-parent-themes are theme frameworks for the BuddyPress plugin. They show what can be done with the BuddyPress plugin and I appreciate that a lot.
For a current project with WPMU as CMS plus BP for an organization, I went with creating a customized child theme using the bp-sn-parent throughout the site including all blogs for a consistent look and feel.
Aware of the time I could allocate for this project and my average skillset, creating a child theme was the path of least resistance during continuous trunk upgrades of WPMU and BP since I started this project late September for a tentative launch mid to late January. And I would say the time I invested in creating customized child themes was worth it, 10x over.
At this time, all I have to watch for in my child themes are code changes in the files from upgraded parent themes – header.php, footer.php, sidebar.php, home.php, functions.php, style.css, and some new page templates I created.
When the new bp-default theme came out for BP 1.2 trunk, I made a new child theme based on that for blog_id_1 (BP install) specifically because of the new forums layout My only question for the new bp-default parent theme is:
why is it that the only way I could find to avoid getting a white screen when I activate my bp-default’s child theme (with own home.php) is by consistently copying the code of bp-default/activity/index.php over bp-default/home.php ?
@mercime, I appreciate the practical examples. I’m probably going to go with Hybrid as my parent, maybe with the BP-specific template files added for members, groups, etc. I’ll have to see how much functionality is trapped in template files as opposed to styles.css and functions.php. If most of the good stuff is in those two files, it shouldn’t be too bad.
I’m not saying separation is a bad thing, far from it. BuddyPress adds new template tags that have changed from version to version. If you create a theme with these template tags that are no longer present, things will break.
BuddyPress is much more than theme mods.
BuddyPress adds new template tags that have changed from version to version.
Is there a list of these changes somewhere?
I’m currently upgrading my custom theme from version 1.0 to 1.1.3, still based on the classic theme, which avoids the worst problems for now…
@Andy, First, I have nothing negative to say about BP. It is allowing me to do things I would NEVER even attempt on my own. Looking back on the programming I’ve done in the past, there was NO separation (mostly pre-CSS, php/mysql where my separation was myriad includes). However, as I look at Justin’s code, I’m learning the elegance (and additional complication) of separating form from function.
Doing everything through functions.php, styles.css and hooks is a challenge for me, but I do see the benefits. If there are sufficient hooks, most things can be accomplished this way. If there is a hook, I can use the new template tag just by modifying functions.php instead of changing the myriad template files that might contain the new tag.
What sucks (for me) in that model is I have to switch back and forth from template to function and then ensure I test everything well. What works is I get to change it once.
Regardless, for template tags and other changes, what’s most important is documentation (which can be a challenge with development cycles). If the changelog tells me what to look for and what functionality has changed (see Peter’s post above), the process is MUCH less painful. I know you know this, but most of us would rather have the features now and struggle without the docs – Catch 22.
Whatever the result, I’m ecstatic that Buddypress exists, that Automattic adopted it and you finally have some additional help.
