Welcome to WebmasterWorld Guest from 22.214.171.124
I have been working on a form for some time and am baffled about why it is not doing what I think it is suppose to do.
By the way, it is a form that I have inherited and part of a CMS so I am limited about how much I can change it by the application.
The situation is that the form (which is using the output buffer)has a
Almost forgot, this is a complex login form that has an IP Address
check in it. If the "expected" IP address is different that the one
stored in the database, it loops back and adds a test for the users
birthdate which does a different database lookup. This one form is
used to manage both conditions.
The form was originally designed to use a text box and the request was
to replace it with a drop down because his users didn't follow the
instructions for formatting most of the time, even with an example
provided. The form does a lookup to see if the birthdate matches the
one that is stored in the database. In the lookup, it compares the
value in $_POST['birthdate'] with the value in the database. The text
box works fine if you enter the correct yyyy-mm-dd format.
The replacement dropdown has three $_POST values very creatively
assigned, $_POST['year'],$_POST['month'],$_POST['day']. To compensate
for the replacement of $_POST['birthdate'] and try to make the change
transparent to the rest of the script I generated it manually in a
hidden field (I actually thought this one WAS creative until I
discovered that it didn't work as I expected, lol),
<input type="hidden" value="<?=$_POST['year'] . "-" . $_POST['month'] . "-" . $_POST['day'];?>" name="birthdate">
The problem, as you may have already guessed is that
$_POST['birthdate'] gets no date values until AFTER the submit button
and that is too late for it to do its database compare so it fails. If
you rerun the form entry a second time the script works, no problem
but the first time through nada.
I have placed several print_r statements to see what is going on and
the very last I have just after the submit and just after the
ob_get_content and just before the return and $_POST['birthdate'] has
the correct value in it but apparently the script compare function
isn't see it for some reason. If, like I say, I run the input again,
it works fine?
I have tried replacing the $_POST['birthdate'] with a variable
$birthdate that I generate manually with the correct data and pass it
to the diff function but that breaks the script so that it doesn't work
at all no matter how many times you run it. I would really appreciate
someone who might have done something like this and solved it to give
me an idea of where I need to go with it.
Many thanks for your attention,
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
<input onchange='document.getElementById("year").value=this.value' ...>
<input onchange='document.getElementById("month").value=this.value' ...>
<input onchange='document.getElementById("day").value=this.value' ...>
<input id="year" type="hidden" value=''>
<input id="month" type="hidden" value=''>
<input id="day" type="hidden" value=''>
<input name="birthdate" type="submit" value="Use this birthdate">
You have those three values:
You want it in this format:
There seems to be something to it, but how about having the values restructured in the way you wanted them after you submit the data?
birthdate = $_POST['year']."-".$_POST['month']."-".$_POST['day'];
Thanks for the feedback, I appreciate it, mikesz
When you submit the form it does go to some php file, doesn't it?
<form name="mydata" action="submitted.php">
Now if you see my point on submitted.php, you can do the following.
$birthdate = $_POST['year']."-".$_POST['month']."-".$_POST['day'];
MarkFilipak's solution is also a good one, but I do think you should do it from the server side like shown above if you don't have a different reason not to.
Sorry for not being as clear, I didn't get the information across as well as I should have. Using the hidden field, $_POST['birthdate'] does exist but on the first submit it is contains only '--'. If you submit the form a second time it works with the correct date, for example, 1933-01-01 but the first time through it does not get the data from the dropdown.
I think Mark's code is a possible solution but I too would like it to be server side if possible.
The solution you have provided is the very first one I tried to work around this issue but it breaks the code so the "test" on the values from the submit fails. For some reason that I haven't found, the script is testing the value in $_POST['birthdate'] which is what the original code supplied but when I change it to a $birthdate which is logical to me, the data validation fails even if you hardcode the correct date expected.
pretty weird stuff...
thanks again, mikesz
What I did understand so far is that you do have three dropdowns (year, month, day), and the script expects an input in the format: yyyy-mm-dd.
If that is the case let's do the following:
1. Remove the hidden value ($_POST['birthdate']), we won't need it.
2. In the code that follows, if $_POST['birthdate'] has been used anywhere on the related code, replace it with $birthdate.
3. When submitted place this code somewhere on the top: $birthdate = $_POST['year']."-".$_POST['month']."-".$_POST['day'];
What made me think about the verify function was a debug statement I put in the first function just after the submit and before the output buffer clean and I put a similar debug statement in the verify function. The first one displayed the correct value but when it got to the verify function it was empty so I started thinking that clearing out the output buffer was shooting me in the foot and apparently it was because moving the definition to the verify function seems to have solved the problem.
I tried a few different things to try to make the $birthdate global thinking that was the problem but none of them worked.
I am not sure I like the resolution meaning that I think that "passing" that variable should have worked but didn't.
Thanks again for the insights I was pretty much banging my head and the feedback helped.
kindest regards, mikesz