Viewfield Force Default doesn't work

The force default is a little bit tricky to set up, but it does not seem to be broken (I use almost only this mode with no trouble at all).
Here's how:

1. Open the configuration page of your viewfield
2. Check Force default option
3. [Optional] Check the Allowed views options you are interested in
4. [Important!] Check the Use a common default value for all nodes if the user does not override it on the node form option. If you don't check this one you are telling viewfield to force the default value, but you are providing no default value as the following settings will be ignored.
5. Set up the default values (view and arguments)

That's all

I have the same problem in D7, however the option to "Use a common default value for all nodes if the user does not override it on the node form" does not exist.

If I dpm($element) in viewfield_select_process() the #default_value is NULL on the node edit form, but it is correct on the field configuration form.

In 7.x-2.x, there is an option on the field configuration form called "Always use default value" but there is a bug in using the default values when the option is checked. Please try this patch with that option turned on after assigning appropriate default values. If you created any nodes before checking the option, those nodes will have to be re-saved for the default values to be used.

Champion. Works a treat.

sub

Committed as http://drupalcode.org/project/viewfield.git/commit/2152622.

After installing 6.x-1.1, "Always use default value" does not work.
If this option is selected a NULL value is provided in the SQL updating clause
I tried modifying the "Use a common default value for all nodes if the user does not override it on the node form" option, but always the NULL value is provided.
I supose that no default value is returned when this option is selected.
The option worked in the previous version.
Excuse-me, I am talking about viewfield for drupal 6.22

so i guess this is needs-backport.
@jparets, did you try 1.x-dev?

@jparets Very little has changed in the 6.x-1.x branch since I started maintaining a couple of months ago. There have been only a couple of bug fixes not related to this area, so it is hard for me to understand how it was working in the past. The unusual handling of default values in that branch lead us to create the 6.x-2.x version, which handles them better. Future bug fixes are likely to go into 6.x-2.x only. Would you try the 6.x-2.x-dev version and see if that fixes your problem?

Edit: simultaneous posting removed D6 backport tag.

The problem was not exactly fixed, but the behavior of default value is now more consistent with other drupal fields. I had to change the values in the database, because NULL values were the default in version 1.
I observed that now the default is stored in the database as the name of the view. I hope that this behavior will not be changed in the future, because one of the main problems in different versions of viewfield was the aleatory decisions about the default values. ( I tested/suffered more than ten versions in the two last years)
I agree with the current decision because it allows recursivity and implies an stable behavior of viewfields.
Thank you for the excellent work.

@jparets I'm glad this helped.

Dear @keithm , I detected a problem that probably should be fixed.
The default value overrides the current value when editing the node. This occurs also when "Always use default" is not set.
This is a little problem when"Always use default" is on. But a big one when you have a node type whose Viewfields use different views. For me is a big problem because I use a node type with a viewfield field which can contain a view from more than 100.
The same occurs when a viewfield field is optional and you select "none". When edited, the default value overrides the "none" value.
In addition this is not the usual behavior for default values in other field types.
Thank you again and will be a pleasure to test any improvement.

@jparets Confirming this. Thanks for your report. Please try this patch and try to break it! Thanks for your help.

No the patch is still not working with default value :-(

I think what we want is something like this. Not sure about the widget's default_value array structure though, needs to be double-checked.

@fiftyz What specific operation is failing for you? We need steps to reproduce your specific problem.

@sun Is the intention to move the logic to the widget form as a matter of correct placement or is there a behavioral benefit to placing it there? I'm not seeing how you're handling the case when force_default is TRUE.

It merely looked cleaner to me to prepare the default value in the widget form hook, as we're setting the default value there already. However, no idea whether this has any pitfalls or other implications (I hope not).

I don't think we need any further/extra care for force_default though. I see this flow:

1. If we have a stored value, we use it, regardless of anything else.
2. If we don't have a stored value but have a default value, we use it.
3. Now that we have the proper default value, the select processing always uses it.
4. Lastly, if force_default is TRUE, #access to the select is denied, and Form API automatically takes over the default value as #value.

@keithm the view with argument Contextual filters "Content: Nid" and default argument in field settings [node:nid] is not displayed.

Some comments:
1. If we have a stored value, we use it, regardless of anything else. --> No problem
2. If we don't have a stored value but have a default value, we use it. --> If "none" is selected in an optional viewfield, what is the stored value? If the value is NULL you should detect if the operation is create or edit.

3. Now that we have the proper default value, the select processing always uses it.
4. Lastly, if force_default is TRUE, #access to the select is denied, and Form API automatically takes over the default value as #value.

If you select "none", then "none" (NULL|''|0) is stored as field value. Well, at least, that's how it's supposed to be. ;)

So, for optional viewfields you have to detect the type of operation. In creating the default value should be used, but in editing the NULL value should be respected.

@sun I expect force_default == TRUE to be the most frequent usage since it provides a centralized value for all entities in a type without having to set values for each viewfield individually. I think it is this behavior that the old super_defaults was intended to address, and also very possibly accounts for the popularity of the views_attach module.

Based on this thinking, my processing model is slightly different than the one you articulated in #19:

1. If we're editing an entity and force_default is set, use the default value (even if NULL) regardless of any previously stored value.
2. Otherwise, if we have a stored value, use it.
3. Otherwise use the default value.

Case 1 handles the situation where the administrator has assigned values but later changes his mind and wants defaults used everywhere. Otherwise force_defaults would have no effect in this situation.

#24 works for me, too

Another attempt along the lines of #24.

+++ viewfield.module
@@ -171,7 +171,7 @@ function viewfield_select_process($element, $edit, $form_state, $form) {
-    '#default_value' => isset($field['widget']['default_value']) ? $field['widget']['default_value'][$element['#delta']]['vname'] : NULL,
+    '#default_value' => isset($element['#value']['vname']) && !$field['widget']['force_default'] ? $element['#value']['vname'] : $field['widget']['default_value'][$element['#delta']]['vname'],

The field value should actually be contained in #default_value, not #value... (?) This baffled me most when I looked at the code.

Overall, I think I'd prefer to tweak the patch in #17 accordingly, since this ternary condition is extremely long and confusing. However, leaving to you to decide.

Actually I like the widget form approach in #17 better. Rerolled #26.

That looks ready to fly for me. Didn't test it though.

@sun After some more checking, and doing some experiments with the D7 form API, I've concluded that the field hiding process associated with the force_default operation is fundamentally broken.

In viewfield_select_process(), the two lines

  '#access' => $is_field_settings_form || !$field['widget']['force_default'],

were being used to hide the viewfield input fields when force_default was set. That's fine but there was also an expectation that the default values would be used to replace the stored values when the entity edit form was submitted, even when the fields had #access == FALSE. Somehow that approach worked in D6 but it doesn't work at all in D7.

I think it's better to use #value fields when there is no expectation of user interaction. Would you check out this patch please?

the default values would be used to replace the stored values when the entity edit form was submitted, even when the fields had #access == FALSE. Somehow that approach worked in D6 but it doesn't work at all in D7.

Form API still takes over #default_value if #access is FALSE. The idea, expectation, and code is valid for D6 and D7.

I'm not sure why you think it wouldn't work. Can you clarify?

Yes, you're correct. Today I verified that #28 maps to D7 just fine. Yesterday I was struggling a bit with the #access documentation and I suspect I had some kind of cache problem that distorted my results.

Wonderful, so let's go with #28.

Committed in http://drupalcode.org/project/viewfield.git/commit/5f3e9cc and http://drupalcode.org/project/viewfield.git/commit/5144c4f.

There should be a way to update all records using the appropriate settings. Doing it manually for a bunch of sites isn't fun (especially with clients breathing down your neck because a bunch of views aren't showing).

@antiorario If you've checked "Always use default value", you should only have to save the node to use the default values. You can use vbo to help you save a set of nodes.

@keithm I tried that, but the data is still not saved unless I save every single node via its edit form. (Of course I did it manually via MySQL.)

@antiorario: I've added a new task #1207552: Use instance defaults when "Always use default value" is checked to address this.