Get a free trial // Grow your CSS skills // Land your dream job

Self-Processing PHP Form

  • # October 18, 2012 at 9:30 pm

    Hey guys, I’ve made a PHP form that processes itself, that is, it is it’s own back-end engine. This is amazingly helpful when you just want to drop a PHP include in your page, say `< ?php include 'contact-form.php'; ?>` and be done with it, and not have to reference an engine or maintain more than one document. My contact forms used to be 5 documents, because I would have a default, success, error, form, and engine file to load dynamic content based on how the engine performed. This takes that same concept, and reduces all five of those files down to one form that you can include anywhere on your site. It’s completely functional right now, but I’m working on developing it further and improving it. If anyone would like to try it out, or would like to contribute, you can find it on [Github](

    # October 18, 2012 at 11:11 pm

    have you thought about making this a class?

    I’m still reading through it, but my first bit of advice is to **not** break out of PHP: finish all of your PHP processing first, output all of your HTML last. This makes for better error control/recovery, and makes the script more flexible overall (e.g., you could handle generating an entire page or just the form itself).

    # October 20, 2012 at 3:42 pm

    Great point @traq. This is definitely still a work in progress, and is in active development. I did some cleaning up that I pushed to origin right after you forked actually. I’ll make it a point to split up the two. I’m trying to walk the fine line of making it user friendly for non-coders and making it efficient. I’ll do some more cleaning up of the code and push changes to the repository so you can re-fork if you’d like.

    EDIT: @traq I’ve rewritten the code to eliminate breaking in and out of PHP. Committed and pushed to Github. Next step will be to automate the building of the forms themselves, and getting rid of the hideous isRequired() function.

    # October 20, 2012 at 10:26 pm

    I’ve been thinking about automated form building (which would, in turn, make automated validation *very* easy). I’ll organize what I have and open a repo for it (I’ll let you know when I push it).

    # October 29, 2012 at 7:01 pm

    @traq check out where I’m at now on it, I think you’ll be able to help out. I’ve laid the framework for automated form building, but not validation (because validation is inherently different depending on the type of field) – trying to find a way to make it anticipate the kind of data meant for each form.

    # October 29, 2012 at 7:58 pm

    Okay, so I’ve created a self-processing PHP form that builds itself dynamically based on a configuration array.

    $inputFields = array(
    // Which fields do you want the contact form to include?
    // FORMAT: array(referenceKey (no spaces), Display Name, fieldType, isRequired?),
    array(‘name’, ‘Name’, ‘text’, true),
    array(‘phone’, ‘Phone Number’, ‘text’, true),
    array(’email’, ‘Email Address’, ‘text’, false),
    array(‘source’, ‘Source’, ‘text’, false),
    array(‘message’, ‘How can we help you?’, ‘textarea’, true),

    I’ve hit a slight road block, as I’m not sure how I should approach dynamic validation of the data passed into the forms. Each field has different validation that goes further than just determining if a required field is blank (email address will be validated via REGEX differently than a phone number). I need a way to be able to validate many different types of input, without knowing explicitly what they are.

    I can obviously use pre-fit reference keys (email for email address, name for name, phone for phone number, etc.), but that isn’t something that’s very user friendly, as that all has to be documented and places limitations on the code. For the complete code, you can visit [GitHub]( Ideas?

    # October 29, 2012 at 8:52 pm

    I’ve been using this one for a long time now.

    Also he has it just for a regular site also.

    # October 30, 2012 at 9:40 pm

    > I’m not sure how I should approach dynamic validation of the data passed into the forms. Each field has different validation that goes further than just determining if a required field is blank (email address will be validated via REGEX differently than a phone number). I need a way to be able to validate many different types of input, without knowing explicitly what they are.

    What I do is pass the required validation when I create the field. In your `$inputFields`, you might add another param for validation (or re-purpose the `isRequired` param). For example, `isRequired` could be an array:

    array( {bool isRequired},{string validationType} );

    where `validationType` could be a keyword (e.g., “email”, “ctype_digit”) that maps to a preset validation function, or a regex (e.g., “#[yes|no]#ui”) that can be used with `preg_match()`.

    You could even make `validationType` an array for multi-step validations.

    Something else to think about for validation:

    Don’t overthink it.

    Checking some things is fine (for example, you want to give a “heads-up” if the email address doesn’t have an `@`), but for others, it doesn’t really make sense.

    Yeah, make sure the name is filled in, but testing against a regex is a downhill battle. Your regex, for example, doesn’t accept accented letters.

    Making a regex for phone numbers is even worse – for example, it is *very* common for some people to split up a phone number like 000-000-00-00, which your regex will reject because of the last hyphen.

    The overriding consideration, however, is that **you can never know it’s right anyway**. The best advice I’ve ever heard about validation is “Just trust that they know their own name|phone number|etc..”

    A place you *should* have validation (but mot people don’t) is things like <select> lists and checkboxes. Whenever you send a particular set of options, the response *really must* be one of those options (seriously, discard the entire submission if it’s not).

    One more: it would be a really good idea to use a token with your form. If you’re not familiar with this:

    1) Assign a random value to a hidden field in your form. It must be **unique** and **unpredictable** every time.

    2) Save the value in your SESSION also.

    3) Compare the two when you get a form submission. If they don’t match, or if one or the other is missing, ignore the form submission (this might indicate that the submission was forged).

    4) If the values match, process the form as normal. Delete the value from your SESSION (this will make sure that the form isn’t accidentally submitted twice, e.g., when the user “backs up” over the form with the [back] button: since the token is no longer in the SESSION, the extra submission will be ignored).

    BTW, I found the function I used to dynamically create forms. I’ll add a little documentation and make a gist so you can check it out.

    # October 30, 2012 at 9:49 pm


    > * ENHANCEMENT – Add the capability of sending HTML content messages to customers (may already work).

    It’ll work, just add a couple headers to your email:

    “MIME-Version: 1.0rn”;
    “Content-type: text/html; charset=utf-8rn”;

    # October 30, 2012 at 11:59 pm

    Here’s [the gist of my HTML mapper function](

    # October 31, 2012 at 10:45 am

    @traq thanks for your input! I’m changing things up right now, and I thought of a way to handle things thanks to what you said. I’ll let you know when it’s committed and pushed. I haven’t got a chance to look at your gist yet, but I’ll do that very soon.

    Had a question about adding the header to the email though: if I add it do I have to change the returns in my body to carriage returns? and do I add these headers before the To: From: etc headers?

    # October 31, 2012 at 3:58 pm

    No problem!

    1) The header order doesn’t *really* matter. I put them after.

    2) Modern computers/email clients usually don’t have trouble sorting those things out, but CR LF (`rn`) is the standard for exchange over the internet. I’d recommend using that.

    You’re welcome to use that function if you’d like (contact me if the license [CC/BY-SA] doesn’t work for you), but it’s probably overkill for what you’re doing.

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.

There's a whole bunch of content on CSS-Tricks.

Search for Stuff   •   Browse the Archives

Get the Newsletter ... or get the RSS feed