I think you're right Nancy. I'd had a $_SESSIONectomy and hadn't considered it! Ayen Designs - quality software the first time, every time! -----Original Message----- From: nan wich <nan_wich@bellsouth.net> Sender: development-bounces@drupal.org Date: Tue, 10 Aug 2010 19:20:33 To: <development@drupal.org> Reply-To: development@drupal.org Subject: Re: [development] Temporary form data storage ... and avoiding validation Hmm, to me that sounds like a good use of $_SESSION for storage (as in the cookie), with the advantage that it would persist across site visits, and it only belongs to that user. Nancy ________________________________ From: Jeff Greenberg <jeff@ayendesigns.com> To: development@drupal.org Sent: Tue, August 10, 2010 10:12:49 PM Subject: [development] Temporary form data storage ... and avoiding validation I'm using a module-generated form in a mode like a shopping cart, where the user can add data to it, go to other pages, and come back to it, and the data persists. At first I wasn't submitting the data until it was time to complete the process, and so, to persist the data, I was using variable_get/set because without the form being submitted, nothing was being persisted in form_state. However, I've since switched to each of the buttons (return to other pages, update form, submit) causing a submit, with varying logic based on which button was clicked. I discovered (duh!) that variable_set/get was a poor idea, because two users online at the same time end up would get each other's persisted data on the form. So, two questions. Is form_state going to persist the user data for me between form loads, or is there a better method? And I've run into an interesting problem in that the portion of the form with required fields (name, etc) doesn't need to be filled in until the user wants to submit, but of course, that ends up throwing an error when the form is 'submitted' due to one of the other buttons being clicked. Is there a way to have those buttons cause a submit, but bypass validation?