Google Forms v0.75-beta-1 available

This evening I posted beta-1 of Google Forms v0.75.  This beta release contains a new option to turn off the HTML filter which has been part of Google Forms since the very early iterations of the plugin.  In the early days of the Google Forms plugin, the HTML Google generated was full of unnecessary stuff and as a result, it tended to mess up the rendering of the form within WordPress.  Over the years Google has iterated on forms a number of times and the HTML is much cleaner and includes new attributes for things like accessibility.

Based on a user request to support the accessibility attributes I decided to offer an option to turn off filtering completely.  The disable HTML filtering option is located on the Advanced Tab of the plugin settings.

GForm_SS_73

Google Forms Beta (500 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 (243 downloads)

 

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

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.

wp-SwimTeam v1.40 released

I have finally released v1.40 of wp-SwimTeam.  Thanks to everyone who helped test the new features and flush out any bugs.  This release has a slew of new features and functionality.

  • This update requires phpHtmlLib v2.6.7 or later!
  • Fixed initializion bug when Adding Events to an Event Group. Events were by default not being assigned to the correct group.
  • Fixed pagination bug when managing large number of events. When paging through events the GUI would get confused.
  • Fixed Event Group bug which was propagating the wrong event group to subsequent actions.
  • Added support for Mixed Gender and Combined age groups.
  • Added support for Mixed Gender and Combined Events.
  • Added support for exporting mixed gender event entries in SD3 and HY3 formats.
  • Added support for mixed gender events when importing events.
  • Fixed bug resulting in database error when generating RE1 roster.
  • Re-implemented Roster Export functionality – multiple formats can now be exported. The export can also be limited one gender.
  • Added support for age groups where min age and max age are identical.
  • Added smart processing of 0 as min or max age in HYV event imports, mapping 0 to minimum or maximum age setting as appropriate.
  • Fixed bug in USS Number generation.
  • Fixed bug in HY3 entries generation where E1 record did not contain gender.
  • Fixed reported entry count when exporting SDIF, count was off by 2x.
  • Fixed bug exporting roster by single gender which resulted in no swimmers.
  • Fixed bug which prevented proper HY3 meet entry generation for Opt-In swim meets.

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

wp-SwimTeam v1.40-beta-8 available

This morning I released beta-8 of wp-SwimTeam v1.40.  This beta release addresses a couple problems.

  1. I have fix the problem when exporting the roster by a single gender in Hy-tek format results in an empty roster.
  2. I have fixed the problem where the entry count is off by 2x when export meeting entries in SD3 format as compared to HY3 format.

There was some other minor debug code cleaned up nothing visible on the Dashboard.

wp-SwimTeam Beta (353 downloads)

wp-SwimTeam v1.40-beta-7 available

This morning I released beta-7 of wp-SwimTeam v1.40.  This beta release addresses the problem where exported Hy-tek entries won’t load into Meet Manager.  The problem was the E1 records didn’t have the gender specified in columns 14-15.  I believe this problem was introduced when I implemented mixed gender events earlier this year.

wp-SwimTeam Beta (353 downloads)