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 (1040 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.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 (1040 downloads)

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.

WordPress Google Form v0.39 released

This morning I released v0.39 of my WordPress Google Form plugin.  This update addresses the corner case exposed when using WordPress Google Form with the Unite theme from Paralleus.  To solve this incompatibility I’ve introduced a new short code attribute called unitethemehack which defaults to off.  By turning it on, WordPress Google Form will modify the Google Form HTML to protect the Submit button(s) from being manipulated by the Unite theme.

You can find this update in the WordPress plugin repository or as an update on your WordPress Dashboard.

Debugging a Theme conflict with wpGForm

About a week ago I was contacted through my WordPress Google Form Support and Help form by a user of my WordPress Google Form plugin.  The symptoms he described sounded very much like the problem I recently chased down with ModSecurity.  I figured this must be another use model that I hadn’t accounted for.

Fortunately and unfortunately, I was wrong.  After going through the usual process of trying to narrow down the problem (using wpGForm debug mode, disabling all plugins, etc.), we were able to isolate the problem to what I suspected was a theme issue.    Ugh.  A lot of times people don’t want to or can’t change their theme. I wanted to swap the theme for TwentyTen or TwentyEleven but that wasn’t really possible as the site is live and being used.

Now what?  Since the user couldn’t switch the theme and we ended up putting a copy of his theme in a development area and were able to replicate the problem.  Whew – the helped a lot.  I could switch back and forth between his theme and TwentyTen in debug mode and compare the results.

It took a while to track it down but it turns out the theme, Unite from Paralleus, has a jQuery script which scans the page content for Submit Buttons, removes the buttons, and rebuilds them to match the theme style.  In theory this is actually rather clever and makes the submit buttons attractive although I am not sure why it couldn’t be done with CSS classes, I didn’t look at it closely enough.  However, in practice when the submit buttons are reconstructed, they don’t contain all of the attributes they started with so they are not equivalent.  And this matters when submitting a Google form.  A lot.

A Google form just can’t be submitted with a submit button.  It needs to be submitted with the submit action having a named parameter and a value.  Google uses the named parameter and it’s value to support multi-page Google forms.  It is this named parameter and value that Unite strips off effectively making the form incomplete which causes Google to rejects it as an incomplete form.  Because Google rejects it, WordPress Google Form simply redisplays the form again.  To the end user it looks like the form was never submitted.

As a plugin developer, I am not sure what the right answer is here.  Actually, that isn’t true.  I do know the right answer is.  The theme should be fixed but I have zero control and influence over that happening.  To solve the problem in the short term, I have created a hack of sorts that works around this problem with the Unite theme but that is in a one-off build for testing.  What should I do to my plugin?  Add a unitethemehack=’on’ attribute?  Right now that is probably the best option although it feels pretty dirty.  The code to enable this hack is trivial because Unite won’t muck with submit buttons which have the noStyle CSS class applied to them.  At least there is a work-around.  The hack I added to WordPress Google Form is inserting class=”noStyle” to any submit button in the Google Form HTML.

But I am wondering how many more scenarios like this will I run into?  Is there a more general purpose solution?  Probably.  I’ve been thinking about a “find and replace” solution as I was asked about doing something similar previously to rename all of the submit buttons as something else.  I’ll keep noodling but for the time being, I think I’m going forward with a new attribute.

WordPress Google Form v0.38 released

Today I released v0.38 of my WordPress Google Form plugin.  If you look at the change log you’ll see I actually released it a couple times today (ugh).

Release v0.36 addressed a bug when the Browser Check option was enabled.  I susquently released v0.37 because I didn’t tag v0.36 correctly and the WordPress Plugin Repository didn’t see the update.  I then released v0.38 because I left some debug code active that I used to chase down the problem I originally fixed in v0.36.

I apologize for the multiple updates, it certainly was not my intention.  You can find v0.38 on your Dashboard Update or in the WordPress Plugin Repository.

WordPress Google Form v0.35 released

This afternoon I released v0.35 of my WordPress Google Form plugin. Included in this update are:

  • Minor fix to email formatting to address poorly formed HTML.
  • New short code attribute (spreadsheet='<url>’) which, when used in conjunction with the email=’on’ attribute setting, will include a link to the Google Docs Spreadsheet which contains the form submission data.

You can find the latest version of WordPress Google Form in the WordPress Plugin repository or as a Dashboard Update.

wp-SwimTeam v1.36.973 released

This morning I released v1.36.973 of wp-SwimTeam.  This build addresses a bug which prevents Users from signing up for job from the Jobs tab.

Yesterday I released v1.35.971 which addressed a problem when there were zero swimmers (aka a new installation) in the system.  This bug caused some of the pages to display oddly for the Roster and list of Swimmers.  Lastly, I enhanced the registration email such that it includes the Optional Field data defined for a swimmer.  This enhancement is only included when using HTML formatted email.  The Plain Text email continues to be very brief in nature.

You can find the latest version of wp-SwimTeam on the Download and  Installation page or in the WordPress Plugin repository.  I also released an update to phpHtmlLib yesterday which addresses the very odd situation which resulted in blank pages within the wp-SwimTeam Dashboard.

phpHtmlLib updated to v2.6.4.3566

I received another report from a user experiencing blank pages on some of the wp-SwimTeam tabs.  I had run into this previously and determined it to be a PHP issue in the early 5.3.x releases (.1 and .2 for sure).  PHP was terminating with a fatal error which resulted in an incomplete HTML page.  If you looked at the page source for these “blank” pages you would see nice HTML simply terminate with no closing tags which obviously resulted in missing content.

It turns out that phpHtmlLib was the culprit (which I suspected) and it was behavior that is inconsistent between releases of PHP including PHP4.

Many of the widgets in phpHtmlLib build upon one another by extending classes.  It is not uncommon to find some classes that are extended 3-4 levels.  No problem, that is one of the beauties of classes.  The problem came from some classes having constructors where some of their descendants did not AND the grand child (or great grand child) class referenced the parent constructor.

Because phpHtmlLib originated in PHP4, all of the syntax remains in PHP4 format including the use of class constructors.  The following example illustrates the problem I had run into:

<?php
/* vim: set expandtab tabstop=4 shiftwidth=4: */

class Sample_A {
    /**
     * Constructor
     */
    function Sample_A() {
        printf('<h3>%s::%s - Sample A Constructor</h3>', basename(__FILE__), __LINE__);
    }
}

class Sample_B extends Sample_A {
    /**
     * No Constructor!
     */
}

class Sample_C extends Sample_B {
    /**
     * Constructor
     */
    function Sample_C() {
        printf('<h4>%s::%s - Sample C Constructor</h4>', basename(__FILE__), __LINE__);
        parent::Sample_B() ;
    }
}


ini_set('display_errors','stdout');
error_reporting(E_STRICT | E_ALL) ;

printf('<h2>%s::%s - Instantiating Sample A</h2>', basename(__FILE__), __LINE__);
$A = new Sample_A() ;
printf('<h2>%s::%s - Instantiating Sample B</h2>', basename(__FILE__), __LINE__);
$B = new Sample_B() ;
printf('<h2>%s::%s - Instantiating Sample C</h2>', basename(__FILE__), __LINE__);
$C = new Sample_C() ;

?>

Running the code above results in the following with certain versions of PHP (e.g. 5.3.1).

<h2>sample.php::33 - Instantiating Sample A</h2>
<h3>sample.php::9 - Sample A Constructor</h3>
<h2>sample.php::35 - Instantiating Sample B</h2>
<h3>sample.php::9 - Sample A Constructor</h3>
<h2>sample.php::37 - Instantiating Sample C</h2>
<h4>sample.php::24 - Sample C Constructor</h4>

Fatal error: Call to undefined method Sample_B::Sample_B() in /var/www/clients/client3/web44/web/sample.php on line 25

Why does this happen? It turns out that earlier (and now later) versions of PHP would handle the missing constructor in Sample_B implicitly. Because some constructors are fairly complex and pass multiple arguments, I don’t really want to add all of the intermediate constructors just because some versions of PHP don’t handle the constructor chain properly (or at least consistently). So I came up with the following solution:

class Sample_B extends Sample_A {
    /**
     * Constructor - needed for early PHP 5.3.x compatibility
     *
     * @param Parent Constructor
     * @param array of Constructor Arguments
     */
    function Sample_B() {
	    call_user_func_array('parent::Sample_A', func_get_args()) ;
    }
}

Adding this constructor to the Sample_B class results in the following (which is what I want):

<h2>sample.php::39 - Instantiating Sample A</h2>
<h3>sample.php::9 - Sample A Constructor</h3>
<h2>sample.php::41 - Instantiating Sample B</h2>
<h3>sample.php::9 - Sample A Constructor</h3>
<h2>sample.php::43 - Instantiating Sample C</h2>
<h4>sample.php::30 - Sample C Constructor</h4>
<h3>sample.php::9 - Sample A Constructor</h3>

There is a chance there are more places within phpHtmlLib that could have this problem with some versions of PHP5.3.x. Now that I know how to solve them, fixing them is pretty simple and very quick. If you run into any blank pages within wp-SwimTeam, let me know ASAP and more than likely a solution like the above within phpHtmlLib will address the issue.

The phpHtmlLib plugin has been updated to v2.6.4.3566 and committed to the WordPress plugin repository.