Earlier today I received a report of a security bug in wp-SwimTeam. While the security flaw is true, I believe the ability to take advantage of the exploit is pretty hard is it would require knowing the value of a WordPress site’s ABSPATH value. It is certainly possible to guess the value in some cases but without knowing the proper value, the exploit simply fails.
This morning I released a minor update to wp-SwimTeam. Unless you are running under WordPress multi-site, you will not see a difference. Under Multi-Site there was a bug in the database query that pulls the list of users from the WordPress database. Because not all users stored in the user table should be visible to a particular site, the list of users needs to be filtered and limited to just those who have access to the site. It was this filter portion of the query which was wrong.
Yesterday I finally released Swim Team v1.42. With almost 50 downloads of the beta and no problems reported, I figured it was as tested as it was going to get! Some of the fixes and enhancements include:
Added checking and error messages for creation of temporary files used during export (CSV, HY3, SD3, RE1).
Added support for Event Number suffixes.
Added support for Transients as temporary storage when exporting data or generating reports.
Major change to how files are included to better support newer versions of PHP. The PHP include_path is no longer modified nor assumed.
Fixed bug in MyJobs which appears when no active season is designated.
Functionally this release is identical to v1.42-beta-8. You can find the update in the WordPress plugin repository or as an update on your Dashboard.
This morning I posted beta-8 of Swim Team v1.42. I hope to formally release it in the next day or two barring no reported issues. This update addresses a few more areas where I missed the changes to how files are included. This manifested itself mostly through usage of shortcodes but there were a few other spots too (e.g. event management).
This evening I posted beta-7 of Swim Team v1.42. This build addresses a problem reported earlier today. This bug manifested itself when there isn’t an active season which would be the case when the plugin is first installed. It is also possible to set all seasons inactive in which case, the same problem was present.
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.
It turns out adding support for mixed-gender events isn’t as simple as I thought it might be. Because so much of wp-SwimTeam revolves around age groups, I haven’t made it very easy on myself to add this enhancement.
Events are tied to age groups so in order to add a mixed gender event, I need a mixed gender age group to associate it with. A mixed-gender age group doesn’t really make any sense although it is similar to another feature which isn’t easy to support – age groups which are supersets of other age groups.
I have learned that some leagues have “special” events which are open to swimmers from multiple age groups. For example: The league my niece and nephew swim in has open freestyle events at the end of the meet. There are two age groups (10 and under, 11-18) for each gender. The wp-SwimTeam definition of an age group doesn’t work well for these groups either although it isn’t as problematic as a mixed gender event it.
After noodling around with a few ideas I think I have come to the conclusion that I need some sort of Age Group classification to allow defining a group which spans ages and/or genders. I am struggling with nomenclature for these groups but I believe the fundamental idea is sound.
For now I am referring to these special age groups as a “Combined” age group. They will not be counted in swimmer population numbers but will be used for Events and Entries.
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.
This afternoon I posted an early build of wp-SwimTeam v1.31. You can download and manually install it if you want to try it. This build completes the work for exporting the roster to Hy-tek Team Manager. All of the swimmer and parent fields that can be logically mapped into the Team Manager Athlete profile have been mapped. I was even able to map some of the Swimmer Optional fields (if they’re used) as Hy-tek Team Manager supports importing up to three custom fields.
If you run into any problems, please let me know. I’d like to release this update in the next day or so.
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.