broken php form/script (worked for years)

I have a contact form and associated php script that worked together for years. A while back I thought of testing it and the script returns the if..else error based on an empty message. I'm not competent with forms or php but this is simple straightforward stuff and I just can't see why it should fail, unless something basic as changed in php syntax? Can anyone spot the error?

Form:

<form method="POST" action="script.php">
<table border="0" cellspacing="8" cellpadding="0">
<tr>
<td align="right">Name:</td>
<td>
<input type="text" name="name" size="32" maxlength="50">
</td>
</tr>
<tr>
<td align="right">Email:</td>
<td>
<input type="text" name="addy" size="32" maxlength="50">
</td>
</tr>
</table>
Your Message:



<textarea name="comments" wrap=physical cols="56" rows="12"></textarea>


<input type="submit" value="Send">
   
<input type="reset" value="Cancel">
</form>


Script:

<?php
if ($comments != ""):
$message = "Name: " . $name . "\nEmail: " . $addy . "\n\n" . $comments . "\n";
mail ("richardj@example.com", "Contact page feedback!", $message, "From: richard@example.com");
?>

...acknowledgment html...

<?php
else:
?>

...error html...

<?php
endif;
?>

Are you using {curly braces} around your if's or are they actually :colons: ?

if ( [something is false] ) {
[do false];
} else {
[do true];
}

Thanks sXi,

I thought for a while you'd nailed the problem, but I had to go researching where to put the braces with respect to the alternating php and html. Not altogether, but eventually arrived at this page in the official php manual --I actually only found this because I was having trouble finding any reference to the endif statement.

The reason, I now think I see, that the endif statement is uncommon is precisely that it is superflous with the common brace usage. However, it seems that using colons for the condition statements along with a control structure end statement is a correct alternative to braces, and it gets special mention with regard to clarifying mixed php and html.

I can't see anything materially different in my script's control structure, colons and endif included, from the examples on the manual page.

So I'm back to square one.

The only other clue I found in my searching was a lot of references to php changes involving register_globals and Superglobals--all way over my head.

Maybe I would do better to find another ready-made script that works. I've looked at a few but they seemed way too fancy when all I want to do is let site visitors email me without giving my address to spammers.

There's a really cool cgi mail script (a default DreamHost one) floating around somewhere. Might pay to do a search here and on the Wiki.

--Edit--

Try this: http://wiki.dreamhost.com/Formmail


Edited by sXi on 10/08/08 01:56 AM (server time).

Thanks again--I think that's maybe a good solution. I thought there was something at DH but I looked in the web panel for it, didn't think of the wiki.

Restricting email destinations to accounts at DH doesn't eliminate the use of the form by spammers but it certainly puts limits on it! I like that.

{html}
E-mail address:<input type="text" name="T2" size="30" value="" />
{php}
$email=htmlentities(trim($_POST['T2']));

Maybe this will give you a clue as to how the strings get passed.
Silk


My website

Thanks...

Now I'm more strongly persuaded to make a cgi script based on the stuff in the wiki :-)

The php script I used was simple and, as I said, worked for years without a hitch, but it dates back to php2 or 3, maybe earlier. I liked the element of security that came from having the script on a different page from the form, but I realise that there are lots of other issues not covered in such a simple script. I've only just discovered that spammers could have (I don't know how, but that's irrelevant) used my form and BCC to send their crap and I would have been at fault for letting my server get hijacked.

What I did was include all the fields as part of the message and had hard coded headers. This way I still saw what they type for each field, yet didn't have to worry about them altering how the mail function is suppose to work. Plus I knew the email came from my site due to the hard coded headers.
Silk

My website

I had difficulty following both your posts, but since you took the trouble to help, I've gone back to it a few times and now I think I have the gist of it, so that:

Yes your previous post does (now) give me a clue, enough that I think I could follow through after a bit of study of php basics. The only reasons I'm not going to do that right now are

1. I have so many things to do that I'm not coping with and this isn't essential because
2. It seems that just using the formmail script 'as designed' will work
3. I can change my mind if problems arise.