Hello, I recently designed a website and I have a contact page where they can send me an email by filling in their name, email, phone number, and a message. If they don't fill in all the fields, it won't send. However, I've gotten a few emails where all the fields are blank. How are these being sent? Here is the link, don't be afraid to send me some emails to try it out. Bugbytecomputers.com/contact.php And here is the code for the contact page: <div class="emailform"> <form method="post" onsubmit="return check()" action="email.php"> Name: <br> <input type="text" name="name" class="txt" maxlength="40"> <br> <p id="nameerror" class="error"></p> <br> Email: <br> <input type="text" name="email" class="txt" maxlength="40"> <br> <p id="emailerror" class="error"></p> <br> Phone Number: <br> <input type="text" name="phonenumber" class="txt" id="phone" pattern="\d*"> <br> <p id="phoneerror" class="error"></p> <br> Prefered Method of Contact: <br> <input type="radio" name="contact" value="Phone" class="inputbutton"> <span class="inputtext">Phone</span> <input type="radio" name="contact" value="Text" class="inputbutton"> <span class="inputtext">Text</span> <input type="radio" name="contact" value="Email" class="inputbutton"> <span class="inputtext">Email</span> <br> <p class="error" id="contacterror"></p> <br> Subject: <br> <input type="text" name="subject" class="txt" maxlength="50"> <br> <br> Message: <br> <textarea class="messagefield" name="message" style="resize:none; -webkit-appearance: none; border-radius: 0;" maxlength="5000"></textarea> <br> <p class="error" id="messageerror"></p> <br> <button type="submit">Send</button> </form> </div> And the code for the email form: <?php $name = $_POST['name']; $email = $_POST['email']; $phonenumber = $_POST['phonenumber']; $contact = $_POST['contact']; $message = $_POST['message']; $subject = $_POST['subject']; $content = "<html><div style='font-family:arial; line-height:19px; max-width: 700px; margin: 20px auto 0;'> <b>Name: </b>$name <br> <b>Email: </b>$email <br> <b>Phone Number: </b>$phonenumber <br> <b>Prefered Contact: </b>$contact <br><br> $message </div></html>"; $headers = "Content-type:text/html;charset=UTF-8" . "\r\n"; $headers .= 'From: Bug Byte: ' . $name . "<" . $email . ">\r\n"; $headers .= 'Reply-To: ' . $email . "\r\n"; mail("", $subject, $content, $headers); ?>
And here is the email I'm getting: (I've gotten emails that work as well, just a few that look like this)
Hi Brennen. It might be a just few today, but you'll receive a lot more of spam emails soon enough Don't trust onsubmit="return check()" for email validation / sanitation / whatever. Use your PHP instead. I've already forgotten where, but you'll find many discussions about mail() function in following subforum: https://forums.digitalpoint.com/forums/php.37/
Could you explain why the check I'm currently using doesn't work? And how blank emails are getting through?
It's not your script. It seems to work quite well, at least to me But... there're ways to turn-off javascript. And when it's off check() would no longer works. I know only 2 ways to do that in Firefox: Through browser url bar and about:config... Through Inspector and Toolbar option...
Uhg, where to begin... As others mentioned you don't trust client side validation, particularly scripttardery. It can be blocked, unavailable, circumvented, and generally ignored. EVEN if you have the best in HTML 5 or JavaScript checks in place, you MUST check it again on the server. PERIOD. Your form is incomplete rubbish with zero graceful degradation. Where are your fieldsets? Your labels? Why are you wasting so much time on classes for nothing? Why are you inlining scripting/error state only paragraphs? (that's stuff that should be added by the script or server). what are you doing with that pointless DIV you couldn't do directly to the FORM? Much less onsubmit in the markup with zero fallback plan -- when good scripting should hook to the markup instead of from it. Of course, you're using the train wreck of mouth-breathing dumbass developer asshattery known as jQuery, so I won't even waste time trying to make sense of that disaster of scripttardery. Even your maxlength attributes are rubbish since valid e-mails can reach 320 characters in length! Server side it's even worse; you NEVER blindly trust values in $_POST, it's stupid to be wasting time creating copies of the values in "variables for nothing", and HTML e-mails wihtout the properly formed header (which you clearly do NOT have) can be flat out blocked or ignored by mail clients... and that's before we talk the static CSS in the markup that most mail agents will ignore anyways. Pretty much what you have there is a laundry list of how NOT to write HTML, use JavaScript, or even process a form. The first step would be to fix the form. There's more tags that go inside a form than just input, textarea and select... something like this: <form method="post" action="email.php" class="contactUsForm"> <h2>Contact Us</h2> <p> Call (435) 720-0420, or fill out the form below to schedule an appointment or find out more about our services. </p> <fieldset> <label for="contactName">Name:</label> <input type="text" name="name" id="contactName"> <br> <label for="contactMail">Email:</label> <input type="text" name="email" id="contactMail"> <br> <label for="contactPhone">Phone Number:</label> <input type="text" name="phone" id="contactPhone"> <br> <fieldset class="contactBy"> <h3>Prefered Method of Contact:</h3> <input type="radio" name="contact" id="contactByPhone" value="Phone"> <label for="contactByPhone">Phone</label> <br> <input type="radio" name="contact" id="contactByText" value="Text"> <label for="contactByText">Text</label> <br> <input type="radio" name="contact" id="contactByMail" value="Email"> <label for="contactByMail">Email</label> </fieldset> <label for="contactSubject">Subject:</label> <input type="text" name="subject" id="contactSubject"> <br> <label for="contactMessage">Message:</label> <textarea name="message" id="contactMessage"></textarea> </fieldset> <div class="submitsAndHiddens"> <input type="submit" value="send"> </div> </form> Code (markup): Though I'd probably have a random hash as a hidden input in there tied to the session, so as to prevent resubmits and/or abuse. Also notice I axed the e-mail; the reason to have a contact form is to avoid being spammed by your e-mail. If you're going to just blindly list it on the page, why are you bothering with the form? Server-side you'd have to check that form as if scripting doesn't exist, so that's the next step. I typically build my forms using a PHP array that I can use to hold both the validation type and the labels -- so checking values can be automated on the server. I would place the form in its own PHP file called my an email.php which would handle BOTH the output of the page and form, as well as sending the mail. It's called "one index to rule them all" construction and is a very smooth/slick way of handling mails and minimizing the overhead. I'm out the door for dinner, but I'll try to revisit later and post up example code of what I'm talking about -- probably using a hybrid "multipart" version of the e-mail so that you can send both as text and html, so mail servers and clients don't end up assuming your HTML mail is just spam.
I've been coding in html for a whole month, I know my code isn't perfect, that's why I posted here. The classes and divs are because I have two style sheets, one for mobile and one for regular browsers, so everything has to have a class. I'm sure there are more efficient ways, but this is the way I found that works. I thought when I designed the form that it was a server side check, but I guess not, I will work on changing it.
Also, the emails are only being sent to MY email address, and it works fine so that's all that matters as far as the email formatting.
A month deep? That's pretty good -- particularly if you're diving into the PHP side of things already. You just need to up your game slightly on the semantic side of things. HTML has tags that MEAN things, and should be chosen based on those meanings. LABEL for example, which you lacked, is supposed to wrap the text associated with a input, select or textarea. Generally speaking apart from <input type="submit"> or <input type="image'> if you have a form element like input, it should have a label. The Label needs to point at an ID, which is why all your input, select and textarea that have labels should have ID's. This form a semantic relationship for non-visual UA's and other accessibility methods. That's a hard hurdle to jump -- that HTML is for saying what things ARE as there's more to HTML's audience than just desktop screen users. Screen readers (aka sofware that reads the page to you), Braille readers, TTY devices -- all still in common use and as much a part of who websites are for as anything you do visually from the CSS. Really a lesson that should be taught early on but usually gets glossed right over. That really shouldn't be why there are classes -- if you've got perfectly good semantic tags it's only the one-off's you have to worry about, and since they should have ID's for their labels to point at, you can just as easily use those. You've got a few cases of unnecessary classes site-wide, including your menu. If every element under a parent tag is getting the same class, none of them need classes. See your .menuitem classes. One of the parent DIV has a perfectly good "menu" class on it, so why do they need classes? Of course you have them as anchors with no block level separators, when a menu is in fact a short list of bullet points. Hence why that should be a set of UL+LI around those anchors so you don't have a run-on sentence that reads "Home Computers Internet Phones Promotions Contact us About us" -- remember anchors do NOT change or provide meaning, it simply says to link someplace else. As such they are considered "semantically neutral" so when something like a screen reader or braille reader hits that, it's going to treat it all as one sentence! ... and really in the age of responsive layout, separate stylesheets for mobile and desktop is kind-of missing the point. PARTICULARLY if they are replicating the same code. (I'm not actually seeing said mobile code anywhere in your page actually...). You're also missing a lot of "basic" attributes on things like your stylesheet <link> like media targets. At some point you should read up on those. "Works" is a very relative term. There's a lot of shortcomings and flawed methodology thanks to incomplete markup. NOT entirely your fault, most of the nube-predating scam bait out there like W3Schools or garbage like Dreamweaver -- much less career educators not qualified to teach a damned thing and authors who don't know enough to be flapping their gums on it -- makes it VERY hard for someone starting out to get a handle on the simplest of concepts that have been around since HTML was created. When you are just starting out getting a handle on what runs on the client (browser) an what runs on the server is a bit confusing. JavaScript is (normally) a client-side language, it runs in the browser. That's why it can't be trusted as anything that runs on the browser can be blocked, disabled, or even subverted. The last of those can be a particular worry as it opens up possible security holes. That's why you should really be checking things server-side (in your case in the PHP). Client side validation -- be it by HTML 5 attributes or by JavaScript -- is pretty much there as a convenience to try and save time and bandwidth. It simply cannot be relied upon though for actual functionality. Hence the pesky "unwritten rule of JavaScript" -- if you can't make a fully working page without JavaScript FIRST, you likely have no business adding scripting to it. Just got in the door a bit ago, I don't think I'll get to that example PHP tonight, but since it's the weekend I'll see if I can squeeze it in. When I do rewrites for people I usually go the full distance of text breakdowns of the how/what/why of every step of it so people can learn from it.
Thanks for your help. I'm not real concerned about proper labels and all that stuff, I know I should be but this website is just for a small local business, so as long as it provides the information it works for me, I'm not planning on becoming a web developer. I will implement some of the things you mentioned though.