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)