WordPress Google Form v0.59-beta-1 available

I have posted WordPress Google Form v0.59-beta-1 in response to a request to have the ability to preset form values by passing a parameter as part of the WordPress URL.   This is an interesting request so I did some work on it this morning and it turned out it wasn’t to difficult to implement.

Much like custom field validation and presets, this new functionality builds upon the name of the field that you want to preset.  Google has a way to preset values, the field name is passed as a parameter with a value.  This new functionality does much the same but pulls it back to WordPress for processing.

Using my Validation Demo form as an example, here are two URLs:

  1. Standard URL
  2. Standard URL with preset values

As you can see, the second URL will have the first two fields prefilled with the values which were part of the URL.  The following was appended to the URL.  The specific parameter names (e.g. entry.1666054688) had to discovered by examining the source Google Form.

?entry.1666054688=joe@example.com&entry.327623672=www.yahoo.com

GForm_SS_63

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

This morning I released beta-3 of WordPress Google Form v0.58.  This update addresses one problem, properly handling newline characters in TEXTAREA entry boxes.  This issue was reported on the WordPress Support Forum.

If there are no more reported issues, I will likely release v0.58 in the next day or so.

Google Forms Beta (776 downloads)

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 (678 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.

Debugging the Email Users CC issue

For the past few days I have been chasing a reported issue where Email Users is putting recipient addresses into the CC header instead of the BCC header.  This has been a challenge to chase down.  To assist in this I have add a bunch of  new debug and checking to Email Users.

Email  Users will now check and report if wp_mail() has been overloaded by a plugin or theme.  Since wp_mail() is a pluggable function, this is the one area which is really out of the control of Email Users.  Simply knowing if wp_mail() has been overloaded is very helpful.

Additionally, I have finally found a way to initiate a complete email which is aborted just prior to the email actually being sent.  The content of several internal structures is displayed on the Dashboard so the email headers can easily be examined.

This build is in DEBUG mode which means it will never actually send an email unless wp_mail() has been overloaded in which case all bets are off.  Please visit the Settings page first to determine if wp_mail() has been overloaded.  If it has, do not send any email but let me know which plugin or theme has overloaded wp_mail().

Email Users Beta (678 downloads)

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 (678 downloads)

Email Users v4.5.3-beta-3 now available

This afternoon I posted the third beta release of Email Users v4.5.3.  There is a pretty significant change in this build so I may bump to v4.6 when I release it.

Yesterday I posted an article about an odd Email Users problem I was looking at.  This build fixes (correctly) the problem encountered by that user by properly using get_users() instead of a complex SQL query to retrieve the information used to construct the User Settings page.

In addition to being properly constructed, the User Settings page has a number of fixes including proper sorting and the addition of Search (which I could never get working using the old query).

I’ve also addressed a couple of other very minor requests that came up recently in the WordPress Support Forum.

Email Users Beta (678 downloads)

A Really Odd Email Users Problem

I was recently contacted about an Email Users issue on a site that is using bbPress and S2Member.  The person had come to the conclusion that there was some sort of conflict between the three plugins which resulted in the Email Users -> Users Settings screen being empty and asked me to look into it.

EU_SS_20

Clearly something is amiss as in order to access the WordPress Dashboard you need to login and in order to login, there needs to be at least one user!  This isn’t the sort of situation I can easily replicate.  Fortunately the person with this problem provided me access to their server so we could do some debugging.

The functionality in Email Users is based on the WP_List_Table class and an example plugin which you can find in the WordPress Plugin Repository.  When I first implemented it I was retrieving the list of users with a call to get_users() however I never got the sorting working correctly.  After playing around with it for a while, I gave up and wrote my own query.  The query I wrote yielded the results and sorting I wanted so I didn’t think much about it.  Until today.

This the query that WordPress generates and sends to MySQL:


SELECT ID, display_name, user_email, user_login, m1.meta_value first_name, m2.meta_value last_name, m3.meta_value massemail, m4.meta_value notifications
FROM wp_users u
LEFT JOIN wp_usermeta m1 ON (m1.user_id = u.ID AND m1.meta_key = 'first_name')
LEFT JOIN wp_usermeta m2 ON (m2.user_id = u.ID AND m2.meta_key = 'last_name')
LEFT JOIN wp_usermeta m3 ON (m3.user_id = u.ID AND m3.meta_key = 'email_users_accept_mass_emails')
LEFT JOIN wp_usermeta m4 ON (m4.user_id = u.ID AND m4.meta_key = 'email_users_accept_notifications')
ORDER BY last_name ASC LIMIT 0,100

What this query does is select all of the WordPress User Ids, first names, and last names, which have the proper Email Users user meta keys. The data is returned and stored in a format which can be rendered in the List Table.

Because the table was empty, I wanted to see what the results of the query were as that would tell me where the issue might be.  Because I had access to the MySQL database via phpMyAdmin, I was able to run the query directly against MySQL.  When I did so, this is what I found:

EU_SS_21

This certainly was unexpected but it explained why the List Table was empty.  I have never run into this sort of problem, in fact, I had never heard of either the SQL_MAX_JOIN_SIZE or the SQL_BIG_SELECTS MySQL system variables.

I was able to alter SQL_BIG_SELECTS using the following SQL:


SET SQL_BIG_SELECTS=1

When I did this and re-ran the query, phpMyAdmin returned the results I would have expected to see.  This was good news – it appears this users problem is due to a MySQL setting.  The bad news is sometimes it is hard to change these settings and it isn’t something I thought I could add to the query itself.

As a test, I modified the source for one of Email Users files so it was calling the original method I had coded  based on get_users() to see if it would work and it did.  This is very good news as I suspect fixing the sorting issue (or living with it) will be easier than changing the MySQL system variable settings.

My next step is to see if I can fix the sorting problem and roll out an update.

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 (678 downloads)

Google Forms v0.58-beta-1 available

This afternoon I posted a beta release of v0.58 to address a problem reported in the WordPress Support Forum.  The problem arises when the answer for a checkbox or radio button contains the apostrophe character.  This releases fixes the problem but needs testing.  I did some testing using the form which was having UTF-8 issues and all seems ok.

Google Forms Beta (776 downloads)

Email-Users 4.5.2 released

This morning (updated) afternoon I released a minor update, v4.5.2 (updated) v4.5.3, of Email-Users.  This update adds new information on the Dashboard to help the WordPress Admin ensure that the number of users they expect to receive email is correct.

There is a new Dashboard Widget and an updated Settings Page which note how many users will receive each type of email.  If no users will receive notifications or mass emails, a warning message will be displayed at the top of the Settings Page.