Settings wont hold unless...

What versions of CCK and Drupal Core are you using? Are you using the latest development snapshot of viewfield?

Jer

Hi jer,

Replying on the the duplicate thread #373885:
I'm using CCK 6.x-2.1 on the latest Drupal 6.9, Viewfield 6.x-1.x-dev (latest snapshot)

I think I've been having the same problem, and have found the part of the code that is dropping the viewfield in my case.

My specific use case is that I have a viewfield which gets removed for each node it is placed on when I run node_save() on that node in a custom module I'm using.

I stepped through the code and found that the viewfield is deleted when the code hits the viewfield_field() function during the content 'presave' operation.

The code that actually does the removing is the following.

      // get items out of fieldset
      foreach ($items as $delta => $item) {
        if (!empty($item['fieldset']) &&
          // the view name may be empty if we are not ovverriding the default values
          (!empty($item['fieldset'][$field_key_vname]) ||
          (isset($item['fieldset']['override_default']) && !$item['fieldset']['override_default']))) {
          $items[$delta] = $field['super_default'] && !$item['fieldset']['override_default'] ? $super_defaults : $item['fieldset'];
        }
        else {
          // remove empty views
          unset($items[$delta]);
        }

where $item is each viewfield on the node object. The problem in my case is that there is no ['fieldset'] key on the $item array so it always unsets $items[$delta]. Here's a quick dprint of what the item array actually is.

$item = array
(
[vname] => assets|block_1
[vargs] => %nid
[default] => 1
[actual_vargs] => Array
(
[0] => 93
)
)

I have 'fixed' the problem in my case by removing the references to the fieldset key, so eg. $item['fieldset'][$field_key_vname] becomes $item[$field_key_vname] which does exist in the $item I have.

I have no idea if this will break other use cases, it seems that there used to be a fieldset surrounding the viewfield item, but this has been removed for some reason?

I need to do a bit more testing to see if these changes fix the issue for me, but I'll post a patch if/when it seems to be working .

A bit more investigation.. The item seems to have the fieldset key when it the node is saved from a form submit (on the node edit page eg) but not when it is saved from a node_save() function (as in my custom module, or I would assume the content updater on the content list page /admin/content/node).

So my idea of just removing the fieldsets above loses the viewfield when you submit from the node/edit page. A very quick and dirty hack is to move the item's keys into a fieldset key if one doesn't exist.

        //hack to make sure each item is within a fieldset (happens when presave is called from node_save)
        if(!isset($item['fieldset'])) {
          $item_fixed['fieldset'] = $item;
          $item = $item_fixed;
        }

which goes just after foreach ($items as $delta => $item) in viewfield_field() function.

So the block of code now looks like

      // get items out of fieldset
      foreach ($items as $delta => $item) {
        
        //hack to make sure each item is within a fieldset (happens when presave is called from node_save)
        if(!isset($item['fieldset'])) {
          $item_fixed['fieldset'] = $item;
          $item = $item_fixed;
        }
        
        if (!empty($item['fieldset']) &&
          // the view name may be empty if we are not ovverriding the default values
          (!empty($item['fieldset'][$field_key_vname]) ||
          (isset($item['fieldset']['override_default']) && !$item['fieldset']['override_default']))) {
          $items[$delta] = $field['super_default'] && !$item['fieldset']['override_default'] ? $super_defaults : $item['fieldset'];
        }
        else {
          // remove empty views
          unset($items[$delta]);
        }
      }

I don't think this is worthy of a patch, but hopefully it can give someone who knows the code better a clue how to fix it properly.

I've got some more testing to do with default values not being set, which may or may not be a different issue, and is just as likely to be me not knowing how to set the module up properly(though I have used it before).

Duplicate of issue 386430.

Just committed a fix for this that removes the fieldset entirely, it's kind of superfluous and was just causing issues.

Jer