Where did Email Users go?

A week ago (July 19th) I was contacted by WordPress regarding a potential security flaw in Email Users. Email Users was “closed” (which is why it doesn’t show up at WordPress.org) until the security flaw was addressed and a new version of the plugin was tagged and release.

Due to some work issues, I did not have a chance to work on the plugin until this past weekend.  I have resolved the security concerns, committed all of the changes, and tagged a new release.  On July 26th (Sunday) I notified WordPress.org that everything (I know of) has been addressed.  At this point, I am waiting for the plugin to be opened again or notified that I’ve missed something.

I’ve uploaded v4.84. to my web site in the event anyone wants to download the update before WordPress.org makes it live again.

Email Users (2741 downloads )

Google Forms v0.73-beta-3 available

This morning I released beta-3 of Google Forms v0.73. This beta build addresses a request recently posted on the WordPress Support Forum to allow the notification email to be sent to multiple email addresses.

This request has been implemented – multiple notification email addresses may be entered, they should be separated by a semicolon character (;).

Unless there is a an issue reported in the next day or so, I plan to release v0.73 shortly.

Google Forms Beta (35878 downloads )

Email Users v4.6.10-beta-4 available

This morning I released beta-2 and very quickly afterward, because I found a bugs, beta-3, then beta-4 of Email Users v4.6.10.  This beta-4 build addresses a couple enhancements that were recently raised in the Support Forum.

  1. Templates – while not exactly templates per se, the Post/Page notification email will now allow the user to change the email subject and body content.  It will still be initially populated based on the default template.
  2. Hooks – there are now two hooks which other plugins and themes can use to modify the behavior of wp_mail().  The two hooks are mailusers_before_wp_mail and mailusers_after_wp_mail.  The primary use for this is to account for other plugins which modify the sender address.

Additionally, the Notification email process now has a preview of what the email will look like based on the current settings.  The preview will not reflect any changes made to the subject or email content until it is submitted.

EU_SS_36

Email Users Beta (27550 downloads )

 

Google Forms v0.66 available

This evening I released v0.66 of Google Forms.  This version fixes two major issues:

  1. The conflict with WordPress SEO has been resolved.  The implemented solution will likely be replaced with something which runs less frequently.  However, the solution implemented in v0.66 should make sites running both Google Forms and WordPress SEO a little happier.
  2. Due to a bug, all form submissions have been logged regardless of the plugin setting.

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

Google Forms v0.64-beta-3 available

This evening I uploaded v0.64-beta-3 of Google Forms.  This version adds a check for the WordPress HTTP API cURL transport and issue a notification if it isn’t present.

There was a substantial change to the WordPress HTTP API between 3.6.1 and 3.7.  I don’t know the full details of the change but what I found in pretty extensive testing is the streams and fsockopen transports work in 3.6.1 with the Google Forms plugin but from 3.7 and later, they do not.

However, the cURL transport does work and as long as it is available, the plugin will work as it always has.  The problem is I cannot find any way to work with sites that don’t have the cURL transport available so I have added this check and issue a notice when it isn’t present.

GForm_SS_70

 

Please download and test out this beta version and report any issues found.

Google Forms Beta (35878 downloads )

Chasing down Email-Users out of memory issues

For the past couple of days I have been looking at two sites which were experiencing an issue with Email Users where any of the pages on the Dashboard which presents a list of recipients was incomplete.  Looking closer at the pages, PHP was crashing which resulted in an incomplete page.  One of the sites had another clue, it reported a request for memory which could not be granted.

Both users provided me access where I could upload a debug version of Email-Users.  While not an ideal debug environment, I am grateful for the trust and access both users provided as I would have not been able to chase this bug down in my own development environment.

I was able to narrow the problem down to a call to get_users() which is a standard WordPress API function.  Because Email Users has been around a while, it still contains some code which was necessary in older versions of WordPress and the arguments passed to get_users() included the ‘all_with_meta’ parameter which was the only way to retrieve the first and last name of a user prior to the magic methods which were introduced for get_users() in WordPress 3.x.  The magic methods remove the need for the ‘all_with_meta’ parameter however the plugin was never updated because it wasn’t broken.

In the process of chasing down this memory problem I added some code to partition the get_users() query into blocks of 500 users and I could watch the memory usage increase with each query.  This would continue until memory was exhausted at which time PHP would terminate ungracefully and the partial page would be rendered.

An email to the wp-hackers mailing list helped me understand how much data was being cached by calling get_users() with the ‘all_with_meta’ parameter and I realized I needed to find a different solution as what I was doing wouldn’t scale.

I had encountered the get_users() magic methods previously and I realized that I no longer needed to call get_users() with the ‘all_with_meta’ parameter so I removed it and did some testing and sure enough, I was able to successfully run on both sites without any issues.  Memory usage on the site with 13K users topped out at 47M, well under the 256M maximum defined by WordPress.

In the current beta version (4.6.3-beta-8) there is still some debug code in place to monitor memory usage.  If you look at the page source you will find something like this:

<pre id="line1"><!-- email-users.php::1091  Query #1  Memory Usage:  34.5M -->
<!-- email-users.php::1091  Query #2  Memory Usage:  34.75M -->
<!-- email-users.php::1091  Query #3  Memory Usage:  35.25M -->
<!-- email-users.php::1091  Query #4  Memory Usage:  35.75M -->
<!-- email-users.php::1091  Query #5  Memory Usage:  36.5M -->
<!-- email-users.php::1091  Query #6  Memory Usage:  37M -->
<!-- email-users.php::1091  Query #7  Memory Usage:  37.5M -->
<!-- email-users.php::1091  Query #8  Memory Usage:  37.75M -->
<!-- email-users.php::1091  Query #9  Memory Usage:  38.5M -->
<!-- email-users.php::1091  Query #10  Memory Usage:  39M -->
<!-- email-users.php::1091  Query #11  Memory Usage:  39.5M -->
<!-- email-users.php::1091  Query #12  Memory Usage:  40M -->
<!-- email-users.php::1091  Query #13  Memory Usage:  40.25M -->
<!-- email-users.php::1091  Query #14  Memory Usage:  40.75M -->
<!-- email-users.php::1091  Query #15  Memory Usage:  41.25M -->
<!-- email-users.php::1091  Query #16  Memory Usage:  41.5M -->
<!-- email-users.php::1091  Query #17  Memory Usage:  42.5M -->
<!-- email-users.php::1091  Query #18  Memory Usage:  43M -->
<!-- email-users.php::1091  Query #19  Memory Usage:  43.5M -->
<!-- email-users.php::1091  Query #20  Memory Usage:  44M -->
<!-- email-users.php::1091  Query #21  Memory Usage:  44.25M -->
<!-- email-users.php::1091  Query #22  Memory Usage:  44.75M -->
<!-- email-users.php::1091  Query #23  Memory Usage:  45.25M -->
<!-- email-users.php::1091  Query #24  Memory Usage:  45.75M -->
<!-- email-users.php::1091  Query #25  Memory Usage:  46M -->
<!-- email-users.php::1091  Query #26  Memory Usage:  46.5M -->
<!-- email-users.php::1091  Query #27  Memory Usage:  47M --></pre>

I need to do some additional testing but based on these two sites now working, I am bullish on this solution to this unusual problem.

WordPress Google Form v0.61-beta-4 now available

I have just uploaded beta-4 of WordPress Google Form v0.61. This build corrects a couple more jQuery issues when using multiple instances of a form on the same page. In order to use multiple instances of the same form on a single page, you must use the uid parameter with the wpgform shortcode. Usage of this new parameter is outlined in the v0.61-beta-1 announcement.

The uid parameter is not supported in the deprecated gform shortcode.

Please download and test this beta release, all feedback is much appreciated.

Google Forms Beta (35878 downloads )

WordPress Google Form v0.61-beta-2 available

The second beta build of WordPress Google Form v0.61 is now available.  This beta build addresses some jQuery syntax errors introduced in the process of supporting multiple form instances.  It also addresses a bug where the CAPTCHA would not be output as part of the form under certain circumstances.

Please download and test this new build if you have time and report anything which isn’t working.

Google Forms Beta (35878 downloads )

wpGForm Unintended Functionality

For the past couple days I have been helping a user who was running into some problems with WordPress Google Form.  There are two threads on the WordPress Support Forum (here and here) where we went back and forth with me trying to understand his problem.  Eventually we moved to email so he could send me some screen shots as he wasn’t working on a live site.

As you can see from the support threads, I was rather confused as to what the user was trying to do.  It turns out, this user was using WordPress Google Form to display a Google Spreadsheet as opposed to a Google Form.  Once I understood what the user was doing the questions made a whole lot more sense.

The part which still didn’t make sense was why he was using WordPress Google Form to display the spreadsheet instead of a plugin dedicated for the task (e.g. Inline Google Spreadsheet Viewer).  I had never tried using my plugin to view a spreadsheet as it was never designed for that purpose.

As it turns out, for the most part it works.  If you publish a spreadsheet and use the URL when defining a Google Form, you will end up with something which looks like this:

GForm_SS_65

Surprisingly, it doesn’t look all that bad.  With a little bit of Custom CSS, it could actually look pretty good.  Here is some form specific Custom CSS I added to the form definition:

td.hd {
 display: none;
}
tr.rShim td {
 width: auto !important;
}
div div span.powered {
 display: none;
}
div.listview {
 display: none;
}

The result now looks pretty good.

GForm_SS_66

The header rows and and the table content are actually output by Google in separate tables.  It would be nice if they were in a single table – I am not sure of the logic behind having them as separate tables but that is what Google generates.

I am adding some new functionality to support this unusual usage of the plugin.  Because the Google “Powered By” block contains a link to the original spreadsheet, which often times is a undesirable, if the Legal option is turned off for the defined form, the “Powered By” block will be removed with jQuery.

I am also going to add some basic CSS (like above) to the default CSS to support this as well.  Look for a new beta release shortly.

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