Email Users v4.5.1 released

This evening I released a minor update to Email Users. This update, v4.5.1 addresses two feature requests (Post Author Keyword Replacement and Post Excerpt Filtering, removes some debug code, and adds Italian language support.

You can find the update in the WordPress Plugin Repository or on your Dashboard as an update.

WordPress Google Form v0.56-beta-3 available

This evening I released beta-3 of WordPress Google Form.  This release addresses a requested feature to have “pre-populated fields which disappear when clicked“.

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.

GForm_SS_60

Placeholder values are defined when the form is added as a Custom Post Type.

GForm_SS_61

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.

Google Forms Beta (325 downloads)

WordPress Google Form v0.56-beta-1 available

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.

Google Forms Beta (325 downloads)

WordPress Google Form v0.54-beta-6 now available

I have a posted a new beta version of WordPress Google Form.  This version (v.054-beta-6) fixes a problem reported today which happens when Logging is enabled on certain servers.  This update will now test for the variables it wants to track before trying to use them.

This update also includes an enhancement with respect to HTTP API Transports.  Previously the plugin allowed control of the various transport options in debug mode.  Recently I found a case where it made sense to disable one of the transports on a permanent basis so I have pulled that functionality out of the debug module and moved it into the plugin core.

Google Forms Beta (325 downloads)

WordPress Google Form v0.54-beta-2 now available

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.

Google Forms Beta (325 downloads)

GForm_SS_52 GForm_SS_53 GForm_SS_54

WordPress Google Form v0.54-beta-1 available

The first beta release of WordPress Google Form v0.54 is now available for download. This beta release introduces a pretty significant enhancement – Advanced Validation for any field on a Google Form. This is an “advanced” feature as it requires the user to dig into the form in order to gather the necessary information for the validation to work correctly.

There are a few things which I know aren’t working (e.g. Range Checks) which I will look into.  I would really appreciate some feedback on this new functionality.

Google Forms Beta (325 downloads)

Advanced Validation with WordPress Google Form

One of the most common requests I receive is the desire to validate fields on a Google Form. Google provides some basic validation (required or not) but there really isn’t a way to ensure that if you request an email address that the user actually provides a valid one. Similarly, there is a need for URLs, numbers, and other specific fields.

I’ve been using the jQuery Validate plugin (which looks to have a new  home) for a while now to validate required fields and in some cases, email addresses, and most recently, CAPTCHA support.

A number of people have asked me about extending the validation to include any field.  I have been reluctant to do this for several reasons:

  1. The jQuery Validate plugin needs to know which fields (by name or id) it is going to validate.  There isn’t an easy way to pull these out of the Google Form HTML.  It could be done on a single page form but because Google supports multi-page forms, they only way to find the information we need is to visit every page of the form.  This isn’t easy to do programatically.
  2. The rules needed to be written in jQuery syntax.  While the syntax isn’t difficult, if I allow entry of Javascript the potential for syntax errors (which would break the plugin) is very high.

For these reasons I’ve kept this on the back burner for a while.  However, a couple recent requests got me thinking about it again and it would be useful for a project I am doing for my daughter’s soccer team.  So I decided to dig into it.

I don’t think it is possible to make it completely foolproof however I did want to make it as simple as possible.  I decided to add a new Meta Box to the Custom Post Type editing screen which “helps” the user define new rules.

The key to making rules which accomplish something is getting the name attribute for the form entry element that needs to be validated.  There really isn’t a good way to do this other than to look at the HTML source.  I like FireBug with Firefox but both Chrome and IE have the ability to easily inspect an element.

GForm_SS_48Now that I know my input element’s name (entry.409811816) I can set up my new rule.

If you have been using WordPress Google Form the first thing  you’ll notice is the Form Editing screen has changed quite a bit.  The form was getting very long and cluttered so I have moved some of the lesser used options to a new Meta Box on the right hand side leaving just the critical or frequently used options on the primary Meta Box.

There is a new Meta Box just for Validation.  This Meta Box lets you add a series of fields where you can enter the name, the type of check to perform, and if needed, a check value.

GForm_SS_49Once the validation fields are set up, you can see the effect as you fill out a form.

GForm_SS_50 GForm_SS_51I am going to clean up a few things and make a beta release available for people to test with.  I think this functionality is pretty cool and it was a bit of a challenge to (a) get it working and (b) find what I think is a viable usage model.  As always, feedback is welcome.

 

 

 

WordPress Google Form v0.46 is finally out!

After 19 beta releases, the first one being back on November 14, 2012, this afternoon I released v0.46 of WordPress Google Form.  This update represents a significant change in how the plugin works.  The plugin now defines a Custom Post Type for defining forms which is much easier to use than the old shortcode.  The shortcode was getting very complicated with all of the options.

The Custom Post Type functionality is supported by a new shortcode, wpgform, which is much easier to work with as it only has one argument, the Post Id of the form.  The original gform shortcode will continue to work however it will not received new features (e.g. columns) and at sometime in the future, I will likely deprecate it.

During the development process of v0.46, Google made a significant change to Google Forms.  The change required re-work of a number of features, support for multi-page forms being the most important and hardest to figure out.  Things changed on Google’s side several times as they rolled out the update to Google Forms.  The most recent change restored the ability to control the language of certain parts of the form immediately after I had spent several days working out a jQuery solution to allow text replacement on certain form elements.

There has been quite a bit of testing of this update over the past few months and I want to thank the people who tested the early releases and reported problems.  In particular I want to thank several people who trusted me with access to their server in order to chase down and debug some very odd problems.  In the end , I think I was able to resolve all of them.

The only known issue at this point is with respect to IE7 support.  I cannot get the validation support to work with IE7 which means the CAPTCHA doesn’t work properly either.  If someone can figure it out I am happy to incorporate a fix but I have exhausted by ability to chase down an odd problem with an ancient browser.

The number of new features and fixes is pretty long, I recommend reading the v0.46 release notes here.

You can find the update in the WordPress plugin repository or as an update on your WordPress Dashboard.  If you have any problems, I have retooled my Help and Support form to mimic the fields on the Custom Post Type screen.  Don’t hesitate to use it if you run into something which isn’t working.

WordPress Google Form v0.46-beta-17 is now available

I have just uploaded WordPress Google Form v0.46-beta-17 which addresses one bug and adds new capability to the CAPTCHA functionality.

  • CAPCTHA can now have 2 or 3 terms
  • CAPTCHA now supports operators for addition (+), subtraction (-), and multiplication (*)

GForm_SS_44 GForm_SS_45

I finally found a solution to passing the query arguments correctly so the page navigation for the Form Submission Log now works properly.

At this point I think I am close to done with this release.  Scope creep can be a killer and it has been a long time since I’ve formally released an update.  With the number of questions I am getting about new Google Forms and all of the fixes being in this beta, it is time to get it out!

The next question to resolve is do I bump the version number to 1.0 with all of the changes I’ve made or continue as it is and release v0.46 – thoughts?

Google Forms Beta (325 downloads)

WordPress Google Form v0.46-beta-16 is available

I have just uploaded WordPress Google Form v0.46-beta-16 which addresses one bug and adds the ability to oveeride the default Google text in several more areas:

  • Radio Button hint
  • Check Boxes hint
  • “Other” option when allowed as a Radio Button option

The bug fixed had to do with saving the Options tab losing the Override setting on the Advanced Options tab.  It only happened if the Options tab was saved after the Advanced Options but now that it is fixed, save order is no longer an issue.

I also added some more default CSS to account for some of the CSS changes Google has made lately.

Google Forms Beta (325 downloads)