Drupal 4.4.2, webform module CVS after replacing 4.4.0 which also produced the same error.

Basically, all works but form submissions. I have produced the form, set the appropriate permissions up, but the submissions table doesn't get populated with submission data. This happens with 4.4.0 and CVS module version respectively, and I just can't figure the possible reason. User fills the form and 'Send' just refreshes the submittal page. Reset doesn't actually reset the form leaving all data as entered.

Please, can you give me a hand here because I really need this module, and I just can't figure it out? You can see the live version of the contact form on http://www.beautymag.net/kontakt page.

CommentFileSizeAuthor
#3 webform.module24.18 KBullgren
#2 beauty_beautymag.zip1.04 KBSupaDucta
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Ok, first.
Don't use the CVS version of the module since it is not working.
I will have a extra look at things soon.
I have a 4.4 version of drupal with the 4.4 version of the module up and running with no problem.
Can you please fill me in on the details of your system. Database version, php version etc.

SupaDucta’s picture

FileSize
1.04 KB

First of all, let me thank you for the extremely prompt reply, I have prayed for it because site is online at the finishing stage waiting to be published.

Reverted the 4.4.0 module back, and uploaded it to server.

Local info: php 4.3.8, mySQL 4.0.20, Windows XP.

Remote info: php 4.3.8, mySQL 4.0.20, RedHat Linux.

You have probably noticed I am using special characters for labels. Find attached the webform_ tables SQL export.

There was a small modification I have performed in htmltags.inc to conform with W3C XHTML Strict validation, although I don't think it makes any difference in this case - in function _html_tag, the lines:

18
$output = "<$name$attr>$data</$name>";

21
$output = "<$name$attr>0</$name>";

that outputted ex.

<input></input>

were replaced by:

18
$output = "<$name$attr />$data";

21
$output = $output = "<$name$attr />0";

to produce

<input />
with the omittag so the page validates as XHTML Strict. Those were the only modifications that took place - noting them here just in case.

Please find the attached zipped SQL export of the webform_ related tables.

Again, thank you for your warp-speed reply ;)

ullgren’s picture

FileSize
24.18 KB

Thanks ... well all seems well ...
Can you please test this module and look for any error in the drupal log after submission.
Also try to enable webform debugging and tell me if you get any output.

The htmltags.inc file will be obsolete in the new (4.5) version of webform.

ullgren’s picture

When you are doing the tests make sure you are accessing the page with the corect URL.
I have check to prevent cross-site posting to the form.

So if the base_url in conf.php is set to http://www.example.org, You must access the page http://www.example.org/kontakt and not http://127.0.0.1/kontakt even if it is on your locale machine.

SupaDucta’s picture

Tested locally as you instructed me to, and noticed this in the log (GRRRRRRR! Should have turned the debug info ON before):

Trying to post to webform from other another domain.

So I have set the following:

 function _webform_process_submit(&$node, &$errors) {
  global $user, $base_url;
  
  // Check referer to deny posting from of sites.
  if ( variable_get('webform_allow_cross_site_posting', 'OFF') == 'OFF') {
    $referer = parse_url( urldecode($_SERVER['HTTP_REFERER']));
    $base = parse_url( urldecode($base_url.'/'));
    
    if ( $referer['scheme'] != $base['scheme']
         || $referer['host'] != $base['host']
	 ) {
      // The submission didn't originate from our own domain, return false
      watchdog('error', t('Trying to post to webform from other another domain.'), $_SERVER['HTTP_REFERER']);
      return false;    
    }
  } 

to:

if ( variable_get('webform_allow_cross_site_posting', 'OFF') == 'ON')

and it works. Although the form actually did originate from our own domain - conf.php has the following setting: $base_url = "http://www.beautymag.net";. I don't know if this solution enables mass form populating from other sites? Is there a better way to fix this?

SupaDucta’s picture

Basically I was using base url all the time, both locally and on the web. Yet, for example locally, as a referer I didn't get the URL but IP of the virtual hosts directive. Oddly, the same thing happened on the web, although form was also submitted from the real base URL.

SupaDucta’s picture

Yes, the system mails neatly :) All I have to do is fix the Croatian special characters that are not parsed correctly in the email form but basically works now, although cross-site posting is ON for now.

ullgren’s picture

Ok ... well this is a strange behaviour.

I'll add the watchdog messages to the 4.4 version (and the CVS). I'll also add the setting option to allow/deny cross site posting.
Yes it would leave your site open to evil persons. But the defens is pretty low since one can easily fake the referear with a well crafted HTTP post. So I don't think it'll be a big problem.

Please send me patches for the escaping of the characters if you get it to work.
Personaly I had no problems with your chars, but I am using a UTF-8 compliant mail client.

Also: Can I consider this issue as closed ??

SupaDucta’s picture

Thank you very, VERY VERY much. I have set the status to 'Fixed'.

I'll keep you posted on the special chars handling.

Thanks again ;)

ullgren’s picture

Closed