8

My soon-to-be production Drupal site's Webforms have stopped saving submissions; instead it comes back to the same page, complete with the inputted values. I do not have a timeline when it stopped working. In a sandbox environment, Webform 7.x-3.17 works fine.

I'm looking for some suggestions to further debug.

I've tried the following, but to no success:

  • Disabling any modules that refer to Webform (notably Webform Template and Webform Validation, and my own custom module that had been using hook_form_alter).
  • Upgrading to the latest Webform (yes I remembered to use update.php).
  • Based on documentation, combining hook_form_alter($form, &$form_state) with array_unshift($form['#submit'],'my_custom_submit') to insert a custom callback, where I called drupal_build_form($form['form_id']['#value'],$form_state) to emulate a submission.
  • Obviously flushing caches consistently.
  • Ensuring that the Webform is published.
  • Writing a bare-bones module to simply monitor $form_state['executed'] (it always returns false).
  • Checking my server's error_log both on SSH and FTP.
  • Checking Reports > Recent log messages.
  • New: Tried disabling & uninstalling Webform, deleting old Webform files, and installing a fresh new version of Webform; no good.

I'm pretty sure the issue is not isolated to Webform, so it wouldn't make sense to post to their issue queue.

What other debugging methods can I pull out to help crush this bug? If I disable every module without uninstalling, is an entire FTP backup necessary or just SQL?

EDIT: Some more things I've tried as per suggestions (unsuccessfully)

  • Explicitly defining $cookie_domain and $base_url in settings.php
  • Looking through Trigger and Action modules for any potential misfiring redirects
Improve this question
3
  • Have you checked for a trigger/action or rule that causes a redirect that may be misfiring?
    – Patrick Kenny
    Apr 6, 2012 at 0:34
  • @PatrickKenny Unfortunately no, there are no leads in the Trigger or Action module UI pages.
    – Morgan Delaney
    Apr 7, 2012 at 21:37
  • Make sure you are using the proper settings.php, that the values of $base_url and $cookie_domain are set properly, I recommend using multiple settings folders for your different settings. Each has their own database, $base_url and $cookie domain settings. Makes troubleshooting easier, in my humble opinion.
    – stefgosselin
    May 8, 2012 at 4:19

5 Answers 5

Reset to default
2

I have never had any problem with the Webform module, but if it happened to me I would double check sites/default/setting.php to see if there are any settings for an explicit $base_url or $cookie_domain. The latter is much improbable, since you would probably have problems with logging in.

Improve this answer
1
  • Dang. I tried adding this to the bottom of sites/default/settings.php: pastebin.com/94PBeeiG. That did not work, but thanks for the response! (I'm certainly running desperate.)
    – Morgan Delaney
    Apr 5, 2012 at 23:59
1

Just in case you are using the Boost module, that was happening to me and the problem was in the .htaccess file, check my solution here: https://drupal.stackexchange.com/a/207102/11424

Improve this answer
1

I had the same issue. Like Dennis, the problem was caused by putting a URL alias on the webform node. When I removed the alias and did a full URL then it worked just fine. In my case, there was a conflict because my chosen URL alias was equal to a directory name on my site. So I could use a different alias and it worked fine. I just can't use the alias I wanted, unless I rename the conflicting directory on my site.

Improve this answer
0

I was just getting exactly this issue. I found that the problem was that the form was being altered in a way that prevented webforms from understanding it. As far as I could tell, the $form_state was not being affected by the changes, but altering the $form was still enough to break the whole thing.

I haven't found the workaround yet. I'll update my answer if I do.

Update: For my workaround, I used the #prefix and #suffix to add markup to elements instead of putting them in form containers. This fixed the problem.

Improve this answer
1
  • I have a similar problem here, whereby the presence of certain fields remove the #node element, which ruins submission / validation.
    – njp
    Nov 7, 2013 at 15:13
0

I wanted to add my two cents worth here. I had the same issue on a dev site. The site will go live soon, but I was checking the functionality and got this very same issue.

The problem was caused by putting a URL alias on the webform node. When I removed the alias and did a full URL (mysite.com/?q=node/8) then it worked just fine.

Also, I don't have clean URLs enabled so that might fix the issue with the URL alias.

But I wanted to throw this out to anyone else with the issue . . .

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.