My solution to this request was to implement the placeholder attribute for the input tag. This is also much easier than expecting users to decipher the complex URL requirements to pass default values to a form. The difference between a placeholder and a default value is the placeholder value cannot be submitted. In the case of wanting to have something like “email address”, which isn’t a valid email address, in the form field as a “placeholder”, using the placeholder attribute is a better solution. At least I think so.
Placeholder values are defined when the form is added as a Custom Post Type.
Like the custom validation rules, to use placeholders you will need to know the name attribute for the field you are defining a placeholder for. Refer to this post I wrote on Advanced Validation to learn how to identify the field name.
I have posted the initial beta version of WordPress Google Form v0.56. This preliminary release has bug fixes to handle UTF-8 characters in from values and also handles the unusual case where a tab character is embedded in the form response value.
The embedded tab issue was particularly tricky to track down as it is (a) it wasn’t obvious since web browsers render tabs as white space and (b) it isn’t easy to actually enter a tab into an HTML form (which is how Google Forms are created). I was able to embed a tab in a form response by pasting some text from Word. It turns out the user that had the problem I was trying to resolve had done the exact same thing.
Handling the tabs turned out to be tricky so initially I thought I thought I might have to simply detect them and display a warning but in the end I was able to find a viable solution.
This beta release also has the first implementation of Transients for the initial rendering of a form. This use case is likely not all that common but came from a user who had four (4) forms on a single page and was seeing timeouts from Google. Caching the initial rendering of the form will help in this situation. Thanks to Camilo Flores for providing a patch which I based the implementation on.
Yesterday WordPress 3.6 was released. The bundled version of jQuery was updated to 1.10 which broke the jQuery Columnizer plugin I use to split a form into columns. The result was jQuery would go into an infinite loop and eventually you would have to kill the page.
Fortunately someone had already encountered this problem and provided a patch to the jQuery plugin. I have incorporated the patch and released v0.55. If you’re running WordPress 3.6, this is a critical release. Older versions should continue to run correctly.
I have just posted what I hope is the final beta release of WordPress Google Form v0.54. This latest beta release fixes a couple of minor issues, notably the lack of stickiness on the Form Submission Log setting and adds one new feature. You can now define a CAPTCHA message to appear below the CAPTCHA input box. These two screen shots show the information on the Plugin Settings page and the result when the form is rendered. The message is placed in a DIV which has the class “wpgform-captcha-description” so it can be styled as needed.
This evening I posted a new beta release (#4) of WordPress Google Form v0.54. This beta release addresses a problem where values with escape characters and/or other encoded characters end up in the response spreadsheet.
As you can see in the image above, the values are escaped until the final entry. This fix needs some testing to make sure it doesn’t break anything, please try it out and let me know how you make out.
A quick bump to beta-3 for WordPress Google Form v0.54 to fix a problem which resulted in a PHP error message due to missing post meta data for field validation. Forgot to account for the situation where a form hasn’t defined any fields to validate!
I have just uploaded beta 2 of WordPress Google Form v0.54. This update fixes the problem with the validation meta box not allowing adding additional fields (a jQuery script was not loading correctly) and also fixes the issue with range checks I mentioned in the beta 1 announcement. At this point I believe everything is working correctly.
I have put together a Validation Demo Form that you can play with to see how it works. There are some images below from the demo form running in my development area including how I set up the validation information when creating the form.