Prepared Statment Update - Dont include blank fields

[Adamhumbug]

HI,

I have a user form on a modal.

The user can be updated from this modal but on the second tab is where the users password can be updated.

The update button commits all changes including the password update.

If the New Password field is blank i do not want it to be updated.

I am using a prepared statement and am not sure how to ommit a field if it is blank.

In actual fact there is a new password and a confirm password field which must be the same before the password field is updated.

if ($_SERVER['REQUEST_METHOD']=='POST'){
	$uid = $_POST['UM-uid'];
	$fname = $_POST['UM-firstName'];
	$lname = $_POST['UM-lastName'];
	$email = $_POST['UM-emailAddress'];
	$accountlevel = $_POST['UM-accountLevelId'];
	$mobile = $_POST['UM-mobileNumber'];
	$roleid = $_POST['UM-roleId'];
	$newpass = password_hash($_POST['UM-pass'], PASSWORD_DEFAULT);


	if(!empty($_POST['UM-firstName'])){
		// prepare stmt
		$stmt = $conn->prepare("
			UPDATE ssm_user 
			SET 
			user_password=?,
			user_email=?,
			user_firstname=?,
			user_lastname=?,
			user_account_level_id=?,
			user_mobile=?,
			user_role_id=?
			WHERE user_id = ?
			");

		$stmt->bind_param('sssssssi', $newpass, $email, $fname, $lname, $accountlevel, $mobile, $roleid, $uid);
    	$stmt->execute();
    	$_SESSION['user']=$fname." ".$lname;
    	$_SESSION['updateUser']="has been successfully updated";
    	$_SESSION['actionstatus']="success";

I am sure i will be able to work out the password confirmation part, its just the omitting password from being part of the update if blank.

[mac_gyver]

dynamically build the sql query with only those fields that you intend to update. since this will also involve dynamically binding the input data, this would be a good time to switch to the much simpler PDO database extension, that will simply let you build and supply an array consisting of the input values that match the prepared query when you call the ->execute([...]) method.

note: the account_level and role_id are permission related and shouldn't be included in the profile edit process when the user is editing his own data, but could be included if a moderator/administrator is editing someone else's profile, so these two fields would need to be dynamically handled depending on who the current user is. you may want to only edit them through a moderator/administrator permission edit interface, rather than to have them as part of the profile edit interface.

if you are doing this for real, you need to test and enforce user permissions to insure that the current user is authorized to both see and process a profile edit form.

if you store validation error messages in an array, using the field/column name as the array index, you can test at any point if there's an error associated with any field/column name, by using isset(). you can test at any point if there are no errors or there are errors by testing if the array is empty or not empty.

copying variables to other variables, without a good reason, is a waste of time. a good reason to do this would be if you were trimming the data. you can do this using a single php statement that will trim all the data at once.

[mac_gyver]

you would also handle the user id differently, depending on if a user is editing his own profile or if a moderator/administrator is editing someone else's profile.