About a week ago I got a notice from WordPress.org letting me know Email Users had been de-listed from the plugin repository due to potential security exploit. While the odds were low, it was still a vulnerability which required fixing. This came at a time I was heading to Taiwan for work so my ability to fix it quickly was limited.
This morning I had some cycles to work on it while traveling home. I made the necessary fixes, committed them to Subversion, and informed WordPress.org. I just received a notice from WordPress that Email Users has been listed again. It may take a day or two to propagate through their cache.
Look for the version update notice on your Dashboard and I highly recommend installing this update. There is one other fix for users who use the Ithinx Groups plugin which had a bug in it.
Today I released wp-SwimTeam v1.45 which fixes a possible security problem I was alerted to as well as addresses a number of bugs. The CSV roster export bug was the primary issue holding up getting this release out, I fixed the security problem last week.
It turns out I had implemented a method in both a parent class and (redundantly) in a child class as well. The RE1, SDIF, and HY3 exports all (properly) used the method from the parent class but the CSV export was using the child class version. It took me a while to sort it out as I was staring at the wrong code trying to determine what was wrong. It turns out, nothing was wrong, I was just looking in the wrong place. Once I removed the redundant method declaration, everything resumed working as it should.
I think I have resolved all of the multi-site issues, please let me know if you run into any more.
Earlier today I received a report of a security bug in wp-SwimTeam. While the security flaw is true, I believe the ability to take advantage of the exploit is pretty hard is it would require knowing the value of a WordPress site’s ABSPATH value. It is certainly possible to guess the value in some cases but without knowing the proper value, the exploit simply fails.
This afternoon I posted beta-1 of wp-SwimTeam v1.45. This build fixes a number of issues when running wp-SwimTeam under WordPress multi-site. In a number of cases all users registered within the blog network were presented as opposed to just those who are registered to a particular blog.
Swim Team season must be approaching because I’ve had a couple more bugs reports and found two more myself while looking into other issues. A couple these are limited to running under WordPress Multi-Site so most people / teams won’t run into them but there are some issues with report generation as well. I am looking into these and will issue an update as quickly as I can.
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.
After a couple days of testing and five beta releases, I have released WordPress Google Form v0.61. This build supports multiple instances of the same form on a single page.
Why would you do this? It turns out, it is a fairly common request. A number of people have uses of the same form where some of the fields are hidden and preset (both features were added fairly recently) which allows them to present the form in different ways with seeded input while allowing the user to complete the rest. Because the form instances are all based on the same Google Form, they will have the exact same entry elements with the exact same attribute IDs. HTML does not allow multiple elements to have the same ID attribute, the behavior is unpredictable.
To support this new feature, a new parameter, uid, has been added to the wpgform shortcode. The uid parameter can be set to any string which is legal for an HTML element ID attribute. When the Google Form is processed, all of the attributes are modified to include the uid parameter to ensure they each have a unique value.
[wpgform id='879' uid='B-']
This release also addresses some issues with missing CAPTCHAs which would happen under certain circumstances. The jQuery generation is much cleaner now as well.