wp-SwimTeam v1.40-beta-7 available

This morning I released beta-7 of wp-SwimTeam v1.40.  This beta release addresses the problem where exported Hy-tek entries won’t load into Meet Manager.  The problem was the E1 records didn’t have the gender specified in columns 14-15.  I believe this problem was introduced when I implemented mixed gender events earlier this year.

wp-SwimTeam Beta (2470 downloads )

wp-SwimTeam v1.40-beta-5 now available

I have just uploaded beta-5 of wp-SwimTeam v1.40.  This is a minor update, the only fix is to the generation of the USS Number when used as swimmer labels.  Previously the USS Number was being computed in YYMMDD format where as the USS Swimming SDIF specification calls it out in MMDDYY format.

wp-SwimTeam Beta (2470 downloads )

wp-SwimTeam v1.38.983 released

This afternoon I posted an update to wp-SwimTeam.  This update addresses a number of bugs that have been reported recently.

  • Fixed bug in Hy-tek entries generation which caused a PHP warning but no loss of data.
  • Fixed bug which caused parents/guardians to see all swimmers instead of just their swimmers when opting in or out of a swim meet.
  • Added checking and a warning message when the selected meet occurs outside of the active season. Some operations makes sense, however some do not (e.g. opt-in or opt-out).

You can find the update in the WordPress Plugin Repository or as an update via your Dashboard.  You can also download it here.

Google Forms Beta (8753 downloads )

Odd behavior with PHP’s method_exists() function

I recently had a report from a user that many of the pages within the wp-SwimTeam plugin were blank.  This is odd and incorrect behavior but I have seen it before.  When I last chased it down I found that the way various versions of PHP 5.2.x and 5.3.x handled Constructors was different and in some versions Constructors in parent classes would be called and in some versions they wouldn’t.

I assumed this new report of blank pages meant that I had missed one of these Constructor issues somewhere.  It turns out that wasn’t the case.  This time I found that PHP’s method_exists() function behaves differently between different versions of PHP on different platforms.

The report came in from a site running PHP 5.3.13 which is the same as what I am running in my development area.  The only difference I can see between the two servers is mine is running on Windows under IIS where as the problematic site is running Apache under Linux.

When a page is rendered for wp-SwimTeam, the objects on the page are traversed and HTML code is generated.  The objects which comprise the page content can either be strings (HTML code) or objects themselves which then traversed recursively until all of the leaf HTML is assembled.  This is core functionality in phpHtmlLib that I have been using for years without any issues until now.

What I found was that if the variable passed to method_exists() was a string instead of an object, PHP goes out in the weeds and never returns which ultimately results in the blank page.  This is the code that has been rendering objects in phpHtmlLib for 10+ years:

if (method_exists($item, "render") ) {

It was fairly simple to fix it.  By checking to see if the item is an object prior to checking for it’s render method, the problem is resolves and the page renders correctly.

if (is_object($item) && method_exists($item, "render") ) {

I will be updating phpHtmlLib with this fix shortly.

phpHtmlLib v2.6.5.3569 released

This morning I release an update to phpHtmlLib which resolves an issue for users still running sites based on PHP 5.2.  The recent update to address early PHP 5.3.x releases contained code which was not 5.2.x compatible.  This update addresses that problem.  You can find the update on the Download and Installation page or as a Dashboard Update from the WordPress plugin repository.

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.

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.34-beta with Hy-tek HY3 meet entries!

Tonight I posted an early build of wp-SwimTeam v1.34.  You can download it and manually install it if you would like to try it.  This build introduces the ability to export Meet Entries in Hy-tek HY3 format which can be imported directly into Team Manager and Meet Manager.

This build also addresses a number of bugs I’ve encountered, the most notable being the inability to generate a single swimmer roster export in SDIF and HY3 formats.  Instead of just one swimmer, the entire roster was exported.  This has been fixed.  The CSV export was not affected by the bug.

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.33.949 now available

After a day of testing on the MacDolphins site without any issues, I have released v1.33.949.  There are no changes between this build and the v1.33 beta build except the version number and the removal of the beta tag.

This build fixes a number of problems related to swimmer and user data which surfaced after I changed the database queries I was using in v.1.32.

  • Fixed bug which prevented generating roster report.
  • Fixed bug which prevented scratching swimmers from Meet tab.
  • Added additonal table to Meet Report when operating in Stroke mode which reports number of swimmers Opting In or Opting Out per age group.
  • Completed first phase Meet Entries export in Hy-tek HY3 format. Not exposed on the GUI yet.
  • Fixed bug which prevented Job Reminder emails from being sent.

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