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.
I have just pushed out v1.20.787 of wp-SwimTeam. This release fixes a pretty serious bug in the Jobs module. If Jobs were assigned using the Swim Meets tab, other jobs could potentially be unassigned, possibly even from prior seasons. Hopefully my own team was the only one affected by this problem. The WordPress Plugin repository has been updated as has the Download & Installation page.
One of the changes I made in the last week has introduced a pretty significant bug in the Jobs module. If you assign a set of jobs from the Swim Meet tab, it may unassign a bunch of previously assigned jobs, possibly even from prior seasons. I have identified the bug and am in the process of fixing it.
If you updated to any of the wp-SwimTeam v1.16.x releases you must update again to v1.17.707. I inadvertently introduced a bug which prevented almost all of the registration (season, swim meet, etc.) actions. I quickly fixed this bug once I became aware of it, I apologize for any inconvenience.
This morning I posted an update to wp-SwimTeam.
This release fixes a couple more places where the first and/or last name should appear but was being displayed as “N/A”. It turns out I had re-used the same code which I had fixed a couple weeks ago in some other spots so the problem was the same. This time I fixed it by moving the solution down into a parent class and eliminated a bunch of redundant code. Hopefully it is gone but there is an outside chance I missed one.
Anyone who has used wp-SwimTeam may recall that the actions used to be buttons across the bottom of the widget I frequently use to display data. This worked well until I had more actions than I had room for buttons. My solution was to move the actions into a drop down list and many of the tabs used this model. This release reconciles the inconsistencies so all tabs now use the drop down action model.
I have started work on some of the event changes I have posted about, hopefully I’ll have some new functionality in the next week or so.
I ran into a problem this past week that I am not sure will affect anyone else but my own swim team. Our volunteer coordinator let me know that she was unable to add new jobs. I couldn’t replicate the behavior in my development area which required me to debug it on the live server (ugh).
Because most of the things I add and/or changes I make to wp-SwimTeam are for the MacDolphins (but not always), I usually test them on the MacDolphins web site before releasing an update. When I first added the Jobs module to wp-SwimTeam I had defined column names in the database table. At some point I decided to be more descriptive with my names and changed the column names. I think, but I can’t be sure, that I did this before publicly releasing the plugin update. WordPress usually, but unfortunately not always, handles database schema changes correctly and will change column names.
In my case, WordPress, for whatever reason, didn’t change the column name, it defined a new one. While this isn’t of itself a real problem, having a few unused columns in the database isn’t preferred, it isn’t a real big problem either. Except that the default value for the column was never defined (oops) and at some point, MySQL (maybe MySQL5) started to care that the column wasn’t initialized.
The net result was we was we were unable to add new jobs because MySQL was returning an error message due to the uninitialized column that wp-SwimTeam wasn’t accounting for. The simple solution for us was to simply delete the columns that shouldn’t have been there in the first place and won’t ever be there for people using the plugin now.
In the process of chasing this problem down, I found an area of my database interface where I wasn’t properly accounting for possible database errors. I have updated the database interface class and the Jobs module which sits on top of it. Over time I will also retrofit this change into other parts of the plugin as I work on them.
Look for a plugin update to be released in the next day or so.
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.
There is still a bug I missed in the first nane / last name section of the code which I updated yesterday. If you haven’t already updated, I recommend holding off until I fix this other problem. I hope to have a fix available in the next hour or two. The bug manifests itself in a PHP warning from the phpHtmlLib plugin but that is not where the source of the problem is.
There was a typo in one of commits I made over the weekend which resulted in the Opt-In/Opt-Out CC address not working correctly. This release fixes that problem (which was affecting the MacDolphins). The release is available from the Download page and has also been committed to the Plugin repository. It should appear via the Auto-Updater in the next hour or two.
Update: I had the version number wrong in the post title – the correct version is 1.12.662.
About a week ago one of the volunteers inadvertently registered (Opt-In) our entire rosters for a swim meet. An Opt-In will supercede any existing Opt-In or Opt-Out information so we lost our entire scratch list for our meet this past Tuesday. I was out running errands getting my son ready to go on a mission trip when I started seeing numerous registration e-mails coming across my phone. Yikes – what happened? Initially I thought someone had gotten administrative access to our database and was playing games.
As it turns out the mistake our volunteer made was an honest one and I tracked it down by examining the Opt-In/Opt-Out records in the database. I have always logged the user ID for the user who submitted an Opt-In/Opt-Out request but never displayed it as I never had a need. It would have been really useful last weekend – imagine digging through your database using phpMyAdmin on an iPhone which is how I found it because I wasn’t anywhere near a computer at the time.
As a result of this exercise I have enhanced the Swim Meet Report on the Report menu to optionally show the user detail for the user who submitted the request. I also changed the Time Stamp so it can be shown if desired. Both of these options are on by default.
This release also addresses a bug where Opt-In/Opt-Out email confirmations were being sent to the Registration e-mail address. For a lot of teams this is probably same address but for the MacDolphins it is not. The result was our Accountant was being flooded with Opt-In/Opt-Out email confirmations and has been for the past three years! She never mentioned it to me until recently. Oops!
The release is now available from the Download page but has not been committed to the WordPress Plugin Repository yet because WordPress changed all of their passwords last week. While I can login to WordPress.com without any problems, I cannot get access to the plugin repository. Hopefully I will get this sorted out soon and then it should appear as an automatic update from the WordPress plugin repository shortly.
Update: I finally got my WordPress.org password issue straightened out and have committed the latest set of changes. The automatic update process should proceed within a couple hours.