Setting a cck field as autocomplete and using it as a node reference causes form validate hook fail, on line 684 $elements['#title'] is missing, so the output of the validation error doesnt shows up the cck field label.
BTW, this does not happens when using any other field type such as select.

Comments

markus_petrux’s picture

Status: Active » Postponed (maintainer needs more info)

Re: "on line 684 $elements['#title'] is missing"

Which file? version?

Also, autocomplete widget for node reference fields seem to work on many sites, so it could be something related to your particular installation. Could it be related to another module? Steps to reproduce your issue?

andres.torres’s picture

CCK version 6.x-2.6, validate hook failing on form.in line 684 $elements['#title'] is empty, so when validating an autocomlpete field that has been created as a nodereference, the output is being shown up as
form_error($elements, $t('!name field is required.', array('!name' => $elements['#title']))); without !name

andres.torres’s picture

Status: Postponed (maintainer needs more info) » Active
alan d.’s picture

Title: Error validating autocomplete field » Missing label in error messages when validating multiple value fields that are rendered by core (CONTENT_HANDLE_CORE)

This appears to applies to all multiple value fields that are handled by core. I was able to replicate using a multiple value integer field, both as unlimited and limited to xx values.

The single autocomplete fields work fine as the #title attribute is not removed when theming single values.

alan d.’s picture

Version: 6.x-2.6 » 6.x-2.x-dev
Component: nodereference.module » content.module
Status: Active » Needs work
StatusFileSize
new2.69 KB

Right, I'm no CCK expert, so I'm setting this straight to "needs work", but this approach works on the site we are developing.

During the core CCK content_field_form(), I've added a custom validator to the main element if required, and removed the #required attribute from the multiple value delta 0 field. And for lack of a better place to put the validator (this must be in the included path) I added it to the main content.module. This filters the form_state items and if empty, triggers the error.

The error message labels appear, and ANY of the fields can have values (not just relying on delta 0). The main negative, apart from it has had very limited testing, is that the entire collection of elements are tagged with the error class, where it really only needs to have the first element selected.

andermt’s picture

Version: 6.x-2.x-dev » 6.x-2.6
Status: Needs work » Needs review
StatusFileSize
new2.2 KB

Here is my alternative patch made the same way as filefield module validation.

alan d.’s picture

Title: Missing label in error messages when validating multiple value fields that are rendered by core (CONTENT_HANDLE_CORE) » Removing the WTF from CCK multiple value required validation.
Version: 6.x-2.6 » 6.x-2.x-dev
Priority: Normal » Major

@andermt This is a global issue and it is not limited to the node reference module. For example, user reference is another example of a field that uses CONTENT_HANDLE_CORE setting for multiple values. The approach is practically the same though!

I've renamed the issue as it addresses two separate issues:

Missing label in error messages when validating multiple value fields that are rendered by core.

So the non-descriptive, "field is required" is rendered as "LABEL field is required".

The #required attribute only checks delta 0.

The custom validation allows any delta value to fulfill the requirement of the field element.

I considered a #pre_render for the title display, similar to Drupal 7, but this could lead to issues with other modules overriding the attribute. This would also need to be copied down the tree to the actual rendered element, adding some additional complication to the patch.

Love to see this get in, even as Drupal 7 is nearing the start if its' production life....

alan d.’s picture

StatusFileSize
new3.15 KB

An updated patch

alan d.’s picture

StatusFileSize
new3.15 KB

Looks like a bug in the attachment, this time without the hash