wp-SwimTeam v1.22.823 beta now available

I have made an early release of wp-SwimTeam v1.22 available for download.  This new version introduces the ability to export a Meet Entries file in SDIF format.  I touched a lot of code as I worked on this feature and fixed a bunch of bugs as well as some nits which have always bothered me.  This version also adds checking on the various actions to ensure that when a selection is required, one has been made.

Download:  [download#14]

Please give it a shot and let me know if you run into any issues.

Export Meet Entries from wp-SwimTeam!

For the last week or so I’ve been working on a significant chunk of new functionality to export a Meet Entries file directly from wp-SwimTeam.  I’ve got a preliminary version of it working and I am able to generate a SDIF file which passes validation with the WinSwim SDIF Checker (which is absolutely invaluable if you work with SDIF data!).

The current implementation makes some assumptions (e.g. how zero times should be handled) which need to be under the control of the end user via a form. Now that I have it working, building the form should go pretty quickly.

The basic premise of exporting meet entries works is like this:

For each event in a swim meet (a meet must have a set of events connected to it), the active roster is compared against the scratch list and the remaining eligible swimmers have entries created for them.  For relay events, all eligible swimmers are listed as alternate swimmers for the ‘A’ relay team.  Once the entries are in your Meet Management tool, you can re-arrange swimmers into lanes and heats as you would normally do.

I know this new feature will save our team a ton of time as we try to reconcile our scratch list against the WinSwim database – now we won’t have to.  We’ll just import the entries and not have to worry about activating or deactivating swimmers.

I’ve also fixed a number of bugs so I am considering releasing an update with the functionality as it stands so people can try it out.  The bugs would be most obvious when either the User or Swimmer option count was set to zero.  In a number of places, the comparison was wrong and it result in using the default number of options which is 5.

 

Suppressing White Space

One of the more common questions I receive is with respect to extra white space on a Google Form. Sometimes the rendering of the form within WordPress is significantly different than it appears within the Google Docs context and people want to know why and more importantly, how to fix it.

Fortunately Google Forms have lots of CSS classes so in all of the cases I’ve seen so far, I’ve been able to help the person solve their white space problem by adding CSS definitions to their custom wpGForm CSS settings to achieve the result they wanted.

The two most common problems I’ve seen so far are extra margin and/or padding on paragraph <P> element and/or <BR> element.  Another situation which I ran into recently involved a theme adding a <BR> element after every <P> element.  This was an unusual situation but I suspect not all that uncommon.  How would this happen?  A theme can define something called the_content filter which will modify the content of a page or post before it is rendered and in this particular case, the filter appended  a <BR> element at the end of every P element!

Fixing White Space Problems

So how do you fix these problems?  Extra padding or margin for the <P> and <BR> elements can be tweaked using the following CSS:

div.ss-form-container p { margin: 0px; }
div.ss-form-container br { margin: 0px; }
div.ss-form-container p { padding: 0px; }
div.ss-form-container br { padding: 0px; }

You may not need all four directives, in fact, in most cases you won’t but it might take a combination of the four to achieve the desired results.

Suppressing Extra <BR> Elements

What do you do if you encounter a situation like described above where the theme is adding extra <BR> elements or you simply don’t want them?  Again, CSS can be used to solve the problem.

div.ss-form-container br { display: none; }

This CSS will essentially prevent the browser from rendering the <BR> elements within the form.  They will still appear in the source HTML but they have no effect because they are not displayed.

I recommend using FireBug to help chase down CSS issues.  It is what I use when looking into problems people have asked me to look at.

WordPress Google Form Enhancements

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.

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

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.

wp-SwimTeam v1.20.786 released

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.

wp-SwimTeam v1.19.783 released

This afternoon I released an update to wp-SwimTeam.  This latest update continues work on the new Event Model.  Events can now be imported from a Hy-tek Events File (.hyv) and connected to a swim meet.  I also made a number of GUI improvements to fix flow control and be more intuitive.  Other changes include:

  • Fixed wp-SwimTeam so it will work in sub-directory installations and WordPress multi-site.
  • Added new option to toggle message verbosity. Some actions generate numerous messages, this option will reduce and summarize messages.
  • Fixed Event Opt-In/Opt-Out which was broken with Event Model changes in v1.18.
  • Added ability to load Meet Events from an Event Group into a swim meet.
  • Fixed broken GUI controls for Events (expand, collapse, page forward and back).
  • Tightened up flow control between Event Groups and Events and Swim Meets and Events.
  • Changed buttons on for some actions (events, swim meets) to return to a logical place. “Back” and “Home” didn’t really mean anything in most cases. In particular, “Back” has been a reliability challenge so in most cases it has been eliminated.
  • Fixed several bugs in report generator which manifested themselves when User or Swimmer optional field count was set to zero.
  • Fixed bug which resulted in broken Opt-In and Opt-Out actions on the drop down lists.
  • Fixed bug which incorrectly entered Opt-In/Opt-Out information in Stroke format even when set for Event Mode.

This update is available now from the WordPress Plugin Repository or from the Download and Installation page.  Existing users should see an update notification appear on the WordPress Dashboard.

If you run into any problems, please let me know and I will try and fix them ASAP.  We’re gearing up for swim team season so I am actively engaged in adding features and fixing bugs right now.  My next effort, which I’ve already started, is what I refer to as Phase 3 of the new Event Model which will provide the ability to export a Meet Entries file accounting for scratches and/or registrations which can be loaded directly into one of the various Swimming applications (e.g. Hy-tek, WinSwim, and others).

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]