Core of the question

I have a form that might throw a validation error based on the values in other entities on the site. If a user fills out an entity form and hits submit, they will see validation errors that tell them another entity is in conflict.

I would like to provide the user with an option to update the other entity on the site to clear up the validation issue. The problem with that, however, is that the user would have to navigate away from the form throwing the validation errors, and they'd then lose their input.

I would like to fix this up without using Ajax, because I think that Ajax will complicate the UI and I'd like to keep javascript out of the equation for now.

Is there a standard non-hackish way to use $form and $form_state in a way that will allow me to just grab the user input and stash it into the SESSION or something so once the user fills out a secondary form, they go back to the original form and their originally input values are still there?

The desired user experience

  1. {Entity A} exists with field data on the site that will cause a validation error on {New Entity B} add form.
  2. User enters field input into {New Entity B} add form, and hits submit.
  3. My custom {New Entity B} form validation callback checks {Entity A} and discovers a problem that requires {Entity A} to be edited before {New Entity B} can be saved.
  4. User does ??? and {New Entity B} $form and {New Entity B} $form_state are "saved for later" while user goes to {Entity A} edit form.
  5. User updates and saves {Entity A} and is redirected back to {New Entity B} add form. {New Entity B} add form has the same input values the user already entered, because they were retrieved from a "stashed" {New Entity B} $form and {New Entity B} $form_state.

Is this possible? How?


Caveat about uncertainty of form fields

The exact fields on the entity form are unknown. I want to apply this logic to numerous entity forms, which means I don't know which fields are there in my validation callbacks. This is why I'm looking to stash $form and $form_state in their entirety. I don't want to get involved with individual field values.

  • It sounds more like the problem you need to solve is the functional dependency, not the work-around. Without all the developer-speak, can you give us a real life example of this?
    – Triskelion
    Commented Mar 12, 2013 at 16:23
  • I'm building a scheduling module that allows various entities to be placed onto a schedule. I don't want 2 different users putting the same entity on their schedule at the same time. If that happens, I want to provide steps to resolve the scheduling conflict.
    – tmsimont
    Commented Mar 12, 2013 at 16:27
  • It sounds like these 'entities' are 'Tasks'. If each task is discrete, and can only be claimed once, then providing the user with a list of unclaimed tasks would prevent the problem.
    – Triskelion
    Commented Mar 12, 2013 at 16:38
  • The problem is that I want to provide an option to override another referrer's claim (or request override, request sharing, all which require filling out another form). Also, i don't want to build a new UI to choose from a list of unclaimed time ranges. the time ranges are not really even list-able, as they are not limited in definition (could be 3pm to 4pm or could be mon-thurs, etc)
    – tmsimont
    Commented Mar 12, 2013 at 16:51
  • And by "entities" I do mean Drupal Entity's -- I'm using EntityAPI and Entity Reference fields. It could be an "instructor" or a "location" or any reference-able Drupal Entity type that has a date field.
    – tmsimont
    Commented Mar 12, 2013 at 16:52

1 Answer 1


I just looked at your Entity Availability project page, and it looks interesting. You are facing the classic Temporal dependency problem of all scheduling systems (eg Departure time depends on Arrival time). This is the one data dependency which cannot be resolved statically.

The Webforms module uses $_SESSION to store information for multi-page forms for the anonymous user. In the case of the Webform module, the submission ID ($sid) is saved the $_SESSION, and the $form_state is saved in and retrieved from the database, however I see no problem with using $_SESSION to maintain a working copy of the $form_state object ($_SESSION['form_id'] = $form_state;). However, I would suggest you look at a cache_entity_availability table keyed on, perhaps, form_id and uid, just in case the session expires (servers down, network problem etc).

Thanks for the additional info, and good luck with the project.

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.