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.

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.

wp-SwimTeam v1.34.963 available for download

This afternoon I fixed a couple of minor bugs and pushed out v1.34.963.  The primary new feature in this release is the ability to export Meet Entries to Hy-tek Team Manager.  I have had lots of requests to support Hy-tek over the years so I am happy to say I can finally support it!

As anyone who has read my postings over the past few years knows, I am no fan of Hy-tek.  Between the closed data format and the awful user interface, it amazes me that their products have become the defacto standards for Swim Team and Swim Meet management but they have.  If you want to play in this space you need to interface with Hy-tek.  Fortunately some smart guys decoded the HY3 checksum and through lots of experiments some other people have figured out the HY3 file format so building on the work of others, I can now export a roster and meet entries in HY3 format.

I would appreciate feedback in this area as I have tested what I can but there is no such thing as too much testing and I may not have envisioned every scenario.  There is also a very strong possibility that some of the fields in the HY3 format may not be in the right place or contain the right data.

I also fixed a number of issues when browsing Parents, Swimmers, and the Roster where the Search function wasn’t working correctly.  Most of these problems were due to the SQL changes I made to address performance issues but a couple of them were due to allowing search against fields which are computed as opposed to extracted from the database.

wp-SwimTeam v1.33-beta.948 now available

This afternoon I posted an early build of wp-SwimTeam v1.33.  You can download it and manually install it if you would like to try it.  This build addresses a number of bugs which I introduced by changing the SQL in v1.32 for querying user data as it relates to swimmers.

Please let me know if you run into any issues.  I plan to release this later today after some more testing.

Download:  [download#14]

If you run into any problems, please let me know.  I’d like to release this update in the next day or so.

wp-SwimTeam v1.32.931 now available

After a few days of testing on the MacDolphins site without any issues, I have decided to go ahead and release v1.32.931.  There are no changes between this build and the beta build except the version number and the removal of the beta tag.

The primary feature in this update is new SQL which addresses performance problems when working with user data, particularly when is relates to swimmers.  The Job Commitment Report was particularly noticeable in how slow it was (4-5 minutes) if it completed at all.  The SQL addresses that performance problem however since it used extensively across the plugin I wanted to make sure I hadn’t broken something else.

You can find the update on the Download & Installation page or in the WordPress Plugin Repository.

The Magic of the get_users() Function

While working on Email Users recently I encountered a performance problem with some SQL which I had received via the WordPress Hackers Mailing List back in January of 2008.  At the time I needed it for my wp-SwimTeam plugin (where I am still using it) and it served me well.  When I first committed a patch for Email Users (v3.4.0) I used this SQL to allow sorting of the users as prior to v3.4.0, only the usernames were displayed.

It turns out this SQL is pretty inefficient (I am by no means an SQL expert) and it was causing performance problems for people using Email Users with a large number of users.  Again I turned to the WP Hackers Mailing List and received some significantly improved SQL.

The ensuing discussion also recommended migrating my SQL to the WordPress API get_users() function.  I am all for using the API when I can as it is much safer and typically much easier to work with.  In this case, I couldn’t understand how it would help me retrieve the first and last names from the Meta table that I needed.  It wasn’t mentioned anywhere in the Codex so I was confused.

A subsequent post in the thread mentioned the “magic” of get_users() which I then tried and sure enough, the data I wanted was available.  Ok, now I am really confused.  Where does this magic data come from.  Fortunately another post referenced this article which explains how these magic methods work and why the data is available.  This is pretty neat and very useful although I have no idea how developers would know this exists based on the documentation in the Codex.

These “magic methods” strike me as one of those “inside baseball” things that not being a full time WordPress developer I’d never know about.  It is very useful and something I’ll certainly remember and use in the future.  Thanks to the WordPress Hackers Mailing List – an incredibly valuable resource.

wp-SwimTeam and WordPress 3.4

I see on my Dashboard that WordPress 3.4 is out today.  I knew it would be out soon as I follow the WordPress Hackers and WordPress Testers mailing lists but have not done anything with it yet.  In the past I have tried to do a basic smoke test against one of the release candidates before the final release is out but this time I haven’t had the time to do it.

So the answer to “will it work?” is “I don’t know!”.  I realize that isn’t a very good answer and I will try to test it in the next few days.  My recommendation is to hold off until I’ve done some basic testing.  I am not aware of anything that will break based on what I know is coming but until I test it, you never know!

I am now contributing to the E-Mail Users plugin

I am happy to say that I have been granted Subversion commit access to the popular Email Users plugin.  I have been using this plugin for a number of years and have submitted several patches which were included in the 3.4.x releases.  Recently I needed to add some functionality to support the MacDolphins web site and use of the plugin and after submitting a patch, I was invited to be a contributor by Vincent Prat at Marvin Labs which I gladly accepted.

The 4.0.0 release of Email Users is a pretty substantial change.  It updates the plugin to use the WordPress Options API and updated menu API.  It also adds a new feature that allows easy access to managing the email options for one or more users.  No more visiting the User Profile for each user, bulk actions are now available!

More to come over the next few days.