Are you saying one of these inputs , e.g.$_POST["attend_state"] is a checkbox?
If a checkbox is not checked then it won’t be present in the POST array. This will cause a query error as $_POST[“attend_state”] is not found.
Be sure to check values before processing.
RE: $msg double check button name compared to coding. Make sure this code is accessible i.e. Not inside some other condition and the variable $msg is not being overwritten elsewhere in the code.
You also are talking about using the same btn_save query after clicking btn_convert But this totally different form and values that are in the modal form. The values from btn_save are gone at this point. And so processing for btn_convert is separate and different. And again $_POST["member_id"] is the member id in the modal.
I wanted to also note I have NOT seen any DB table field in queries indicating the Event this member is attending. Maybe selecting the convention or event is step that is done before attending members are listed. Just be sure that goes along with all records for this event.
Kind of. The way you’re going about it is what’s making you struggle a bit. So, the reason why you would want to use try-catch blocks are to prevent systematic errors. This would be things like a database crashing for random reasons. You don’t really want to be carrying around that kind of connection so you would catch that error and display back some generic message, obviously not the actual error for obvious security reasons.
Now, what you’re trying to do is use try-catch blocks in place of your logical errors. You really shouldn’t be doing that. So I would use if statements instead since this is a logical problem and not a systematic problem.
Then there’s the inconsistency of running a redirect or a $msg variable. I know this isn’t you, I’ve seen this a lot with a lot of other people. So to me, it doesn’t make a lot of sense to have a $msg variable at all. What I would do is in place of that, I would set a session variable instead. And inside that session variable, I would put a Boolean value to it. Once I do that, in my HTML code, I would use PHP to check if that variable exists and if it equals to say 1. If it does, then write in a generic error message or the error message you’re trying to use. After that, I would unset the session variable. This emulates the whole user experience of “what would happen if I refreshed the page without submitting data”. It would just remove the error message you could say.
Say in code, it’d look something like
if($_SEVER['REQUEST_METHOD'] == 'POST') {
// Do your query
...
if($stmt->rowCount() > 0) {
$_SESSION['attendance_success'] = 1;
} else {
$_SESSION['attendance_error'] = 1;
}
// this URL should match the destination you want. If the success page is different from the error page, then I would move this redirect statement into the proper if statements above.
header('Location: URL_HERE');
} else {
// put your HTML or View here
...
// unset the variables here
if(isset($_SESSION['attendance_success'])) unset($_SESSION['attendance_success']);
if(isset($_SESSION['attendance_error'])) unset($_SESSION['attendance_error']);
}
Then in my HTML code, I would just do
if(isset($_SESSION['attendance_success'])) {
print 'You have successfully submitted your attendance!';
} elseif(isset($_SESSION['attendance_error')) {
print 'There was an error processing your attendance, please resubmit your information again.';
}
Something along those lines. Please don’t this exact code, but just the idea of it. It’s untested and just an idea for you to rethink about. This makes things much easier instead of having random variables sitting there for no reason.
Your question to me was about processing and doing more queries…
You have 3 submit buttons and so each should be handled in their own way.
How you define a message is a matter of taste but I generally would only use session if processing is done on a separate page. In MHO, defining messages as numbers can be a headache as more and more messages are added.
Also, thus far there has been no checks on POST in your processing code. At the very least all required fields should be checked for expected value, e.g.
if(empty($_POST['member_email'])):
$msg = "Email is a required field.";
endif;
if(filter_var($_POST['member_email'], FILTER_VALIDATE_EMAIL)):
$msg = "Email is not valid.";
endif;
//etc.
Then it’s only after this you query for absence and or attendance and process accordingly.
This could be done my checking if their is no message, e.g.
if(empty($msg)):
//Continue processing
endif;
I mentioned as well about the try catch and so you would want to query to see if there is an attendance record for this event and so it would be based on the result of the query that you process a new.attendance record or define a message. (much like you are checking for absence.)
You’re getting close. Your if statement should go after executing the prepared statement. Then you check to make sure it actually was inserted. If it isn’t, then that’s where you would let the user know that their attendance couldn’t be processed. Really, what most people would do is let the prepared statement run its course. Once it does, check to make sure the results didn’t return some sort of error code. If it does, you can determine what the cause is. That means you can have multiple if statements to let the user know. For instance, if there’s already a duplicate, you can check for the error code specific to being duplicates. Then let the user know they’ve already been marked present.
No. You’re still using the catch block which you’re missing the whole point. Like I said earlier, normally, you would only use try-catch blocks for systematic problems. Not logical problems. What you’re trying to achieve is a logical problem. Logical meaning “is this person already present, if so do something”. A systematic problem like I’ve said before is when something breaks and you’re not in control of the system. For example, a database crash. It might not be your fault that the database crashes, it could be a connection problem between the database server and the internet. That’s a systematic problem and therefore, it’s appropriate to use try-catch blocks for this. You really don’t want bad database connections being passed around because say you’re doing what you’re doing now. You’re trying to select an attendance and for some reason, the database connection comes back as NULL or undefined. Well, that’s not really your fault. Like I said before, it could be a poor connection between the database server and the internet. My point here is, since the database returns NULL or an undefined connection, once you try to run a query, your query will fail. That’s when it’s appropriate to use try-catch blocks. Never use try-catch blocks as a replacement for if statements. That’s bad coding practice.
Yeah, that’s getting close to it. You still would use HTML elements though in your messages. So something like this.
<div class="small">
<?php
// list all messages here
if(isset($_SESSION['attendance_success']) && $_SESSION['attedance_success'] == 1) {
?>
<p style="text-align: left; font-size: 14px;"><b class="text-success">You have successfully submitted your attendance!</b></p>
<?php
} elseif(isset($_SESSION['attendance_error']) && $_SESSION['attendance_error'] == 1) {
?>
<p style="text-align: left; font-size: 14px;"><b class="text-danger">There was an error processing your attendance, please resubmit your information again.</b></p>
<?php
}
?>
</div>
It’s really up to you how you want to implement something like this. You don’t necessarily have to put a crap ton of HTML in those if statements. You could put just the words in them and then the HTML elements outside the if statements. It’s really up to you.