Google Forms v0.70-beta-1 available

This weekend I spent some time looking at adding support for regular expressions as part of the Google Forms validation functionality.  This seemed like a reasonable and useful request.  I was surprised to find that the jQuery Validation plugin doesn’t offer regular expressions as a standard check  however, I found a fairly simple solution on Stack Exchange.

It took me a little while to get it working as Saturday morning I went down a wrong path initially following another post I had found.  When I first read the post I linked to above, I convinced myself that I didn’t want to use the AddMethod solution.  I am not sure why, I guess it was because I haven’t been into the code in a while so I was trying to avoid it.  It turns out it is definitely the right answer and fairly easy to implement.

The beta build also contains a Serbo Croation translation provided by Borisa Djuraskovic
of www.webhostinghub.com.

To see the new functionality in action, check out my Validation Demo Form where the last entry field must begin with a capital letter.  The regular expression “[A-Z]” is used to match a capital letter when setting up the validation.

GForm_SS_72

Google Forms Beta (450 downloads)

Google Forms v0.65 finally released

This morning I released v0.65 of Google Forms, a long overdue update.  I have been sitting on this release for a while because of one outstanding issue I was aware of which I simply haven’t had time to chase down.  The ability to email the end user upon form submission broke at some point, I am not exactly sure when but it has been reported a few times recently.  It turns out, it only worked if email to the admin was also enabled.

Here are the highlights from the Change Log:

  • Implemented “save_post” for custom post type eliminating general purpose “save_post” (only option prior to WordPress 3.7) action which could potentially, if not handled correctly by another plugin, corrupt post data.
  • Formally deprecated the gform shortcode by updating README file.
  • Added flush of rewrite rules upon plugin activation and deactivation.
  • Implemented protocol relative URLs for loading jQuery script from Microsoft CDN to avoid mixed-content warnings when serving over https.
  • Fixed layout of CAPTCHA options on settings page.
  • Fixed bug with preset values as part of the URL which contain spaces.
  • Fixed bug sending End User email upon form submission.
  • Refactored construction of email headers based on experience with Email Users plugin.

You can find the update in the WordPress plugin repository or on your WordPress 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 (450 downloads)

Chasing Checkbox Support

For the past couple of days I have continued to look at the problem I wrote about with Google Forms and Checkboxes with PHP 5.4 and PHP 5.5.  It turns out, that it really isn’t PHP version related, at least I don’t think so.  It is WordPress related as near as I can tell.

As I’ve written before, I love VMware Workstation as it allows you to create virtual machines for very specific purposes, use them as long as needed, then put them away until needed again.

I created an Unbuntu VM to play with Ruby on Rails a couple months ago so I decided to check what version of PHP it had running.  Lo and behold, it had PHP 5.5.x running so it was a good platform to further test potential solutions for my checkbox problem.  My Windows environment is running PHP 5.3.3 and is still running WordPress 3.6.1 (don’t ask why but it proved to be very useful that it was).

I quickly set up WordPress 3.8 on Ubuntu and sure enough, submitting the form failed.  The exact same plugin code on my Windows VM submitted correctly.  I continued to dig through my code and eventually into WordPress itself trying to see what was different.

I eventually started looking at the source to wp_remote_post() and decided to identify which transport was being used.  On Windows WordPress was using cURL but on Ubuntu it was using Streams.  Ah-ha.  Since the WordPress HTTP API abstracts the details of the transports away from the application, it shouldn’t matter but it seems to.  I continued digging.

Using an advanced feature of WordPress Google Form to control transports, I disabled the cURL transport on the Windows machine and much to my surprise, the form still submitted correctly.  Now this is odd.  So I then installed cURL on Ubuntu and the form submitted correctly.  The good news is there at least appears to be a solution although I’d prefer to not have cURL be a requirement.

Now what was different?  I started looking into WordPress’ class-http.php file (which defines the WP_Http class) and noticed that the file on Windows was very different than the file on Ubuntu.  Looks like something changed between 3.6.1 and 3.8.1.

I decided to download the 3.6.1 and 3.7.1 releases from the WordPress archive and do some tests on Ubuntu where it is trivial to switch between WordPress releases.

To add a little more information, I did some testing with older versions of WordPress in combination with the http_api_transports to force a specific transport (‘streams’, ‘fsockopen’, and ‘curl’).  I found the following results:

WordPress 3.6.1 WordPress 3.7.1 WordPress 3.8.1
cURL Success Success Success
fsockopen Success Fail Fail
streams Success Fail Fail

Something clearly changed with the streams and fsockopen transports between 3.6.1 and 3.7.1.  A diff of the class-http.php file shows the change was substantial as the files are significantly different.

At this point I have concluded that my plugin will only work with sites where cURL is available.  I will probably release a version which displays a warning on the Dashboard if cURL is not available and that usage of the plugin is not recommended.

Poor Response Time

I’ve been out of pocket for the past few weeks, for anyone who has submitted a bug or help request, I apologize.  I am back in North Carolina and have some time to address some of the questions and help requests which have queued up since before Christmas.  I have answered a few Email Users and WordPress Google Form questions in the WordPress Support Forum but if you haven’t heard back from me, don’t hesitate to ping me again.

WordPress Google Form v0.63-beta-2

What? Another beta release? Yes. A few weeks ago I had a report from a user who ran into a problem with WordPress Google Form running under PHP 5.4.4-14+deb7u2. None of the values in the form were being submitted to the target spreadsheet. The user was able to resolve the problem by changing how I was calling wp_remote_post() and sent me a DIFF file.

Unfortunately I had already started working on the changes I made to support multiple form instances (v0.61, v0.62) and the diff file couldn’t be applied to my source tree. I then forgot about it in my effort to get v0.61 out which had a number of other fixes in it that were affecting quite a few people.

Over the weekend I received a couple more help requests from people who had forms submitting that didn’t result in any data in the spreadsheet OR if the fields were required, messages indicating they had unanswered questions.

In looking at one of these sites in detail, everything looked correct on the WordPress side.  This site has the Suhosin security module installed.  I’ve run into Suhosin before but I couldn’t find any comments in my code nor any references to it on my web site.  I am guessing that I was never able to fix the problem when I ran into it previously.  In reading about Suhosin again, I recalled the patch which was sent to me a couple weeks ago.

My suspicion is that the way I was constructing the arguments to wp_remote_post() isn’t palatable to some versions of PHP.  I decided to implement the changes that the patch had incorporated and see if it would address the problem.  The change involves constructing the body argument as an array instead of a long URL formatted string.  This is the right way to do it and it makes the code a little cleaner when needing to look at the parameters passed to wp_remote_post().

I was able to incorporate the patch by manually finding the corresponding source code lines in my current version and accounting for the changes I have made in the past month and get a beta release together fairly quickly.  This fix allows the test form on the sites (one running PHP 5.4.6, one running PHP 5.3.10-1ubuntu3.8 with Suhosin-Patch).

If you want to try out this latest version, I would appreciate any feedback.

Google Forms Beta (450 downloads)

Where did all of this wp-SwimTeam stuff come from?

You may have noticed an influx of content (posts, pages, etc.) related to wp-SwimTeam and wonder where it came from.  For the past four years I have been developing, enhancing, supporting, etc. a WordPress plugin called wp-SwimTeam.  This plugin can be used to manage the registration, volunteers, participation, and other aspects of running a youth swim team.  Several groups have used it for Masters Swimming as well but it is targeted at youth swim teams.

I first started wp-SwimTeam to support our local neighborhood team when my wife was the swim team chair.  Over the years it grew in features to the point where it was fairly comprehensive.  My children no longer swim and my involvement in swim team has largely ended but I still maintain my plugin because (a) people use it and (b) I still feel it serves a need and it doesn’t take much of my time to continue supporting it.

I have always had a separate web site for wp-SwimTeam but over time that came to make less and less sense. In fact, I had some people contact me on this site and some on the other site so I had questions and solutions on both sites.  I decided that I would migrate everything here So I exported all of the content and then imported it.  There were a few hiccups, mostly around downloads but I think everything else came over ok.

The old URL redirects to the wp-SwimTeam page on  this site.  From time to time you may see updates for wp-SwimTeam or phpHtmlLib in addition to the normal flow of information on Email Users and WordPress Google Form.

wp-SwimTeam v1.4.0-beta-3 available

This morning I resolved my Subversion problems with phpHtmlLib and have posted v1.40 beta 3 of wp-SwimTeam.  This release cleans up the Roster Export functionality which had become cumbersome as more formats were added.  Instead of multiple choices from the dropdown menu, there is a single choice (Export Roster) which brings up a new form which allows the user some control over how much of the roster is exported and in what format(s).

wpst_SS_05

This release is dependent on an update to phpHtmlLib so make sure you update it before loading this beta version.  You must be running phpHtmlLib v2.6.7 or later for this new Export Roster functionality to work correctly.

wp-SwimTeam Beta (339 downloads) Email Users Beta (224 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.

Google Updates Forms Again

Sometime in the past few days (as near as I can tell) Google has updated Forms again.  This most recent update adds the H5F Javascript library to do required field checking.  This functionality is similar to the jQuery Validation plugin solution I included in WordPress Google Form a number of months ago.

This new validation functionality doesn’t appear in all forms, just those created after a certain date.  Existing forms do not appear to have this new functionality embedded in it.

So how do I know if I have the new functionality?  The most obvious sign is the appearance of the text “This is a required question” underneath the form element.

GForm_SS_58

 

It is fairly easy to make these messages go away since they are redundant with the plugin functionality.

You can add the following to your Custom CSS (form specific or global):

div.required-message {
    display: none;
}

This will hide the messages and the form reverts to looking as it did prior to Google’s latest change.

GForm_SS_59

I will likely include this CSS as part of the default CSS in the next update but I need to do a little more testing first.