wp-SwimTeam v1.19 beta available for testing

I flew out to Phoenix and back this week and had some airplane time to work on wp-SwimTeam.  I have completed what I am calling “Phase 2” of the Event Model changes.  Events can now be assigned to a swim meet AND the Opt-In/Opt-Out system is working in the Event Mode (which I had broken in v1.18).

The majority of the work in this build is related to Events and their connection to swim meets which is the precursor to Phase 3 which will be the generation of Meet Entries in SDIF format that can be imported into tools like MeetManager and WinSwim.  I have also fixed quite a few bugs in the report manager which were present when either the User or Swimmer option count was set to zero.  There was some logic that didn’t test right and would result in using the default count which is 5.  So if you have seen checkboxes without labels on the User or Swimmer report generator, this has been fixed.

Please let me know if you run into any issues.  I am doing some testing with our team right now and we have our pre-season open house this weekend which tends to result in a good chunk of our registrations.  Assuming all goes well, I’ll release an update to the WordPress repository early next week if not sooner.

[download#14#image]

wp-SwimTeam v1.18.747 released

This afternoon I released v1.18.747 of wp-SwimTeam.  This release includes what I am calling Phase 1 of the new Event Model.  The event model has been completely overhauled in anticipation of being able to generate Meet Entry files in SDIF format directly from wp-SwimTeam.  The whole Events tab looks and works differently.  Events are collected into what I call Event Groups.  This release adds the ability to import events from a Hy-tek Events File (.hyv).  Events are managed (added, deleted, imported, re-ordered, etc.) within the context of an event group.  In Phase 2 events will be connected to a swim meet via an event group although the swim meet will still retain the ability to re-order the events on a meet by meet basis.

Key features in this release are:

  • Phase 1 of overhauled Event Model is complete. The new Event Model introduces the concept of Event Groups. Events are now defined in the context of an Event Group. Swim meets currently do not have any connection to Events but that will chance in a release fairly shortly in Phase 2.
  • Added ability to import events from a Hy-tek Events File (.hyv) into an Event Group.
  • Added ability to delete all events from an Event Group.
  • Changed Google Maps API Key from required to optional. If the API key hasn’t been entered, wp-SwimTeam will now gracefully work without it.

I changed a lot of code in this release, if you run into anything odd or functionality that isn’t working or behaves differently, let me know ASAP and I’ll do my best to fix it quickly.  Now that I am back to a stable code base I should be able to turn bug fixes pretty quickly.  That is hard to do when you’re doing a bunch of remodeling!

This release has been committed to the WordPress Plugin Repository so you should an update notification on your Dashboard.  You can also download it and manually update it from the Download & Installation Page.

Edit (4/16/2012 @ 10:07 AM):  This update includes a database update so you must de-activate and re-activate the plugin after updating to have the database upgrade run.  One of these days I’ll figure out a more elegant way to do this!

wp-SwimTeam v1.11.659 now available

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.

Definite bug in Swim Meet Report short code

There is definitely an issue with the Swim Meet Report, particularly the opt-in/opt-out list, produced by the wpst_meet_report short code.  It produces different results depending on whether or not a user is logged in to the web site and what WordPress capabilities the user has.  I hope to have a solution this morning as it is causing a fair amount of confusion with my own team!

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.

wp-SwimTeam v1.4.573 released

This evening I released wp-SwimTeam v1.4.573.  It can be downloaded from this web site or from the WordPress plugin repository.  The plugin auto-update will also update to this release.  New and fixed in this release are:

  • Fixed bug in Opt-In/Opt-Out e-mail confirmation which duplicated recipients.
  • Fixed bug in handling Country when set to US Only.
  • Added Club Profile initialization based on State or Province in Team Profile.
  • Added E-mail confirmation for Job Assignments.
  • Added Job Options tab on Options page to configuring Jobs module.

Make sure you visit the Job Options tab to configure your jobs module.  There is still work to be done to report the number of credits a user has signed up for and to flag which users have not met the threshold.  Hopefully that functionality will come in the next week or two.

Update: This release had a minor update due to a file missing from the WordPress plugin repository.  The missing file prevented the Jobs Options tab from rendering.  Other minor tweaks were also made to the Jobs Confirmation e-mails.

Using the WordPress auto-updater?

WordPress has a nice built in feature to update plugins when there is a new version available.  Because wp-SwimTeam isn’t hosted in the official WordPress plugin repository, I haven’t been able to take advantage of this feature.

I have set up projects in the official WordPress plugin repository for both wp-SwimTeam and phpHtmlLib.   I am working on a process where the plugin updater will work by adding the code into the WordPress repository when Iam ready to release it.

Currently the version of the code in the WordPress repository is the same as what is available for download although the version number reported is wrong (1.0.553 vs 1.2.553).  The “553” is the critical part of the release number because it represents the Subversion commit number (build number) that the release is based on.

If you see a “plugin out of date” message within the WordPress Dashboard, it is because I am working on this process.  The latest and greatest release will likely be available first as a download on this site but when I reach what I consider a “stable” release, I will also make it available through the WordPress plugin repository.  Stay tuned as this flushes out.

Flip-Turn – swim results management

A few weeks ago I mentioned that I had started working on a new swim team project.  I am calling it Flip-Turn.  Flip-Turn is a basic PHP/MySQL web application which allows a swim team or swim association to publish swim results on the web in a format that is easy to navigate and view.

Dealing with results has been the last real big hole in wp-SwimTeam and I’ve started working on it a couple times only to abandon it because I didn’t like where it was headed.  Over the winter I had an e-mail dialog where a team was simply looking to store results in a database so they could be easily displayed on a web page.  As I started thinking about this I came to the conclusion that it would be an interesting project to work on and would be an easy way for me to find a better way to manage results.

For the last couple weeks I have been working on Flip-Turn as time permits and I now have a basic demo up and running.  You can see it here:  http://demo.flip-turn.com The demo is pretty simple, it allows a user to upload results in SDIF format and parses the results and stores them in a database.  The results can then be queried based on swimmer, event, or swim meet.  While pretty basic, it works pretty well.

In its current state Flip-Turn doesn’t deal with relay (E0) records but does handle individual (D0) records correctly.  In most cases, what people seem to be concerned with are their individual results so that is what I have focused on.  I don’t anything I have done will prevent dealing with relay records at a later date but for now, I don’t plan to address them.

Wile the code seems fairly robust, I am not ready to distribute the code yet as I don’t have a great solution for initializing the database tables or changes to the tables.  I need to figure something out there – right now I have an SQL script that needs to be run against the database to create the tables.  I used phpMyAdmin to initialize mine.

I fully expect to roll this effort back into wp-SwimTeam as this is something I’ve wanted to do for our swim team for a couple seasons.

Bugs and WP 3.0.1 testing

I have finally had some time to do testing against WordPress 3.0.1 and in the process, I have ran into a couple bugs that I need to fix.  So far I haven’t found any issues running against WP 3.0.1 itself, the things I’ve run into would be an issue with any version of WordPress.  These are known issues:

  • Critical:  Adding a Season will fail with an error regarding an Unsupported Action.  This failure is due to a typo in a constant.  I am not aware of a work-around.
  • Critical:  The Users tab on the Manage menu yields a blank screen.  The cause is unknown and I am not aware of a work-around.

I hope to have these bugs fixed later this week and fully qualify WordPress 3.0.1.

wp-SwimTeam v0.2.496 available

I just uploaded a minor  update to wp-SwimTeam.  This release adds enhancements to the reporting for jobs and the opt-in/opt-out system.  A new field called “Notes” was added to the Jobs definition.  This field is reported when viewing the Job Assignments for a swim meet.

The time stamp for opt-in/opt-out is now included when generating a swim meet report.  The time stamp can also be displayed via the short code by adding “timestamp=’y'” to the short code.  Reporting the time stamp will allow you to easily see exactly when users submitted their request.