When implementing a custom component in BuddyPress, you will often have additions for the member theme. Member themes live in their own folder, /wp-content/bp-themes/.
To render a member theme template, your component will call dpa_load_template() which takes an argument of the name of the template to load. The path is hardcoded to the /wp-content/bp-themes/ folder.
The problem with this is that after installation of a custom component, the site administrator will need to move the relevant member theme files (bundled with your component) into /wp-content/bp-themes/. This is an annoyance to site administrator, and it may end up being a frequent support request (“why is X not working?”). This very first hurdle may even stop people trying out your component.
Something else I’ve seen is that when installing future updates, people may forget that they need to move the updated member theme files into place; this can cause incompatibility issues between versions of your software, something we’ve seen with recent versions of BuddyPress.
For my upcoming “Achievements” plugin (think a cross between forum points and Xbox Live), I decided all that I wanted the site administrator to do would be to download it from the Plugins admin panel – no moving files into the member theme.
So, I present to you my code: (06/01/10 – updated for BP 1.1.3+)
bp_core_load_template( 'yourcomponent_theme_filename' ); // loads /plugins/your_plugin/filename.php
function yourcomponent_screen_filter_template( $located_template, $template_name ) {
if ( !empty( $located_template ) )
return $located_template;
if ( $bp->current_component != $bp->your_component->slug )
return false;
if ( false !== strpos( $template_name[0], 'yourcomponent_theme_' ) ) {
$prefix = strlen( 'yourcomponent_theme_' );
$template_name = substr( $template_name[0], $prefix, strlen( $template_name[0] ) - $prefix );
$template_path = WP_PLUGIN_DIR . "/your_plugin/$template_name";
if ( file_exists( $template_path ) )
return $template_path;
}
return false;
}
add_filter( 'bp_located_template', 'yourcomponent_screen_filter_template', 10, 2 );
Ray and 
Paul Gibbs are discussing. 
Ray 6:18 am on May 14, 2010 Permalink |
Hey Paul,
Was meaning to reply to this the other day, but got sidetracked!
Just tried it and it does what I want it to do, except for one instance.
I’m trying to override a string that BP uses on an AJAX request (in my case, when a private message is sent, BP outputs a message).
I’ve tried overriding the string by hooking into the “init” action, but not sure if this is the correct action I should be hooking into.
Here’s the full function:
function ray_override_l10n() {
global $l10n;
$mo = new MO();
$l10n['buddypress'] = &$mo;
if ( isset( $l10n['buddypress'] ) ) {
$l10n['buddypress']->entries['There was an error sending that message, please try again']->translations[0] = 'You are not friends with the person(s) you are attempting to send a message to. Your message has not been sent.';
$l10n['buddypress']->entries['There was a problem sending that reply. Please try again.']->translations[0] = 'You are not friends with the person(s) you are attempting to send a message to. Your message has not been sent.';
}
}
add_action( 'init', 'ray_override_l10n' );
Any ideas?
Paul Gibbs 7:18 am on May 14, 2010 Permalink |
For Welcome Pack’s email feature, I use the above technique and have it hooked in like so:
add_action( 'init', 'dpw_load_dynamic_i18n', 9 );Have a look dpw_load_dynamic_i18n() in Welcome Pack’s core.php. It is a bit hard to read as there’s a pair of nested FOR loops, but would suggest you use MO->add_entry() etc rather than write directly to the arrays. I think I switched to doing that after I wrote the above post.
Ray 8:10 am on May 14, 2010 Permalink |
Paul, thanks for the moment of clarity!
Of course it has to do with setting the priority for the init action! *slaps head*
Thanks also for the add_entry() tidbit, I’ll look into that!