Blog

We work on the Internet and are constantly consuming information. There's a lot of it out there. We'd forget it if we didn't write it down someplace…

Visual Lizard's blog covers everything from web standards to the muppets, from php to comic books to music, just about anything we find interesting

Daily Links

Daily Links

Daily Links

Daily Links

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.

Something to be said for old school

I like working as a web developer. My job is to take graphic design for a web environment and translate it into a working interactive interface that allows the user to read, view, listen to, and interact with the creator's content. A slick interface with animation, interactivity, and vibrant imagery can be very engaging.

There are times however where we sometimes see that this level of complexity is not really required, and can in some cases take away from what the user is actually looking for. Working in this industry for more than 25 years, we see the trends come and go and the one thing that seems to remain consistent is that a simple straightforward presentation of content is always preferable to slick, colourful designs filled with animation.

I would say that I am somewhat biased in this opinion. I have a strong sense of wanting to cut through the fluff and the slick paint job to get to the heart of the content.

We've always advised our clients that it is important that the design shouldn't get in the way of what their audience is after. We ask our clients to take the perspective of who will be visiting their website or web application. Why are they visiting? What are they looking for, or what do they need to accomplish? Once they can answer those questions, we can start on the construction.

The reason we push our clients in this direction is because sometimes they get caught up in the intricacies and politics within their own organizations. They feel the need to push forward an agenda for the stakeholders. However that perspective can backfire for those stakeholders if the audience of users can't find the information they are after.

Recently we had a client with a new website administrator that was looking at their current content and realizing that the content did not represent the audience they were looking for. This wasn't an oversight, it was more about the evolution of the organization's purpose over time. The initial purpose of the site was to inform the public about the organization, its purpose, and its presence in the community. This involved information about public consultations, the history, and eventually construction.

Now that the organization is established, the purpose of the website has changed. They are now more focused on the services it provides to the community. Therefore the site architecture needs to change to better highlight those services. While the historic content of the site may be interesting, it is no longer the focus. A change in structure can also dictate a change in design.

If the focus of the content changes, the design may need to change in order to better present this new dynamic. Where a flashy design with a focus on big ideas was needed to catch the attention of the community as a form of marketing, the new focus may need to be more subtle and full of contextual content for the new audience. Substance over marketing.

Getting back to what I was originally getting at here. With this kind of change in focus, sometimes a more simple design makes more sense. Back to basics, so to speak. A simple layout of copy with minimal graphic design and imagery. Get the contextual point across without all of the figurative icing. And by working in this way, we also end up designing and providing content that is accessible to everyone by default.

As I said before, I am somewhat biased. I don't like ads. I don't want to see them cluttering up my viewing experience on a website, application, or social media. I understand the need for marketing, and I do appreciate good design in marketing, but I could do without seeing it, and I would safely guess that I am not the only one.

I would always advise keeping the design simple and keep marketing subtle. I watched Ready Player One again last night and there is a scene where the corporate villain is talking about filling up to 80% of the player's field of view with advertising in order to make a profit for the shareholders. This resonated with me when I look at web and social media interfaces today. I didn't like the idea in the movie, and I don't like it in reality.

When your website, it's marketing, and initial purpose has been successful, remember that you are now building and writing for an established audience. Use that knowledge to power through your re-design meetings and keep all the stakeholders focused on serving your audience. You will end up with a better project, better content, a more accessible site, and an ever increasingly loyal audience.