Email Users v4.6.0-beta-3 now available

If you’ve been following the Email Users Support Forum, you are aware that for the past couple of days I have been chasing a bug which affects some users and places all of their intended recipient email addresses in the CC header instead of the BCC header.

This has been a challenging bug to find as it doesn’t happen on any of the systems I have access to.  Fortunately I had a few users affected by this problem willing to help me and I appreciate their assistance.  I am not sure how I would resolved this problem without their assistance.  Again, thanks.

So what was the problem?  The WordPress wp_mail() API allows you to pass extra header information as part of the mail content.  Email Users makes use of this by constructing a BCC header which contains all of the email addresses for the intended recipients.  The wp_mail() function supports headers as a single string or an array of headers, each header as an array element.

Up until this evening Email Users had constructed all email headers as a string.  With a large number of email addresses this string could end up being very long.  However, I don’t believe the length of the string had anything to do with the problem.

When wp_mail() receives headers as a string, it tries to intelligently decompose them.  In some cases it appears that the string wasn’t splitting correctly which means the BCC field wasn’t ever seen.  The “Bcc:” text became part of an email address which was subsequently discarded because it resulted in a bad address.

Email Users v4.6.0 has a rewrite of the mailusers_send_mail() function plus some new debug functionality which helps resolve these sorts of issues.  Additionally, the new debug is under user control so can be turned on and off as needed.

Email Users Beta (71 downloads)


For testing this new version, I recommend turning Debug on until you’re comfortable with the the structure of the email addresses.

Questions or comments -don’t hesitate to ask.

Theme Experiments with TwentyTen and Git

I am doing some experiments with the TwentyTen theme and Git.  Up until very recently I have never used Git, I’ve done all of my version control with Subversion.  With Git gaining in popularity, I see more and more WordPress projects using it.  I figured I ought to educate myself.

I recently picked up the O’Reilly Version Control with Git book.  On a recent trip to Phoenix and back I read through a fair amount of it.  I have found that nothing forces you to learn how to do or use something like having a real problem to solve.  You can take training classes, read books, attend lectures, etc. but you’ll never really learn until you have to actually have to apply the material to solve a real problem.

It was like that for me with Git.  While I’ve used Subversion for quite a while, I was having a tough time getting my arms around the concepts of forks, pushes, pulls, etc.  For all practical purposes, I still am but I am getting there.

I like the idea of child themes.  I have no desire to completely reinvent the wheel.  The  guys who put out WordPress are smart and clever and have done some nice themes that work well.  In particular, I like TwentyTen as a parent theme and have done a couple child themes from it.  I find myself using some of the same ideas and plugins across these theme projects so what I’d really like is a core child theme that I can adapt or build from that contains all of the things I like and have figured out already.

So while reading up on Git I envisioned being able to use it to build a base theme that I could adapt to several others very quickly.  If I made a change it would propagate out to the other themes that are based on the base theme.  At least that is the theory.  I am still not sure if it will work like that or not but I’ve decided to try.

For the past day or so I’ve assembled a TwentyTen child theme I am calling TwentyTen-ACME.  Why ACME?  Because it is a pretty generic name.  ACME was the company that provided everything to Wile E. Coyote in the Road Runner cartoons.  ACME is the definition of generic!

So now that I have my base theme pretty much done, I am going to build a derivative from it for a project I am doing for our middle school.  Shortly there after I am going update my LEGO theme which is based on Sandbox and is long overdue for an update.  I am hoping that as I need to push changes back to the base theme I will be able to flow them back out to the others quickly.  We’ll see.

Debugging a weird one

Yesterday I was contacted by a WordPress Google Forms user who was getting a permission denied problem when submitting his form.  After trying a number of obvious things (like disabling all other plugins), I asked him to try switching to one of the default WordPress themes.  He switched the site over to use TwentyTwelve and the problem went away.  Yeah!  I was worried that we might be dealing with another ModSecurity problem.

So we narrowed the problem down to something in his theme but what would generate a 403 error?  The user was gracious enough to let me have access to his site.  By enabling Debug, I was able to see a dump of the header information.  The header information showed a redirect was being requested (makes sense due to 403).

Using Firebug I could see that the POST variables looked correct.  Oops, maybe not.  Everything looked ok except a hidden variable that Google uses in forms to pass information between the pages of multi-page forms.  Even single page forms have this hidden variable.  On the initial load of the form, this variable should be empty (a null string) but it wasn’t.  How could that happen?

Looking at the HTML page source for the form, I could see there was quite a bit of odd stuff in the form code.  It doesn’t come from Google, where does it come from?  Because form submission worked with TwentyTwelve but didn’t work with the user’s theme, I suspected there was a filter mucking with the HTML.

Sure enough, digging through the theme’s functions.php file I found a custom filter that did several things, one of which was make a call to wptexturize().  Well that would certainly explain the manipulated HTML.

The next step was to comment out the calls to the filter to verify that was indeed the problem.  As expected, the form submitted without any issues.  At that point I wasn’t sure what to tell the user.  We could have left the filters commented out but they are part of the theme and there for a reason.  I decided to look at the filter a little closer.  It turns out, the theme defines a short code, actually, it doesn’t define one, the filter looks for one, called [raw][/raw] and if it finds it, leaves the content between the short code tags untouched.

Well this will work!  So I created a test page and placed the wpgform short code between [raw][/raw] and sure enough, the form submitted properly.

While I don’t like what the theme is doing, at least there was a work-around for it.  Unfortunately there is no way (yet) to accomplish the same thing with the Form URL.

This whole process took a couple of hours – far more than I am typically able to spend helping people but I was genuinely curious what was going on.  I am glad we got the user up and running.

I am trying to think of a good way for people to define forms which can handle such a situation.  I can define a hook but that means people need to write some code to use it or I could define more options for the plugin that allow the generated HTML to be wrapped in some prefix and suffix text (plain or HTML).  I am not sure what to do so will continue to think about it for a day or two.

Huh? How’d I miss WordCamp Raleigh?

I was perusing some WordPress feeds I follow this morning and was reading an article about recent debate on where Custom Post Types should live (plugin or theme – for the record, I am on the side that CPTs should reside in a plugin for the same reasons the article points out) on when I saw a mention that the debate originated at WordCamp Raleigh.

A WordCamp here in Raleigh?  How did I miss that?  Unlike many weekends where I am out an about with soccer, basketball, lacrosse or the like, I was around this weekend.  I couldn’t have gone to the whole thing but the venue for WordCamp Raleigh is maybe 15 minutes from my house.

Bummer – I really would have liked to have attended a couple of the sessions, in particular Using AJAX in your Plugins, Using Git with WordPress and a couple of others.

Maybe next year …

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 (156 downloads)

WordPress Google Form v0.39 released

This morning I released v0.39 of my WordPress Google Form plugin.  This update addresses the corner case exposed when using WordPress Google Form with the Unite theme from Paralleus.  To solve this incompatibility I’ve introduced a new short code attribute called unitethemehack which defaults to off.  By turning it on, WordPress Google Form will modify the Google Form HTML to protect the Submit button(s) from being manipulated by the Unite theme.

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

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.

Suppressing White Space

One of the more common questions I receive is with respect to extra white space on a Google Form. Sometimes the rendering of the form within WordPress is significantly different than it appears within the Google Docs context and people want to know why and more importantly, how to fix it.

Fortunately Google Forms have lots of CSS classes so in all of the cases I’ve seen so far, I’ve been able to help the person solve their white space problem by adding CSS definitions to their custom wpGForm CSS settings to achieve the result they wanted.

The two most common problems I’ve seen so far are extra margin and/or padding on paragraph <P> element and/or <BR> element.  Another situation which I ran into recently involved a theme adding a <BR> element after every <P> element.  This was an unusual situation but I suspect not all that uncommon.  How would this happen?  A theme can define something called the_content filter which will modify the content of a page or post before it is rendered and in this particular case, the filter appended  a <BR> element at the end of every P element!

Fixing White Space Problems

So how do you fix these problems?  Extra padding or margin for the <P> and <BR> elements can be tweaked using the following CSS: p { margin: 0px; } br { margin: 0px; } p { padding: 0px; } br { padding: 0px; }

You may not need all four directives, in fact, in most cases you won’t but it might take a combination of the four to achieve the desired results.

Suppressing Extra <BR> Elements

What do you do if you encounter a situation like described above where the theme is adding extra <BR> elements or you simply don’t want them?  Again, CSS can be used to solve the problem. br { display: none; }

This CSS will essentially prevent the browser from rendering the <BR> elements within the form.  They will still appear in the source HTML but they have no effect because they are not displayed.

I recommend using FireBug to help chase down CSS issues.  It is what I use when looking into problems people have asked me to look at.

Sandbox-LEGO theme v3.0.368 available

After updating my Sandbox-SwimTeam theme, I turned to my Sandbox-LEGO theme.  Like Sandbox-SwimTeam, Sandbox-LEGO is built on top of Sandbox and shares quite a bit of the same feature set and code.  Once I updated Sandbox-SwimTeam, migrating the same changes over to Sandbox-LEGO was pretty straightforward.

If you have a LEGO web site, this a great theme for you!  You can see this theme in action on my web site (although I don’t do much with LEGO any more).  You can download the theme from the Sandbox-LEGO theme page.

Unlike the update to Sandbox-SwimTeam, this theme update will retain your settings even so you don’t have to re-enter them.  I need to migrate this same logic back to Sandbox-SwimTeam too now that I’ve figured out a solution I am happy with.