Email Users v4.6.0 released

This morning I released version 4.6.0 of Email Users.  This release addresses the problems with addresses appearing in the CC header instead of the BCC header which cropped up in v4.5.4 and v4.5.5.  This version has gone through quite a bit of testing to ensure the problem with addresses was fixed.  In addition to this critical fix, there are also a couple of minor new features now available.  If you were running Email Users v4.6.0-beta-4, this version is nearly identical.  The version is different and the default string for the new footer was trimmed eliminating the version number.

  • Significantly improved debug functionality to chase down mail header issues.
  • Check added to determine if wp_mail() has been overloaded by a theme or plugin.
  • Rewrite of mailusers_send_mail() fucntion to construct headers as arrays instead of as a single string. The string would sometimes not break correctly and recognize the Bcc: field.
  • Implemented new email footer option.
  • Cleaned up presentation of Options page.
  • Implemented new omit display names option.
  • Updated language translation files.

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

Email Users v4.6.0-beta-3 now available

If you’ve been following the Email Users Support Forum, you are aware that for the past couple of days I have been chasing a bug which affects some users and places all of their intended recipient email addresses in the CC header instead of the BCC header.

This has been a challenging bug to find as it doesn’t happen on any of the systems I have access to.  Fortunately I had a few users affected by this problem willing to help me and I appreciate their assistance.  I am not sure how I would resolved this problem without their assistance.  Again, thanks.

So what was the problem?  The WordPress wp_mail() API allows you to pass extra header information as part of the mail content.  Email Users makes use of this by constructing a BCC header which contains all of the email addresses for the intended recipients.  The wp_mail() function supports headers as a single string or an array of headers, each header as an array element.

Up until this evening Email Users had constructed all email headers as a string.  With a large number of email addresses this string could end up being very long.  However, I don’t believe the length of the string had anything to do with the problem.

When wp_mail() receives headers as a string, it tries to intelligently decompose them.  In some cases it appears that the string wasn’t splitting correctly which means the BCC field wasn’t ever seen.  The “Bcc:” text became part of an email address which was subsequently discarded because it resulted in a bad address.

Email Users v4.6.0 has a rewrite of the mailusers_send_mail() function plus some new debug functionality which helps resolve these sorts of issues.  Additionally, the new debug is under user control so can be turned on and off as needed.

Email Users Beta (5015 downloads )

EU_SS_29

For testing this new version, I recommend turning Debug on until you’re comfortable with the the structure of the email addresses.

Questions or comments -don’t hesitate to ask.

Email Users v4.5.3-beta-4 now available

This morning I pushed out beta-4 for Email Users v.4.5.3.  This latest update addresses the duplicate header information discovered by Andy Fragen.  I had already fixed the problem with the TO header Andy noted but was unaware of the duplicate MIME-Version header.  It turns out, there was also a duplicate X-Mailer header as well.

By default wp_mail() sits on top of PHPMailer.  WordPress does not check for either the MIME-Version header nor the X-Mailer header.  Unless specifically set, PHPMailer will add its default values for these two headers which is what was happening.  It appears that some systems are sensitive to duplicate headers and reject the messages and others do not.  This definitely explains why it is difficult to reproduce reports that come in of users not receiving email.

Because wp_mail() is pluggable, other mail implementations may be expecting these headers to continue to exist.  What I have done is added two new options to add the headers as Email Users has been doing all along.  By default these two options are off because PHPMailer duplicates them and I expect most people use the default WordPress implementation.

EU_SS_23

I also improved the information panel I added recently to report the existance of any filters which may interact with Email Users.  For the most part these filters don’t do any harm however they can change override the FROM information in the email or the format which may be unexpected. The new information in the panel is nothing more than a note that something else may be affecting your email outside of Email Users (e.g. why is my From name different than what I set?).

EU_SS_22

Please report any issues with this latest beta update.

Email Users Beta (5015 downloads )

Email Users v4.5.3-beta-1 now available

I’ve been looking at a problem reported on the WordPress Support Forum.  While I can’t replicate the problem, I have found some things in the code which constructs the email headers which needed some attention.

This beta build has refactored the construction of the email headers as well as a couple recently requested minor enhancements (%POST_CONTENT% keyword, CC Sender).

Email Users Beta (5015 downloads )

Email-Users v4.5.0-beta-1 now available

I’ve been working on Email-Users this week and have added quite a bit of functionality.  Before I release it I’d like to get a few people put an early version through its paces so if you have a chance to test it out, please do so.

This new version has a number of new features:

  • All postboxes on the admin screens now have their own CSS ID and Class so they can be styled or easily hidden.
  • Email-Users now support integration with two User “Group” plugins:  User Groups and User Access Manager.  When you set up groups in either of these plugins you will be able to select them as recipients from the Group Email and Post/Page Notification pages.
  • Selection of Custom Filters as Group Recipients is no longer a separate action – it, along wit the Group support noted above, are all presented in the same target recipient selection list.  This allows the Custom Filters to work on Post/Page Notifications as well.
  • A new action has been introduced:  mailusers_update_custom_meta_filters  This action will allow for updating meta filters dynamically just prior to their use.  This is the best way to create complex meta filters or integrate other plugins.  There is a good example in the plugin README file.
  • Chinese language support has been contributed.
  • Integration panel added to the Plugin Settings Page.
  • Updated language support files which incorporate 20+ new strings.

A few other things were cleaned up while I was tinkering with the code as well.

Email Users Beta (5015 downloads )

I have also updated the sample plugin file I use to test Custom Meta Filters.  It has the full example of the “Public Works” example.

Email Users Custom List (5588 downloads )

WordPress Google Form v0.54-beta-7 now available

I have just posted what I hope is the final beta release of WordPress Google Form v0.54.  This latest beta release fixes a couple of minor issues, notably the lack of stickiness on the Form Submission Log setting and adds one new feature.  You can now define a CAPTCHA message to appear below the CAPTCHA input box.  These two screen shots show the information on the Plugin Settings page and the result when the form is rendered.  The message is placed in a DIV which has the class “wpgform-captcha-description” so it can be styled as needed.

Google Forms Beta (7986 downloads )

GForm_SS_56

GForm_SS_57

WordPress Google Form v0.54-beta-3 now available

A quick bump to beta-3 for WordPress Google Form v0.54 to fix a problem which resulted in a PHP error message due to missing post meta data for field validation.  Forgot to account for the situation where a form hasn’t defined any fields to validate!

Google Forms Beta (7986 downloads )

WordPress Google Form v0.54-beta-1 available

The first beta release of WordPress Google Form v0.54 is now available for download. This beta release introduces a pretty significant enhancement – Advanced Validation for any field on a Google Form. This is an “advanced” feature as it requires the user to dig into the form in order to gather the necessary information for the validation to work correctly.

There are a few things which I know aren’t working (e.g. Range Checks) which I will look into.  I would really appreciate some feedback on this new functionality.

Google Forms Beta (7986 downloads )

Advanced Validation with WordPress Google Form

One of the most common requests I receive is the desire to validate fields on a Google Form. Google provides some basic validation (required or not) but there really isn’t a way to ensure that if you request an email address that the user actually provides a valid one. Similarly, there is a need for URLs, numbers, and other specific fields.

I’ve been using the jQuery Validate plugin (which looks to have a new  home) for a while now to validate required fields and in some cases, email addresses, and most recently, CAPTCHA support.

A number of people have asked me about extending the validation to include any field.  I have been reluctant to do this for several reasons:

  1. The jQuery Validate plugin needs to know which fields (by name or id) it is going to validate.  There isn’t an easy way to pull these out of the Google Form HTML.  It could be done on a single page form but because Google supports multi-page forms, they only way to find the information we need is to visit every page of the form.  This isn’t easy to do programatically.
  2. The rules needed to be written in jQuery syntax.  While the syntax isn’t difficult, if I allow entry of Javascript the potential for syntax errors (which would break the plugin) is very high.

For these reasons I’ve kept this on the back burner for a while.  However, a couple recent requests got me thinking about it again and it would be useful for a project I am doing for my daughter’s soccer team.  So I decided to dig into it.

I don’t think it is possible to make it completely foolproof however I did want to make it as simple as possible.  I decided to add a new Meta Box to the Custom Post Type editing screen which “helps” the user define new rules.

The key to making rules which accomplish something is getting the name attribute for the form entry element that needs to be validated.  There really isn’t a good way to do this other than to look at the HTML source.  I like FireBug with Firefox but both Chrome and IE have the ability to easily inspect an element.

GForm_SS_48Now that I know my input element’s name (entry.409811816) I can set up my new rule.

If you have been using WordPress Google Form the first thing  you’ll notice is the Form Editing screen has changed quite a bit.  The form was getting very long and cluttered so I have moved some of the lesser used options to a new Meta Box on the right hand side leaving just the critical or frequently used options on the primary Meta Box.

There is a new Meta Box just for Validation.  This Meta Box lets you add a series of fields where you can enter the name, the type of check to perform, and if needed, a check value.

GForm_SS_49Once the validation fields are set up, you can see the effect as you fill out a form.

GForm_SS_50 GForm_SS_51I am going to clean up a few things and make a beta release available for people to test with.  I think this functionality is pretty cool and it was a bit of a challenge to (a) get it working and (b) find what I think is a viable usage model.  As always, feedback is welcome.