Yesterday I was contacted by a WordPress Google Forms user who was getting a permission denied problem when submitting his form.  After trying a number of obvious things (like disabling all other plugins), I asked him to try switching to one of the default WordPress themes.  He switched the site over to use TwentyTwelve and the problem went away.  Yeah!  I was worried that we might be dealing with another ModSecurity problem.

So we narrowed the problem down to something in his theme but what would generate a 403 error?  The user was gracious enough to let me have access to his site.  By enabling Debug, I was able to see a dump of the header information.  The header information showed a redirect was being requested (makes sense due to 403).

Using Firebug I could see that the POST variables looked correct.  Oops, maybe not.  Everything looked ok except a hidden variable that Google uses in forms to pass information between the pages of multi-page forms.  Even single page forms have this hidden variable.  On the initial load of the form, this variable should be empty (a null string) but it wasn’t.  How could that happen?

Looking at the HTML page source for the form, I could see there was quite a bit of odd stuff in the form code.  It doesn’t come from Google, where does it come from?  Because form submission worked with TwentyTwelve but didn’t work with the user’s theme, I suspected there was a filter mucking with the HTML.

Sure enough, digging through the theme’s functions.php file I found a custom filter that did several things, one of which was make a call to wptexturize().  Well that would certainly explain the manipulated HTML.

The next step was to comment out the calls to the filter to verify that was indeed the problem.  As expected, the form submitted without any issues.  At that point I wasn’t sure what to tell the user.  We could have left the filters commented out but they are part of the theme and there for a reason.  I decided to look at the filter a little closer.  It turns out, the theme defines a short code, actually, it doesn’t define one, the filter looks for one, called [raw][/raw] and if it finds it, leaves the content between the short code tags untouched.

Well this will work!  So I created a test page and placed the wpgform short code between [raw][/raw] and sure enough, the form submitted properly.

While I don’t like what the theme is doing, at least there was a work-around for it.  Unfortunately there is no way (yet) to accomplish the same thing with the Form URL.

This whole process took a couple of hours – far more than I am typically able to spend helping people but I was genuinely curious what was going on.  I am glad we got the user up and running.

I am trying to think of a good way for people to define forms which can handle such a situation.  I can define a hook but that means people need to write some code to use it or I could define more options for the plugin that allow the generated HTML to be wrapped in some prefix and suffix text (plain or HTML).  I am not sure what to do so will continue to think about it for a day or two.