I did some additional testing with UTF-8 characters over the weekend and everything is working as expected. With no known issues outstanding I have released v0.64 this morning. You can find the update on your Dashboard or download it from the WordPress Plugin Repository.
Fixed a number of strings which were missing translation wrapper functions.
Reverted to manually constructed body parameter for wp_remote_post() to allow checkboxes to be properly passed to Google.
Fixed warnings generated by calls to static functions which were not declared static.
Added check for HTTP API cURL transport and issue a warning when not present. There was a change between WordPress 3.6.1 and 3.7 to the WordPress HTTP API and the streams and fsockopen transports are unable to post form values back to Google using wp_remote_post().
Added a setting to allow hiding the cURL transport missing message on the Dashboard.
Added a check to ensure jQuery script isn’t output more than once.
Remove hook into “the_content” to reduce potential conflicts with other plugins (e.g. WordPress SEO plugin by Yoast).
Added placeholders for some of the form fields when defining a Form within the UI.
This morning I uploaded beta-4 of wp-SwimTeam v1.42. This build completes transient support for all file downloads ( reports, rosters, entries, etc.). Additionally, all download operations now share common code and consistently download files with the same content type.
I have just released beta-6 of Google Forms v0.64 which is a CRITICAL update for anyone who loaded beta-5. Beta-5 had a serious bug which if you had defined more than one form using the Dashboard UI, would corrupt the content of all of the saved forms so every form would display the same content. Beta-6 fixes this issue!
This afternoon I released beta-3 for wp-SwimTeam v1.42. This builds adds a new option to allow control of the temporary storage used when exporting data to use outside of WordPress. For now, this new functionality is limited to Roster Export only however if it works, I’ll do it for everything.
Historically wp-SwimTeam has used PHP’s temporary file facility to store the constructed export data and it then sends it to the browser for download. In a few corner cases, it appears the server configuration won’t allow doing this so I have added a new option to use WordPress transients as temporary storage. It is a little slower than using temporary files so be patient for the download dialog box to display. I am hoping this is a viable solution and will allow users who run into this issue, which I assume is security related, to use wp-SwimTeam.
This morning I uploaded beta-2 of wp-SwimTeam v1.41. This build adds intelligence and error messages during the export process (rosters only for now) to detect an unusual, but critical situation, which occurs when the plugin is unable to generate a temporary file. The temporary files are used to hold the generated data which is eventually sent to the browser for download.
Empty User Groups from the Groups plugin are no longer displayed when sending group messages or notifications.
Please do some testing with this build, I would like to release it fairly soon. I have limited knowledge of Paid Memberships Pro so it could use some testing. My experience with PMP is it is pretty fragile, I had to mess with my WordPress database just to get users assigned to PMP groups.
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.
This evening I uploaded v0.64-beta-3 of Google Forms. This version adds a check for the WordPress HTTP API cURL transport and issue a notification if it isn’t present.
There was a substantial change to the WordPress HTTP API between 3.6.1 and 3.7. I don’t know the full details of the change but what I found in pretty extensive testing is the streams and fsockopen transports work in 3.6.1 with the Google Forms plugin but from 3.7 and later, they do not.
However, the cURL transport does work and as long as it is available, the plugin will work as it always has. The problem is I cannot find any way to work with sites that don’t have the cURL transport available so I have added this check and issue a notice when it isn’t present.
Please download and test out this beta version and report any issues found.
This evening I released beta-2 of the upcoming v0.64 release of WordPress Google Forms. This build addresses a problem recently reported on the Support Forum where the responses for checkboxes wasn’t being recorded properly.
I was able to verify this problem using one of my test forms and began looking into it. It turns out, the changes made in v0.63 to allow the plugin to work with later versions of PHP 5.4 breaks the ability to uses checkboxes. This build employs a similar method of submitting parameters to Google that versions prior to v0.63 did.
Handling checkboxes has long been a challenge due to the different ways which Python (used by Google) and PHP (used by WordPress) handle the assignment of checkbox values to a named parameter.
Please download this build and test and let me know if you run into any issues.
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.