xProfile: problem with saving data from Base fields groups

[slaFFik]

It doesn't matter whether I'm in my own profile, or as admin editing somebody's profile. The result is the same - data in Base fields group is not updating.

Here is the screencast showing errors and that strange behaviour:
​http://screencast.com/t/5i7NTgSt

[boonebgorges]

I can't reproduce. Are you running other plugins?

[slaFFik]

No, nothing at all.
WordPress 3.2.1 and BuddyPress trunk.

[boonebgorges]

Until you get error logs up and running (which may show nothing, btw), could you run some tests within xprofile_set_field_data() (bp-xprofile-functions.php:196)? Just put some var_dump() and die() statements in there, to see if you can track down where it's returning false. (I have a feeling it might be at the very beginning of the function.)

[slaFFik]

Incredible..
bp-xprofile-screens.php:101 - sending new data to save.
bp-xprofile-functions.php:196 - receiving that data, but it is old! So I'm saving field all the time with the exact the same value.

[boonebgorges]

Very strange. Are you doing any funny caching? Opcode caching like eAccellerator?

[slaFFik]

My local machine has no caching at all, WP installation has no caching plugins (no plugins at all - except for BuddyPress).
Will try to do smth with it in the evening (in 10-12 hrs).

[r-a-y]

From the screencast, looks like you have a plugin running in /mu-plugins/.
Try disabling it/them?

[slaFFik]

Here is its content:

if(!function_exists('print_var')){
	function print_var($var, $die = false){
		echo '<pre>';
		if(empty($var))
			var_dump ($var);
		else
			print_r ($var);
		echo '</pre>';
		if($die)
			die;
	}
}

So as you can see - it can't influence.

[r-a-y]

I can't reproduce on trunk either.

I know this is drastic, but can you try a fresh setup?

[DJPaul]

I can't recreate on 1.5-beta-2, either.

[slaFFik]

I found the problem. Please see ​ticket 3446. My comment there describes why this happens and patch attached fixes this bug.

[DJPaul]

slaFFik; thanks for investigating this, and finding/patching #3446. Can you confirm if that fix, which is now in trunk, fixes this ticket? If it does, mark the ticket as complete, otherwise I'll spend some time looking into this more.

[johnjamesjacoby]

Replying to DJPaul:

slaFFik; Can you confirm if that fix, which is now in trunk, fixes this ticket?

Best I can tell, that should do it. I renamed the field in the DB and duplicated the brokenness. Then renamed via the UI and confirmed it fixed. Will wait for slaFFik to chime in just in-case.

[slaFFik]

I confirm that in current trunk this problem is fixed. So closing the ticket.