No. In the past you could do that but not with new template compatibility. You would need to unhook bp adding those files and then add your own.
@henrywright-1 Why are you choosing to work that way rather than running with theme compat template files? You do have a choice no way is right or wrong though if running the older style template approach you would need to have declared add_theme_support( 'buddypress' ); to ensure js/ajax unlinked, there is an issue with this though in that BP tries to get this value too early so fails to bail out of the theme compat class, so it needs to be positioned outside of a hook such as ‘after_setup_theme’ to be run early enough for bp.
@modemlooper Thanks, I’ll give that a shot but then I may decide not to edit them altogether as they work well already. I could add my own .js elsewhere
@hnla the site I’m working on was built pre BP 1.7 so uses a child theme of bp-default. I thought that BP assumes add_theme_support for bp-default child themes?
‘Assumes’ ? assumptions dangerous things those, I would verify if that’s the case then.
@hnla apologies should have explained that a bit better – i’m not assuming, I think BP does the assuming. Take a look at the last line of Boone’s post:
BP Theme Authors: make sure your theme registers 'buddypress' support
ah ok, however I would still want to know what in a child theme prompts BP to assume (& it still stands: Assumptions are a bad thing altogether, period 🙂 ), didn’t spot that in the ticket referenced and as I’ve mentioned there is one issue we know of.
Yes definitely agree with that! especially in this case where loading the theme compat stuff unnecessarily will cause a little extra overhead.
Can I ask – would you take this approach? e.g. still use a child of bp-default? or would you opt to use the new template hierarchy? I have always been an admirer of the bp-default theme (not so much the styles (I dequeue the CSS) but more so the ajax and js that comes with it).
@henrywright-1
I think on balance I would tend now to favour going the theme compat route, as the process best to follow in all theme/site building respects, we added extended capabilities with the template hierarchy which make it more useful and the templates and styles were updated and improved.
But the other approach is perfectly valid and leaves full templates directly in your control.
Personally I like the the ability, though, of being able to neatly segregate BP templates under one root dir /community/ or /buddypress/
As for the js being the reasoning remember that both approaches essentially use copies of the same file/s so you still get those either way, one thing I’d like to see and may propose is the main js & ajax files being centralized as bp assets that both approaches could access rather than maintained separately in the theme folders – although that is the place they ought to live really.
This whole question of approach taken is one I’ve raised as there are confusing aspects and I want a codex guide that outlines the approaches on offer and brings some clarity to making choices, which we’ll pencil in to the new guides once Codex is straightened out.
@hnla
As you say both approaches are valid which makes the choice difficult. A Codex guide on the advantages and disadvantages of each approach would be V useful. I find the attraction with bp-default is it is tried and tested. That said, the template hierarchy allows me to ‘get my house in order’ – everything in my theme that is BP is filed nicely under a community folder which makes good sense for maintenance or development down the line.
I’m sure there are more advantages with each route so a Codex guide on this would certainly be useful to me at least.
