Hi,

When a CCK field implements the 'validate' operation of hook_field_settings() (or hook_widget_settings()) it may issue form_set_error() to warn the user, etc.

In this case, the message "The default value is invalid" is also displayed to the user. It happens because form_get_errors() is checked in content_field_edit_form_validate() when validating the $default_value, but that could be correct and the form errors could be related to field or widget settings.

if (form_get_errors()) {  // <--- this check is the cause!
  if (trim($form_values['default_value_php'])) {
    form_set_error('default_value_php', t("The PHP code for 'default value' returned @value, which is invalid.", array(
      '@value' => print_r($default_value, TRUE))));
  }
  else {
    form_set_error('default_value', t('The default value is invalid.'));
  }
}
CommentFileSizeAuthor
#1 cck_defauly_value_errors-331794-1.patch1.23 KByched

Comments

yched’s picture

yched commented
Status: Active » Needs review
StatusFileSize
new cck_defauly_value_errors-331794-1.patch1.23 KB

Does this make things better ?

markus_petrux’s picture

markus_petrux commented
Status: Needs review » Reviewed & tested by the community

Works here.

The message "The default value is invalid" appears only when the default value is really flagged as invalid by a field validatation routine. But that routine has already used form_set_error(), so there are 2 messages displayed. For example, if you create a CCK number field of type integer with max=99, then you set default value for this field to 100, you get "myint: the value may be no larger than 99." and "The default value is invalid". The former explains the reason, the later helps to focus user attention to the field in the form that is invalid. It may sound redundant information because there are 2 messages trying to describe the same error. If that's "by dessign", then it's perfect to me. :)

yched’s picture

yched commented

The additional "The default value is invalid" was here in D5 because the original message issued for the default value by hook_field('validate') does not flag the error on the right form element, because it assumed a node form structure.
If we didn't have this additional message, the 'default value' input wouldn't get its red "error" border, making it really hard for the user to understand where the error lies.

Now, it might very well be (didn't test) that the '#error_field' entry that 'core' widgets add in D6 does in fact allow hook_field('validate') to flag the right form element. Problem is this '#error_field' is more of a non-formalized trick, and there might be contrib field modules that do not use it,

markus_petrux’s picture

markus_petrux commented

The field/widget validation routine doesn't know if it is validating a "default value" in the field settings form, so its own generated message will say nothing about a "default value".

While the "The default value is invalid" message might be redundant, it does not confuse the user... so there seems to be no problem if it remains like that until '#error_field' is normalized in some way.

markus_petrux’s picture

markus_petrux commented

I just noticed a possible inconsistency in the way CCK validates fields, so I opened a separate issue, as it is not exactly the same thing that we're talking about here, I think.

#332176: Best practices for implementing validation routines for CCK fields?

yched’s picture

yched commented
Status: Reviewed & tested by the community » Fixed

Committed the patch in #1. Thanks.

Status: Fixed » Closed (fixed)

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