Category Archives: Bug

10.25.12
by

WordPress Google Form v0.43 now available

This evening I released v0.43 of my WordPress Google Form plugin.  This update addresses a couple of bugs and fixes a few more issues with the optional CSS prefix.  It also addresses a potentially serious problem when using Debug Mode with PHP version prior to 5.3.

  • Reimplemented shortcode attribute br=’on’ usinq jQuery instead of preg_replace().
  • Reimplemented shortcode attribute legal=’off’ usinq jQuery instead of preg_replace().
  • Fixed DEBUG mode so it will work with PHP 5.2 (which doesn’t support anonymous functions).
  • Fixed CSS prefix bugs which prevented CSS prefix from being applied to all Google CSS classes.
10.19.12
by

WordPress Google Form v0.41-beta available

This afternoon I made a beta version of WordPress Google Form v0.41 available for download from this site. I have not posted this version to the WordPress plugin repository yet as I’d like to get some additional testing done on it before doing so.

There are a could of significant new features and a few bug fixes in this version.

  1. Simple CAPTCHA!  You can now add a  simple math based CAPTCHA to a Google Form to help prevent SPAM form submissions.
  2. Improved support for multiple forms on one page.
  3. The return of jQuery validation for required fields.  This validation is optional but since I used the same jQuery plugin to implement the CAPTCHA solution, I figured I may as well make it available for required field validation again.  It works the same way it did in the initial plugin implementation until is was removed with the support for multi-page forms.
  4. New Debug options on a separate Settings tab.
  5. Several more bug fixes, notably for custom CSS prefixes.

Download the beta release and please let me know if you run into any issues.  You can see an example of the CAPTCHA and new Validation options on my Test Bed Form.

Google Forms Beta (9812 downloads )
10.16.12
by

Two Google Forms on one page?

A user of my WordPress Google Form plugin brought me an interesting problem to look at. He wanted to put two forms on one page. The forms were each placed in a DIV and then visible to the user based on which tab on the page was selected. The presentation isn’t really germane to the problem as under the hood the page had two forms on it.

What does this mean to WordPress Google Form?  Right now it means there is a bug (which I have fixed but not yet released) that results in a Javascript error.  The Javascript which manipulates the check boxes is added once for each form and run once for each form.  As I noted above, I have already fixed this bug and it has been tested on a live site.

However, there are still a couple of other things to sort out when more than one form is present which is why I haven’t released an update yet.  These are the things I am struggling with:

  • If the alert shortcode attribute is used, the alert from the first short code is always displayed.  What is desired is the alert from the submitted form should be displayed.
  • The HTML provided by Google which is used to build the form has a FORM element with an ID of “ss-form”.  This is not an issue when there is only one form on the page BUT is technically invalid HTML when two elements have the same ID.

I am not sure what to do about the second issue.  It wouldn’t be hard to manipulate the HTML so the FORM element ID is unique but I don’t know if it is used on the Google side and it could also result in CSS issues if rules have been defined based on #ss-form.

I am considering adding a new shortcode attribute to override the FORM element ID value.  I think this is the safest way to do it but really know if there are any ramifications on the Google side until I try it.

As for the alert, I think I need to track which form is submitted and detect which alert should allow me to generate the Javascript for the correct alert.  I am less worried about this issue than the FORM element ID issue.

While I am digging around in the code, I am also looking at CAPTCHA solutions.  The lack of CAPTCHA is a bit of a problem with Google Forms and it isn’t a simple problem to solve.  What do you do on multi-page forms?  CAPTCHA on every page?  CAPTCHA only on Submit page?  I think the later but that is a little harder to detect.

08.20.12
by

Email Users v4.3.14 released

This morning I pushed the v4.3.14 update to Email Users to the WordPress plugin repository.  This update adds a new Spanish language translation, updates the French language translation, and fixes a problem where users who have either the capability to send to a single user OR the capability to send to multiple users, but not both, receive a permission denied error when trying to send email.  A number of the permission errors have also been updated so they use the proper WordPress styling.

07.18.12
by

wpGForm and Apache Sercurity

A while back I was contacted by a user who had deployed wpGForm on their site with a problem they wanted my help with.  In looking at it I was absolutely stumped as to why it wasn’t working.  Nothing appeared obvious – when the form was submitted, the form would be displayed again as if for the first time.  In the process of chasing down this problem I’ve added quite a bit of debug code but in the end, I found Firebug’s Net Panel incredibly useful.

In this particular case it was showing me that the form was being posted but a 403 Permission Denied response resulted.  Why?  The exact same URL worked to show the form, why wasn’t it working to process the form?  I ended up separating the rendering and processing part of the plugin thinking this was the problem (like it was on a site a couple of weeks ago) but it didn’t make any difference (although it was the right thing to do).  I was still getting 403 problems.

I was working closely with the site owner, they were nice enough to allow me to really dig into their site.  What did I find?  A bunch of plugin and theme minor issues that I chased thinking they were conflicting somehow to no avail.  I ended up opening a ticket with the hosting provider and once we clarrified the problem, they sent me so error log information:

[error] ModSecurity: Access denied with code 403 (phase 2).Match of "rx
://%{SERVER_NAME}/" against "MATCHED_VARS:gform-action" required.
[file "/usr/local/apache/conf/modsec/10_asl_rules.conf"]
[line "489"]
[id "340162"]
[rev "262"]
[msg "Atomicorp.com UNSUPPORTED DELAYED Rules: Remote File Injection attempt
in ARGS (AE)"] [data "
https://docs.google.com/spreadsheet/formresponse?formkey=dhzsutftwllwzwf6lwd
yb0xcmkzsogc6mq&ifq
"]
[severity "CRITICAL"]
[hostname "lanaddicts.org"]
[uri "/test-form/"]
[unique_id "UAbUbnrJTaEAAHtoboQAAAAG"]

Wow! At first I didn’t know what to make of this. A Google Search led me to this Atomic Corp Wiki. I decided that the Apache Security Module must not like the Google Form URL that I need to carry around through the process in order to submit the form variables to Google. I decided to encode it and then decode it when needed to see if that would satisfy the Apache Security Module.

Guess what?  It works!!!!  This is a big relief as I have another user with almost the exact same error being reported and I am betting my updated plugin will fix their problem too.

If you want to try out an early build while I continue to test, you can find one here.

04.09.12
by

wpGForm v0.28 released

This morning I released an update to my WordPress Google Form plugin.  I can only assume very few people are using the email confirmation feature because it wasn’t working and I didn’t hear about it until this past weekend!  The email confirmation feature (add the attribute email=’on’ to your short code) will notify the WordPress administrator that a form submission has been made.

The update is now committed and should appear on your WordPress Dashboard shortly.

03.25.12
by

Custom Confirmation problems with v0.26

In v0.26 of WordPress Google Form I changed how I was handling the custom confirmation page as many people had told me they didn’t like the redirection which caused a rapid page reload.  The new mechanism does a partial page reload using Ajax so the effect is much more graceful but I have heard from several people that it isn’t working for them.

If you are having this problem, please let me know so I can figure what is going on as it is working fine in my development and testing area.  I am still looking for a more graceful solution but the model I used before supporting multi-page forms simply won’t work with multi-page forms.  Multi-page forms are too important and commonplace not to support them.  Sort of a catch 22 for now but I am trying to find a viable alternative.

02.24.12
by

WordPress Google Form v0.24 fixes UTF-8 bug

Recently a couple people have reported problems with international (or UTF-8) characters. The UTF-8 characters were not being passed correctly from the form on the WordPress site on to Google. I had planned to look into the problem this coming weekend but a wpGForm user (cablop.net) beat me to it and has provided the fix (thank you very much!).

I have incorporated the fix and tested it and was able to submit a couple Spanish words that have UTF-8 characters. The update should appear on your Dashboard shortly.

02.04.12
by

WordPress Google Form update – v0.22

Yesterday I received a report from someone using WordPress Google Form that their checkboxes weren’t working. This was very confusing to me because last weekend I spent a bunch of time fixing and testing the checkbox problem.

It turns out the jQuery script which fixes the checkboxes to work with PHP was never running. Why wasn’t it running? Because jQuery wasn’t ever loaded. Why wasn’t jQuery loaded? Because wpGForm never loaded it! It turned out the website which reported the problem was using a theme that doesn’t use jQuery and therefore never loaded it.

Well the WordPress Google Form plugin, which needs jQuery, didn’t load it either. I (and I can only assume other people) was never seeing a problem because either the theme or another plugin was loading jQuery.

The v0.22 update corrects this problem which was somewhat of a corner case, but a problem none the less.