Google moves Form Downgrade Option

Google has moved the “Running Man” icon which I had been recommending to downgrade a new Google Form to the prior version required by the Google Forms plugin.  Initially it looked like Google had removed the option which I was worried about.  The option to downgrade a form is now in the lower right hand corner for the form editor under the question mark (?) icon.

2016-05-22_13-30-02

Opting out of new Google Forms

As I noted in a post last week, Google has a new version of Forms on the horizon and it doesn’t currently work with the Google Forms plugin.

For the time being, it looks like Google has provided the ability to opt out of the new version of Google Forms which means you can still create forms which work with the Google Forms plugin.

2015-11-23_13-55-12

When creating a new form, look for the small running man icon in the lower left corner of the form editor as shown below.

2015-11-23_13-49-56

Clicking on this icon will revert the form the older version which works with the Google Forms plugin.

I still plan to look at supporting the new version as questions have already started to come in. I am just not sure when I will have a solution IF I can.

Google Changing Google Forms again?!?

Earlier today I was alerted to the possibility of Google changing Google Forms again.  Based on my reading, I think it is more than a possibility, it looks like a done deal to me.  This is a major change.

That doesn’t look very good.  Not only does it not look very good, it doesn’t work either.  I have no idea when Google will roll this out.  Almost certainly before I can update the plugin.  Based on my quick look at the HTML of the new form, it is very different than what Google has been generating for a number of years.

The biggest change is Google appears to be using their own custom DIV elements instead of real HTML INPUT elements for things like radio buttons and checkboxes.  I can’t think of why this could/would be a good thing but I am sure there is some rationale behind it. These news forms require Javascript from Google to work and it looks like the actual form submission process is also different.

So … it looks like a lot to figure out at a time when I  am really busy at work.  I am hoping this isn’t wide spread for a while as I don’t expect to have much free time until the Christmas holidays arrive and work will slow down a bit.

Google Forms v0.83-beta-1 available

Based on a question in the Support Forum I have added a new feature to suppress breaking a form into multiple columns when the browser is narrower than a specified width (e.g. on a phone).  This should allow forms which are set up for columns to be presented better on phones and tablets.

GForm_SS_88

If you’d like to try out this feature, download this beta release and provide feedback on any issues.  By default, the plugin will handle columns exactly as it always has.

Google Forms Beta (7742 downloads )

Google Forms Date and Time Fields

At some point Google added support for Date and Time fields to Google Forms.  When building the form, the Question Type now includes the “Date” and “Time” options.  These are pretty handy options because requesting dates and times from users is a very typical requirement.

GForm_SS_83Earlier this week a user posted on the WordPress Support Forum asking why their date field didn’t look the same on their web site using the plugin as it did when looking at the form within Google Drive.  The user assumed the plugin was doing something to change the form inputs.

The Google Forms plugin does not add or remove input fields (except the optional CAPTCHA field) – it simply retrieves the HTML from Google, strips of the content which falls outside of the form itself, and renders it within the WordPress context.

So why would the input fields be different when the form is viewed within WordPress versus viewing the Google Drive version of the form?

GForm_SS_85

Google Form in WordPress

GForm_SS_84

Native Google Form viewed in Firefox

Native Google Form viewed in Chrome.

Native Google Form viewed in Chrome.

As seen in the images above, the native Google Form is rendered differently in Google Chrome than it is in Firefox.  Having done some work with jQuery Mobile I know that Chrome recognizes HTML5 input tags where as Firefox does not.  I suspected this was the source of the problem.

I ran a couple of tests playing with cURL commands and different user agent strings and sure enough, Google is returning different HTML for different user agent strings.  I quickly added the user agent string to the parameters I was passing to the HTTP API to retrieve the HTML from Google and sure enough, the form, when viewed in Chrome, now matches what is seen when viewing the native form.

GForm_SS_87

I have committed the change to the plugin to pass the user-agent through the HTTP API.  This change will allow Chrome users to see the forms as intended.

What about other browsers?  Unfortunately the trick Google uses to add the date picker to the forms when viewed in Firefox, IE, or others which don’t recognize HTML5 input, or that Google thinks don’t support HTML5 input, isn’t easily passed through the HTTP API.

For now, I don’t see any simple way to solve this problem.  Over time it should go away as more browsers support HTML5 input types but for now, it is a limitation for non-Chrome users.  I fully expected it to work on the iPhone as the iOS browser is fully HTML5 compliant for input but it too is sent separate select inputs for the various fields.  I am not sure why, but it appears Google is treating their own browser differently than all other browsers.

The user-agent addition will be added to the next version of the plugin which will go out shortly with another validation bug fix.

 

 

Google Forms Custom Confirmation

I tend to get a lot of question regarding how to implement a custom confirmation page with the Google Forms plugin.  This morning I wrote up a step by step process which walks through all of the steps I use to define a confirmation page and make the process as smooth as possible for the end user.

Google Forms v0.77-beta-1 available

This morning I uploaded beta-1 of Google Forms v0.77.  This release would only be of interest to users who are using the deprecated gform shortcode and ware worried about PHP warnings in the log file (see this post on the WordPress Support Forum).

The warnings were a result of the plugin looking for meta data which is stored with the Custom Post Type (recommended) usage of Google Forms.  The fix skips the check when using the gform shortcode thus eliminating the PHP warnings in the log file.

Unless there is a significant bug reported I will likely release this update fairly quickly as I view the changes made as very low risk.

Google Forms Beta (7742 downloads )

Google Forms v0.75-beta-1 available

This evening I posted beta-1 of Google Forms v0.75.  This beta release contains a new option to turn off the HTML filter which has been part of Google Forms since the very early iterations of the plugin.  In the early days of the Google Forms plugin, the HTML Google generated was full of unnecessary stuff and as a result, it tended to mess up the rendering of the form within WordPress.  Over the years Google has iterated on forms a number of times and the HTML is much cleaner and includes new attributes for things like accessibility.

Based on a user request to support the accessibility attributes I decided to offer an option to turn off filtering completely.  The disable HTML filtering option is located on the Advanced Tab of the plugin settings.

GForm_SS_73

Google Forms Beta (7742 downloads )

Google Forms v0.73-beta-4

This evening I released beta-4 of Google Forms v0.73.  This builds add support for Right to Left (RTL) languages by adding a column order option when using multiple columns.  This functionality was requested earlier today on the Support Forum and was very easy to implement as the jQuery Columnizer plugin already supported RTL.  The only other change is an update of the language translation files.

Google Forms Beta (7742 downloads )