Earlier today I released Email Users v4.7.10 which is the formal release of a number of fixes I’ve had in the queue. Now that it is out, I’ve moved on to the first real new functionality in a while which is why this will be v4.8.x.
Recently there was a 1 Star rated review of Email Users which had a comment about not being able to search for a user in a list of potential recipients. As you can see in the comments, I didn’t disagree with the user although what they wanted to do was sort of possible.
I’ve used the jQuery Chosen plugin a couple times and it works great for making SELECT elements much more user friendly. I decided to add it to Email Users to make finding users, particularly for sites which have lots of users, much easier. If you used WooCommerce, you’re familiar with Chosen as that is what WooCommerce uses for SELECT elements as well.
The v4.8.0-beta-1 release is the first implementation of Email Users with the jQuery Chosen plugin integration. Please download it, try it out, and report any issues or concerns.
Implementing Chosen allows for easy search and selection as noted in these images.
From the Send to User(s) page
From the Send to Group(s) page
From the Send to Group(s) page after entering “au” to do some filtering
Based on a question in the Support Forum I have added a new feature to suppress breaking a form into multiple columns when the browser is narrower than a specified width (e.g. on a phone). This should allow forms which are set up for columns to be presented better on phones and tablets.
If you’d like to try out this feature, download this beta release and provide feedback on any issues. By default, the plugin will handle columns exactly as it always has.
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.
I had started looking at bounce issues a while back but never completed the work. It turns out bounce emails are problematic and the PHPMailer code included with WordPress has deprecated support for it. I’ve made some minor changes that may help those trying to use the bounce email address capability.
I stress the “may” aspect of it because my own testing I have been unable to get it to work. I have not seen anything not working from the changes I’ve made but I have not received any bounce emails either. They simply seem to go in the bit bucket as far as I can tell.
Due to this unreliability I am recommending against using the bounce email address feature and have added a warning on the settings page advising as much which appears when a bounce address is set.
From looking at email headers this morning, I believe they are constructed properly. I have no idea when bounced messages are actually routed versus discarded and different email servers seem to do it differently.
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.
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 morning I posted beta-1 of Email Users v4.7.3. This build addresses an out of memory error during plugin activation which was recently reported on the WordPress Support Forum. This error would likely only happen on sites which very large numbers of users, 1500 or more, and is very dependent on the amount of memory the server has access to.
This morning I uploaded beta-1 of Google Forms v0.77. This release would only be of interest to users who are using the deprecated gform shortcode and ware worried about PHP warnings in the log file (see this post on the WordPress Support Forum).
The warnings were a result of the plugin looking for meta data which is stored with the Custom Post Type (recommended) usage of Google Forms. The fix skips the check when using the gform shortcode thus eliminating the PHP warnings in the log file.
Unless there is a significant bug reported I will likely release this update fairly quickly as I view the changes made as very low risk.
This evening I posted beta-1 of Google Forms v0.75. This beta release contains a new option to turn off the HTML filter which has been part of Google Forms since the very early iterations of the plugin. In the early days of the Google Forms plugin, the HTML Google generated was full of unnecessary stuff and as a result, it tended to mess up the rendering of the form within WordPress. Over the years Google has iterated on forms a number of times and the HTML is much cleaner and includes new attributes for things like accessibility.
Based on a user request to support the accessibility attributes I decided to offer an option to turn off filtering completely. The disable HTML filtering option is located on the Advanced Tab of the plugin settings.