Tried to use this code piece in an install profile I'm building:

  $form['l10n_client_wrapper']['l10n_share_wrapper']['l10n_client_key'] = array(
    '#type' => 'textfield',
    '#title' => st('Your personal key on localize.drupal.org'),
    '#description' => st('Each user account on the site should have their own localize.drupal.org key set up so the remote submission can be attributed properly. To get your key go to !server-link.', array('!server-link' => l($server_link, $server_link))),
    '#states' => array(
      'visible' => array(
         'input[name="l10n_client_sharing"]' => array('checked' => TRUE),
      ),
      'required' => array(
         'input[name="l10n_client_sharing"]' => array('checked' => TRUE),
      )
    ),
  );

Visible works like a charm. However, required adds the form-required class on the form label itself, making the whole form label red all over. In practice Drupal just uses this class on a span which has * in it. So I think this should in fact add a star with that class and remove a star with that respectively instead of this code that we have now there.

  $(document).bind('state:required', function(e) {
    if (e.trigger) {
      $(e.target).closest('.form-item, .form-submit, .form-wrapper')[e.value ? 'addClass' : 'removeClass']('form-required');
    }
  });
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Gábor Hojtsy’s picture

Ups, in fact it puts the class on the .form-item, so all the children got to be red. The only thing stopping them is that the text input field and then the description of the form item all have specific colors in the CSS. If they would not have, all would be red.

Gábor Hojtsy’s picture

Status: Active » Needs review
FileSize
815 bytes

Suggested patch adds a star with the right class and removes it respectively. Although I don't think this makes any sense for submit buttons, so removed that item.

Gábor Hojtsy’s picture

FileSize
818 bytes

Ups, tag mismatch with the span.

effulgentsia’s picture

subscribe

pwolanin’s picture

Looks good and works.

james.elliott’s picture

Status: Needs review » Reviewed & tested by the community

This also brings the state change inline with how a required field is themed.

joelstein’s picture

The patch in #3 looks and works great for me.

ikpoe’s picture

Status: Reviewed & tested by the community » Needs work

patch from #3: The theme with asterisk is working fine, but the javascript validation is not working. There is no error warning if I leave the input (I tested using textfield) blank. It should be an error warning if I leave the input blank, because it is required field.

Gábor Hojtsy’s picture

Status: Needs work » Reviewed & tested by the community

No, it is not going to be required on the server side, and we should be consistent with the validation. This is just an indication that we'd like the user to fill it in. If it is an issue that it is not validated as required, we should remove this feature entirely as it does not make sense. Looking for committer feedback.

dawehner’s picture

Version: 7.x-dev » 8.x-dev
Issue tags: +Needs backport to D7
Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to 7.x and 8.x. Thanks!

aspilicious’s picture

Issue tags: -Needs backport to D7

untagging

Status: Fixed » Closed (fixed)

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

alexverb’s picture

Status: Closed (fixed) » Active
FileSize
209.91 KB

On a multiple checkboxes element it puts an asterix after the main label and each checkbox label. Is this the wanted behaviour? I would think it should only append on the main label.

See attachement.

alexverb’s picture

Appending the asterix to the first-child only seems to fix it. See patch

alexverb’s picture

Status: Active » Needs review

Forgot to update status.

mstrelan’s picture

#15 works for me ... not sure if there are any other associated issues with it. We should probably compare this to the logic used when PHP adds the required asterisk.

almc’s picture

The issue remains with D7.23. For 'required' state when it's activated on the form for a dependent field, multiple red asterisks appear for that required field (particularly if there are other fields on the form with unlimited cardinality and Add new item was clicked for any of them), and 'required' state is not being enforced actually for the dependent field during the form processing. So it seems currently 'required' state doesn't work.

almc’s picture

Also, the patch #15 doesn't apply in D7.23: 'The patch cannot be applied in the selected context'

deetergp’s picture

Issue summary: View changes

I am seeing that same behavior in 7.27.

deetergp’s picture

I rerolled the patch from #15 so that it applies in Drupal 7.27. This patch only addresses the "*" appearing on the first child. Does not resolve the issue where the items in question are not actually required, in spite of being flagged as such.

Status: Needs review » Needs work

The last submitted patch, 21: drupal-required-states-first-child-1017882-21.patch, failed testing.

deetergp’s picture

Okay, taking a step back, it seems as though this is a Drupal 8 ticket. Looking at the latest version of the current /core/misc/states.js file, it looks like it has been completely revamped and looks nothing like any of the patches posted thus far. At this point, I'm not quite sure what is the right way to go about addressing this in Drupal 7. Any thoughts on the matter would be appreciated.

deetergp’s picture

Version: 8.x-dev » 7.x-dev

I changed the version on this ticket back to 7.x-dev. Drupal 8 deals with this issue in different manner that isn't easily back-ported. Since the patch being passed around pertains to D7, it makes sense for the ticket to also be D7.

deetergp’s picture

Status: Needs work » Needs review
lmeurs’s picture

Patch from #1017882-21: Required elements buggy with #states (manually applied) works as advertised, though as deetergp states: only an element with the asterisk is added, the required attribute is not being toggled on the input element. This seems not so hard to implement, but I worry about nested form fields like ie. the managed file and AdressField fields which exist out of multiple child form fields.

Marked #2298809: Compound form element #states property and required mark as duplicate.

juanjo_vlc’s picture

#21 works for me. Thanks!

heddn’s picture

This is moderately related to #1592688: #states can cause the form "required" mark to appear more than once on the same element, which resolves the issue with duplicate asterisks getting added on subsequent ajax calls on the page.

The underlying issue in the issue summary isn't really addressed in any of the recent patches, so leaving this at needs work.

dtamajon’s picture

Hi,

I have applied the following patch where is solved the 'required' state and duplicity problems, producing the same code as per default:

diff --git a/misc/states.js b/altereco/misc/states.js
index 6d98da8..b4fc7ca 100644
--- a/misc/states.js
+++ b/misc/states.js
@@ -493,10 +493,21 @@
 $(document).bind('state:required', function(e) {
   if (e.trigger) {
     if (e.value) {
-      $(e.target).closest('.form-item, .form-wrapper').find('label').append('<span class="form-required">*</span>');
+      var label = $(e.target).closest('.form-item, .form-wrapper').find('label');
+      var input = $(e.target).closest('.form-item, .form-wrapper').find('input');
+      
+      if (!label.hasClass('required')) {
+        label.append('<span class="form-required" title="' + Drupal.t('This field is required.') + '">*</span>');
+        label.addClass('required');
+      }
+      if (!input.hasClass('required')) {
+        input.addClass('required');
+      }
     }
     else {
       $(e.target).closest('.form-item, .form-wrapper').find('label .form-required').remove();
+      $(e.target).closest('.form-item, .form-wrapper').find('label').removeClass('required');
+      $(e.target).closest('.form-item, .form-wrapper').find('input').removeClass('required');
     }
   }
 });
kenorb’s picture

Status: Needs work » Postponed (maintainer needs more info)
dtamajon’s picture

From my point of view, it "looks like" the problem is solve, but the behavior it not being exactly the same than when the field is sent from the server. I mean, for example, a required field has a tooltip indicating it is "This field is required.", and has some additional attributes.

On the given solution, javascript is not reproducing exactly the same behavior than the field generated from the form.inc. In #29, I tried to reproduce that behavior exactly, so the feeling is the same from whatever the field gets required.

Lukas von Blarer’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)

[ #1592688] solved this issue for me as well. marking this as a duplicate.