Refactoring BuddyPress plugin / add on template files.
This topic is to further a twitter convo I had with @boonebgorges.
I read the dev chat log and noticed a comment by Boone that said most BuddyPress theme are lame because everyone is essentially cut-n-pasteing the default or just doing a CSS makeover. My reply was if BuddyPress add ons weren’t so dependent on bp-default then people would create custom layouts. If you even move the sidebar to the left you have already broken almost every add on. This is not good for creating new and exciting layouts.
My suggestion is to switch it so plugins do not include redundant files like /add-on/index.php. Instead create a /plugins/index.php that ALL add ons can use. This way it wouldn’t matter which theme you used or how crazy a layout was. The plugin would work because it’s not relying on it’s on template files.
The /plugins/index.php could check its slug and then the plugin could output the code in a plugin loop. i’m not sure the semantics of how to make it work but it seems like something to consider.
I point you towards BP 1.4 and custom post types. John, Boone and I have had discussions about the templating before and it seems to me that a good time to make this change would be when custom post types have been implemented.
I didn’t expect it tomorrow but it’s become a problem when creating different layouts. Good to hear it’s been discussed.
You can still create custom layouts. A lot of plugins allow you to copy the template files across to your current theme. Granted, it’s a lot of work, both the initial conversion and keeping the template files updated, but it’s possible.
Sorry but I’m not creating free themes and then keeping track of 20+ plugins template files. Sure paid themes might be worth it but even then it’s a PITA
Not just a PITA but simply and utterly impractical.
This is a subject I have attempted to raise and get serious dialogue running on from a long ago as ~Jan last year. BP is too intertwined with it’s own theme, naturally one can see why but nonetheless that makes true theming next to impossible in the sense of portable standalone themes as one might create with WP, what we actually see most of the time are simply re-skinnings of bp-default.
There are other issues though that are overlooked seemingly by many where BP needs to take serious stock of how it handles or doesn’t handle separation of core backend from frontend, there still remains much markup written into core simply as it was quicker and easier at the time – we’ve all done it and we’ve all made those comments marking blocks of code as ‘temp’ and to be revisited and improved/removed, that actually needs to happen though and not simply overlooked as it might mean a more involved process of examining how data is passed through to the presentational or view tier.
At present and while creating custom layouts maintained by and for author/client is doable albeit hard work creating true themes one tends to keep coming across those issues that make it seem impractical at this stage in BP’s life cycle.
I’m interested in how custom posts will improve matters as I don’t get that at this stage (that is not meant to say I think they won’t, just that I actually do not ‘get’ how custom posts will work in this respect)
In respect of that aspect being discussed, please keep those conversations very open and transparent please you ‘three’; be wary of ivory towers involve a wide audience of people that have an interest in this side of things, solicit as much feedback as possible.
I think there are a couple things that could be done to improve the situation with respect to themability and plugins. Right now, bp-default contains two generic plugin templates: /members/single/plugins.php and /groups/single/plugins.php. These do, essentially, exactly what @modemlooper suggests in the OP: they provide a shell (header, footer, sidebar, padder, nav) in which plugins can insert their own content. The skeleton component gives a sense of how plugin developers can use them: first, you hook your title to bp_template_title and your content to bp_template_content, then you include the plugin template with something like bp_core_load_template( ‘members/single/plugins’ );
The first problem is that a fair number of plugin authors (myself included, in some cases) have ignored this, and written their own template files that include the header, footer, etc markup that should be left to the plugins.php files, and then included them directly in their plugins. As long as plugin authors do this, it’ll make it completely impractical for anyone to make truly customized themes that look nothing like bp-default. I want to distinguish here from the practice of including overridable templates with a plugin – that is generally a very *good* thing. It’s just that those templates should not include general BP elements, which should be left to the plugins.php files.
The BP dev community should do a better job of making this clear to plugin authors. That means: the skeleton component, the codex, these forums, etc. IMO, that’s the first step toward solving the problem.
The second potential problem is that theme authors don’t know about these files and their purpose. That might be because the files are buried too deep in the structure of bp-default (maybe), or because they are poorly documented (definitely!). We might solve the former by taking @modemlooper‘s suggestion and moving /members/single/plugins.php -> plugins/members.php (and mutatis mutandis for groups). That might make it a little clearer (though it might also cause confusion because it breaks up some of the logic of bp-default’s directory structure). The latter problem is, again, one of education. I don’t think that BP devs and community have done a good job of agreeing upon, and publicizing, best practices regarding theme (or plugin) development. The following rule is a good place to start: BP theme developers should always have files at members/single/plugins.php and groups/single/plugins.php, and the header/footer/etc markup should be mirrored with the other templates so that plugins automatically “work”.
Another thought (as I sit and stare at the plugins.php files!) is to get the wrapper content out of plugins.php altogether, and load plugins.php from inside of home.php like all the other templates. It doesn’t make much sense that the home.php template contains general stuff like navigation for every component (so that it doesn’t have to be reproduced in profile.php, activity.php etc) *except for plugins.php*, which is expected to provide its own markup. I think this sets a bad example, as it suggests that plugin authors should be providing this stuff in their custom templates. I don’t think that this was the intent of building plugins.php that way, but I have a feeling that plugin authors simply copy plugins.php, modify it, and include it in their plugins. (I have done that myself.) It shouldn’t be that way.
FWIW I don’t think that custom post types have anything to do with this. I think Paul was just suggesting that the major refactoring that CPTs will require might provide a good opportunity to rethink the structure of bp-default and of BP templating in general, since the car will already be on the lift, with its engine removed
All very good points made Boone, in fact it brings to mind when I was starting to think about getting a handle on plugin writing in general that I did the obvious and started to look through a few of the better known ones that I deemed written by those that knew their stuff as those should have guided me in the general structure and approach yet what I actually found was that NOT one was written in anything like the same manner and I was quite surprised and a little forlorn that they helped my understanding little or gave me much of a clue how best tp proceed, I fell back to the skeleton component as my de facto guide – which after all it ought to be and thus found myself happy with the notion of working with plugins.php – note to all concerned: bet that issue with title function still remains though!-
Of course this still leaves the issue of plugin authors following their own path and the comment:
don’t think that BP devs and community have done a good job of agreeing upon, and publicizing, best practices regarding theme (or plugin) development
Becomes therefore one requiring remedial attention? even if things may change it suggests that perhaps due instruction along with a strong warning of the consequences arising from deviation from said approach possibly causing theme issues needs to be added to the codex and the skeleton component given an overhaul as I found issues with that I had to work around or simply puzzle out as to why I was getting no action.
Could try moving the wrapper stuff out of the plugins.php template and including via home. Need to see how the actions around plugins.php are used and how this might affect the members’ settings screen, for example.
Coming later to the party here but there are 2 road blocks as I see causing ‘same themes’ and a dependency on bp-default:
1. Flux and before until very recently not knowing when something will change – it’s easier to rely on something like bp-default. This is far less a point now and is increasingly less of one. I think there has been an incredible push in communication and the sheer focus on themeing in BuddyPress … it’s an exciting time.
2. Plugin authors being so tied to a fault to bp-default.
Anything that can make it more fluid and less dependent frees up designers to even in commercial themes with the updating and support constraints to go more extreme and push what a BuddyPress theme does.
The forum ‘BP-Default’ is closed to new topics and replies.