I recently had a report from a user regarding a problem importing a HYV event file. This event file was using Event Numbers with a one character suffix (in their case A-J). I didn’t know using a character suffix was a legal event number and had never encountered one previously.
It turns out it is fairly common, particularly with High School and YMCA teams. Since the database had defined the Event Number as an integer field, adding support for these “suffixes” as I am calling them wasn’t simple.
This build of wp-SwimTeam adds support for non-numeric Event Numbers and needs testing. I have added, updated, imported, and deleted event numbers and all seems to be working correctly. I have also exported SDIF and HY3 entry files which also look correct. However, I would appreciate some testing from someone who is more familiar with these sort of event numbers than I am.
Please checkout the beta release and provide feedback on any problems you encounter.
wp-SwimTeam Beta (1021 downloads)
This morning I released v1.41 of wp-SwimTeam. You can find the update on your WordPress Dashboard or in the WordPress plugin repository. This release addresses two bugs, one of which is pretty significant but would not affect a site where the age groups were already set up.
- Fixed bug which resulted in warning regarding extra output upon plugin activation. This was introduced in the WIP role code and as the result of a reference to a non-existing role.
- Fixed a serious bug which prevented creation or update of standard age groups. If age groups were already set up, this bug was unlikely to be encountered but for new installations, it was a significant issue.
You may have noticed an influx of content (posts, pages, etc.) related to wp-SwimTeam and wonder where it came from. For the past four years I have been developing, enhancing, supporting, etc. a WordPress plugin called wp-SwimTeam. This plugin can be used to manage the registration, volunteers, participation, and other aspects of running a youth swim team. Several groups have used it for Masters Swimming as well but it is targeted at youth swim teams.
I first started wp-SwimTeam to support our local neighborhood team when my wife was the swim team chair. Over the years it grew in features to the point where it was fairly comprehensive. My children no longer swim and my involvement in swim team has largely ended but I still maintain my plugin because (a) people use it and (b) I still feel it serves a need and it doesn’t take much of my time to continue supporting it.
I have always had a separate web site for wp-SwimTeam but over time that came to make less and less sense. In fact, I had some people contact me on this site and some on the other site so I had questions and solutions on both sites. I decided that I would migrate everything here So I exported all of the content and then imported it. There were a few hiccups, mostly around downloads but I think everything else came over ok.
The old URL redirects to the wp-SwimTeam page on this site. From time to time you may see updates for wp-SwimTeam or phpHtmlLib in addition to the normal flow of information on Email Users and WordPress Google Form.
Several people have asked for enhancements, many of which are similar. The most common request is to add either pre-filled or hidden fields based on something WordPress knows about. A recent request was to add tracking so a form could only be submitted by a user once. I am certainly not opposed to adding features like these, I think most would be pretty useful. However, there are some things to think about before implementing a solution or adding new features.
- To auto-fill a field or populate a hidden field, the field must be mapped from what the column is called on the Google Docs side of the form to something WordPress knows about (e.g. username, email address, etc.). How should this mapping be done? Arguments as part of the shortcode? For anything to be posted to the form processor on the Google side, the field must be defined on the form so the results spreadsheet has a corresponding column. For hidden fields, wpGForm would have to turn what is an existing field (which may or may not be a simple text box) into a hidden field with a value supplied by WordPress. This isn’t impossible, jQuery can do much of the work fairly easily but the problem is it is fraught with potential errors so I am reluctant to add it until I have a better idea how to bullet proof it. Pre-populating values is fairly easy, as long as we know what the field name
- I’ve considered, and posted about, introducing a Custom Post Type for forms. If I do this, then it makes addressing the tracking aspect fairly easy because the CPT id could be stored as part of the users meta data. That is pretty straight forward once the CPT exists (which it doesn’t yet). However, it does require the user to be logged into the site which many people don’t want to allow. This could also be handled by the CPT which could in theory, define a new form as anonymous or not. An anonymous form would have some limitations, tracking being one of them.
I’ve got some ideas on how to implement these features, most of which would be pretty useful. Introducing a CPT is absolutely on my radar screen but right now I am focused on my Swim Team plugin as we’re gearing up for Summer Swim Season here in North Carolina. Once I knock out my to-do list on the Swim Team plugin I’ll come back and look at adding the CPT for WordPress Google Forms which would facilitate adding some of the requests people have asked for.
There was a bug in the scratch process where if you started on the Meets tab when the Scratch action was selected, there was not a list of swimmers presented for the user to scratch. When starting on the Roster page and selecting a swimmer to scratch did work properly. The bug has been fixed and v0.2.488 is now available for download and both paths, starting with a meet or starting with a swimmer, now work correctly. The same bug would have affected Opt-In meets as well.
Like a lot of projects, documentation for wp-SwimTeam is severely lacking. It has been on my to-do list for a long time and I have been thinking about it recently. I was heading down the Wiki route recently and actually got one set up. I’ve never been a big Wiki fan but I do see their attraction for certain types of projects.
I personally prefer “real” documentation and by “real” I mean something you can print and read away from the computer. I’ve always like the model that used by Version Control with Subversion has used. The source is in DocBook format which means it can easily be produced as web pages, a PDF file, or an actual book.
Right now I am leaning toward using the DocBook format. At a minimum I am going to try it and see how it goes. Stay tuned!
For a while I have wanted this blog to be little more than an aggregator for some of the other thins I am working on. I thought LifeStream would do that and it does … sort of. LifeStream does a pretty good job of catching what is new, particularly from the Social sites (e.g. FaceBook, Twitter, etc.) and linking to it. What it doesn’t do is actually display content in a way where it can be read without leaving this site.
So I have moved LifeStream over to the sidebar using the LifeStream widget and reduced the number of feeds it monitors. In its place, I am now using FeedWordPress which is a plugin that monitors feeds and add the content as posts to this blog. Yes, some of the content is duplicated and I am ok with that. It allows me to have a single place where all of the content is available in one spot.
I prefer to post in content specific sites (e.g. on www.wp-SwimTeam.org) for certain projects so that material is self contained. But at the same time, I want that material to exist in the steam of all of the other things I am doing (this blog). So far it is working as I expected although I did end up with a category explosion when I added a couple feeds. That took a little while to sort out.
I posted wp-SwimTeam v0.1.418 late tonight to the download page. This update fixes a minor problem with SDIF generation of the roster. In certain instances the first name field would be empty.
This morning I uploaded a new version of wp-SwimTeam. It is available on the download page. This version fixes a minor bug that somehow I overlooked. The bug manifested as a PHP syntax error on the Reports menu. No other changes are included in this build.
Over the last couple of days I have been playing around with WordPress MU (aka WPMU), the multi-user, mult-blog version of WordPress. It has been on my “to checkout” list for a while but I haven’t had a compelling reason to do so until now.
I was asked to help set up some blogs for a group of soccer teams that are traveling to Europe later this year after doing one for my daughter’s team (one of the teams). This seemed like a good opportunity to try out WPMU since I’d also like to do it for my wp-SwimTeam plugin and make it available to swim teams as a hosted service.
Downloading and installing WPMU was pretty straight forward but getting it to work with sub-domain mode blogs turned out to be a challenge. I have concluded that without the ability to edit the httpd.conf file, it isn’t possible to make it work. I did manage to get the sub-directory mode working but that isn’t what I need for the soccer team project.
So for now, I am going to abandon WPMU and set up a series of regular WordPress blogs, one for each team. I am also looking at wp-Hive to help with this.