Contrib.social

Value checked for requireness and set into node when field is disabled/hidden

Open on Drupal.org →
Created on 27 July 2018, over 6 years ago
Updated 19 February 2024, about 1 year ago

We have a term reference field in one of our contents. In some cases this field is hidden (#access set to FALSE) or disabled (#disabled set to TRUE). This is i.e. the case when using Jammer module or in our case some custom code.

When using Term Reference Tree as widget, editing a node with field hidden/disabled leads to:
- error message about missing required field if field is required
- field value in edited node overwrited with an empty value if field is not required

Using 'select list' or 'check boxes/radio buttons' as associated widget don't lead to this behavior: no 'missing required field' is printed even if field is required, and value is let unchanged after validation.

As far as I can see in function _term_reference_tree_widget_validate() from file term_reference_tree.widget.inc no check are performed against #access nor #disabled.

I changed a little bit the code:

-  if ($element['#required'] && empty($value)) {
+  // if element is hidden (#access is FALSE) or disabled do not check for value
+  $validate = TRUE;
+  if (!$element['#access'] || (isset($element['#disabled']) && $element['#disabled'])) {
+    $validate = FALSE;
+  }
+  if ($element['#required'] && empty($value) && $validate) {

This prevents 'missing required field' when field is hidden/disabled.
But it don't prevent value to be overwritten by 'empty'.
I tried to perform the form_set_value() only if $validate but it didn't changed anything, so I added code to remove field value from $form_state and it finally works as (I) expected:

-  form_set_value($element, $value, $form_state);
+  // set value only if needed
+  if ($validate) {
+    form_set_value($element, $value, $form_state);
+  } else {
+    // needed: the empty value is present and node is modified without that (why?)
+    unset($form_state['input'][$element['#field_name']]);
+    unset($form_state['values'][$element['#field_name']]);
+  }

Now I get the same behavior than for other fields or for that field with an other widget.
I did not attached a patch because I don't understand well why the second part is needed, so I prefer wait for feedback and better knowledge.

Regards.

🐛 Bug report
Status

Needs review

Version

2.0

Component

Code

Created by

🇫🇷France Yannick Perret

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Open on Drupal.org →
    Core: 7.x + Environment: PHP 5.6 & MySQL 5.5
    last update about 1 year ago
    Waiting for branch to pass
  • Comment about 1 year ago →
    🇷🇴Romania MirceaP

    Encountered the same issue while using version 2.0.x.
    When trying to save a node that previously didn't use Term Reference Tree as widget, we get an error and can not save the node (the parent terms are added and on the translations this field is hidden (#access set to FALSE)).

    Created a patch to check against #access set to FALSE.

  • Comment about 1 year ago →
    🇷🇴Romania MirceaP

    Added an isset().

  • Comment about 1 year ago →
    🇷🇴Romania MirceaP

    Fixed typo.

  • First commit to issue fork.
  • Merge request !27Prevented validation if user is not allowed to access element → (Open) created by Denist3r
  • Comment 12 months ago →
    Denist3r

    Created MR.
    Tested on my own project, works fine for me

  • First commit to issue fork.
  • Comment about 2 months ago →
    🇧🇪Belgium andreasderijcke Antwerpen / Gent

    I've expanded the patch, as the previous version was did non suffice on D10.4 when the widget is hidden on entity translation forms due to the field being not translatable.

    Core field constraints on the field are still fired, thus blocking creation of the entity translation. In the process, access check on the field returns 'allowed' causing the field to be taken into account for validation, even though it should not.

    Have not found a solution to prevent this from happening, but discovered along the way that when the widget is hidden, the field submission values contain the options and current value, which cause the field constraint validation to fail.
    By massaging the field submission values, or cleaning, this can be prevented and translation submission proceed.

    This solution is added to the MR, including note that it is only a workaround until a better/real fix can be found.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024