So you’ve designed a Google Form and you’re happy with the layout of it. Now you’re ready to integrate it with your WordPress site and you’ve decided to use the WordPress Google Form plugin. Awesome. Looks like it will do exactly what you want: Easily create custom forms and gather data in a Google Docs spreadsheet for easy collection and dissemination of data.
So you install WordPress Google Form and get your shortcode set up and you visit your page to see the result. In most cases, as long as the short code is properly set up, WordPress Google Forms works as advertised. 98% of the support requests I receive are for help with styling the form using CSS to make it match the host site better.
However, from time to time a user runs into an issue where WordPress Google Form simply doesn’t work. This usually manifests itself in one of two ways:
- The form is never displayed and instead an error message that indicates the form couldn’t be retrieved and try reloading the page.
- The form displays properly but doesn’t submit correctly and the form results are never posted to the Google Docs spreadsheet.
Case #1 usually indicates one of two things:
- Most frequently the short code isn’t properly formatted. This takes on all sort of possible problems, the most common one is when the WordPress Visual Editor converts the the URL to the form into a hyperlink. There are other errors, such as the wrong quote character around attribute values but the hyperlink problem is by far the most common occurrence.
- Your web hosting environment doesn’t support the WordPress HTTP API. This isn’t too common but it does come up from time to time. It is very common on “free” hosting service packages. Frequently these plans have fopen() and other remote transports disabled. The only solution here is to move to a hosting plan which supports the WordPress HTTP API.
- A firewall prevents access to Google for remote requests. I’ve only run into this once but it happened and it was very difficult to find. In the end, I didn’t find it, the user did but that was after we had done a bunch of debugging to figure out what was going on.
Case #2 usually indicates a problem with Apache’s ModSecurity.
I’ve run into this a couple of times and made some pretty significant changes to the plugin to account for ModSecurity but there is still a chance it can kick in IF the user is being asked for a URL or a similar value which ModSecurity doesn’t like. Right now there isn’t much that can be done when this happens except to not request URL values or to instruct the user to strip off the “http://” (or other) prefix.
In addition to the Debugging aid I’ve added to the plugin, I recently found the Core Control plugin. Core Control is a very useful plugin for chasing down the sort of problems I’ve encountered with WordPress Google Form. It can show which transports your server supports for the WordPress HTTP API and even has the ability to disable some of them to chase problems down.