Huh? How’d I miss WordCamp Raleigh?

I was perusing some WordPress feeds I follow this morning and was reading an article about recent debate on where Custom Post Types should live (plugin or theme – for the record, I am on the side that CPTs should reside in a plugin for the same reasons the article points out) on wpBeginner.com when I saw a mention that the debate originated at WordCamp Raleigh.

A WordCamp here in Raleigh?  How did I miss that?  Unlike many weekends where I am out an about with soccer, basketball, lacrosse or the like, I was around this weekend.  I couldn’t have gone to the whole thing but the venue for WordCamp Raleigh is maybe 15 minutes from my house.

Bummer – I really would have liked to have attended a couple of the sessions, in particular Using AJAX in your Plugins, Using Git with WordPress and a couple of others.

Maybe next year …

WordPress Google Form v0.45 now available

This afternoon I released v0.45 of my WordPress Google Form plugin.  After validating the changes I made in the beta with a user who was dealing with a polluted jQuery script, it looks like moving the jQuery script into the WordPress footer action is the right answer.

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

WordPress Google Form v0.45-beta available

I’ve made a subtle but potentially significant change to WordPress Google Form that I am looking for some people to try out.  The plugin generates a jQuery script on the fly to perform a number of actions depending on the shortcode attributes present and their setting.

Historically the jQuery script has been output as part of the form code but I’ve seen a number of cases lately where another plugin or in some cases, the theme, is manipulating the page content which ends up affecting the jQuery script.

In one case I looked at this weekend something, I am still not sure what, is injecting paragraph elements into the HTML after it detects a closing DIV tag.  For the most part this isn’t a big deal except, there are closing DIV tags in the jQuery script as part of the CAPTCHA functionality.  The CAPTCHA functionality injects a DIV which holds a second DIV and some other input elements and labels.  What ever is injecting the P elements into the HTML after every closing DIV is causing my script to have syntax errors when the page loads.

To solve this problem I have moved to loading of the jQuery script into the WordPress footer action.  In my testing making this change  has zero effect on the functionality but I’d like some other people to test it and provide me feedback.

Google Forms Beta (1041 downloads)

WordPress Google Form v0.43 now available

This evening I released v0.43 of my WordPress Google Form plugin.  This update addresses a couple of bugs and fixes a few more issues with the optional CSS prefix.  It also addresses a potentially serious problem when using Debug Mode with PHP version prior to 5.3.

  • Reimplemented shortcode attribute br=’on’ usinq jQuery instead of preg_replace().
  • Reimplemented shortcode attribute legal=’off’ usinq jQuery instead of preg_replace().
  • Fixed DEBUG mode so it will work with PHP 5.2 (which doesn’t support anonymous functions).
  • Fixed CSS prefix bugs which prevented CSS prefix from being applied to all Google CSS classes.

WordPress Google Form v0.42 now available

This morning I released v0.42 of my WordPress Google Form plugin. This version fixes a number of minor bugs, one major bug, and adds some new functionality. Of particular note is the ability to add a CAPTCHA to your Google Form to help reduce SPAM form submissions.

  • Added simple math based CAPTCHA support.
  • Reintroduced jQuery Validation for checking required fields.
  • Improved support for multiple forms on one page.
  • Fixed several bugs where CSS prefix, when used, was not output in some places.
  • Moved Debug control to its own tab on the settings page.
  • Added new Debug options to facilitate chasing down HTTP API issues.
  • Fixed bug where the CSS prefix, when used, was not being applied properly to elements which had more than one class. Only the first class was properly prefixed.

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

WordPress Google Form v0.41-beta available

This afternoon I made a beta version of WordPress Google Form v0.41 available for download from this site. I have not posted this version to the WordPress plugin repository yet as I’d like to get some additional testing done on it before doing so.

There are a could of significant new features and a few bug fixes in this version.

  1. Simple CAPTCHA!  You can now add a  simple math based CAPTCHA to a Google Form to help prevent SPAM form submissions.
  2. Improved support for multiple forms on one page.
  3. The return of jQuery validation for required fields.  This validation is optional but since I used the same jQuery plugin to implement the CAPTCHA solution, I figured I may as well make it available for required field validation again.  It works the same way it did in the initial plugin implementation until is was removed with the support for multi-page forms.
  4. New Debug options on a separate Settings tab.
  5. Several more bug fixes, notably for custom CSS prefixes.

Download the beta release and please let me know if you run into any issues.  You can see an example of the CAPTCHA and new Validation options on my Test Bed Form.

Google Forms Beta (1041 downloads)

CAPTCHA is working!

I work much better in the early morning than I do at night.  Always have.  Last night I was working on CAPTCHA support for WordPress Google Form and for the life of me, couldn’t figure what was causing a jQuery syntax error.  Granted, working on my laptop in my truck in the dark while at my daughter’s soccer practice isn’t the ideal work location but that was my situation when I had some cycles to look at it.

This morning I looked at it again, made one minor change and the syntax error was obvious.  Syntax error fixed and my CAPTCHA solution appears to be working.  I am going to clean up some debug code and then post a beta release for testing.  Hopefully I will have this formally released in the next day or two.

CAPTCHA Support for wpGForm

Over the past year one of the most common requests I’ve received is to add some sort of CAPTCHA support to WordPress Google Form.  I don’t deny the need for CAPTCHA but it has never been a real high priority for me personally as I didn’t have a pressing need and more importantly, because Google Forms don’t support CAPTCHA, there wasn’t an easy and/or obvious solution.

However, recently my Help and Support Form has been receiving quite a few SPAM submissions to the point it is annoying.  So now I have a vested interest in finding a solution.

Because Google Forms don’t support a CAPTCHA solution, anything I do has to be done on the WordPress side as part of the short code processing.  This makes it a bit of a challenge because the only way to support CAPTCHA is to add more content to a form.

Essentially what I need to do is generate HTML and insert it into the form and then process it and validate it upon form submission which then can’t progress if the CAPTCHA validation fails.  There are quite a few different CAPTCHA solutions, I wanted to find one that would integrate well with how WordPress Google Form works.

Since I needed to modify the HTML I immediately thought a jQuery solution would be the best bet as (a) I am already using jQuery in several places and (b) what better way to manipulate HTML than using jQuery!  A Google search yielded this list of 10 jQuery CAPTCHA plugins.  After looking through them I leaned toward QapTcha however in investigating it, using QapTcha would be a little more involved that I wanted.  I also considered jQuery Real Person but eliminated it as too cumbersome to integrate.  I may go back and look at these two again as both are interesting but both are more invasive than I was willing to take on right now.

I subsequently found another list of 10 jQuery CAPTCHA plugins.  This list had some overlap with the other list but one entry caught my eye:  #6 –  jQueryValidate Plugin plus PHP equals CAPTCHA  It caught my eye because I had previously used the jQuery Validate plugin within WordPress Google Form for validating required fields (it was eliminated later when it was no longer necessary as validation came from Google when I added support for multi-page forms).  After reading the article, I realized I could very easily implement a similar solution and more importantly, I could resurrect the jQuery Validate code from an earlier version of the plugin.

So that is where I am headed.  Getting an initial CAPTCHA on the page was pretty simple.  What proved to be the challenge was to only display the CAPTCHA when the Submit button is present.  It took me a little while to figure out the jQuery selector but as I write this post, I have the basics of a simple math CAPTCHA working for both single page and multi-page Google Forms.

I have decided to add the fields using the same classes that Google uses for their forms so any styling done using the Google CSS rules will also apply to the CAPTCHA fields.

If you want to test this out before I release it feel free to get in touch with me and I’ll make an early build available.  By no means is this solution fool proof but it should help eliminate some form SPAM and that is what I am currently trying to do.

Two Google Forms on one page?

A user of my WordPress Google Form plugin brought me an interesting problem to look at. He wanted to put two forms on one page. The forms were each placed in a DIV and then visible to the user based on which tab on the page was selected. The presentation isn’t really germane to the problem as under the hood the page had two forms on it.

What does this mean to WordPress Google Form?  Right now it means there is a bug (which I have fixed but not yet released) that results in a Javascript error.  The Javascript which manipulates the check boxes is added once for each form and run once for each form.  As I noted above, I have already fixed this bug and it has been tested on a live site.

However, there are still a couple of other things to sort out when more than one form is present which is why I haven’t released an update yet.  These are the things I am struggling with:

  • If the alert shortcode attribute is used, the alert from the first short code is always displayed.  What is desired is the alert from the submitted form should be displayed.
  • The HTML provided by Google which is used to build the form has a FORM element with an ID of “ss-form”.  This is not an issue when there is only one form on the page BUT is technically invalid HTML when two elements have the same ID.

I am not sure what to do about the second issue.  It wouldn’t be hard to manipulate the HTML so the FORM element ID is unique but I don’t know if it is used on the Google side and it could also result in CSS issues if rules have been defined based on #ss-form.

I am considering adding a new shortcode attribute to override the FORM element ID value.  I think this is the safest way to do it but really know if there are any ramifications on the Google side until I try it.

As for the alert, I think I need to track which form is submitted and detect which alert should allow me to generate the Javascript for the correct alert.  I am less worried about this issue than the FORM element ID issue.

While I am digging around in the code, I am also looking at CAPTCHA solutions.  The lack of CAPTCHA is a bit of a problem with Google Forms and it isn’t a simple problem to solve.  What do you do on multi-page forms?  CAPTCHA on every page?  CAPTCHA only on Submit page?  I think the later but that is a little harder to detect.

Time to add Captcha support for wpGForm?

I’ve had my Help and Support form for my WordPress Google Form plugin online since April and it has greatly improved my ability to help people use my plugin. I get all of the information at one time where as before it took several passes via email to get all of the data I typically need to resolve an issue.

Up until about two weeks ago, I never got any spam via the form but lately I’ve been receiving 2-3 form submissions per day that contain nothing but gibberish.  So it got me thinking about how to implement a Captcha solution.  A Captcha solution has been requested several times and I’ve never looked at it seriously because (a) Google doesn’t support it and (b) it wasn’t something I thought was terribly important.  I am rethinking my position how important it is!  😉

The fact that Google doesn’t support a Captcha solution is the biggest hurdle.  The challenge is to add the necessary code to the HTML generated by Google, recognize and process the Captcha, and it is passes, remove the Captcha input prior to submitting the form values to Google for processing.  This becomes a more complicated issue on a multi-page form:  Does every page have a Captcha or only the last page with the Submit button?

I don’t have a solution yet but this is something I am noodling on as I have some spare cycles.  The solution will almost certainly be jQuery based, I can’t think of a better way to do it and I am already using jQuery to process radio button inputs so they can be converted from PHP style inputs on the WordPress side to Python style inputs on the Google side.