Weird Javascript behavior after form_set_error on Drupal forms
Hello all, I'm developing a Drupal-based Purchase Order Management module for my company. The purchase order node form uses a few autocomplete elements as well as other JQuery bits to do a pop-up using blockUI to fill out the PO line items. The PO line item form is hidden by default (display: none). If I skip a required field on the parent Drupal node form (using Drupal's built-in #required => TRUE) then Drupal comes back as expected with the red form_set_error box at the top of the page listing all the required elements I skipped. However, that seems to break much of my Javascript. Here are some specifics: 1) Before the form is submitted the autocomplete fields go look up contacts from my Drupal contacts database (another custom module I've developed), then bring back the selected contact's mailing address and pop it into a div below the autocomplete box. After the form_set_error returns, the autocomplete still looks up the values in the contacts database, but the resulting mailing address is not popped into the div. 2) Before the form is submitted there's a link entitled "Add/Edit/Delete line items" and when clicked it does a blockUI and shows the line items form in the javascript pop-up window above a grayed out screen. After the form_set_error returns, the "Add/Edit/Delete line items" link doesn't block the UI and show the line items form. However, the line items form is displayed on the main parent page (no longer display: none until blockUI as it was before I submitted). I added a javascript alert at the top of $(document).ready() to show when the document is done loading, and it doesn't reappear after the form_set_error comes back, so I'm guessing it's not reloading the page when it does that. However, I'm not sure why it would break all the javascript, or where I could intercept the form submit processing to fix the situation. Any help for ideas of where to troubleshoot this would be appreciate. I'd be happy to post code as well, but it's quite a bit of code so I'll spare you all the details until I get some ideas of where to drill down. Any help would be appreciated. Best, Dave
Hi Dave, I had almost exactly this issue a while ago. I think it was down to how I was loading the javascript, in that when form_set_error had been called the form was rendered out but my javascript wasn't actually being loaded on this new page load. Are you able to inspect the page using firebug or similar to see if your javascript file is actually being loaded after the form validation fails? Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites Phone : 024 7666 7277 Mobile : 07702 131 576 Twitter : darthsteven http://www.computerminds.co.uk 2009/12/17 David Thibault <dthibault@esperion.com>:
Hello all,
I’m developing a Drupal-based Purchase Order Management module for my company. The purchase order node form uses a few autocomplete elements as well as other JQuery bits to do a pop-up using blockUI to fill out the PO line items. The PO line item form is hidden by default (display: none). If I skip a required field on the parent Drupal node form (using Drupal’s built-in #required => TRUE) then Drupal comes back as expected with the red form_set_error box at the top of the page listing all the required elements I skipped. However, that seems to break much of my Javascript. Here are some specifics:
1) Before the form is submitted the autocomplete fields go look up contacts from my Drupal contacts database (another custom module I’ve developed), then bring back the selected contact’s mailing address and pop it into a div below the autocomplete box. After the form_set_error returns, the autocomplete still looks up the values in the contacts database, but the resulting mailing address is not popped into the div.
2) Before the form is submitted there’s a link entitled “Add/Edit/Delete line items” and when clicked it does a blockUI and shows the line items form in the javascript pop-up window above a grayed out screen. After the form_set_error returns, the “Add/Edit/Delete line items” link doesn’t block the UI and show the line items form. However, the line items form is displayed on the main parent page (no longer display: none until blockUI as it was before I submitted).
I added a javascript alert at the top of $(document).ready() to show when the document is done loading, and it doesn’t reappear after the form_set_error comes back, so I’m guessing it’s not reloading the page when it does that. However, I’m not sure why it would break all the javascript, or where I could intercept the form submit processing to fix the situation. Any help for ideas of where to troubleshoot this would be appreciate. I’d be happy to post code as well, but it’s quite a bit of code so I’ll spare you all the details until I get some ideas of where to drill down. Any help would be appreciated.
Best, Dave
It is not being reloaded, I don't think. All the javascript happens inside $(document).ready(function() {}). The first line in that function was alert('document is ready') for debugging purposes. When I first load the page, the alert fires. After submitting the form, form_set_error returns the errors for missing required values but "document is ready" doesn't pop up again, so it's like it's not rerunning the javascript. If the page never went away and came back, I'm not sure why the javascript is broken. If it did go away and come back, I'm not sure why it doesn't fire the alert again. Did you ever find a workaround for this? I was thinking about taking out the submit button, doing all the validation in javascript, and saving the records using ajax as a complete workaround, but I'd rather do this the Drupal way to be consistent with other modules I've put on our intranet. Dave -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Steven Jones Sent: Thursday, December 17, 2009 12:34 PM To: development Subject: Re: [development] Weird Javascript behavior after form_set_error on Drupal forms Hi Dave, I had almost exactly this issue a while ago. I think it was down to how I was loading the javascript, in that when form_set_error had been called the form was rendered out but my javascript wasn't actually being loaded on this new page load. Are you able to inspect the page using firebug or similar to see if your javascript file is actually being loaded after the form validation fails? Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites Phone : 024 7666 7277 Mobile : 07702 131 576 Twitter : darthsteven http://www.computerminds.co.uk 2009/12/17 David Thibault <dthibault@esperion.com>:
Hello all,
I'm developing a Drupal-based Purchase Order Management module for my company. The purchase order node form uses a few autocomplete elements as well as other JQuery bits to do a pop-up using blockUI to fill out the PO line items. The PO line item form is hidden by default (display: none). If I skip a required field on the parent Drupal node form (using Drupal's built-in #required => TRUE) then Drupal comes back as expected with the red form_set_error box at the top of the page listing all the required elements I skipped. However, that seems to break much of my Javascript. Here are some specifics:
1) Before the form is submitted the autocomplete fields go look up contacts from my Drupal contacts database (another custom module I've developed), then bring back the selected contact's mailing address and pop it into a div below the autocomplete box. After the form_set_error returns, the autocomplete still looks up the values in the contacts database, but the resulting mailing address is not popped into the div.
2) Before the form is submitted there's a link entitled "Add/Edit/Delete line items" and when clicked it does a blockUI and shows the line items form in the javascript pop-up window above a grayed out screen. After the form_set_error returns, the "Add/Edit/Delete line items" link doesn't block the UI and show the line items form. However, the line items form is displayed on the main parent page (no longer display: none until blockUI as it was before I submitted).
I added a javascript alert at the top of $(document).ready() to show when the document is done loading, and it doesn't reappear after the form_set_error comes back, so I'm guessing it's not reloading the page when it does that. However, I'm not sure why it would break all the javascript, or where I could intercept the form submit processing to fix the situation. Any help for ideas of where to troubleshoot this would be appreciate. I'd be happy to post code as well, but it's quite a bit of code so I'll spare you all the details until I get some ideas of where to drill down. Any help would be appreciated.
Best, Dave
I think what you're seeing is that the form that is validated comes from the cache, and thus never goes through hook_form_alter (might be making that bit up). So you will want to ensure the js is added in some other way. You could sneakily add it in a custom validation handler for the form? Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites Phone : 024 7666 7277 Mobile : 07702 131 576 Twitter : darthsteven http://www.computerminds.co.uk 2009/12/17 David Thibault <dthibault@esperion.com>:
It is not being reloaded, I don't think. All the javascript happens inside $(document).ready(function() {}). The first line in that function was alert('document is ready') for debugging purposes. When I first load the page, the alert fires. After submitting the form, form_set_error returns the errors for missing required values but "document is ready" doesn't pop up again, so it's like it's not rerunning the javascript. If the page never went away and came back, I'm not sure why the javascript is broken. If it did go away and come back, I'm not sure why it doesn't fire the alert again.
Did you ever find a workaround for this? I was thinking about taking out the submit button, doing all the validation in javascript, and saving the records using ajax as a complete workaround, but I'd rather do this the Drupal way to be consistent with other modules I've put on our intranet.
Dave
-----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Steven Jones Sent: Thursday, December 17, 2009 12:34 PM To: development Subject: Re: [development] Weird Javascript behavior after form_set_error on Drupal forms
Hi Dave,
I had almost exactly this issue a while ago. I think it was down to how I was loading the javascript, in that when form_set_error had been called the form was rendered out but my javascript wasn't actually being loaded on this new page load.
Are you able to inspect the page using firebug or similar to see if your javascript file is actually being loaded after the form validation fails?
Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites
Phone : 024 7666 7277 Mobile : 07702 131 576 Twitter : darthsteven http://www.computerminds.co.uk
2009/12/17 David Thibault <dthibault@esperion.com>:
Hello all,
I'm developing a Drupal-based Purchase Order Management module for my company. The purchase order node form uses a few autocomplete elements as well as other JQuery bits to do a pop-up using blockUI to fill out the PO line items. The PO line item form is hidden by default (display: none). If I skip a required field on the parent Drupal node form (using Drupal's built-in #required => TRUE) then Drupal comes back as expected with the red form_set_error box at the top of the page listing all the required elements I skipped. However, that seems to break much of my Javascript. Here are some specifics:
1) Before the form is submitted the autocomplete fields go look up contacts from my Drupal contacts database (another custom module I've developed), then bring back the selected contact's mailing address and pop it into a div below the autocomplete box. After the form_set_error returns, the autocomplete still looks up the values in the contacts database, but the resulting mailing address is not popped into the div.
2) Before the form is submitted there's a link entitled "Add/Edit/Delete line items" and when clicked it does a blockUI and shows the line items form in the javascript pop-up window above a grayed out screen. After the form_set_error returns, the "Add/Edit/Delete line items" link doesn't block the UI and show the line items form. However, the line items form is displayed on the main parent page (no longer display: none until blockUI as it was before I submitted).
I added a javascript alert at the top of $(document).ready() to show when the document is done loading, and it doesn't reappear after the form_set_error comes back, so I'm guessing it's not reloading the page when it does that. However, I'm not sure why it would break all the javascript, or where I could intercept the form submit processing to fix the situation. Any help for ideas of where to troubleshoot this would be appreciate. I'd be happy to post code as well, but it's quite a bit of code so I'll spare you all the details until I get some ideas of where to drill down. Any help would be appreciated.
Best, Dave
OK, so I just noticed in Firebug that pomanagement.js has not been included in the page after form_set_error returns. It's completely gone at that point. I have been using hook_form_alter to inject css and js via drupal_add_css and drupal_add_js. Is that not correct? Is there a better place to put that stuff? Does hook_form_alter not get processed after a form error occurs? Dave -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Steven Jones Sent: Thursday, December 17, 2009 12:34 PM To: development Subject: Re: [development] Weird Javascript behavior after form_set_error on Drupal forms Hi Dave, I had almost exactly this issue a while ago. I think it was down to how I was loading the javascript, in that when form_set_error had been called the form was rendered out but my javascript wasn't actually being loaded on this new page load. Are you able to inspect the page using firebug or similar to see if your javascript file is actually being loaded after the form validation fails? Regards Steven Jones ComputerMinds ltd - Perfect Drupal Websites Phone : 024 7666 7277 Mobile : 07702 131 576 Twitter : darthsteven http://www.computerminds.co.uk 2009/12/17 David Thibault <dthibault@esperion.com>:
Hello all,
I'm developing a Drupal-based Purchase Order Management module for my company. The purchase order node form uses a few autocomplete elements as well as other JQuery bits to do a pop-up using blockUI to fill out the PO line items. The PO line item form is hidden by default (display: none). If I skip a required field on the parent Drupal node form (using Drupal's built-in #required => TRUE) then Drupal comes back as expected with the red form_set_error box at the top of the page listing all the required elements I skipped. However, that seems to break much of my Javascript. Here are some specifics:
1) Before the form is submitted the autocomplete fields go look up contacts from my Drupal contacts database (another custom module I've developed), then bring back the selected contact's mailing address and pop it into a div below the autocomplete box. After the form_set_error returns, the autocomplete still looks up the values in the contacts database, but the resulting mailing address is not popped into the div.
2) Before the form is submitted there's a link entitled "Add/Edit/Delete line items" and when clicked it does a blockUI and shows the line items form in the javascript pop-up window above a grayed out screen. After the form_set_error returns, the "Add/Edit/Delete line items" link doesn't block the UI and show the line items form. However, the line items form is displayed on the main parent page (no longer display: none until blockUI as it was before I submitted).
I added a javascript alert at the top of $(document).ready() to show when the document is done loading, and it doesn't reappear after the form_set_error comes back, so I'm guessing it's not reloading the page when it does that. However, I'm not sure why it would break all the javascript, or where I could intercept the form submit processing to fix the situation. Any help for ideas of where to troubleshoot this would be appreciate. I'd be happy to post code as well, but it's quite a bit of code so I'll spare you all the details until I get some ideas of where to drill down. Any help would be appreciated.
Best, Dave
participants (2)
-
David Thibault -
Steven Jones