September 27, 2009
I develop quite a few sites in WordPress. Being that many of these sites are not “blogs” and need to behave like a traditional, static website, I’ve come across and worked through several obscure and (understandably) poorly documented issues and quirks in WordPress.
This is one of those stories.
I had a page template with a simple contact form that was posting to # (itself):
<form name="contactform" method="post" action="#"> <input name="name" /> <input name="email" /> <input name="phone" /> <textarea name="comment"></textarea> <input type="submit" name="submit" /> </form>
Looked great, but when I submitted the form, instead of reloading the page with the form posted, WordPress would display the 404 error page. Looking at the address bar, the URL was identical (except with a # at the end), and if I reloaded the page without reposting the form data, the unsubmitted page would load fine. I was both baffled and maddened.
As a last, desperate resort, I decided to change the names of the form fields, after which it worked perfectly. Being that I’d worked on that issue for an hour, it was a frustrating relief.
I didn’t know this at the time, but WordPress uses POST variables (the same kind that you pass when you submit a form) in the secret hocus pocus that goes on in the background as a page loads. And my POST variables were conflicting with them.
So, I just added “form” in front of all the field names, and it was golden:
<form name="contactform" method="post" action="#"> <input name="formname" /> <input name="formemail" /> <input name="formphone" /> <textarea name="formcomment"></textarea> <input type="submit" name="submit" /> </form>
So the moral of the story is this:
If you are posting a custom form anywhere within WordPress, use very unique field names so that they don’t conflict with WordPress’ variables. Otherwise, when you submit the form, it will have errors displaying the page, and instead display the 404 error page.
I think I just saved you an hour.