Support Cycle for Huge Form

This is a fictionalized story of a recent support cycle.

The issues and conundrums are real. The mentioned solutions are real solutions that are likely to work for you in similar situations. The story is fictive to omit the client's real identity and to arrange the issues and solutions in an orderly way.

Our client, a web developer, had a client who had a huge form with lots of upload fields. And they had problems with the form.

The support request came to us because our Master Form PHP was used to process form submissions.

The Initial Complaint

The initial complaint was that no uploads were happening. Uploads were supposed to be stored on the server and also attached to an email sent to website admin.

Turns out, people were uploading photographs directly from their cell phone.

Which would be fine. Except the server wouldn't accept files that big. When an upload exceeds maximum size, the upload is discarded.

It was a quick fix.

An .htaccess file was added to the directory where Master Form PHP is installed with these two lines:

php_value upload_max_filesize 64M
php_value post_max_size 128M

The first line is for the maximum file upload size. The second line is for the maximum size of form post data because the size of a form post includes the size of any and all uploaded files.

(PHP Form Submission Limits has more information about using the .htaccess file to change PHP-configuration limits related to forms.)

Other "solutions" that were considered:

• Determine a maximum size and use JavaScript to test the size before the form can be submitted. For oversized images, the user would need to optimize the photograph for a smaller file size before trying again.

• Split the form into several forms, with each form having only one file upload field, so the maximum post size doesn't have to be so high.

• Put each upload field into an iframe that pops up on demand. The iframe would upload the file separately from the rest of the form.

The above solutions weren't incorporated because they effectively would make the users conform themselves to the form's requirements rather than the form conforming itself to the user's requirements.

The Next Complaint

Some emails were received and others weren't.

Turns out the mail server's attachment size limit needed to be adjusted. The web developer took care of that at their client's server.

Email to ISPs at other servers would still reject email with oversize attachments. Because all attachments were being emailed via the one server, that wasn't an issue for this case. (Other ISP's maximum attachment size isn't something they could easily be convinced to change, if at all possible to do so.)

The Third Complaint

Another issue cropped up during this support cycle: When the form was submitted and an error message received on the next page, tapping "back" to the previous page cleared all the form fields.

It was a serious issue because it was a huge form with lots of fields and now the person must fill them in all over again.

It occurred only with certain browsers. The issue may have been browser specific and related to the form being at an SSL URL or to browser preferences the user had set up.

Be that as it may, it needed to be addressed to remove the aggravation.

Two things were done:

1. JavaScript tests for valid information in all form fields.

   It took a lot of coding to test all fields for valid information, but it was done.

   (HTML5 has built-in error checks. JavaScript was used because not all users could be counted on having HTML5-compatible browsers.)

   The user should now never see any error messages on the page after form submission. But it may still be possible, which is the reason for the second step.

2. Form contents are stored in a cookie.

   When the form is submitted, the form field contents are stored in a cookie. The cookie is now available to repopulate the fields when the form is reloaded.

   For security reasons, repopulation won't occur for file upload fields.

As an added bonus for the form user, the form content is stored in the cookie intermittently while the form is being filled in. Then, if they're unable to complete the form and come back later, the fields previously filled in are filled in again, allowing the user to continue where they left off.

Happy Camper

It was a tense period for the web developer's client. The form had not been thoroughly tested before opening up registrations. (It was a huge registration form.)

The issues were quickly addressed and everybody is smiling.

The takeaway is to thoroughly test a form before going live. Not always will everything be caught during the testing, so it's good to have responsive support available.

Even though we respond to support requests as soon as we're able to do so and generally get you going quickly, it's not quite instant. It's better to have the form working well before it's needed.

(This article first appeared in Possibilities newsletter.)

Will Bontrager