[jreeve]

You’re right–putting it lower in the loading order fixed it. Thanks!

[jreeve]

I’m putting this in my theme’s functions.php, just to test it out there. But the function will eventually be triggered when a user registers for the site, wherever that appears in the code.

[jreeve]

Thanks @r-a-y, that works like a charm.

[jreeve]

Thanks @r-a-y! Internal link breakage is something I hadn’t fully considered, thanks for that. That might keep us from renaming this slug, after all. But if we do decide to do it, I’ll look into this hooks.

[jreeve]

@danbp, changing the parent forum name doesn’t have any effect on the slug.

[jreeve]

Hi @danbp,

I’m familiar with how BuddyPress tests work in general, and so I’ve read https://codex.buddypress.org/developer/automated-testing/ and https://codex.buddypress.org/developer/automated-testing/writing-automated-tests-for-buddypress-dependent-plugins/, but what I’m asking is, what’s the best-practices way of writing an automated setup for automated tests, in the style of install-wp-tests.sh, so that tests will run on any machine, and not just my own development box (i.e. Travis, etc.)? If you look at that file, you’ll see that it installs WordPress in /tmp so that it can test against it, using the function install_wp(). I figure I also need a function install_bp() that would do something similar with BuddyPress. Simple enough. But I was wondering whether someone already has a setup like this in their install-wp-tests.sh, so that a) I didn’t have to go about the process of writing my own, and b) I can take advantage of whatever optimizations experienced BP developers may have made in this process, which I might be unaware of. Do you know of a setup like that? For instance, what do you use to set up your Travis box so that it can automatically run tests for your plugins?

[jreeve]

Added https://buddypress.trac.wordpress.org/ticket/6281#ticket.

[jreeve]

I’ll add this to Trac as a feature request, then.

[jreeve]

Thanks for that, @r-a-y. I added that function to my theme so that our custom .mo file will still load when we upgrade to 2.1. But even if the file still loads, will it work if the line numbers are off? That’s to say, if the line numbers in our .mo file still correspond to a previous version of BP, will they still work in the current version of BP? If not, is there a way I can programmatically map all the older translations to the new translations file, without having to rewrite it?

[jreeve]

Thanks @danbp. I got it to work by doing this:

cd /path/to/wp-content/plugins
svn co https://buddypress.svn.wordpress.org/trunk/src buddypress

And then installed the bp-default theme manually with this:

mkdir buddypress/bp-themes
cd !$
git clone https://github.com/buddypress/BP-Default.git

[jreeve]

In case anyone else runs into this issue, I’ve created issue #5827 here: https://buddypress.trac.wordpress.org/ticket/5827#ticket

[jreeve]

@danbp: in fact, bp-core-template.php is what I’ve been describing. I guess you’re saying that if there isn’t a function that does this thing? Maybe this belongs as a bug report instead of a support forum thread. I’ll open trac tickets for this.

[jreeve]

Thanks @shanebp. debug_backtrace() seems to be pretty helpful in that respect. It seems like the error is coming from cbox-theme. I’ll see if I can reproduce it on a clean install and if so, submit a bug report to them about it.

[jreeve]

It’s definitely a theme or plugin issue. The error is in my debug.log. I already have wp_debug activated, which is how I can see these errors.

I’m using a theme I wrote, based on the cbox-theme. Tons of plugins, but mostly those included in CBOX.

[jreeve]

@skyrie, You’ve probably already figured this out by now, but in case anyone else wants to know how to do this, you can put this code in your functions.php:

function my_admin_bar_change_howdy_target( $wp_admin_bar ) {
        $user_id = get_current_user_id();
        $current_user = wp_get_current_user();
        $profile_url = get_edit_profile_url( $user_id );
        if (substr($profile_url, -5) == 'edit/') {
                $profile_url = substr($profile_url, 0, -5);
        }

        if ( 0 != $user_id ) {
                /* Add the "My Account" menu */
                $avatar = get_avatar( $user_id, 28 );
                $howdy = sprintf( __('Howdy, %1$s'), $current_user->display_name );
                $class = empty( $avatar ) ? '' : 'with-avatar';

                $wp_admin_bar->add_menu( array(
                        'id' => 'my-account',
                        'parent' => 'top-secondary',
                        'title' => $howdy . $avatar,
                        'href' => $profile_url,
                        'meta' => array(
                                'class' => $class,
                        ),
                ) );

        }
}
add_action( 'admin_bar_menu', 'my_admin_bar_change_howdy_target', 11 );

Also I’d love to hear suggestions for better ways of doing this, in case anyone has any.

[jreeve]

Great! That’s way simpler than I thought. I saw the images with the UUID-looking filenames, and I assumed that it was more complicated than that.

I was able to copy one avatar to all the rest with this BASH magic:

for i in {336..368}; do sudo cp -R 370 $i; done
for i in {336..368}; do sudo chown -R www-data:www-data $i; done

where 336 and 368 were the group IDs of the start and end group I wanted to change.

[jreeve]

I’ve since discovered that I can filter the function that gets the group avatar, but I just want to set a particular avatar instead of overriding the default. Is there a way to do that?

[jreeve]

Ok so I figured it out: https://gist.github.com/JonathanReeve/10425661

[jreeve]

I *sort of* got it to work with this hack, although I can’t figure out a way to truly remove the input tag, since it seems to be necessary:

                          <?php if ( 'textbox' == bp_get_the_profile_field_type() ) :  ?>

					<?php if ( 'Name' == bp_get_the_profile_field_name() ) : ?> <!-- Don't allow users to edit their names. --> 

						<label for="<?php bp_the_profile_field_input_name(); ?>"><?php bp_the_profile_field_name(); ?> <?php if ( bp_get_the_profile_field_is_required() ) : ?><?php _e( '(required)', 'buddypress' ); ?><?php endif; ?></label>
						<!-- Dummy input, disabled in CSS, because otherwise saving anything causes the user's full name to be overwritten with the username. --> 
						<input type="text" name="<?php bp_the_profile_field_input_name(); ?>" id="<?php bp_the_profile_field_input_name(); ?>" value="<?php bp_the_profile_field_edit_value(); ?>" <?php if ( bp_get_the_profile_field_is_required() ) : ?>aria-required="true"<?php endif; ?> style="display: none;"/> 
						<!-- The thing that actually displays. --> 
						<p id="name"><?php bp_the_profile_field_edit_value();?></p> 

					<?php else : ?> 

						<label for="<?php bp_the_profile_field_input_name(); ?>"><?php bp_the_profile_field_name(); ?> <?php if ( bp_get_the_profile_field_is_required() ) : ?><?php _e( '(required)', 'buddypress' ); ?><?php endif; ?></label>
						<input type="text" name="<?php bp_the_profile_field_input_name(); ?>" id="<?php bp_the_profile_field_input_name(); ?>" value="<?php bp_the_profile_field_edit_value(); ?>" <?php if ( bp_get_the_profile_field_is_required() ) : ?>aria-required="true"<?php endif; ?>/>

					<?php endif; ?>

				<?php endif; ?>

[jreeve]

Thanks. Although it looks like adding && 'field_1' != bp_get_the_profile_field_input_name() ) has an unexpected effect: with this in place, changing any other editable field and saving it causes the user’s full name to be overwritten by his username slug, i.e. the name “Jonathan Reeve” is overwritten by “jreeve.” I can’t figure out what’s causing this.

[jreeve]

Great. Where/how can I override that template?

[jreeve]

I can sort of do what I want by putting this a plugin:

function filter_out_membership_activities($a, $activities, $args){ 
	$args[per_page] = 9999; //We have to edit the full list, otherwise we'd just be editing the first 20 items 
	global $activities_template; 
	$activities_template = new BP_Activity_Template($args); //rebuild activities based on new args
	$i=0; 
	foreach ($activities_template->activities as $activity) { 
		if ($activity->type == 'joined_group') { 
			unset($activities_template->activities[$i]); //get rid of membership activity items
			$activities_template->activity_count = $activities_template->activity_count - 1; //change the count to reflect this 
			$activities_template->total_activity_count = $activities_template->total_activity_count - 1; 
		} 
		$i = $i + 1; 
	} 
	$activities = $activities_template; 
        error_log(print_r($activities)); 
	return array($a, $activites, $args);
}

add_filter('bp_has_activities', 'mla_filter_out_membership_activities', 10, 3); 

The print_r($activities) shows the correct activities list, but that isn’t reflected in the actual activities displayed. I think I’m missing something here about how filters work, how parameters are being passed through them, and which ones get edited. What am I doing wrong?