So far we have been loosely using the term Default Theme to refer to both the Default Theme and the upcoming “set of templates”. Perhaps this is a good time to officially assign a name to the “set of templates” in order to ensure clarity during discussions.

I very much like seeing this happen, but why not go one step further and abstract everything into a proper lib full of functions. Kinda like them theme frameworks, like Genesis, are doing it. Why stop at template parts? A carefully created lib of functions give you so much more granular control over your output than template parts..

In my opinion, buddypress will be a game changer if we achieve this. For me working now in pretty big projects with buddypress, the process to convert themes onto buddypress compatible requires too much work and not always well fitted.

Also the work of the core for getting high standars on buddypress plus some plugins will made a rock star platform for social way…

Great stuff, long discussed or should that be whinged on about by many – uncoupling core from theme will drive BP forward far faster, core should never need to worry about theme as it just becomes an impediment as has been seen.

We’ve created a theme framework that we’re currently calling the “SASS Bootstrap Theme” that basically integrates Twitter Bootstrap and uses SASS/Compass to generate the stylesheets required for the theme, making it incredibly easy to reskin your website with just a few quick modifications. Integrating bbPress was a breeze, as we simply copied over the template files and customized the markup to match the requirements of Bootstrap. We plan to also do this for BuddyPress but have sort of been waiting until the process became a bit easier… Is it safe to say that with both bbPress and BuddyPress that we will be able to eliminate some of the theme files in favor of simply using template parts? Would we be able to remove these templates from the theme or are those custom page templates required to be included in the theme?

My other question, regarding BuddyPress, is this: would it be possible to abstract templates into UI parts, rather than specific templates? Basically what I’m after is a way to define the UI markup structure without repeating common elements in other templates. I think that’s sort of what you’re after but I want to verify that this is the case.

This would be a huge benefit to me, so I look forward to seeing what kind of progress is made. I chose to use a theme that had nothing to do with Buddypress, and have been shoe-horning Buddypress into it. It’s messy and doesn’t look as good as I would like.

So the default theme is just going to be built into the plugin? I’ve always thought you should move in the opposite direction, completely separating theme from the programming the way WordPress does.

If you are suggesting doing it the way bbPress has been evolving, oye, there is nothing more frustrating than trying to edit a bbPress page, going through line after line, file after file, until you delete the entire theme folder and the PAGE STILL EXISTS!!!!

I’ve been following Buddypress for over two years and bbPress even longer because I think these projects have a lot of potential and a lot of cool ideas, but I have given up on them the last year or so because usability is just so screwy and doesn’t seem to be getting better.

New to this whole WordPress / BuddyPress, but am encouraged by this news. I’ve loaded BuddyPress just days ago. My question is: Should I wait to work on the site design elements after the Theme Compatibility” process is complete and the set of templates – ‘bundled theme’ or ‘fallback theme are released? Thanks!

@betterbogether The theme compatibility John posted above is about a new process that’s slated for BP 1.7 and quite different and separate from the theme compatibility you would have to go through at this time for BP 1.5.5. I know, it can get confusing at times

For 3 sites, I’ve been rolling my own child theme and using the BP template pack to help with compatibility. It sounds as if updating won’t break my installation, but if I want to make use of the built-in templates, do I just remove my theme’s bp template files?

More importantly, how will the template styles be enqueued? Will I be able to overwrite them with my child theme’s style.css? It sure is a pain dealing with hooks that stuff inline css into the header (but I know you guys don’t do that ).

Side note: did anyone get that more simple bp-compatibility-pack method to work (bp-header.php, , bp-sidebar.php, bp-footer.php)? I tried several times to no avail.

What is the timing of this change, realistically? We are working on a social site that needs a fair amont of customization and potential to grow to hopefully millions of users. We are trying to decide if WordPress/buddypress or Drupal is the right path to go down. Drupal seems to be more customizable today compared to Buddypress.

@homediary Still not sure. Either the next version or the one after. It’s a top priority. We’ve very nearly finished BP 1.6, and we’ll start planning 1.7 in the next few weeks. Keep on eye on our dev blog, http://bpdevel.WordPress.com/, for more info.

I’ve been watching this thread and my concern so far is that whatever is done would be done not just to suit the developer brain so to speak. Functions, hooks… calls are all great but if we really want to get more designers creating themes we need to at least be doing things as easily as WordPress or even further. We also need to be documenting things better but think we all know that one (both on buddypress.org and in our own blogs doing how tos).

One of the hurdles that WordPress had was moving some code into functions and leaving designers playing hunt the code (*cough comment_form). I’d propose if functions are used a similar approach to comment lists and pagination in themes like Twenty Eleven is taken. Have it over-rideable in themes and heavily documented.

I do worry if everything became functions and was as hidden as some frameworks – perhaps this is a nod to better documentation and also having things override-able in child themes (I do worry about a functions.php the size of a novel which can occur in some frameworks). I hope we can keep an element of human/non dev readability. I also dream of the day BuddyPress doesn’t rely on a div#content Whichever route I hope that ‘html5ification’ can happen to the template parts that inevitably will probably (however many) occur.

It’s a fine balance though. I think a key will be documentation on this one whichever route works out. Also listening to many voices and finding what those working with it need / want and why those that aren’t are frustrated. It’s a chance to fix some frustrations with BuddyPress themes.

I also hope that along with this will come the proper theme side ‘use what components you want’ and limit the theme to only those. That’s a hurdle currently preventing themes that people can buy off shelf with just one or a couple of components styled. I personally feel, BuddyPress should be able to have just stream themes, just profile themes, just group directory themes. As a theme designer we shouldn’t have to design every possible thing when creating a theme for sale. There should be a simple ‘don’t activate x, y’ that works without hacks.