[adamt19]

Adding this code above $this->$pag_links to bp-members-template solved the issue for us..

/**
			 * Defaults to an empty array to make sure paginate_links()
			 * won't add the $page_arg to the links which would break
			 * pagination in case javascript is disabled.
			 */
			$add_args = array();

			if ( ! empty( $search_terms ) ) {
				$add_args['s'] = urlencode( $search_terms );
			}

			$this->pag_links = paginate_links( array(
				'base'      => add_query_arg( $pag_args, $base ),
				'format'    => '',
				'total'     => ceil( (int) $this->total_member_count / (int) $this->pag_num ),
				'current'   => (int) $this->pag_page,
				'prev_text' => _x( '←', 'Member pagination previous text', 'buddypress' ),
				'next_text' => _x( '→', 'Member pagination next text', 'buddypress' ),
				'mid_size'  => 1,
				'add_args'  => $add_args,
			) );

[adamt19]

This may also be a WPEngine thing, so I’m going to ask them to comment on the possibility of this being a problem with the way they handle sessions

[adamt19]

@djpaul I’d be happy to, but may take a while for a me to figure out (is the server invalidating the session? or what is deleting the cookie? etc.) so if anyone feels like assisting the investigation I’d gladly accept the help!

[adamt19]

I discovered that this (example) cookie:

bp-members-search=a:10:{s:8:”field_28″;s:3:”Men”;s:7:”field_4″;s:6:”Female”;s:7:”field_3″;s:2:”27″;s:10:”field_3_to”;s:2:”35″;s:7:”field_8″;s:5:”80209″;s:9:”zipradius”;s:2:”10″;s:9:”field_112″;s:0:””;s:8:”field_65″;s:0:””;s:3:”dev”;s:1:”y”;s:2:”bs”;s:1:”+”;};

is deleted when you view a member’s profile from search results.

So, with ajax enabled in members search, if you go back to the search results and then click “next”, i THINK this is why the next set of results do not respect the search params? But I haven’t proven that yet. Still working through global js

[adamt19]

@r-a-y I noticed you worked on a similar issue for when ajax is enabled in the messaging views.

I can provide guest account credentials if you’d be willing to help out here — live site issue at the moment D:

[adamt19]

So this only matters if upgrading via wp-admin, because of a disable/re-enable routine? Had no problems deploying to other environments via git/sftp/ssh.

Makes sense though. Will wrap to future proof this for later. Thx!

[adamt19]

here’s what im seeing in error logs:

user XXXXX not found: /XXXXX/profile/change-avatar/, referer: http://website.com/XXXXX/profile/change-avatar/

for the user, its showing 502 errors

[adamt19]

Any update on this?

[adamt19]

Again this is only occurring with the first two profile groups on the edit screen: Base & About.

Our extended profile group doesn’t have this issue for some reason.

[adamt19]

@shanebp in wp_bp_xprofile_fields there is only one instance of each field/question

[adamt19]

Hi @shanebp

This issue has popped up again and oddly enough when I do a complete ‘site-copy’ (WPEngine tool) and move the site to another install, the issue disappears. WPE is trying to help but we’re all scratching our heads on even where to begin.. any ideas?

When identical code /plugins can show symptoms on one server and not on another server.. It’s hard to believe it’s a “plugin conflict” or “theme issue”, but any more suggestions would be greatly appreciated! We’re in maintenance mode on the live site so to avoid users saving double information in the database..

[adamt19]

^.. but this code has been in functions.php for months, whereas this issue is like a week old. Still baffled. And the ‘base’ profile group still has the issue.

[adamt19]

I had replaced ‘edit’ and ‘profile’ templates with those that come with SD, and the problem persisted, so I was trying to narrow down which custom functions may be causing the issue, by deleting one section at a time.

This led me to the following discovery. Deleting this code:

global $bp_tabs;

  /* MM: The new array for our "base" information  */
  $bp_tabs['about'] = array(
      'type' => 'regular',
      'name' => apply_filters('kleo_extra_tab2',__('About', 'kleo_framework')),
      'group' => __('About', 'kleo_framework'),
      'class' => 'regulartab'
  );

.. fixes the issue for the ‘About’ profile group.

[adamt19]

Actually the ‘fixed’ profile group2 is related to something I deleted in functions. This is super weird. I guess I’ll report if I find it.. for future reference if anyone has a similar issue in their theme.

[adamt19]

Deleting the 4th profile group did not re-introduce the problem on the 2nd profile group.

In other words, adding then deleting a 4th profile group fixed the issue for profile group no. 2.

THis is so weird.

[adamt19]

Ya I’m using sweetdate. Definitely a child-theme issue. I restored to base SD and it went away. I’ve disabled all plugins (other than BP) and am deleting functions.php code like 100 lines at a time.

interestingly, I added a 4th profile group, and now this problem only occurs on the FIRST profile group. The second profile group (About) no longer repeats fields.

I know it’s not your job to support this! 🙂 just wondering if anything popped into mind. I have the production site in maintenance mode because if people edit + save their profiles with the repeated fields populated, it’s saving the information doubly as well, which will persist even after I fix this bug. D: eek.

[adamt19]

ANy ideas? we use WPEngine – perhaps something to do with object caching?

THis is a big deal because when profiles are edited and saved, the information duplicates in the DB and displays duplicated on the front side for multi-select options.

[adamt19]

Thanks @shanebp

Attaching mixpanel analytics to buddypress activity on an active site is wildly entertaining.

I’m trying to figure out how to isolate “Viewed Single Message”, since the user is redirected to the single-message view after they send the initial message.

Right now composing a message fire both the “Sent message” and “Viewed message” events.

In BP is there a way to capture whether a user is viewing a message vs. simply being redirected to their message? I was thinking of just checking for POST data.. would need to work with the ajaxy replies as well.

[adamt19]

messages_message_sent seems to work. So I guess the follow up question is how to check:

is the message updating an existing thread *where other members have also submitted messages*, OR
is the message a new-message (or is the person simply sending a second message after not receiving a reply?)

I’m hoping to use that information to send additional data about the message sent event (new vs reply..)

As always, will post my steps if I figure it out on my own 😉

add_action( 'messages_message_sent', 'mm_mp_message_sent', 10 );

function mm_mp_message_sent() {	 
	$mp = Mixpanel::getInstance("xxxxxxxxxxxxxxxxx");
	global $bp;
	$mp->identify($bp->loggedin_user->id);
	$mp->track("Sent message");
}

[adamt19]

This has happened to me in trying to upgrade from 2.0.1 to 2.0.2

Why should upgrading cause fatal errors for those who call built-in BP functions in their functions.php?

[adamt19]

add a step parameter to the action?

eg action=”/register/?r=submitted”

🙂

[adamt19]

@ircsome will try it – but seems like that would eval TRUE on every registration page load (including initial visit)

[adamt19]

This worked for me

function no_photos() { 
	global $wpdb;

	$nophotoids = array();
	
	$ids = $wpdb->get_col( "SELECT ID FROM {$wpdb->prefix}users" );

	foreach( $ids as $id ) { 

		$avatar_check = false;
   
		if ( preg_match('/mystery-man.jpg/', bp_core_fetch_avatar( array( 'item_id' => $id, 'no_grav' => true, 'html'=> false ) ) ) )			
		  $avatar_check = true; 

		if( ! $avatar_check ) { 
			$nophotoids[] = $id;
		}
	}
		
	$nophotoids = implode(",", $nophotoids);
		
	echo 'no photo ids: ' . $nophotoids;
	
		
}

[adamt19]

Is any config changes needed for this to work (eg disable gravatar service, or something)?

[adamt19]

@shanebp thanks but unfortunately this doesn’t return anything. We do have hundreds of users with the default gravatar/grey buddy image. These are the people I’m trying to isolate. Returning just the IDs of these people is fine.

Any other ideas of how to modify the snippet to return those users?