The Problem

The client uses the Contact Form 7 wordpress plugin for events, registrations and subscriptions. Up until this point all the emails needed to be cut and pasted manually into a master list for marketing or other action items.

Specific actions are taken with each contact form. Some are simply added to a master email list while others are used to send content through snail mail. The need for more forms over the next few months will be increasing. These forms are very time sensitive so the solution must be dynamic enough to preclude more than a few hours in turnaround.

The Solution

If resources were unlimited (time and budget) this would be a great place to implement pre-built CRM (customer relations mangment) system. There are plenty of open source and commercial applications that would work well.

The biggest limiting resource here is time. The client knows how use wordpress and the current site is already well established with content. So we’ll hack it.

Logging Emails

Logging outgoing emails from any type of contact form is essential. This could be as simple as storing them in a database or even writing to a flat file. Logging emails will help you pick up security issues as well as troubleshooting.

The solution is pretty simple. Every email sent out through wordpress uses the wp_mail() function, including forms through Contact 7. All we need to do is capture the $_POST variables when a call is made to wp_mail().

We can use the add_action() hook from wordpress to accomplish this.

A simple example

We’ll insert our hook in the functions.php page for the theme. For this example I’ll use a theme called custom.

wp-content/themes/custom/functions.php

We’ll create a function to capture the posts. This function won’t really do anything but you’ll get the point. Then we’ll hook the function into wp_mail().

function saveContact() {
    // all of our post variables are in the $contact array
    $contact = $_POST;

    // now would be a good time to clean and filter
    foreach( $contact as $key => $value ) {
        // trim it, escape ... it you know the drill
    }

    // insert into the database or save a flat file

}

// hook it
add_action( 'wp_mail', 'saveContact' );

Now anytime wordpress sends an email it will call our saveContact() function. This is fine to just capture the data but we want to do something with it. Keep in mind Contact 7 adds in some of its own post variables so you may want to pop those off before processing the data.

If you want to echo anything back to test this turn off your javascript otherwise Contact 7 will send an ajax call behind the scenes.

An advanced example (go cURL yourself)

Wordpress is great but I want to use a MVC framework to handle all of the the different actions. I want to know what form was sent and use the information to populate various tables. I use Kohana but any of the popular frameworks can handle this in the same way. The benefit here is I can use the framework’s built in cleaning and database helpers. We’ll use cURL to send the post variables to our controller.

I’ll send the data to a controller in public_html/example. So the domain www.mydomain.com has a standard wordpress install but we have a kohana controller living in www.mydomain.com/example. I’ll also send along the URI where the form originated. We’ll take care of all the data inside the framework. Clear as mud?

Wordpress by the way does not like putting this source code inside the post. You can check it out here.

For security you can make sure the cURL posts are only sent from your domain.

With permalinks enabled you can differentiate between forms posted from something like www.mydomain.com/contact and www.mydomain.com/contact/subscribe.

I’ve been trying to come to a conclusion of what php framework to use on new projects. I finally took the plunge into Kohana and I’m loving it. Some of the other frameworks that made the short list.

• Zoop – I like the command line, smarty, and PEAR integration.
• CodeIgniter – Great documentation, huge community and heavily used.
• TinyMVC – Stripped down version of CodeIgniter. Easy integration into smarty.
• Zend – All the cool kids are doing it.

Like most developers I fought the extreme urge to do everything myself and reinvent the wheel. Although I could of expedited that decision. In the end choosing a well documented and community driven framework makes any application more valuable. It helps when other developers get involved and don’t have to guess what it is your doing. It sets the standard and hundreds or thousands of developers have contributed to that standard. In short it reduces the “WTF?” moments.

If I need a hand on a project or turn it over to someone else the next developer can pick up where I left off. Some of the features that sealed the deal for me.

• Security – filters XSS by default. No configuration needed.
• Large module/plugin library
• Ajax integration and seperation is easy to work with.
• Strict OOP

Development is very fast with Kohana. The more I dig into the more I’m enjoying it.

The Problem

If the submitted form doesn’t pass validation I want to return the data so the user doesn’t have to re-enter all the information. I don’t want to rely on javascript, although I will add it for user convenience as a final step. I also don’t want the form re-submitted if the user refreshes.

The Solution

There are quite a few ways to solve these problems. My standard approach is to post the form to a processing page and store the POST variables in a session. If the data fails the validation I redirect to the original form, pull the submitted data out of the session variables and re-populate the form with an error message.

Pretty straight forward for small contact forms. Once you get to a gigantic form that makes your eyes bleed this becomes cumbersome. On a side not I try to push my clients to the smallest possible forms they can get away with..

I use a postToSession class to make this go a little quicker.

Example Usage

I’ll use three files for my example. Comments are in the source files.

• index.php
• process.php
• postToSession.php

You can see a working demo of these files in action here.

Basically by using this class I can automatically serialize the form value and stuff it into a session variable. Once I unpack it, it cleans itself up.

Lets start with process.php. The form has been submitted. We instantiate the postToSession class and pass a parameter of _formValues to the constructor. This is the name of the session variable we’ll use.

$session = new postToSession( '_formValues' );

Next we’ll serialize the post values and store them in the session variable.

$session->serializePost();

Now that you’ve saved the posted values you can work validation to your hearts content and set any error messages according. If no error messages are sent the data is ready to go. In this example I simply set a status message and pass them back to the original page. If an error message is set I’ll send them back with failed in the query string.

Either way they are going back to the index page. On index.php I’ll look for the failed variable in the query string. If its set I can pull all the values back out and re-populate the form. I’ll put the values in a local array called $formValues.

$formValues = $session->unserializePost();

Now I’ll assign the form values to print out to the user. If it $_GET['failed'] isn’t set I know we either passed form validation or its a fresh start. I’ll also check to see if there is a status message set in the $_SESSION variables. If it is I’ll assign it to a local variable for display and clear it.

The End

This is just one of those little tricks I wish someone had shown me when I started. By using a separate page to process and redirecting after processing we can keep the user from submitting multiple times by pressing the refresh button. You could just as easily use the query string to repopulate the form but it looks horrible. I also use this method because many times the form is pre-populated with information like the users profile or other account information. I can use the same template for adding new records as well as editing existing records.

This was a little over an hour worth of my life that I’ll never get back.

During development I run with errors set to E_ALL and turn off error reporting for the live site. Today I thought I would see how E_STRICT would pan out on the framework I use. I knew I would get some new errors so I was already bracing for impact. In PHP6 E_STRICT is to take the place of E_ALL so I figured a Sunday afternoon would be a good time to see what I had in store for me for PHP6.

I try to take advantage of any pear packages I can get a hold of. Pear’s goal is to offer backward compatibility so between some of my own code and pear there was allot of notices. Most of them coming from pear’s use of is_a().

As I looked deeper into into the topic I started to think it was time to move away from PEAR and rethink my framework. Wow, that’s allot of time and allot of work. There are allot of good changes for PHP6. Most of them are reducing the ability to create poorly written scripts.

An hour later I decided I’ll look at this again after PHP6 is stable (could be a while). I don’t why I do this stuff to myself.