Hello,

I've been working on a website I have been developing locally for a client on an Apache server. The production server, however, uses IIS 6.0. When using Guestbook on Apache with Drupal 6.8 it works fine, however when I try it on the IIS server nothing happens. The loading icon comes up and stays in this mode infinitely in Firefox, while in Chrome, a Time Out error is given after a while. I've tried this with the stable version and the 2.x development version and I get the same bug both times.

Any ideas on how I can solve this problem?

Comments

sun’s picture

Title: Time out on submission » IIS: Time out on submission
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

Please check your server logs for any error messages and report back what you have found. You might also consider to consult the handbooks about IIS on drupal.org.

NRaf’s picture

There are no logs relating to this issue being stored.

NRaf’s picture

Title: IIS: Time out on submission » Time out on submission
Priority: Normal » Critical
Status: Postponed (maintainer needs more info) » Active

I've done some further research and the error is occuring because in the insert query, there is nothing being added for the comment field, however the comment field doesn't have a default value in the database.

Changing the insert code to fix the issue:

// Insert new message
  if ($user->uid == 0) {
    // Anonymous user.
    db_query("INSERT INTO {guestbook} (anonname, anonemail, anonwebsite, author, recipient, message, created, comment)
      VALUES('%s', '%s', '%s', %d, %d, '%s', %d, '%s')", $form_state['values']['anonname'], $form_state['values']['anonemail'], $form_state['values']['anonwebsite'], 0, $uid, $message, time(), '');
  }
  else {
    // Authenticated user.
    db_query("INSERT INTO {guestbook} (author, recipient, message, created, comment)
      VALUES(%d, %d, '%s', %d, '%s')", $user->uid, $uid, $message, time(), '');
}
sun’s picture

Priority: Critical » Normal
Status: Active » Closed (duplicate)

After replacing those lines with your code, the only difference is a switch in the column order. Thus, this bug was either fixed through another issue, or I'm not able to reproduce it.