wp-SwimTeam v1.40 released

I have finally released v1.40 of wp-SwimTeam.  Thanks to everyone who helped test the new features and flush out any bugs.  This release has a slew of new features and functionality.

  • This update requires phpHtmlLib v2.6.7 or later!
  • Fixed initializion bug when Adding Events to an Event Group. Events were by default not being assigned to the correct group.
  • Fixed pagination bug when managing large number of events. When paging through events the GUI would get confused.
  • Fixed Event Group bug which was propagating the wrong event group to subsequent actions.
  • Added support for Mixed Gender and Combined age groups.
  • Added support for Mixed Gender and Combined Events.
  • Added support for exporting mixed gender event entries in SD3 and HY3 formats.
  • Added support for mixed gender events when importing events.
  • Fixed bug resulting in database error when generating RE1 roster.
  • Re-implemented Roster Export functionality – multiple formats can now be exported. The export can also be limited one gender.
  • Added support for age groups where min age and max age are identical.
  • Added smart processing of 0 as min or max age in HYV event imports, mapping 0 to minimum or maximum age setting as appropriate.
  • Fixed bug in USS Number generation.
  • Fixed bug in HY3 entries generation where E1 record did not contain gender.
  • Fixed reported entry count when exporting SDIF, count was off by 2x.
  • Fixed bug exporting roster by single gender which resulted in no swimmers.
  • Fixed bug which prevented proper HY3 meet entry generation for Opt-In swim meets.

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

wp-SwimTeam v1.4.0-beta-3 available

This morning I resolved my Subversion problems with phpHtmlLib and have posted v1.40 beta 3 of wp-SwimTeam.  This release cleans up the Roster Export functionality which had become cumbersome as more formats were added.  Instead of multiple choices from the dropdown menu, there is a single choice (Export Roster) which brings up a new form which allows the user some control over how much of the roster is exported and in what format(s).

wpst_SS_05

This release is dependent on an update to phpHtmlLib so make sure you update it before loading this beta version.  You must be running phpHtmlLib v2.6.7 or later for this new Export Roster functionality to work correctly.

wp-SwimTeam Beta (12881 downloads ) Email Users Beta (30988 downloads )

Roster Export Improvements – Coming Soon!

Here is a tease of some improvements I am making to the Roster Export functionality.

wpst_SS_05

 

Currently when the roster is exported there is no control over which swimmers are included.  All active swimmers are always included.  Similarly, each format must be exported separately.

This new functionality will allow the ability to export gender specific rosters and/or multiple formats at the same time.

The next release of wp-SwimTeam will also require an update to phpHtmlLib which I had to make in order to properly implement this functionality.

Stay tuned!

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.

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.

wp-SwimTeam and WordPress Multi-Site

I’ve had a couple requests to support WordPress multi-site installations with wp-SwimTeam.  The Tab Model and Form Processor I use require some URL manipulation to work correctly and my original implementation works fine for “normal” installations but breaks when installed in a sub-directory which is pretty common with WordPress multi-site.  I’ve put off fixing in favor of other things but recently did some work on another project which got me thinking about the URL problem.

After getting the Event Module done I decided to take a look at fixing the URL problem and found it wasn’t too hard to fix.  The bigger problem was how pervasive my broken solution was!  I think I have found every place which required a fix.  Before I release an update I’d really like someone to try it with multi-site and give me some feedback.

[download#14#image]

phpHtmlLib v2.6.3.3563 released

This evening I released a new version of the phpHtmlLib plugin which wp-SwimTeam depends on.  This update addresses a number of PHP5 deprecated function warnings which are commonly seen when running under PHP5 with E_STRICT set.  I also fixed an icon bug which appeared on the GUI widget used across wp-SwimTeam when there was no data to display.

The update also removes the documentation and examples from the version of the plugin hosted in the WordPress plugin repository since they are only useful for developers.  A full version of the plugin including documentation and examples can be downloaded from the Download & Installation page.

wp-SwimTeam v1.14.674 now available

I have addressed the bug which slipped through the last build and released v1.14.674.  There was a situation when querying for a users first name or last name against a username where the first or last name didn’t exist, the WordPress API returned an empty array and sometimes returned a one element array containing an empty string.  I am not sure if this is due to different versions of PHP or some other nuance but this update correctly accounts for both situations.  The bug manifested itself as a warning from the phpHtmlLib plugin (which wp-SwimTeam depends on).

The update should appear in the WordPress Dashboard shortly and is available now from the Download Page.