Tag Archives: WordPress

09.14.12
by

Debugging a Theme conflict with wpGForm

About a week ago I was contacted through my WordPress Google Form Support and Help form by a user of my WordPress Google Form plugin.  The symptoms he described sounded very much like the problem I recently chased down with ModSecurity.  I figured this must be another use model that I hadn’t accounted for.

Fortunately and unfortunately, I was wrong.  After going through the usual process of trying to narrow down the problem (using wpGForm debug mode, disabling all plugins, etc.), we were able to isolate the problem to what I suspected was a theme issue.    Ugh.  A lot of times people don’t want to or can’t change their theme. I wanted to swap the theme for TwentyTen or TwentyEleven but that wasn’t really possible as the site is live and being used.

Now what?  Since the user couldn’t switch the theme and we ended up putting a copy of his theme in a development area and were able to replicate the problem.  Whew – the helped a lot.  I could switch back and forth between his theme and TwentyTen in debug mode and compare the results.

It took a while to track it down but it turns out the theme, Unite from Paralleus, has a jQuery script which scans the page content for Submit Buttons, removes the buttons, and rebuilds them to match the theme style.  In theory this is actually rather clever and makes the submit buttons attractive although I am not sure why it couldn’t be done with CSS classes, I didn’t look at it closely enough.  However, in practice when the submit buttons are reconstructed, they don’t contain all of the attributes they started with so they are not equivalent.  And this matters when submitting a Google form.  A lot.

A Google form just can’t be submitted with a submit button.  It needs to be submitted with the submit action having a named parameter and a value.  Google uses the named parameter and it’s value to support multi-page Google forms.  It is this named parameter and value that Unite strips off effectively making the form incomplete which causes Google to rejects it as an incomplete form.  Because Google rejects it, WordPress Google Form simply redisplays the form again.  To the end user it looks like the form was never submitted.

As a plugin developer, I am not sure what the right answer is here.  Actually, that isn’t true.  I do know the right answer is.  The theme should be fixed but I have zero control and influence over that happening.  To solve the problem in the short term, I have created a hack of sorts that works around this problem with the Unite theme but that is in a one-off build for testing.  What should I do to my plugin?  Add a unitethemehack=’on’ attribute?  Right now that is probably the best option although it feels pretty dirty.  The code to enable this hack is trivial because Unite won’t muck with submit buttons which have the noStyle CSS class applied to them.  At least there is a work-around.  The hack I added to WordPress Google Form is inserting class=”noStyle” to any submit button in the Google Form HTML.

But I am wondering how many more scenarios like this will I run into?  Is there a more general purpose solution?  Probably.  I’ve been thinking about a “find and replace” solution as I was asked about doing something similar previously to rename all of the submit buttons as something else.  I’ll keep noodling but for the time being, I think I’m going forward with a new attribute.

09.07.12
by

WordPress Google Form v0.38 released

Today I released v0.38 of my WordPress Google Form plugin.  If you look at the change log you’ll see I actually released it a couple times today (ugh).

Release v0.36 addressed a bug when the Browser Check option was enabled.  I susquently released v0.37 because I didn’t tag v0.36 correctly and the WordPress Plugin Repository didn’t see the update.  I then released v0.38 because I left some debug code active that I used to chase down the problem I originally fixed in v0.36.

I apologize for the multiple updates, it certainly was not my intention.  You can find v0.38 on your Dashboard Update or in the WordPress Plugin Repository.

09.05.12
by

WordPress Google Form v0.35 released

This afternoon I released v0.35 of my WordPress Google Form plugin. Included in this update are:

  • Minor fix to email formatting to address poorly formed HTML.
  • New short code attribute (spreadsheet='<url>’) which, when used in conjunction with the email=’on’ attribute setting, will include a link to the Google Docs Spreadsheet which contains the form submission data.

You can find the latest version of WordPress Google Form in the WordPress Plugin repository or as a Dashboard Update.

09.03.12
by

phpHtmlLib v2.6.5.3569 released

This morning I release an update to phpHtmlLib which resolves an issue for users still running sites based on PHP 5.2.  The recent update to address early PHP 5.3.x releases contained code which was not 5.2.x compatible.  This update addresses that problem.  You can find the update on the Download and Installation page or as a Dashboard Update from the WordPress plugin repository.

08.29.12
by

wp-SwimTeam v1.36.973 released

This morning I released v1.36.973 of wp-SwimTeam.  This build addresses a bug which prevents Users from signing up for job from the Jobs tab.

Yesterday I released v1.35.971 which addressed a problem when there were zero swimmers (aka a new installation) in the system.  This bug caused some of the pages to display oddly for the Roster and list of Swimmers.  Lastly, I enhanced the registration email such that it includes the Optional Field data defined for a swimmer.  This enhancement is only included when using HTML formatted email.  The Plain Text email continues to be very brief in nature.

You can find the latest version of wp-SwimTeam on the Download and  Installation page or in the WordPress Plugin repository.  I also released an update to phpHtmlLib yesterday which addresses the very odd situation which resulted in blank pages within the wp-SwimTeam Dashboard.

08.28.12
by

Finally fixed the Multi-Page Google Form results

Since I first added support for Multi-Page Google Forms I have had a sample form on my site with the submitted results displayed on another page. I use the Inline Google Spreadsheet Viewer plugin to display the submitted results on the page except it wasn’t working.

It worked fine for my Sample Form results but not the Multi-Page Form results. I finally figured out that I was using the wrong Google Docs key to display the results. I was using the key that Google Doc’s Share functionality provides instead of the key that the Publish to Web Page provides.  It is this later key that allows the plugin to operate correctly.  Doh!  Need to read the documentation a little closer I guess.

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.

08.13.12
by

WordPress Google Form v0.33 released

This afternoon I released the v0.33 update to WordPress Google Form.  This update introduces a new setting which allows users who are using the email notification to turn off the Bcc to the Blog Admin feature.  This setting is on my default to match the behavior of the plugin prior to v0.32.

Several other minor bugs were also fixed which affected how default plugin settings are handled.  You can find the update in the WordPress Plugin Repository or on your WordPress Dashboard Update notification.

What happened to v0.32?  I failed to update the version number in the plugin file before tagging the relase in the WordPress plugin repository so I had to increment the version number again.

08.06.12
by

WordPress Google Form v0.31 released

After a couple weeks of sitting on a new release, I have pushed out v0.31. This release addresses the ModSecurity problem that I had noted in a post a few weeks ago.  After chasing this problem down with the help of several users who were willing to work with debug code and/or give me access to their server, I was able to figure out what was going on.

The simple explanation is that the Apache ModSecurity module can be pretty restrictive and returns 403 errors when a form is submitted.  WordPress then does it’s thing and concludes that the page should be displayed again.  The net result is that form is never submitted and no feedback is provided to the user.  From what I’ve seen, ModSecurity doesn’t like URLs passed as parameters which WordPress Google Form does for the Google Form – it needs it to submit the responses to the form.

With this update two things have changed:

  1. If a 403 error is returned, the plugin will check for it and show a message if/when it happens.
  2. The Google Form URL is passed as an encoded parameter so it doesn’t get flagged by ModSecurity.

These changes won’t address all instances when ModSecurity kicks in – if your form includes any input where a user can type a response AND they user submits a URL as a response, there is a pretty good change a 403 error will be issued by the server.

Hopefully this change will help some very odd use cases where users don’t understand why the plugin isn’t working for them.  It has worked in four  (4) additional situations that users have asked me to look at it plus the two original that I looked at.

You can find the update in the WordPress Plugin Repository.

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.