wp-SwimTeam v1.45 released

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.

This update is available via the WordPress Dashboard or from the WordPress Plugin Repository.

Understanding Email Users Options

Periodically I get support questions (on the WordPress Support forum) or comments here on my web site asking why Email Users doesn’t send email to some or all users as the plugin user expects it to.

Sometimes a user is dealing with an odd server restriction (e.g. email limits per hour, too many email addresses in the BCC field and others) but more frequently the target recipients don’t have their Email Users permissions set correctly.  This most frequently happens on a site where Email Users is added to a site that  already has a large set of users.

Email Users employs two options settings at the user level.  No matter what the settings are, any user within WordPress can always sent an email IF they are the only recipient.  This is by design.

The two settings are:

  • Allow Mass Emails:  Mass emails means that the user will accept email (Dashboard > Emails Users > Send to Users or Dasboard > Email Users > Send to Groups) where the resulting recipient list has more than one (1) recipient.  For a user in the WordPress database to receive email this permission must be enabled.
  • Allow Notifications:  Email Users has the ability to generate a notification email from a Post or Page (custom post types as well).  When using post or page notifications, only those users who have Notifications enabled will receive it.

Email Users has a default setting for these values which the WordPress admin can control.  It is on the plugin settings page (Dashboard > Settings > Email Users).

Email-Users-User-Options-1

These settings apply to all new users and when the plugin is activated the first time, are applied to all existing users.  The third option allows users to change their own settings by visiting their profile page.  When this option is enabled and a user visits their profile page, the following options are available for the user to change.

Email-Users-User-Options-2

 

The easiest way for the site administrator to review and change users’ settings, particularly on a site which has a lot of users, is to visit the User Settings Page (Dashboard > Email Users > User Settings).  This page will present all of the users (the number of users per page is set on the plugin settings page – see the image above for User Settings Table Rows) and their current settings.  The ability to perform bulk actions on a group of users is offered on this page.

Email-Users-User-Options-3

 

So if your users aren’t receiving emails, check their settings before heading down the debug path, often the solution is as simply as turning on the Mass Email option for the various users.

Google Forms Date and Time Fields

At some point Google added support for Date and Time fields to Google Forms.  When building the form, the Question Type now includes the “Date” and “Time” options.  These are pretty handy options because requesting dates and times from users is a very typical requirement.

GForm_SS_83Earlier this week a user posted on the WordPress Support Forum asking why their date field didn’t look the same on their web site using the plugin as it did when looking at the form within Google Drive.  The user assumed the plugin was doing something to change the form inputs.

The Google Forms plugin does not add or remove input fields (except the optional CAPTCHA field) – it simply retrieves the HTML from Google, strips of the content which falls outside of the form itself, and renders it within the WordPress context.

So why would the input fields be different when the form is viewed within WordPress versus viewing the Google Drive version of the form?

GForm_SS_85

Google Form in WordPress

GForm_SS_84

Native Google Form viewed in Firefox

Native Google Form viewed in Chrome.

Native Google Form viewed in Chrome.

As seen in the images above, the native Google Form is rendered differently in Google Chrome than it is in Firefox.  Having done some work with jQuery Mobile I know that Chrome recognizes HTML5 input tags where as Firefox does not.  I suspected this was the source of the problem.

I ran a couple of tests playing with cURL commands and different user agent strings and sure enough, Google is returning different HTML for different user agent strings.  I quickly added the user agent string to the parameters I was passing to the HTTP API to retrieve the HTML from Google and sure enough, the form, when viewed in Chrome, now matches what is seen when viewing the native form.

GForm_SS_87

I have committed the change to the plugin to pass the user-agent through the HTTP API.  This change will allow Chrome users to see the forms as intended.

What about other browsers?  Unfortunately the trick Google uses to add the date picker to the forms when viewed in Firefox, IE, or others which don’t recognize HTML5 input, or that Google thinks don’t support HTML5 input, isn’t easily passed through the HTTP API.

For now, I don’t see any simple way to solve this problem.  Over time it should go away as more browsers support HTML5 input types but for now, it is a limitation for non-Chrome users.  I fully expected it to work on the iPhone as the iOS browser is fully HTML5 compliant for input but it too is sent separate select inputs for the various fields.  I am not sure why, but it appears Google is treating their own browser differently than all other browsers.

The user-agent addition will be added to the next version of the plugin which will go out shortly with another validation bug fix.

 

 

Email Users with WP Better Emails

I recently worked with a user who reported Email Users wasn’t working correctly in conjunction with the WP Better Emails plugin.  The user posted a code sample he had used to correct the problem.

Looking at the code sample and his description of what WP Better Emails expected to receive as input, I added a new filter, mailusers_html_wrapper, that when present, would not add the default HTML wrapper around the email content but instead would expect the filter to perform the desired operation.  This new filter was released in the 4.7.2 version of Email Users.  There is an example usage of the new filter in my post announcing Email Users 4.7.2.

Shortly after releasing 4.7.2 I was contacted by the user again letting me know the filter didn’t solve the problem.  Confused, I download WP Better Emails to try and figure out what could possibly be wrong.  It took me the better part of two hours to trace through the WPBE code and figure out what it is doing – it turns out, WPBE wants emails to be “plain text” and not HTML formatted.  This is counter intuitive and had me looking in the wrong place for quite while.  It seems backwards to me but that is how the WPBE plugin works.

So how to make WPBE work with Email Users?  It turns out, it isn’t that hard at all.  There is a WordPress filter, wp_mail_content_type, which influences wp_mail(), the function WordPress uses to send email.

If a wp_mail_content_type filter is defined to force the content type to “text/plain”, Email Users and WPBE will work together correctly.  Below is the filter I defined and tested the interaction of Email Users and WPBE with.  Place this filter in your theme’s functions.php file or somewhere else where it will be loaded.

add_filter( 'wp_mail_content_type', 'mailusers_set_content_type' );
function mailusers_set_content_type( $content_type ) {
return 'text/plain';
}

Google Forms Custom Confirmation

I tend to get a lot of question regarding how to implement a custom confirmation page with the Google Forms plugin.  This morning I wrote up a step by step process which walks through all of the steps I use to define a confirmation page and make the process as smooth as possible for the end user.

Email Users v4.7.3-beta-1 available

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.

Email Users Beta (5000 downloads )

Email Users 4.7.2 released

Late last week there was a request on the WordPress Support Forum to add a filter to allow control over the HTML which wraps email content (post/page notifications or email to users/groups).

email_users_html_wrapper

This seemed like a reasonable request so I decided to look into it.  Adding a filter was fairly easy.  If the mailusers_html_wrapper filter exists, the default, and very basic, HTML wrapper is ignored and the filter is expected to properly construct the necessary HTML to wrap around email content.

This is the result of a email using the example filter now supplied as part of the plugin as viewed on my iPhone.

You can find the update in the WordPress plugin repository or an an update on your Dashboard.


/**
* To customize the look of HTML email or to integrate with other
* plugins which enhance wp_mail() (e.g. WP Better Emails), use this
* hook to wrap the email content with whatever HTML is desired - or
* in some cases, none at all if another plugin will be adding the
* necessary HTML.
*
* This example wraps an "Urgent" message and table around the email
* content so the background can be styled. A table is the best way
* to do this because not all mail clients will recognize styling
* elements such as BODY and DIV like a traditional web page.
*
* Drop this code snippet and modify to suit your needs into your
* theme's functions.php file.
*
* @see https://wordpress.org/plugins/wp-better-emails/
* @see https://litmus.com/blog/background-colors-html-email
*
*/
function mailusers_sample_html_wrapper($subject, $message, $footer)
{
// Wrap the HTML in proper header and body tags
// add some CSS styling to make the email look good.

$mailtext = sprintf('
<html>
<head>
<title>%s</title>
<style>
table { border: 1px solid black; width: 800px; background-color: #c5f6c0; }
td { background-color: #c5f6c0 }
</style>
</head>
<body>
<table class="content">
<tr>
<td class="content">
<div class="content">
<h1>This is an Urgent Message from Email Users!</h1>
%s
</div>
<div class="footer">
%s
</div>
</td>
</tr>
</table>
</body>
</html>', $subject, $message, $footer) ;

return $mailtext ;
}

add_filter('mailusers_html_wrapper', 'mailusers_sample_html_wrapper', 10, 3) ;

Google Forms v0.77-beta-1 available

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.

Google Forms Beta (7975 downloads )

wp-SwimTeam v1.44 released

This morning I released a minor update to wp-SwimTeam.  Unless you are running under WordPress multi-site, you will not see a difference.  Under Multi-Site there was a bug in the database query that pulls the list of users from the WordPress database.  Because not all users stored in the user table should be visible to a particular site, the list of users needs to be filtered and limited to just those who have access to the site.  It was this filter portion of the query which was wrong.

You can find the update on your Dashboard or in the WordPress plugin repository.