[development] tricky drupal_execute() / hook_form_alter() question

[Karen Stevenson]

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 at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20110730/3494763f/attachment.html