Why are my contact form submissions creating draft posts in WordPress?!?

We've been working with a new client recently. Their site has been having issues with being slow, so they've asked us to look into what can be done to make the site perform better. We've been diagnosing issues for them and we've made some recommendations. They're happy for us to follow up and work through some of the issues that we've found.

One of those issues had completely stumped me for awhile, and when I couldn't figure it out immediately I set it on the back-burner as something to revisit when I had some time. Well I was looking into other WordPress sites this afternoon and I decided to take another look at their issue.

The Problem: A contact form was set up to allow the public to contact them with questions and requests. For some reason the public submissions were creating blog posts in draft mode for every submission to the form. The form still sent the email, and the submissions were still stored as specific entries should the need arise to review a specific entry if the initial email were to be deleted. But that additional draft post was a bit superfluous and was not required. Nobody on their end was checking on these posts either. I mean why does the information need to be stored in two spots?

I spent an hour or two trying to find a configuration setting in the Gravity Forms plugin that would be causing this problem. Was the plugin doing it on purpose? Was it a setting?

I've never made a secret of the fact that I am not a fan of WordPress in general. I personally find the system to be a bit of a wild frontier of plugins and themes. My co-workers and I agree that the base WordPress system can be a very useful small scale website management system. But when the sites start to get bigger and more complicated, then the more brittle that system can become. This isn't the fault of the WordPress developers. It has more to do with quality control for those out there who make plugins for WordPress. Some plugins are very good, and the developers of those plugins have taken time to build something of quality. The problem is that there are also those out there who don't. A combination of good quality plugins combined with even a single below standard plugin can cause major problems when trying to keep a website's security and functionality up to date. But I digress.

So, like most coding and website problems that we need to deal with where we have not created the code, I Google'd the issue I was seeing. Low and behold, this issue is a well known one related to Gravity Forms. The plugin itself is well built and if you've read through the features, the issue here is not really an issue. Rather, the individual who was creating the initial form used the incorrect type of field.

When creating a form for a website or web application, there are several categories of form fields in the Gravity Forms plugin.

  • Standard fields - these are the basic HTML form fields that we all know, like Single Line Text, Paragraph (textarea), Drop Down (select menu), Number (integer), Checkboxes, Radio Buttons, Hidden fields, and a few non-field elements to help format the form.
  • Advanced fields - these are also basic HTML form fields but they were added to a later specification of HTML and also include some additional validation checks. They include specific fields for Names, Dates, Times, Phone number, Address, Website, Email, File upload, Captcha (ReCaptcha), Lists, Multi Select, and Consent fields.
  • Pricing fields - these are some advanced fields in the Gravity Form plugin that are designed specifically for developing E-Commerce cart systems or applications.
  • Then there are "Post Fields". This is where our issue arose. These are fields specifically designed to allow public visitors or users to post their own information to a website or web application. Generally speaking, these kinds of fields would be put into a form that would be behind some sort of login, but we've seen requests from public sites for visitor input before. Usually for contests, or requests for proposals and the like. These fields are not meant for a simple contact form.

After reading about the issue, I returned to the configuration of the form and took a closer look at what field types had been added to the form. Sure enough, the large textarea field was configured as a Post Field, not the standard Paragraph (textarea). I ran a test with a plain textarea field, and the result? No extraneous draft post. The submission still appeared as a form submission, and all of my test info was still received, but there was no longer a duplicate draft post cluttering up the database.

This is one of the most satisfying parts of my job. When I figure out a problem and find a solution. Mostly I do this with the help of my co-workers, but sometimes finding the solution myself makes it that much sweeter.

to blog