Changed form variables don't save to DB

Von Steiner 23 May, 2011
Hi All,

Here's my puzzle:

I have a multi-page form which collects monthly or hourly salary information and for reasons of consistency, if it's a monthly wage, converts it to an hourly wage. This involves changing the pay period text of "per month" to "per hour" from one field and calculating the hourly rate inferred from the hours worked each day in a typical week (entered as 7 numbers).

I've written the PHP code to do this and can echo the correct results to the confirmation page. The form data saves successfully to the DB, EXCEPT for the changed form data. Even though I have saved the modified wage and the modified time period back to the POST array using JRequest (and used JRequest to retrieve it to the confirmation page, successfully), the wage and time period date remains unchanged - as the user entered it.

The child form which collects the data does nothing with the database. The mother form saves everything on submit and nothing has changed with that.

Even a dump of the $_POST array shows the correctly altered wage and time period. It just doesn't show up in the DB in the new record - the user entries do.

In desperation, I have tried resetting the form connection to the data tables, but that doesn't help. Could it be the run order? I'm not sure what to do there if so.

How is it saving the unaltered POST array? Are there two copies? Is it in the wrong sequence?

Here's the full code from the On Submit box:

<?php
//*************** BLOCK 1 *****************
/* This code takes the hours submitted for each day of the week, 
and concatenates them into one string for the start and another 
string for the end of employment.  It also adds up the weekly hrs 
for the monthly hours calculation.
	
It goes in the On Submit code box in Chronoforms */
	 
	// use explode to put comma-delimited string in POST array into PHP array
	// NOTE TO SELF: use JRequest instead of POST below: $gethrs=JRequest::getFloat('hrs','post');
	$dailyhrs = explode(",",$_POST["hrs"]);
	
	// Initialise variables
	$staemphrs="";
	$endemphrs="";
	$sta_tot_wkly_hrs=0;
	$end_tot_wkly_hrs=0;
	
	// use trim to remove any spaces; padding w/ zeroes not nec w/ delimiter
	for ($i=1; $i<=7;$i++) {
	 $sta_tot_wkly_hrs = $sta_tot_wkly_hrs + $dailyhrs[$i];
  	 $staemphrs = $staemphrs . trim($dailyhrs[$i]).'^';
	 $end_tot_wkly_hrs = $end_tot_wkly_hrs + $dailyhrs[$i+9];
	 $endemphrs = $endemphrs . trim($dailyhrs[$i+9]). '^';
}
	// Remove final delimiter with substr (otherwise too many)
	$staemphrs = substr($staemphrs,0,-1);
    $endemphrs = substr($endemphrs,0,-1);
	
	//Assign POST variables the value of the strings
	JRequest::setVar('stHrsDbString',$staemphrs);
	//$_POST['stHrsDbString'] = $staemphrs;
	JRequest::setVar('endHrsDbString',$endemphrs);
	//$_POST['endHrsDbString'] = $endemphrs;

//*************** BLOCK 2 *************************
// This code converts monthly wage figures to hourly for DB consistency

	//Starting salary
	$sta_pay_period = JRequest::getVar('empstaregpayperiod','','post');
	$sta_pay_amt = JRequest::getVar('empstaregpayamt','','post');
	if ($sta_pay_period = "per month") {
    //4.345 weeks per month on avg
	$sta_hrs_month = $sta_tot_wkly_hrs * 4.345;
	$sta_hr_wage = round($sta_pay_amt/ $sta_hrs_month,2);
	//change submitted amount and period
	$sta_pay_period = "per hour";
	JRequest::setVar('empstaregpayperiod',$sta_pay_period);
	JRequest::setVar('empstaregpayamt',$sta_hr_wage);
}
	//End or current salary
	$end_pay_period = JRequest::getVar('empendregpayperiod','','post');
	$end_pay_amt = JRequest::getVar('empendregpayamt','','post');
	if ($end_pay_period = "per month") {
    //4.345 weeks per month on avg
	$end_hrs_month = $end_tot_wkly_hrs * 4.345;
	$end_hr_wage = round($end_pay_amt/ $end_hrs_month,2);
	//change empendregpayperiod to "per hour"
	$end_pay_period = 'per hour';
	JRequest::setVar('empendregpayperiod', $end_pay_period);
	JRequest::setVar('empendregpayamt', $end_hr_wage);
}
		
//Output to screen for debugging:
	/*
	echo "stHrsDbString ="; 
	echo $_POST["stHrsDbString"];
	echo "<br />";
	echo "endHrsDbString = ";
	echo $_POST["endHrsDbString"];
	echo "<br />";
	
	echo "Starting weekly hours total is: ";
	echo $sta_tot_wkly_hrs;
	echo "<br />";
	echo "Ending weekly hours total is: ";
	echo $end_tot_wkly_hrs;
	echo "<br />";
	*/
	
	echo "The starting wage is (reg, JRequest) <strong>";
	echo $sta_hr_wage;
	echo ", ";
	echo JRequest::getVar('empstaregpayamt','','post');
	//echo "</strong> $sta_pay_period<br />";
	$temp=JRequest::getVar('empstaregpayperiod','','post');
	echo "</strong> $temp<br />";
	
	echo "The ending wage is (reg, JRequest)<strong>";
	echo $end_hr_wage;
	echo ", ";
	echo JRequest::getVar('empendregpayamt','','post');
	$temp2=JRequest::getVar('empendregpayperiod','','post');
	echo "</strong> $temp2<br />";
	
	// The $_POST dump shows that the changed form data are correct.
	echo var_dump($_POST);
		
?>


Thanks in advance for any suggestions.

[EDIT] ...And yes, I've checked that the manipulated fields still match up with the database table columns. The site is on my dev PC internal network, so not available publicly.
GreyHead 23 May, 2011
Hi Von Steiner,

Is this ChronoForms v4? If so the modified data has to be added to $form->data['input_name'] to be saved.

Bob
Von Steiner 23 May, 2011
Hi Bob,

Oops, sorry, left that key info out. No, I'm using

Chronocontact 3.2
Joomla 1.5.22

on XAMPP with
MySQL 5.5.8
PHP 5.3.5

Do I still have to add it to something? Do I gather that Chronoforms doesn't use the $_POST array directly in the DB queries?

Many thanks,

Justin
GreyHead 23 May, 2011
Hi Von Steiner ,

Ok, in CFv32 your code needs to be in the OnSubmit Before Email box; the DB Connection must be set to 'after email'; and 'Send Emails' must be set to 'Yes' on the Form General tab.

Does this fix the problem?

Bob
Von Steiner 24 May, 2011
Hi Bob,

No, it still doesn't work. It saves the user-entered data instead of the version modified by my code.

The code is in the "On Submit Before Email" box on the child form; the DB connection on the mother form (which is the only form with a db connection) is set to 'after email' (it was set to 'before email' previously) and 'Send Emails' is set to 'Yes' on both mother and child forms.

Here is the sequence:

1. run mother form
2. run child form empinfo
3. run child form empinfo confirm
4. run child form ayiempreport
5. run child form ayiempreport confirm
6. end mother form which is connected to 2 DB tables

The data from all the forms saves correctly in both DB tables the mother form is connected to *EXCEPT* for the data changed in the POST array by my PHP code. So I know it is connected to the database.

It correctly saves a separate string I create in that same code block - but won't save those two fields. In fact, I just did a test and it won't save any field I try to set with the syntax:

$comment = "The lunatics have taken over the asylum";
JRequest::setVar('rcomment', $comment);	


[EDIT] Except, it seems the strings 'stHrsDbString' and 'endHrsDbString' set earlier in Block 1, which do consistently get saved correctly.

Somehow, setVar seems to work on the POST array (var_dump shows the changes), but these changes are not showing up in the DB. Seems that the DB query isn't getting updated or something?

Thanks for your help. I feel bad about the taking up your time, but I can't find any documentation on this at all.

Justin
Von Steiner 24 May, 2011
The plot thickens.

I was relying on

echo var_dump($_POST);

(which I inserted in my On Submit before box for debugging) to supposedly print the POST array variables. It echoes an array which shows the correct processed values for the variables I am trying to change.

HOWEVER, turning on the Chronoforms debug, I get a different dump page bottom, also labelled $_POST array, that shows the variables I am trying to change with their original values. So it would seem that the Chronoforms POST array is the one being saved to the DB, not the one I've been fooling around with.

Which one is the real Spartacus? ("I am $_POST array...No, I am $_POST array... No, I am... etc, etc.)

What is going on here? How do I change the important one?

I have "Chronoforms handle my posted arrays" set to "Yes" everywhere.
GreyHead 24 May, 2011
Hi Von Steiner,

In case you haven't done so, you need to refresh the DB Connection after any changes to database column names. In the Form Editor click the DB Connection tab and set the Connection to 'No'. Click the 'Apply icon in the toolbar to save the form, open the DB Connection tab, set the Connection back to 'Yes' and re-save the form. This will refresh the copy of the table information that ChronoForms uses.

Bob
Von Steiner 24 May, 2011
HI Bob,

Tried that, as I mentioned in the first post, and I tried it again just now. No change (though no database columns were changed). It still doesn't save.

I've now found that the fields I thought were saving aren't, so at least we have a consistent no saving situation, instead of the previous "some are, some aren't" dilemma.

I'm going to have a poke around the form back ends and see whether there's anything I can track down there.

Do you have any idea why the chronoform debug POST array values are different from the var_dump($_POST) values?

Justin
GreyHead 24 May, 2011
Hi Justin,

There is only one $_POST array - though the contents can change. From memory the DeBug report is run at the end of the processing; and the data saved is from the $_POST array when the DB Connection is run.

My guess is that there is a problem with the work-flow and the data is being saved before you process it.

Bob
Von Steiner 24 May, 2011
Hi Bob,

The only explanation must be that the query and the debug output is formed before the custom code is executed.

Anyway, I got it to work by putting all the code in the On Submit Before box of the *mother* form instead of the child form. It all goes in fine now.

Thanks for your time and help.

Justin

P.S. Is there somewhere I can learn this stuff (what runs when and so on) instead of wrestling for days with it and bugging you? How did you learn it?
GreyHead 24 May, 2011
Hi Justin,

I learnt mostly be wrestling with it; answering a lot of questions here and writing a book about it. Not necessarily the best approach :-)

Feel free to ask questions before you wrestle too far.

Bob
This topic is locked and no more replies can be posted.