Checkboxes data not saved, even though cURL is enabled

Sorry I didn’t see this sooner, not sure how I missed it.

I just submitted three responses to your test form and while I get some odd timeout issues both before and after submitting the form, in all cases, two from Firefox, one from Chrome, the responses were submitted and the values of the options recorded in the spreadsheet match the checkboxes I had checked.

Thanks for getting back to me!

I’ve looked into it again and found that the checkboxes in the form sometimes worked and sometimes didn’t, and I have a theory about that. First: you’re right, there were odd timeout messages. Sometimes that prevented loading the page entirely. I found the plugin setting to increase the timeout, and that mostly fixed that, though a few times it displayed the timeout error message at the top of the page, while still displaying the form.

Weirdly, the form *only* recorded the checkbox inputs for me when the timeout message appeared at the top of the page. I added a text box so I could record whether it appeared or not. Unfortunately it’s gotten to some state where that message never appears and the checkboxes never work, so I’m not super confident about this, because I can’t replicate success, only failure.

Would you mind testing it again a couple more times? I want to know whether the checkboxes record for you based on whether you get that timeout message or not.

I’ve submitted it twice and in neither case do the checkboxes get recorded. Can you turn off the redirect? I want to watch the some details using Firebug’s NET tab but the redirect flushes what I am interested in seeing.

Also – can you fill out my Help Form so I can try your form on my site to see if it exhibits the same behavior?

> Can you turn off the redirect?

Done.

> Also – can you fill out my Help Form so I can try your form on my site to see if it exhibits the same behavior?

Done. Thank you for looking into this!

See my email to you for more detail but the quick answer is, your theme is doing something very odd.

The jQuery script which does some housekeeping on the form, most importantly, fixing the checkboxes so they are compatible with Python on the Google side, appears on the page twice and is running twice and modifying the checkbox elements twice which then renders them useless because they don’t match watch Google expects when the form is submitted.

Any update on this issue?

Hi Mike,

Thank you so much for looking into this in such detail! I’ve been looking into it, and though I haven’t fixed it, it’s clear that it isn’t your plugin that’s at fault. So far, I’ve found that wpgform_init() is being called twice, probably because index.php is running twice so it’s running “add_action(‘init’, ‘wpgform_init’ );” twice. I haven’t figured out exactly why yet, but I think it’s in the theme. We use a heavily-customized version of Sheeva version 1.2.2, and the changelog for Sheeva 1.3 it says “Fixed: double content in the pages”. So I’m waiting to hear back from the designer who customized the theme to see if we can compare it to later Sheeva versions and find the bug.

Thank you, again! I’m very appreciative.

Michael

I finally tracked this down to another plugin, WordPress Social Sharing Optimization Pro, causing most of my site’s code to run twice. For some reason it’d run wp-load.php again, which is really early in WordPress’s execution flow. I haven’t looked into why or how it does it; I’ve just disabled it. I suspect my installation of that plugin got into a weird state, because when I updated it (to see if that would fix it instead of disabling it), it gave this error message: “Plugin settings (wpsso_options) have been upgraded, but WordPress returned an error when saving them”

So if anyone in the future has a similar problem, check whether you’re running WPSSO.

That error is usually caused by the setup from shared hosting environments — the database cache (I suspect) doesn’t spin up quickly enough and the options update fails. The plugin will try again, so if you only see that error once, then it only happened once. I know this is an issue on DreamHost, but I wasn’t aware that it was an issue on WPEngine as well.

WordPress documents the return value from the update_option() function as:

(boolean)
    True if option value has changed, false if not or if update failed.

WPSSO basically does this:

$saved = update_option( $options_name, $opts );
if ( $saved !== true )
$this->p->notice->err( ‘Plugin settings (‘.$options_name.’) have been upgraded, but WordPress returned an error when saving them.’, true );

So if WordPress returns anything but true, then an error is printed.

You also mentioned a double-load of your content. This is not normal, but somewhat understandable. WPSSO runs in the header and must expand your Post/Page content (ie. shortcodes, etc.) to create a description. Theme and plugin authors often forget that filter hooks they create may be run more than once — for example ‘the_content’ filter may be run any time a theme or plugin needs to fully resolve the content text of a Post or Page. You can easily test if a badly coded content filter is at fault by unchecking the ‘Apply Content Filter’ option on the SSO Advanced settings page, as explained here: https://surniaulula.com/codex/plugins/wpsso/notes/debugging-and-problem-solving/

js.

Thanks JS! I’ve re-activated WPSSO, and un-checked the ‘Apply Content Filter’ checkbox, and then everything runs correctly.

It’s weird though – I don’t think WPGForms uses the_content filter. “the_content” appears a couple of times in the plugin code, but it’s commented out. WPGForms adds an action to wp_footer:

add_action(‘wp_footer’, ‘wpgform_footer’) ;

And I had thought that it was this which was being run twice, and therefore adding the action twice.

I’m stepping out of this now, because my main problem is fixed. Thank you JS and Mike!

Your issue could be caused by another plugin, so it may be worth testing each one (deactivate, test, reactivate) to see if something else may be at play here. You’d be surprised how many plugin and theme authors don’t code WordPress filters correctly.

If you don’t use shortcodes in your content, it should be fine to leave the ‘Apply Content Filter’ unchecked, but if you use shortcodes to generate text and/or include images, it may be worth re-enabling this option, and finding the offending plugin / function.

js.

On my staging site, I deactivated all the plugins except WPSSO and WPGForms, and the double-content load problem still occurred.

Then, I set up a completely new test site, and installed only those two plugins (although I used the free version of WPSSO), and the problem did not occur.

So it’s not a third plugin interfering, but it’s also not just the interaction of WPSSO and WPGForms alone. I think the problem is in my theme. I’ve long been suspicious of this theme doing weird things with the_content and autop and shortcodes. It has a questionably-grammatical comment “Replace the default get_the_content, managing better the shortcodes” above a function, yiw_clean_text. I suppose that somehow replaces the_content, though I don’t understand the mechanism. In any case, I don’t think it’s replacing it properly. I suspect the original theme wasn’t coded well, and then it was heavily modified by a non-programming designer, who might have changed it further.

One day I hope we’ll completely re-make the theme, but until then, we’ll get by without the Apply Content Filter checkbox. Thanks!