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.wp-SwimTeam Beta (823 downloads)
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!Google Forms Beta (1494 downloads)
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.wp-SwimTeam Beta (823 downloads)
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.wp-SwimTeam Beta (823 downloads)
2/14/2014 Update: If you have more than one form defined, do not use beta-5, there is a serious bug which corrupts the content of the defined forms so they all contain the same data.
Beta #5 of Google Forms v0.64 is now available for testing. This update addresses a plugin conflict between Google Forms and WordPress SEO plugin by Yoast. The new implementation removes the hook into the_content which is a much more robust solution.Google Forms Beta (1494 downloads)
I have just posted beta-11 of Email Users v4.6.3. This beta version has quite a bit in it, new functionality and bug fixes:
- CSS fixes to the settings page so the Editor boxes don’t over flow into the right hand column.
- Integration support for the Paid Memeberships Pro plugin.
- Language file updates.
- 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.Email Users Beta (1048 downloads)
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 (823 downloads)
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.Google Forms Beta (1494 downloads)
For the past couple of days I have continued to look at the problem I wrote about with Google Forms and Checkboxes with PHP 5.4 and PHP 5.5. It turns out, that it really isn’t PHP version related, at least I don’t think so. It is WordPress related as near as I can tell.
As I’ve written before, I love VMware Workstation as it allows you to create virtual machines for very specific purposes, use them as long as needed, then put them away until needed again.
I created an Unbuntu VM to play with Ruby on Rails a couple months ago so I decided to check what version of PHP it had running. Lo and behold, it had PHP 5.5.x running so it was a good platform to further test potential solutions for my checkbox problem. My Windows environment is running PHP 5.3.3 and is still running WordPress 3.6.1 (don’t ask why but it proved to be very useful that it was).
I quickly set up WordPress 3.8 on Ubuntu and sure enough, submitting the form failed. The exact same plugin code on my Windows VM submitted correctly. I continued to dig through my code and eventually into WordPress itself trying to see what was different.
I eventually started looking at the source to wp_remote_post() and decided to identify which transport was being used. On Windows WordPress was using cURL but on Ubuntu it was using Streams. Ah-ha. Since the WordPress HTTP API abstracts the details of the transports away from the application, it shouldn’t matter but it seems to. I continued digging.
Using an advanced feature of WordPress Google Form to control transports, I disabled the cURL transport on the Windows machine and much to my surprise, the form still submitted correctly. Now this is odd. So I then installed cURL on Ubuntu and the form submitted correctly. The good news is there at least appears to be a solution although I’d prefer to not have cURL be a requirement.
Now what was different? I started looking into WordPress’ class-http.php file (which defines the WP_Http class) and noticed that the file on Windows was very different than the file on Ubuntu. Looks like something changed between 3.6.1 and 3.8.1.
I decided to download the 3.6.1 and 3.7.1 releases from the WordPress archive and do some tests on Ubuntu where it is trivial to switch between WordPress releases.
To add a little more information, I did some testing with older versions of WordPress in combination with the http_api_transports to force a specific transport (‘streams’, ‘fsockopen’, and ‘curl’). I found the following results:
|WordPress 3.6.1||WordPress 3.7.1||WordPress 3.8.1|
Something clearly changed with the streams and fsockopen transports between 3.6.1 and 3.7.1. A diff of the class-http.php file shows the change was substantial as the files are significantly different.
At this point I have concluded that my plugin will only work with sites where cURL is available. I will probably release a version which displays a warning on the Dashboard if cURL is not available and that usage of the plugin is not recommended.
WordPress Google Form v0.63 introduced a change which allowed the plugin to work on newer versions of PHP, notably 5.4 and 5.5. Unfortunately that change has broken support for checkboxes.
For those who are new to the plugin or never needed to know how it worked, what the plugin does is retrieve the HTML for the form from Google and render it within the context of WordPress. When the form is submitted, it is actually submitted within the context of WordPress. The data is collected by the plugin and then submitted to Google. The retrieval from and submission to Google is done with the WordPress HTTP API. In particular, the wp_remote_get() and wp_remote_post() functions are used to retrieve and submit the form.
To complicate the problem further, Google uses Python as the backend for their form processor where as WordPress uses PHP. For the most part, the fact that they are based on different scripting languages isn’t a big deal. Until you get to checkboxes. Checkboxes in Python are handled differently than they are in PHP.
I had solved the compatibility problem a couple years ago (see this thread on the wp-hackers mailing list) using a small jQuery script which fixed the form variables on the WordPress side and manual construction of the body parameter for wp_remote_post() when submitting the data to Google. This solution worked fine until I received a bug report that nothing was being submitted on a site which was running PHP 5.4.x.
Fortunately the user who encountered the problem provided me with a patch that I was able to fold in which changed the way the body parameter was constructed (array instead of a string) which worked with PHP 5.4.x and also worked with older versions. However, I didn’t test it thoroughly as I have had several reports that checkbox content was not being submitted correctly. Uh-oh. I was able to verify the problem fairly quickly and was able to push out a version which essentially reverts how the body parameter is constructed (string instead of an array). The problem is, this build doesn’t work with newer versions of PHP.
I have PHP 5.5 running on an Ubuntu virtual machines for testing and so far, I have not found a solution which (a) works with PHP 5.5. and (b) submits checkboxes correctly.