Swim Team v1.42-beta-6 available

This morning I have posted a new build, v1.42 beta-6 of the Swim Team plugin.  This beta release makes a major change to how the plugin includes the various files the plugin uses.  Historically, Swim Team modified the PHP include_path as part of the initialization to include the paths where included files are expected.  In newer versions of PHP this seems to cause some problems for some users.

I have changed the plugin to eliminate the need to modify the PHP include_path however the process of doing so required touching almost 100 files within the plugin.  I have been through all of the menus and tabs and believe I found accounted for every file which included but there is always a chance I have missed something.

Please report any problems and I will do my best to fix it quickly.

wp-SwimTeam Beta (278 downloads)

wp-SwimTeam v1.42-beta-3 available

This afternoon I released beta-3 for wp-SwimTeam v1.42.  This builds adds a new option to allow control of the temporary storage used when exporting data to use outside of WordPress.  For now, this new functionality is limited to Roster Export only however if it works, I’ll do it for everything.

wpst_SS_06

Historically wp-SwimTeam has used PHP’s temporary file facility to store the constructed export data and it then sends it to the browser for download.  In a few corner cases, it appears the server configuration won’t allow doing this so I have added a new option to use WordPress transients as temporary storage.  It is a little slower than using temporary files so be patient for the download dialog box to display.  I am hoping this is a viable solution and will allow users who run into this issue, which I assume is security related, to use wp-SwimTeam.

wp-SwimTeam Beta (278 downloads)

Chasing Checkbox Support

For the past couple of days I have continued to look at the problem I wrote about with Google Forms and Checkboxes with PHP 5.4 and PHP 5.5.  It turns out, that it really isn’t PHP version related, at least I don’t think so.  It is WordPress related as near as I can tell.

As I’ve written before, I love VMware Workstation as it allows you to create virtual machines for very specific purposes, use them as long as needed, then put them away until needed again.

I created an Unbuntu VM to play with Ruby on Rails a couple months ago so I decided to check what version of PHP it had running.  Lo and behold, it had PHP 5.5.x running so it was a good platform to further test potential solutions for my checkbox problem.  My Windows environment is running PHP 5.3.3 and is still running WordPress 3.6.1 (don’t ask why but it proved to be very useful that it was).

I quickly set up WordPress 3.8 on Ubuntu and sure enough, submitting the form failed.  The exact same plugin code on my Windows VM submitted correctly.  I continued to dig through my code and eventually into WordPress itself trying to see what was different.

I eventually started looking at the source to wp_remote_post() and decided to identify which transport was being used.  On Windows WordPress was using cURL but on Ubuntu it was using Streams.  Ah-ha.  Since the WordPress HTTP API abstracts the details of the transports away from the application, it shouldn’t matter but it seems to.  I continued digging.

Using an advanced feature of WordPress Google Form to control transports, I disabled the cURL transport on the Windows machine and much to my surprise, the form still submitted correctly.  Now this is odd.  So I then installed cURL on Ubuntu and the form submitted correctly.  The good news is there at least appears to be a solution although I’d prefer to not have cURL be a requirement.

Now what was different?  I started looking into WordPress’ class-http.php file (which defines the WP_Http class) and noticed that the file on Windows was very different than the file on Ubuntu.  Looks like something changed between 3.6.1 and 3.8.1.

I decided to download the 3.6.1 and 3.7.1 releases from the WordPress archive and do some tests on Ubuntu where it is trivial to switch between WordPress releases.

To add a little more information, I did some testing with older versions of WordPress in combination with the http_api_transports to force a specific transport (‘streams’, ‘fsockopen’, and ‘curl’).  I found the following results:

WordPress 3.6.1 WordPress 3.7.1 WordPress 3.8.1
cURL Success Success Success
fsockopen Success Fail Fail
streams Success Fail Fail

Something clearly changed with the streams and fsockopen transports between 3.6.1 and 3.7.1.  A diff of the class-http.php file shows the change was substantial as the files are significantly different.

At this point I have concluded that my plugin will only work with sites where cURL is available.  I will probably release a version which displays a warning on the Dashboard if cURL is not available and that usage of the plugin is not recommended.

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.

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 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.

wp-SwimTeam v1.21.790 released

This morning I released v1.20.790 of wp-SwimTeam.  This release addresses a bug which only appears on some hosting configurations where the URL http://www.example.com and http://example.com don’t resolve to the same place.   It isn’t clear to me why the server variables sometimes truncate the prefix but in some cases it happens and in some cases it makes a big difference.

Thanks to a couple teams for letting me access their site and chase this problem down as it doesn’t happen on my own sites.  This version makes use of the WordPress API (which I probably should have done that in the first place) to construct URLs for the tabs instead of parsing the PHP server variables. I’ve done a fair amount of testing on four different sites over the past 24 hours so I feel pretty good about the new implementation.

I have also incorporated this URL fix into the construction of the links on the Tabs for the Swim Team, Manage, Reports, and Options pages.  While I wasn’t having a problem here, the new solution is the “correct” way to construct the URL and should be more robust in different WordPress configurations.  WordPress has already figured out the various server configurations, no need to reinvent the wheel!

The update has been pushed to the WordPress Plugin Repository so you should see an Upgrade notification on the Dashboard soon if it isn’t already there.  This build is also available from the Download and Installation page.

WordPress 3.2 will require PHP5

WordPress 3.2 beta is out for testing and with it comes several requirements.  The two notable requirements are PHP 5.2.14 or newer and MySQL 5.0 or newer.  I will likely move to 3.2 for wp-SwimTeam development once it is released and I’ve done some testing with it.  I’ve been running under PHP5 (5.2.14 and 5.3.x) for a while now so I don’t see this as an issue but it might be for people running on older web hosts.

Bug found – PHP 5.3.x incompatibility

The problem which I suspected was due to a plugin conflict turns out to be a PHP 5.3.x incompatibility.  I don’t have a solution yet because I don’t fully understand what changed but I am working on it.  There is no potential of database corruption, the bug simply fails to load the GUI on any of the Swim Team pages except the Overview page.  This bug only affects sites running on PHP5.3.x, sites running on PHP 5.2.x or PHP 4.4.x are not affected and will operate correctly.

UPDATE

I have identified and fixed the problem.  There is a change in PHP 5.3 which affects how objects of a child class can call methods in the parent class.  The syntax which has worked fine until PHP 5.3 occurs in both the wp-SwimTeam plugin and in the phpHtmlLib plugin so both will need to be updated.  I have found several places where the code needs to be updated to the new syntax requirements but still need to do further testing to make sure I have found them all.