I have just posted a beta build (v0.94-beta-1) of WordPress Google Forms. This build introduces a new solution for calculating the CAPTCHA. There have been a number of concerns about the use of the PHP eval() function and recently, an alternate solution has been posted to the WordPress Support Forum. I have adapted the proposed solution to the plugin.
This build also addresses a concern about possible security issue with the user-agent string stored when logging submissions. It is technically possible for a malicious user to encode the user agent string with malicious code. This update ensures that data is sanitized before storing and presenting it.
This morning I uploaded another beta (beta-3) build of Email Users v4.8.5. This build addresses an issue with the mailusers_update_custom_meta_filters action not being applied to User Email (it was only applied to Group and Notificationemail). This problem was reported in the WordPress Support Forum about a month ago.
This evening I uploaded another beta (beta-2) build of Email Users v4.8.5. This build addresses an issue with the user’s email preferences not being respected when using a custom meta filter. This problem was reported in the WordPress Support Forum a few weeks back.
For the past week I have been working with WordPress.org to get my Google Forms plugin relisted. They recommended a different approach to addressing the security concern than I had implemented.
It took a little longer than I expected to get their recommendation working but I have implemented the fixes recommended by the WordPress Security Team and am in the process of getting the plugin listed again.
I would like to enlist some additional testing besides my small suite of test cases with the updated code.
I have just posted beta-4 of Email Users v4.7.10. This beta update fixes another issue with the line breaks (hopefully the last one) and also adds the capability to use or include the user’s email address when sorting and/or displaying the user selection lists.
This version of Email Users adds a new option to enable apply WordPress’ wpautop function to post content prior to sending it as part of a Post/Page notification email. This will allow retaining the line breaks in post content as they are shown with the visible editor. This new option is NOT enabled by default – it must be set on the Email Users settings page. I chose to do this because it would be a change of behavior for users who have been using the plugin and may yield unexpected results.
The difference between what a post notification with and without this setting checked can be seen in the following images:
Test Notification without “Process Content with wpautop” option:
Test Notification with “Process Content with wpautop” option:
Email received from “Send to User(s)”:
This option also ensures that email composed with the Visual Editor is correctly processed. The images below show the compose screen within WordPress and the view of the received email within Gmail.
Download the beta and report any issues encountered.
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.