Further to Generically detecting changed fields in a custom form prior to saving a node, where we're trying to compare the field data in a ready-to-be-saved node with the field data in the original node:

At what point in the process of submitting a form, validating input, running submit callbacks and saving an entity, can you assume the field data will not be modified by module code?

Or, to put this question another way: If a field's array in an unsaved node object contains extra keys which are used for processing the field, but are not saved as part of the field's database schema, at what point can those extra keys be considered "done with"?

What I'm trying to figure out is, in that other question some suggestions involve ignoring field array keys in the unsaved node, which are not present in the original node, but this would seem to be unsafe logic if those extra keys might be used to alter the data being committed to the database when the node is saved.

To illustrate, take this imaginary field array:

Original node object:

$original_node->field_imaginary['und'][0] = array(
  'schema_key_1' => 'some value',
  'schema_key_2' => 'some other value',

Unsaved node object:

$unsaved_node->field_imaginary['und'][0] = array(
  'schema_key_1' => 'some value',
  'schema_key_2' => 'some modified value',
  'processing_key' => 'some value used to modify schema_key_2',

Prior to issuing a node_save($unsaved_node), are we able to assume at any particular stage of the form submission that 'processing_key' has already altered the value of 'schema_key_2' and will not alter it further before it gets committed to the database?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.