if(isset($_POST['submit'])){
$to = "auto@5starastrology.com"; // this is your Email address
$from = $_POST['email']; // this is the sender's Email address
$headers2 = "From:\r\n" . $to;
}
And, the error is same:
Undefined array key "email" in /home4/xxx.com/xxx.php on line 16
In the first example (and the HTML form you posted previously) itâs âen-us-kf-kmâ.
But then you use âsubmitâ.
So what else have you altered that we donât know about?
So what is line 16?
My little example by itself doesnât solve the issue if your are just going to use $_POST['email'] on itâs own without checking even if POST is present. This is why you check for if($_SERVER['REQUEST_METHOD'] === 'POST' then you further check if the unique post KEY is set, i.e. && isset($_POST['en-us-kf-km'])
You posted my example like it was going to magically fix the problem but Notice the comment in my example
//All processing goes within this outer POST condition
All processing including all your email message writing etc. should be within the containing IF condition.
I gave you an example of at least checking that a post KEY is set before trying to use it⌠Especially radio inputs or checkboxes, which would not even be sent with POST if theyâre not selected so they need to be specifically checked for being presentâŚ
Jumping in from post #21 your use of isset does not belong and needs to be removed.
In a properly coded form, ALL form fields save for checkboxes will be isset, therefore checking for isset is pointless. What you need to do is trim the entire POST array at the same time and then check for empty.
Also, hoping the name of a button to be set in order for your script to work will completely fail in certain cases. All you need to do is check the REQUEST METHOD.
Additionally, do not create variables for nothing.( $from = $_POST[âemailâ]; )
There are many times when specific processing needs to be run. A simple example is to Add a topic, Edit a topic, View a topic and Delete a topic. So having 4 named buttons can do very different things.
I do agree with your statement on checking for isset on known inputs being pointless and that trimming and checking for empty values is better processing. He hasnât even gotten to validating user input. This whole topic though has been about OP trying to use a post KEY before it is set, which is why that is the focus of much of the discussion.
I was specifically referring to the type âsubmitâ and the integration with the POST REQUEST check. What you are talking about is a valid use case but should be handled differently by including a hidden identifying field in each form rather than checking the name of the submit button which in fact will completely fail in certain cases as I said.
The only time I have had a submit name fail is when you use name=âsubmitâ, which I always advise against. I still might push back (just a bit) on your âeach formâ issue as 1 form with many subsections might be used for example to update related joined records before a primary submit is done processing the whole form but it really depends on the project.
I donât know what you did when the name=âsubmitâ didnât work, but I guarantee it wasnât because the input or button type submit was named âsubmitâ. The problem was somewhere else.
Not really sure what you are saying with the rest of your reply so I canât comment on it. Feel free to start a new thread about it so we donât get off topic here. Interested to see what you are talking about.
That code is not inside the if () clause that you showed us in post 21, the same as it wasnât inside the if clause that you showed in post 10. As youâve already got the form variable into $from inside the if clause, why are you trying to assign it again afterwards?
When you submit the form, what is in $_POST when you var_dump() it for debugging? (I seem to remember asking that earlier). I wonder how that field might be missing from the form submission when itâs specified as a required field.