It’s been a while since I’ve professed my love for Wufoo. Oh, sweet Wufoo. Thy delicious interface makes form building easy, nay, a pleasure. OK, a poet I am not. A solutions wrangler I am.
In creating a form with Wufoo, you get a special URL right on Wufoo.com where your form resides. You can send people there to fill it out, but much more commonly, you embed the forms directly on your site. You have fairly good design control via their theme manager, or complete control via custom CSS. But these embedded forms come in via an iframe, or through provided JavaScript code which also ultimately ends up as an iframe. Thus, markup control you do not have. (although if you want the HTML to do your own processing, the have templates). This is pretty much a good thing. It means your forms will submit to Wufoo properly without giving you the chance to screw anything up, and allows Wufoo to process it properly and give you access to all the other amazing things Wufoo does.
Now let’s say we want to autofill some fields on the form. We don’t have markup control so we can’t adjust values. And since the form in is an iframe, we can’t even access those fields with JavaScript. Fortunately, Wufoo offers a solution. If embedding via the JavaScript embed method (highly recommended), you can pass a defaultValues parameter to automatically prefill fields!
<script type="text/javascript">
var x7x2q5 = new WufooForm();
x7x2q5.initialize({
'userName':'Wufoo-User-Name',
'formHash':'abc1234',
'autoResize':true,
/* Autofill Magic! */
'defaultValues':'field8=PREFILL-VALUE-HERE',
'height':'562',
'ssl':true});
x7x2q5.display();
</script>
Notice the field8 name? Each field has a numbered name like that. You can find out those values by going under the forms “Code” area and clicking the “API information” button:
So to additionally prefill email in this example, you’d use ‘[email protected]’. You can prefill multiple fields by separating them with &’s: ‘[email protected]&field6=name’.
Use Case Scenarios
Multiple Similar Submissions
For the new Digging Into WordPress book, we have a form for submitting Errata. The form asks for page number, the errata, name and email. We’ve had some folks, very generously, submit lots of lots of little fixes. Every time they submit the form, they need to type our their name and email address, which could be awfully annoying/repetitive.
So in this case, we are going to need to prefill the form with values from the previous submission. This introduces another little issue… How do we get access to just-submitted data in order to use in pre-filling? Wufoo has a full API, but that’s more than we need right now. While editing our form (under “Form Settings”), we can chose to either display text, or Redirect to Web Site. Typically just showing some text is a nice way to show a confirmation, but we’ll be using the Redirect here. The Redirect URL supports templating, meaning that we can put some special code in it to pass data back to our own site.
In the case of the Errata form, we want their name and email to automatically filled out to make an additional submission easier. So after looking up the field ID’s for those things, our redirect URL will look like this:
http://digwp.com/book/errata/?field3={entry:Field3}&field4={entry:Field4}&field5={entry:Field5}
Which results in this after submission:
http://digwp.com/book/errata/?field3=Chris&field4=Coyier&[email protected]
Now on the Errata page on our own website, we’ll attempt to pull those values from the URL when the page loads:
<?php
function clean($value) {
// If magic quotes not turned on add slashes.
if(!get_magic_quotes_gpc())
// Adds the slashes.
{ $value = addslashes($value); }
// Strip any tags from the value.
$value = strip_tags($value);
// Return the value out of the function.
return $value;
}
$firstName = clean($_GET["field3"]);
$lastName = clean($_GET["field4"]);
$email = clean($_GET["field5"]);
?>
The cleaning function there is just to attempt to prevent malicious stuff being entered into the URL.
Now in our JavaScript embed, we’ll echo out those PHP variables to prefill:
'defaultValues':'field3=<?php echo $firstName; ?>&field4=<?php echo $lastName; ?>&field5=<?php echo $email; ?>',
That should do it! Of course you’ll want to provide some kind of feedback that the form was successful sent, so just check for the presence of one of the variables and spit out a message:
<?php if ($firstName) { ?>
<div style="background: #d7ffd6; border: 5px solid #39c235; -moz-border-radius: 20px; -webkit-border-radius: 20px; padding: 20px; margin: 0 0 25px 0; color: black; text-align: center; font: 18px Georgia, Serif;">
Thank you! We'll take a look and get 'er fixed for the next update.
</div>
<?php } ?>
Passing along (hidden) information
On Are My Sites Up, we have a Wufoo form for support requests. It is much easier for us to dig up information on people’s accounts if we know what their account ID is. But people don’t know what their account ID is. It’s not important. We also have a particular setting that is important to know when doing support requests. So when creating this form in Wufoo, we’ll create two fields for this data, but just by using a CSS Layout Keyword, we can hide those fields from displaying to the user.
But just because they are hidden, doesn’t mean their values don’t submit! We can still autofill them. AMSU is a Ruby on Rails app, and on this particular view I can access this user data, so I just spit it out in the defaultValues param when embedding the form:
'defaultValues':'field6=<%= current_user.id %>&field8=<%= current_user.timeouts_enabled %>',
A little behavioral spying
Wufoo themselves used this technique on their support form. They wanted to know what page of the site users were on when they opened the contact form (it must have been in a popup at the time). They used some PHP look at the URL and insert it into a hidden field on the form. The point was to see if users were coming from the Help area (proving they attempted to search for the problem themselves) or not.
If you wanted to learn where users were coming from when they got to your form, a hidden field where you prefill the HTTP_REFERRER might be cool:
$_SERVER['HTTP_REFERER']
It’s very spoofable and generally not reliable, but for a little form like this, it will still likely gather some useful information.
Awesome article Chris !
Was silently wondering about Wufoo aswell.
Kinda turned it off since it got a little bit forgotten , but maybe I’ll look into it agai (this time a lil’ deeper).
Thx,
TeMc
great tricks, th
This is a very helpful article to me because I just started using wufoo.
Tnx!
Dude,
You are the MAN!
Chris, thanks for writing such a great tutorial detailing this feature! We’re glad to see you find such good usage for it.
My pleasure Kevin.
I was excited to discover wufoo a while ago, but kind of put it aside for a while. I thought I was being a wimp for wanting to rely on wufoo for form building rather than doing the work myself. This article sparked my interest again. Didn’t realize they had a sexy API to go along with it. Thanks!
Why do you recommend using the JS-embedding method with Wufoo forms? Wouldn’t non-JS users still be able to use the form if you use the straight up iframe?
If that’s a big concern… then you can go iframe. I care less and less about catering to non-javascript users every day. Cry foul if you must, but that’s the way I feel. The screenreader argument doesn’t hold up because most screenreaders deal with JavaScript just fine. Mobile browsers are dealing with it fine, even really old browsers handle JavaScript just fine.
For the record, the reason the JS Wufoo embedding method is recommended is because the wrapper for it can expand when needed, such as when the form is filled out incorrectly and needs to insert notes/information about what went wrong. Using the iframe method, when this happens the submit button is cut off making the form totally unsubmittable. Bad.
Holy shnikies, thanks for the heads up. I wish I would have known about that issue before deploying several Wufoo forms.
Sounds like maybe the best solution would be to include the straight up iframe form in a noscript tag as a fallback, and then include the JS version as well?
On the topic of catering to non-JS users, I do it because I’m one of them. I only enable JS for a very small percentage of the sites I visit, and I will leave a site that doesn’t work without JS unless I absolutely need to be there.
That’s a darn fine idea. re: noscript tags + JS
They are great!
Wow! Great article chris, I’ve been using wufoo almost since their official launch and never realized that was possible.
Thanks!
I love Wufoo so this is great! Thanks so much for the post.
wufoo, wufoo, we love wufoo. To be or not to, that is the question. To wufoo or not wufoo, that is not the question. If silence be the food of love, wufoo is the food of forms.
Ok, not exactly a poet either!
Great article, Chris! I’m a huge Wufoo fan myself and these are great exercises for pushing beyond what some would see as “limitations”.
G’day Chris,
I have checking out WuFoo for the current project I am working on, since you are a WuFoo guru! do you know if this is possible?
Can I pass a variable from another page (eg:Title of a WordPress Post) and grab that value for use with a Wufoo Form?
Cheers
wow, I never knew about WuFoo… looks pretty cool. Although, not free (3 free forms for individuals).
Great article, as usual!
Is there a way to set an on-click function for the pre-filled fields so that the pre-filled value disappears?
For example: if field1 is first name, and I add “First” as the prefill value, is there a way to auto-clear it when the user clicks inside the field (like you can with regular html forms)?
Thanks!
Jacob
P.S. If you don’t have “Digging Into WordPress” yet, go get it! It’s great!
That’s inside the iframe, so you can’t touch it with JavaScript from your end. You might wanna contact Wufoo and see what they have to say about that. That’s might just be considered a “hint” for what that field wants, and they offer a solution for that already with the hint boxes, however having it inside the field might be even better.
Agreed! I’ll contact Wufoo and report back. It would add that “something special”.
Cheers!
-Jacob
Turns out that Wufoo does not yet support this functionality, as expected. But they are considering it for a future update!
In the meantime, I’m not sure whether or not to go with the pre-filled values. Might be a hassle for the end-users, no?
Been using wufoo heavily with my clients. And can never go back. I agree with Chris, the javascript method is perfect for auto-filling the forms.
The main reason, <IE8 can do some funky things. And with the iFrame would end up losing the Submit button on the early IE browsers.
(Not good for non-profit donate forms!)
The themes can include your own complete CSS. works great.
Thanks for covering this subject!
Wow! Nice article on Wufoo. I’ve started using Wufoo on my site last year but decided to use a WordPress plugin instead. This year, I decided to take the plunge and use Wufoo again. Your post can really help me in enhancing my forms using Wufoo! Kudos!