Field cardinality is a global field setting, which cannot be changed per field.

However, the force_default field instance setting can only be enabled for non-multiple fields.

Actually, I don't see why this dependency exists at all in the first place. Why not simply replace all $items?

CommentFileSizeAuthor
#3 viewfield.force-default-validate.3.patch1.86 KBsun

Comments

sun’s picture

Also, much more important would be to validate that there is actually a default value... ;)

sun’s picture

Added the missing validation for a default value to #1221440: Bogus default value in field widget

However, I still think the validation on field cardinality is obsolete, since we're replacing the field values upon rendering in the meantime.

sun’s picture

Status: Active » Needs review
StatusFileSize
new1.86 KB
keithm’s picture

Status: Needs review » Needs work
+++ b/viewfield.module
@@ -47,24 +49,18 @@ function viewfield_field_instance_settings_form($field, $instance) {
-    if ($field['cardinality'] > 1 || $field['cardinality'] == FIELD_CARDINALITY_UNLIMITED) {
-      form_error($element['force_default'], t('%title does not support multiple field values.', array(
-        '%title' => $element['force_default']['#title'],
-      )));
-    }

The problem in removing this is that force_default == TRUE really only makes sense to the user for a single value. If we allow multiple values but allow force_default == TRUE, we're "allowing" something that can never happen; the field edit elements are hidden and the user can't add any more values anyway.

+++ b/viewfield.module
@@ -47,24 +49,18 @@ function viewfield_field_instance_settings_form($field, $instance) {
     if (empty($widget_values[0]['vname'])) {
       form_error($element['force_default'], t('%title requires a default value.', array(
         '%title' => $element['force_default']['#title'],

This looks good.

sun’s picture

Status: Needs work » Needs review

The problem in removing this is that force_default == TRUE really only makes sense to the user for a single value. If we allow multiple values but allow force_default == TRUE, we're "allowing" something that can never happen; the field edit elements are hidden and the user can't add any more values anyway.

well, this is partially related to #1230534: allowed_views should be an instance setting, not a field setting -- depending on the field storage engine being used, the field cardinality may be set in stone after initial creation of a field, and cannot be re-configured. That is, because an optimized field storage engine like http://drupal.org/project/pbs could rightfully decide to "join" the field values of multiple fields into a single table, as long as they are not multiple (and not translatable) -- basically what CCK was doing by default in D6.

However, the force_default option shouldn't have any impact on the field's schema, nor its values. I think a site admin should be able to enable and disable it at any time -- the only impact is that the field's default value is directly used for rendering.

And since #1207552: Use instance defaults when "Always use default value" is checked, we are no longer really fiddling with the actual field values if force_default is enabled. On view/render, all fields values are simply replaced with the default value of the field widget.

Lastly, note that I learned today that field_ui_default_value_widget() itself does not support multiple default values for a field widget, so as long as core doesn't support it, we can't support it either.

Am I overlooking something?

keithm’s picture

Status: Needs review » Reviewed & tested by the community

There is a patch in the works for #1230534: allowed_views should be an instance setting, not a field setting so that's not an issue any more.

I ran some tests with your patch and everything behaves itself better than I had expected. Turning on force_default nondestructively replaces the field contents with the single default, even when there is a saved multiple-valued field. Turning it off again of course restores the saved values.

Looks good to go.

keithm’s picture

Status: Reviewed & tested by the community » Fixed

Automatically closed -- issue fixed for 2 weeks with no activity.