Question: What are the properties that are essential to be defined in the entity passed to
field_attach_update() for the function to update the appropriate fields (and not silently do nothing)?
This is not detailed in the field_attach_update API page and, in articles I can find written about it, it seems that what I have defined above (ID, bundle, field data to update) should be enough.
Context: I'm using
field_attach_update(); to keep some fields on seperate entities in sync with each other, using code like this:
// Load entity, get entity type data data... $entity = array_pop(entity_load($entity_type, array($entity_id))); $entity_info = entity_get_info($entity_type); $id_key = $entity_info['entity keys']['id']; $bundle_key = $endpoint_info['entity keys']['bundle']; // Do stuff with the entity, modify field_some_field do_stuff($entity); // Build stripped down object containing only essential data $lightweight_entity = new stdClass(); $lightweight_entity->$id_key = $entity->$id_key; $lightweight_entity->$bundle_key = $entity->$bundle_key; $lightweight_entity->field_some_field = array( 'some_key' => 'some_data' 'another_key' => 'more_data' ); // Save it field_attach_update( $entity_type, $lightweight_entity );
This did work fine, but has recently (since updating to Drupal 7.14 I believe) been silently failing. No errors, nothing in logs - but no updates to the fields within Drupal and no changes to the field_data_field_some_field in the database. It seems like field_attach_update() isn't so much failing, as judging that it doesn't have any work to do. My theory is, that something is missing from the $lightweight_entity object, causing field_attach_update() to dismiss it as not a match or not a change.
(I'm piping in an entity object that is as simple as possible, partly because this sync function needs to run often and on many entity types, and partly because I have found that sending the whole original modified $entity object to field_attach_update() can result in PDO database fatal errors due to issues like this one, so simplicity is key. I'm using field_attach_update because it's syncing fields rather than updating the entity - new revisions data doesn't make sense in this specific context - from a user's perspective, the content hasn't been revised, and reverting the sync to become out of sync wouldn't make sense)