Skip to:

Opened 13 years ago

Closed 13 years ago

#3390 closed defect (bug) (fixed)

xProfile: problem with saving data from Base fields groups

Reported by: slaffik's profile slaFFik Owned by: slaffik's profile slaFFik
Milestone: 1.5 Priority: normal
Severity: normal Version: 1.5
Component: Extended Profile Keywords:


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:

Change History (16)

#1 @boonebgorges
13 years ago

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

#2 @slaFFik
13 years ago

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

#3 @boonebgorges
13 years ago

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.)

#4 @slaFFik
13 years ago

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.

#5 @boonebgorges
13 years ago

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

#6 @slaFFik
13 years ago

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).

#7 @DJPaul
13 years ago

  • Cc DJPaul removed
  • Keywords reporter-feedback added

#8 @r-a-y
13 years ago

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

#9 @slaFFik
13 years ago

Here is its content:

	function print_var($var, $die = false){
		echo '<pre>';
			var_dump ($var);
			print_r ($var);
		echo '</pre>';

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

#10 @r-a-y
13 years ago

I can't reproduce on trunk either.

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

#11 @DJPaul
13 years ago

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

#12 @slaFFik
13 years ago

  • Keywords reporter-feedback removed

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

Last edited 13 years ago by slaFFik (previous) (diff)

#13 @DJPaul
13 years ago

  • Milestone changed from Awaiting Review to 1.5

#14 follow-up: @DJPaul
13 years ago

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.

#15 in reply to: ↑ 14 @johnjamesjacoby
13 years ago

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.

#16 @slaFFik
13 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.