Mike Walsh

Can you elaborate on the problem you are having?

The Google Forms plugins loads all of the jQuery elements it uses via the wp_enqueue_script() mechanism which should take care of the http / https problem you alluded to.

The easiest way to “hide” the confirmation page before the redirect kicks in is to use CSS to hide the content of the confirmation page. You would add this CSS using Google Forms’ Custom CSS capability.

I don’t have a form handy to look at but if you temporarily disable your redirect so the Google confirmation page remains, you can look at the page structure and figure out a DIV to hide using display:none;

I think this may work:

div.ss-resp-card {
display:none;
}

The behavior you’re seeing is consistent with what a few others have also found. I cannot really explain why that option achieves the result it does as I can’t explain why it happens in the first place. I think it is due to some poorly structured HTML returned from Google.com when retrieving the form content but I am not 100% sure. I cannot cause the issue to happen in my debug environment so it is almost impossible to chase down.

What has been consistent though is setting that option makes the problem go away without causing any other problems.

Interesting that both were on a Mac. I have no idea why that would make a difference but I’ll run another test on my Mac later tonight. I only have access to an older Mac Mini but it should be sufficient for checking with Chrome and Safari.

There is no known conflict but it certainly sounds like you have found one. What I recommend is to temporarily disable all plugins except email users and make sure it appears on the Dashboard as expected. Assuming it does, start enabling your plugins one at a time until you find the conflicting plugin. Once you identify it, we can figure out where the fault lies.

I myself use the following from your list so doubt they are at fault:

• Akisment Antispam
• Jetpack
• WP Maintenance Mode
• User Role Editor (I think this is the same one I have test with)

I just looked at your form and I am not seeing the text – did you fix it? If it is the same problem a few others have reported, it can be resolved by unchecking the “Disabled HTML Filtering” option in the plugin settings. Here is a post on my web site with more details. While the post subject doesn’t address your problem, the same option should fix the problem you reported.

I just ran through your form on your web site (the WordPress version) so you can delete my submission. It worked without any issues. You have a multipage form which means that for every page of the form, there is a nonce verification being performed. It isn’t done just on the final form submission because WordPress doesn’t know the difference between the final submit and the submit action for each page of the form.

I tested it with Firefox – any idea what browser the people who had it fail were using?

Two failures against how many successful submissions? If you want to send me the form URL you are welcome to do so – send it to me at mpwalsh8 at gmail dot com. The other thing which would be helpful is the URL to the Google Form.

If this only fails every once in a while, it will be almost impossible to chase down. It it fails 50% of the time, that may be a bit easier although there isn’t a lot of information from WordPress itself when a nonce doesn’t verify. The nonce either verifies or it doesn’t.

Any chance your page has more than one form on it or something else which would generate a nonce?

How often does this happen and is there anything else which has changed? I’ve looked through the plugin code again and I don’t see which would cause this to happen and if it was pervasive, I would think I would have more reports about it.

If checkboxes don’t work it almost always means you have a Javascript error on your site which prevents the jQuery script that Google Forms defines from running when the page loads.

One of the last things which happens when rendering a form is a jQuery script executes which modifies the checkboxes. Because WordPress is written in PHP and Google uses Python for Google Forms, there is a compatibility issue between PHP and Python which the jQuery script accounts for. When a page has a Javascript error, the jQuery script never runs so the checkboxes aren’t compatible.

Chrome’s Inspector or Firefox’ equivalent should be able to pinpoint the Javascript error on page load.

No, I have not added an option to do what the thread requests. I spent sometime thinking about it and defining an anchor should be possible. I am out of the country for work for the next week, I’ll see if I can allocate some time to look at this when I get home.

When the validation messages show up when the form first renders it usually means your theme defines a CSS class (error-message as I recall) which conflicts with a CSS class of the same name which Google defines for the validation messages. You can use the CSS prefix option to ensure the CSS class defined by Google doesn’t conflict with your theme.

If you have defined Custom CSS for your form you’ll need to make sure to update all of the rules with the CSS prefix because when enabled, it is added to every CSS class Google defines.

There is a checkbox on the plugin settings (Dashboard > Settings > Email Users) to enable debug mode. It is a setting you don’t want to leave on permanently as it attempts to intercept email as WordPress processes it and before it hands it off to the underlying OS mail transport.

When enabled, you do the normal “Send to Users”, “Send to Group” or “Notify Users” operation like you would during normal operation. When you press the Send button the Dashboard will update as normal but in addition to seeing the normal Dashboard content, the mail header information Email Users constructs will be output as well. It is is dumped in the format PHP stores it, the output isn’t fancy or well formatted but it does allow you to see the content of the mail headers as things like “TO”, “CC”, “BCC” and a few others will be the array keys in the information dumped out.

What you are looking for is to see if the content of the headers matches what you would expect to see for your target recipients. I recommend starting simple, pick 2-3 recipients as picking a group with hundreds of users in it can be overwhelming. By limiting it to a few users you can easily see the email addresses in the header to make sure they are formatted as expected and more importantly, all of the addresses you expect are included.

You should see the bulk of the addresses in the BCC field as that is what Email Users uses to send to more than one user at a time. If you pick a single recipient you should see their address in the TO field. The TO field will likely have the address for the admin user in it and the CC field will usually have the email address of the user sending the message.

If that all looks correct then I am not sure where to go next. wp_mail() is the WordPress API function which is used by WordPress itself to send email and Email Users uses it the same way.

Some hosting providers have rules about numbers of recipients in a BCC field which is why the BCC limit setting was added. Some hosting providers have other rules – it really varies so it is hard to know exactly what might be the issue.

Make sure you turn off debug when you are done.

The plugin is not advertised to support the new version of Google Forms. In fact, it performs a check when a form is defined to let the user know the form may not be supported. The check isn’t perfect but it catches most of them.

As for the process to get it to work – downgrading a Google Form is pretty simple. I am sorry you didn’t have a better experience.

I am not sure I understand your question completely. When I look at your page and click on the next button, the page transitions to the next page of the form as I would expect. It does look like you have two forms on your page but that should be an issue because one is from Contact Form 7.