The node_save() function is far easier to use and much more reliable. For node_save() you only need to know how to construct the node and every field is more or less the same: $node->FIELD_NAME[0]['value'], and 'value' is the value that is stored in the database (the actual column names vary from one field to another, so you still need to know what they are). When you use drupal_execute you have to construct the node as it has been re-organized by all the field widgets, which requires understanding exactly what each widget looks like and what values it expects where. Some widgets (like optionwidgets and date widgets) are extremely complex and the data used on the node form looks totally different than the data that ultimately gets stored in the database. So you have to pre-process your data into whatever the widget expects. The biggest problem is a long-running core bug (that may or may not have ever gotten fixed) that kept validation hooks from firing if you do drupal_execute() on multiple nodes in a single pass, as when you are migrating or importing data. That means that any massaging that might be done by the widgets during validation also does not get done and those types of fields are totally broken. Date fields and nodereference fields are two that have created lots of problems. The only thing you lose by using node_save() is that it does not do validation, but the bug means it doesn't get done reliably anyway. It would be far easier to do your own data validation before you import and then do a simple node_save() to store it. Karen On Fri, Jul 29, 2011 at 7:57 PM, Emma Irwin <emma.irwin@gmail.com> wrote:

I've used node_save without having to worry about defaults for irrelevant fields. Worked fine for CCK for me Personally, I think that your alternate solution & function goes too far into a zone of complexity that you'll have more bugs as a result. I would also feel for any developer that comes after you and has to maintain that code :/

Sent from my iPhone

On Jul 29, 2011, at 12:21 PM, "David Cohen" <drupal@dave-cohen.com> wrote:

...

I'm trying import some data from a user's Facebook profile into Drupal. The site in question has a lot of moving parts: Content Profile, CCK, Drupal for Facebook.

I'd like to query facebook for info about the user, then create or update a node with the data. The node contains a lot of fields, and I'm only interested in updating 1 or 2 (or 3 or 4) of them.

My preference is to use drupal_execute() to create/update the profile node. To do this, I have to fill out a $form_state['values'] array. I've tested this and noticed that if I leave out the values for any field in the node, that field will be reset to blank. In other words my code needs to fill out values for all fields. But to do so essentially prevents anyone from adding more fields via CCK. The code would need to be updated for every change to the content type, which is too onerous.

There are posts on drupal.org describing this same problem, and suggesting using node_save() instead of drupal_execute() for this purpose. What do the experts on this list recommend, drupal_execute() or node_save()?

I had the thought that during hook_form_alter(), I could scan the form for all #default_values, and use them to populate the $form_state['values']. A function able to do that would, it seems to me, make drupal_execute() much easier to use. That code would have to navigate the entire $form tree (at least all element children). And would have to be smart about where #tree is true in order to get all the #default_values into the right $form_state['values']. Has anyone attempted such a thing?

Thanks in advance, -Dave