Tag Archives: Progress

11.21.12
by

wpGForm Custom Post Type Preview

As I noted a couple days ago, I have started a “renovation” of sorts to my WordPress Google Forms plugin.  I have defined a Custom Post Type which makes it much easier to set up a form.  It is no longer necessary to worry about the syntax of a long complicated short code!  Here are a couple images of what the Dashboard UI looks like.

Adding a form to a post or page is as simple as adding the [wpgform id=’N’] short code where N maps to the form’s post id.  The short code syntax for each Google Form appears in the list of forms.

The Google Form Edit Screen has fields which map directly to all of the short code attributes that were defined in the original short code.

There is no change of operation on the front end – the form should continue to operate as it has previously.  If you’re interested in testing this new version, I hope to have a beta available fairly soon which also has some other new features.

Moving to a Custom Post Type may allow for some more robust field validation using the jQuery Validation plugin!  Stay tuned for  more details on that as I don’t think it will be in the first release of Custom Post Types.

11.20.12
by

Email Users v4.3.15-beta-6 available

This morning I made a beta-6 version of Email Users v4.3.15 available for download from this site. I  hope this is the final beta version before the final release.  I am not aware of any outstanding bugs at this time.  This latest beta version has some more tweaks to aid in translation.

Download the beta release and please let me know if you run into any issues.

Email Users Beta (5638 downloads )
11.19.12
by

Adding Custom Post Types to WordPress Google Form

I have been thinking about migrating WordPress Google Form from a shortcode based solution to a Custom Post Type solution.  Today I decided to move from thinking about it to acting on it.  As I add more features the short code complexity has grown quite a bit.  Because the short code contains URLs with special characters, the chance of introducing a syntax error is very high and it is by far the most common support request I receive.

There are a lot of benefits to adding a custom Post Type, among them:

  1. Reduced syntax errors.
  2. Shorter short codes.
  3. No chance of misspelling attribute names.
  4. No chance of having duplicate (or triplicate!) attributes and wondering why the first value isn’t working.
  5. Possibility of having form specific CSS.

I plan to retain the current short code syntax so existing installations will continue to work but will introduce a new short code (likely [wpgform id=’N’]) which can be used in place of the current short code.  Over time I will likely deprecate the older short code but not anytime soon.

The primary reason I am doing this is my desire to connect Google Forms with PayPal which I think I can do using a hook in Woo Commerce.  Having the Google Form as a very simple short code will help me do what I want to do (I think).

11.19.12
by

Email Users v4.3.15-beta-5 available

This evening I made a beta-4 beta-5 version of Email Users v4.3.15 available for download from this site. I still hope to incorporate as many translation package updates as I can before the final release. This latest beta version has some more tuning to aid in translation.

Download the beta release and please let me know if you run into any issues.

Email Users Beta (5638 downloads )
11.15.12
by

Email Users v4.3.15-beta available

This morning I have made a beta version of Email Users v4.3.15 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 as well as incorporate any translation package updates as I can before the final release (which I will likely label v4.4.0).

There are a couple of significant new features and a number of bug fixes in this version.

  1. Fixed the problem where a dollar sign in the post or page content followed by a number disappears.  This was happening due to  preg_replace() seeing the $nn pattern as part of its regular expression processing.
  2. Fixed issues with user settings disappearing.
  3. Added the ability to include the sender in the recipient list as an options setting.
  4. Fixed bug which prevented WordPress Dashboard and Menu Manager from working correctly.
  5. Changed a number of strings to make the process of creating a language package much easier.

Download the beta release and please let me know if you run into any issues.

Email Users Beta (5638 downloads )
11.14.12
by

WordPress Google Form v0.46-beta available

This afternoon I made a beta version of WordPress Google Form v0.46 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. Columns!  You can now have your form rendered in columns.  To have a two column form, add the attribute columns=’2′ to your short code.
  2. When enabled, the simple math CAPTCHA will now appear above the Submit button instead of below it.
  3. Some minor CSS updates to support the new column feature.

Download the beta release and please let me know if you run into any issues.  You can see an example of multi-column support on my Multi-Column Test Bed Form.

Google Forms Beta (8789 downloads )
10.29.12
by

WordPress Google Form v0.45-beta available

I’ve made a subtle but potentially significant change to WordPress Google Form that I am looking for some people to try out.  The plugin generates a jQuery script on the fly to perform a number of actions depending on the shortcode attributes present and their setting.

Historically the jQuery script has been output as part of the form code but I’ve seen a number of cases lately where another plugin or in some cases, the theme, is manipulating the page content which ends up affecting the jQuery script.

In one case I looked at this weekend something, I am still not sure what, is injecting paragraph elements into the HTML after it detects a closing DIV tag.  For the most part this isn’t a big deal except, there are closing DIV tags in the jQuery script as part of the CAPTCHA functionality.  The CAPTCHA functionality injects a DIV which holds a second DIV and some other input elements and labels.  What ever is injecting the P elements into the HTML after every closing DIV is causing my script to have syntax errors when the page loads.

To solve this problem I have moved to loading of the jQuery script into the WordPress footer action.  In my testing making this change  has zero effect on the functionality but I’d like some other people to test it and provide me feedback.

Google Forms Beta (8789 downloads )
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.

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.

05.31.12
by

WordPress Google Form v0.30 now available

Similar to yesterday’s update, today I pushed out wpGForm v0.30.  This version  addresses an unusual problem which prevents the custom confirmation CSS from loading properly.

In some cases, it appears that a plugin or theme, through the use of a filter (likely the_content or wpautop), was inserting paragraph tags into the content which by itself isn’t a problem, however when enabled, wpGForm adds a custom CSS block to style the form during processing, so the CSS definition portion of the content ended up with paragraph tags in it.  This results in CSS which won’t parse correctly and of course it never styles the form.  I have updated the plugin to generate the CSS definition as a single line of text where it previously spanned several lines for readability purposes.

The update should appear on your Dashboard shortly and is also available from the WordPress Plugin Repository.