[D7] Field Conditional State

Hello, and thank you for applying for a CVS account.

As per requirements, the motivation needs to include more than two sentences (possibly a paragraph) that describe the module features (the description should make clear what the module features are without to look at the code), and a comparison with the existing solutions.

I will report here a little checklist:

• The code needs to follow the coding standards; check in particular the format used for the control structures, and the name given to PHP variables, Drupal persistent variables, functions defined from the module.
• Files available from third-party sites should not be included within the module/theme. This is particularly true for files that are not licensed under GPL License v2, but it is also true for files that are licensed under the same license used by Drupal.
• The license file should not be included as well; the packaging script already include that file. In any cases, the code for modules/themes committed in drupal.org repository needs to be released under the same license used by Drupal; any compatible license is not allowed.
• Check the code passes the Coder validation.

great idea, when will it be official available?
Seems like the conditional field module maintainer won't bring an drupal 7 version out in the near future, but i need this functionallity so urgently..

are u going to publish it as module in d.org?

@peem83 - can you please consider added AND/OR functionality into your module.
It seems like this functionality will not make it into conditional fields anytime soon #719068: show if ANY of controller fields are selected (OR vs AND controllers)
But it allows great flexibility in usage.

AND = all designated choices must be selected for the controlled field to show

OR = any of the designated choices may be selected for the controlled field to show

Nice one!!! field_conditional_state awesome work!

Well done @peem83. field_conditional_state looks like a realy nice module.

Thanks peem83 will test it out now. Need conditional fields for D7 but directed here.

Jeez! Great work man, really...

Great work peem83!!

I'm also looking for the AND and OR functionality for controller fields, where AND would mean fields A and B needs to be selected for field C to show, and OR functionality where A or B can be selected for field C to show.

I'm really looking forward to following your work and can't wait for your module to be accepted as a contrib module.

Would you happen to be considering back porting your module to D6?
It seems your module will be far advanced compared to conditional fields module very soon and I feel that it will be a good 6months to a year until big sites with many contrib modules can upgrade with full functionality. If you can support a D6 version it would be truly appreciated!!

+1

D6 must die :D
now is D7 primary point!

+1

Ok, thanks for the information!

I found this as well for D7 #735528: FAPI #states: Fix conditionals to allow OR and XOR constructions

Is it possible for you to make this work with fieldgroups as well? Make it so that an entire fieldgroup & alll fields in them could be affected by conditionals. If you can, that would be excellent.
http://drupal.org/project/fieldgroup

+1 good idea

Awesome work peem83!

Works great on my site. Looking forward to you getting a module landing page.

+1 to #24 for fieldgroup. The link is missing a underscore though so here's the link: http://drupal.org/project/field_group

Subscribe!

Peem83: Wow....awesome.

I agree with lloydpearsoniv, any way to get this to work with fieldgroups so the entire fieldgroup does not display?

Thanks again in advance for your time and efforts.

I'll try this soon, thanks für your work, peem83 !!

You the man!

Just install new version, try to add condition state and got this error
PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'condition_type' in 'field list': INSERT INTO {field_conditional_state} (field_name, control_field, state, bundle, trigger_values, condition_type) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5); Array ( [:db_insert_placeholder_0] => field_tags [:db_insert_placeholder_1] => field_blog_category [:db_insert_placeholder_2] => invisible [:db_insert_placeholder_3] => article [:db_insert_placeholder_4] => a:5:{i:2;s:1:"2";i:3;s:1:"3";i:6;s:1:"6";i:5;s:1:"5";i:4;s:1:"4";} [:db_insert_placeholder_5] => or ) in function field_conditional_state_settings_form_submit() (line 171 in file /home/vitok/public_html/blog/sites/all/modules/field_conditional_state/field_conditional_state.admin.inc).

I was wondering if the new AND will allow the example: field A will be visible when in field B option 1 and field C option 2 is selected ?
Thank you!

Hi peem83, sorry for my bad english and thanks for your effort in this module.

How about creating a project on github waiting imminent migration from CVS to GIT and its new rules?

I'm new to drupal, but I need this capability.

I've attached two field A and B into 2 differents content_type, my need is to relate this (instances of) fields differently in the two content_type, but I've this error:

You already have this state type between these two fields.

Currently I've patched field_conditional_state for consider also bundle for validation. What do you think?

Subscribe

I'm died ;)

-function field_conditional_state_alter_form($form, $form_state) {die;

I'm died ;)

LOL!

Amazing! works great!!!!!!

Can we somehow get this integrated with hierarchical select?

Edit: I think i may have accidentally added Hierarchial select by adding 'taxonomy_hs', to the field_conditional_state.admin.inc
line 230

Suddenly I can select my Hierarchical select category as my control.

However the conditional item never appears during node creation once I select the defined category.

Any guess when this module gets an landing page?
Is there any disadvantage when using this module before it is "official"?

This module seems very stable, in fact more stable than most of the other official releases. I've already created about 50 conditions on one node type, and its amazing!!!!!!! If it could be integrated with the D7 HS module then it would be a powerful combo.

If I don't have misunderstood is needed to implement hook_field_delete_instance() rather than hook_field_delete_field(), otherwise remove an instance of a field attached to 2 different bundle leave orphans in the database.

we must clear field_conditional_state table when an instance of a field is deleted (if ther'is only one instance is called also hook_field_delete_field(), but for conditional_state isn't important).

I've also a little patch for coding standard

After updating to #47, I get this error:

Notice: Undefined property: stdClass::$condition_type in field_conditional_state_get_field_conditions() (line 361 of \htdocs\sites\all\modules\field_conditional_state\field_conditional_state.module).

After updating to #47, I get this error:

Notice: Undefined property: stdClass::$condition_type in field_conditional_state_get_field_conditions() (line 361 of \htdocs\sites\all\modules\field_conditional_state\field_conditional_state.module).

condition_type is added from field_conditional_state_7.

If you have some condition created first to "version 7" you could have condition_type attribute not setted.

try to investigate inside database and if is necessary populate this attribute.

I've 2 field:

field_1

FIELD: List (text); WIDGET: Select list; Possible values: A, B, C

field_2

FIELD: List (text); WIDGET: Check boxes/radio buttons; Possible values: not important...

I add 3 conditional states at field_2:

• Field field_2 is visible when field field_1 has value A (saved into database with ID 31)
• Field field_2 is invisible when field field_1 has value B (saved into database with ID 32)
• Field field_2 is disable when field field_1 has value C (saved into database with ID 33)

Now in the condition list I've 3 delete condition button.

I could click any button and the result is the same: is always deleted the first condition (in this case condition with ID 31)

Currently I can't distinguish the three buttons. For all buttons I've:

$form_state['clicked_button']['#parents'] => Array
        (
            [0] => field_states
            [1] => 33
            [2] => submit
        )

From Form generation I can read:

'triggering_element': (read-only) The form element that triggered submission. This is the same as the deprecated $form_state['clicked_button']. It is the element that caused submission, which may or may not be a button (in the case of Ajax forms.) This is often used to distinguish between various buttons in a submit handler, and is also used in Ajax handlers.

$form_state['clicked_button'] is deprecated, but I can't distinguish the three buttons also with $form_state['triggering_element']

I would add my personal patches.

mikewink

why do u change the module title?????

When control field use a select widget could be a problem determine which will:
- the initial behavior of the controlled field
- the behavior of the controlled field when "- None -" or "- Select a value -" is selected.

To deepen the discussion may be helpful to read these comments:

http://drupal.org/node/140783#comment-3470686
http://drupal.org/node/140783#comment-3519770
http://drupal.org/node/140783#comment-3533170

I would add some patch for try to alleviate this problem

I want to use conditionals with profile2 module during the registration process too. Right now it seams not to work! Could the reason be that profile2 injects the fields in the user registration form and misses dependencies (js files)?

Use profile2 was my first attempt.
When I saw that field_conditional_state did not work with him, I have added fields directly in "people accounts" (admin/config/people/accounts/fields).

I haven't investigated, but I think that profile2 don't work because it use a profile2 bundle inside an user entity type.
Currently field_permission_state don't save information about entity type and don't check for multiple bundle attached to 1 entity (I hope I haven't said crap)

Exportables support:
Looking at the schema of this field it seams hard to ex-/import conditions. I think the numeric ids are problematic. Are there any plans to make this field exportable. Maybe a combination of bundle and fields could be an option (group_foo_field__bar_field) for a machine readable name?

I'm interested in export conditions.

If I haven't misunderstood the ctools capability, I think that the id in field_conditional_state isn't a problem (is used only for delete condition).

I don't have very clear ideas, but I hope that in the near future Is possible to export conditions.

subscribe

Hi. Please read all the following and the links provided as this is very important information about your CVS Application:

Drupal.org has moved from CVS to Git! This is a very significant change for the Drupal community and for your application. Please read the following documentation on how this affects and benefits you and the application process:
Migrating from CVS Applications to (Git) Full Project Applications

• The status of this application will be put to "postponed" and by following the instructions in the above link, you will be able to reopen it.
• Or if your application has been "needs work" for more than 5 weeks, your application will be marked as "closed (won't fix)". You can still reopen it, by reading the instructions above.

Subscribe

subscribe

Great project, worked like a charm, thank you very much for the hard work :D

I get these errors, When using booleans as control fields

Notice: Undefined index: field_yn_cms_experience in field_conditional_state_handle_requirements() (line 187 of /var/aegir/platforms/drupal7/drupal-7.0/sites/all/modules/field_conditional_state/field_conditional_state.module).
Notice: Undefined index: field_yn_gd_experience in field_conditional_state_handle_requirements() (line 187 of /var/aegir/platforms/drupal7/drupal-7.0/sites/all/modules/field_conditional_state/field_conditional_state.module).
Notice: Undefined index: field_researching_techniques in field_conditional_state_handle_requirements() (line 187 of /var/aegir/platforms/drupal7/drupal-7.0/sites/all/modules/field_conditional_state/field_conditional_state.module).
Notice: Undefined index: field_yn_layout_template_theme in field_conditional_state_handle_requirements() (line 187 of /var/aegir/platforms/drupal7/drupal-7.0/sites/all/modules/field_conditional_state/field_conditional_state.module).
Notice: Undefined index: field_yn_web_app_exp in field_conditional_state_handle_requirements() (line 187 of /var/aegir/platforms/drupal7/drupal-7.0/sites/all/modules/field_conditional_state/field_conditional_state.module).
Notice: Undefined index: field_yn_web_design_exp in field_conditional_state_handle_requirements() (line 187 of /var/aegir/platforms/drupal7/drupal-7.0/sites/all/modules/field_conditional_state/field_conditional_state.module).

@peem83 Thanks for your hard work!

Subscribe

This is a great module. Installing and configuring it is easy, the integration is good and everything works as expected. Really nice job.

One little concern (no offence or demand). For my taste, the code is a bit too much squished. Adding some space would make it much more readable.

For example this code:

function field_conditional_state_settings_form_submit($form, &$form_state) {
  if ($form_state['triggering_element']['#value'] == t('Delete condition')) {
    list($field_states, $condition_id) = $form_state['triggering_element']['#parents'];
    $delete_condition_id = $form_state['values'][$field_states][$condition_id]['delete'];
    $delete_condition = db_delete('field_conditional_state')
      ->condition('id', $delete_condition_id, '=')
      ->execute();
  } 
  else {
    $target_field = $form_state['values']['trigger_field'];
    $bundle = $form_state['values']['bundle'];
    $values = $form_state['values']['add_field_state'];
    $state_type = $values['state_type'];
    $control_field = $values['control_field'];
    $condition_type = $values['condition_type'];
    if (count($values['options'][$control_field]) == 1) {
      $condition_type = 'or';
    }
    $control_values = serialize($values['options'][$control_field]);
    $condition = db_insert('field_conditional_state')->fields(array(
      'field_name'     => $target_field,
      'control_field'  => $control_field,
      'state'          => $state_type,
      'bundle'         => $bundle,
      'trigger_values' => $control_values,
      'condition_type'  =>  $condition_type
    ))
    ->execute();
  }
}

Looks much clearer like this:

function field_conditional_state_settings_form_submit($form, &$form_state) {
  
  if ($form_state['triggering_element']['#value'] == t('Delete condition')) {

    list($field_states, $condition_id) = $form_state['triggering_element']['#parents'];

    $delete_condition_id = $form_state['values'][$field_states][$condition_id]['delete'];
    
    $delete_condition = db_delete('field_conditional_state')
      ->condition('id', $delete_condition_id, '=')
      ->execute();
  } 
  else {
    
    $target_field = $form_state['values']['trigger_field'];
    $bundle = $form_state['values']['bundle'];
    $values = $form_state['values']['add_field_state'];
    $state_type = $values['state_type'];
    $control_field = $values['control_field'];
    $condition_type = $values['condition_type'];

    if (count($values['options'][$control_field]) == 1) {
      $condition_type = 'or';
    }
    
    $control_values = serialize($values['options'][$control_field]);
    
    $condition = db_insert('field_conditional_state')->fields(array(
      'field_name'     => $target_field,
      'control_field'  => $control_field,
      'state'          => $state_type,
      'bundle'         => $bundle,
      'trigger_values' => $control_values,
      'condition_type'  =>  $condition_type
    ))
    ->execute();
  }
}

It might be a matter of taste or habit. But I suppose that most people looking at that code would appreciate a more readable formatting. Adding lines of comments is also a valid spacing. :-)

Honestly, really, I prefer 10.000 times the first version than the second "beautified" version.
All this spacing and "beautification" doesn't make it more readable, really, at least not for me.

The only thing I'd change is this:

<?php
->execute();
  } 
  else {
    $target_field = $form_state['values']['trigger_field'];
?>

to this:

<?php
->execute();
  } else {
    $target_field = $form_state['values']['trigger_field'];
?>

I respect what you say. Though for me it has more to do with structure than with beauty. For me it enhances the readability kind of in a way how indentation does (of course not as significant): It uses formatting to emphasize structure. Maybe it does not need to be as extensive as in my example.

But that's just my humble opinion. I thought most others would agree, but I may be wrong.

Regarding the "else" thing. Your version (which I also prefer) does not comply with the Drupal coding standards. At least the Coder Review module does complain about it.