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 afternoon I posted beta-4 of Email Users v4.8.5. This build adds some additional debug information to help chase down slow database queries. When in debug mode, Email Users will now report information about the query like this:
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.
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.
This morning I released v0.87 of the Google Forms plugin. This update includes a new check when saving a form definition. The check scans the HTML from the form to ensure it has the proper HTML structure the plugin expects.
The new version of Google Forms is not supported by the plugin so this check ensures that a user is notified that the form isn’t of the expected format.
You can find this updated on your WordPress Dashboard or in the WordPress plugin repository.
Last night I released Email Users 4.8.2. This version addresses the use of several WordPress deprecated function messages, support for custom email headers and footers, and adds a feature to allow the admin to hide the Email Users menus from non-admin users. Full details can be found in the Change Log.
This afternoon I posted beta-1 of Email Users v4.7.1. This release addresses a warning related to the max_input_vars setting when the server doesn’t have the configuration variable defined. This happens on some older server configurations, notably, those running PHP 5.3.8 and earlier.
This evening I posted beta-1 of Email Users v4.7.0. This build addresses, or at least recognizes, an issue recently reported in the WordPress Support forum where email was not being sent when a large number of users were being selected.
The crux of this problem is the PHP max_input_vars configuration setting which by default, is set to 1000.
Every user selected on the form plus the other form fields are submitted as “input vars”. If ~990 or more users were selected, the input vars would be exhausted and the form submit would be missing required fields. The result was no email sent and the form being redisplayed for the user.
While I can’t change the setting of PHP’s max_input_vars setting, I can detect when the scenario, I can detect when it might be a problem and warn the user.
The warning shown above will now be displayed whenever the number of users which could be selected approaches or exceeds the current setting of max_input_vars.
Hopefully this will alleviate the confusion around this issue. Please report back on any bugs or odd behavior.
I’ve had a number of reports recently regarding loss of line breaks when sending out Post or Page notifications. Nothing has changed in Email Users with respect to formatting the post prior to sending it via email. However, the fact that several people has run into this problem concerns me.
The only thing I can think of which would result in loss of line breaks is if the the_content() or the_excerpt() functions are not calling the wpauto filter (which both do by default unless turned off). As noted in the Codex page, some plugins and themes remove the action.
I’ve added a check within the Email Users Dashboard widget to report the state of the hooks which could reformat the text. The the_content hook is the most likely to change the formatting of the post content but the other two listed could also affect it in some cases.