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.

Finally fixed the Multi-Page Google Form results

Since I first added support for Multi-Page Google Forms I have had a sample form on my site with the submitted results displayed on another page. I use the Inline Google Spreadsheet Viewer plugin to display the submitted results on the page except it wasn’t working.

It worked fine for my Sample Form results but not the Multi-Page Form results. I finally figured out that I was using the wrong Google Docs key to display the results. I was using the key that Google Doc’s Share functionality provides instead of the key that the Publish to Web Page provides.  It is this later key that allows the plugin to operate correctly.  Doh!  Need to read the documentation a little closer I guess.

Email Users v4.3.14 released

This morning I pushed the v4.3.14 update to Email Users to the WordPress plugin repository.  This update adds a new Spanish language translation, updates the French language translation, and fixes a problem where users who have either the capability to send to a single user OR the capability to send to multiple users, but not both, receive a permission denied error when trying to send email.  A number of the permission errors have also been updated so they use the proper WordPress styling.

WordPress Google Form v0.33 released

This afternoon I released the v0.33 update to WordPress Google Form.  This update introduces a new setting which allows users who are using the email notification to turn off the Bcc to the Blog Admin feature.  This setting is on my default to match the behavior of the plugin prior to v0.32.

Several other minor bugs were also fixed which affected how default plugin settings are handled.  You can find the update in the WordPress Plugin Repository or on your WordPress Dashboard Update notification.

What happened to v0.32?  I failed to update the version number in the plugin file before tagging the relase in the WordPress plugin repository so I had to increment the version number again.

WordPress Google Form v0.31 released

After a couple weeks of sitting on a new release, I have pushed out v0.31. This release addresses the ModSecurity problem that I had noted in a post a few weeks ago.  After chasing this problem down with the help of several users who were willing to work with debug code and/or give me access to their server, I was able to figure out what was going on.

The simple explanation is that the Apache ModSecurity module can be pretty restrictive and returns 403 errors when a form is submitted.  WordPress then does it’s thing and concludes that the page should be displayed again.  The net result is that form is never submitted and no feedback is provided to the user.  From what I’ve seen, ModSecurity doesn’t like URLs passed as parameters which WordPress Google Form does for the Google Form – it needs it to submit the responses to the form.

With this update two things have changed:

  1. If a 403 error is returned, the plugin will check for it and show a message if/when it happens.
  2. The Google Form URL is passed as an encoded parameter so it doesn’t get flagged by ModSecurity.

These changes won’t address all instances when ModSecurity kicks in – if your form includes any input where a user can type a response AND they user submits a URL as a response, there is a pretty good change a 403 error will be issued by the server.

Hopefully this change will help some very odd use cases where users don’t understand why the plugin isn’t working for them.  It has worked in four  (4) additional situations that users have asked me to look at it plus the two original that I looked at.

You can find the update in the WordPress Plugin Repository.