function chado_validate_node_form_triggering_element

2.x tripal_core.chado_nodes.api.inc chado_validate_node_form_triggering_element($form, &$form_state)

Validate the Triggering element from a node form.

We are going to inspect the post to determine what PHP knows is the triggering element and if it doesn't agree with Drupal then we are actually going to change it in Drupal.

This fixes an obscure bug triggered when a property is added and then a relationship removed, Drupal thinks the first property remove button was clicked and instead removes a property (not a relationship) and renders the new property table in the relationship table page space.

NOTE: Many Drupal issues state that this problem is solved if the #name of the button is unique (which it is in our case) but we are still experiencing incorrectly determined triggering elements so we need to handle it ourselves.

2 calls to chado_validate_node_form_triggering_element()
chado_add_node_form_subtables_remove_button_validate in tripal_core/api/tripal_core.chado_nodes.api.inc
Validate Removing Subtables entries from the node forms. Supported subtables: Properties, Relationships, Additional DBxrefs.
chado_add_node_form_subtable_ajax_update in tripal_core/api/tripal_core.chado_nodes.api.inc
Ajax function which returns the section of the form to be re-rendered for either the properties, dbxref or relationship sub-sections.

File

tripal_core/api/tripal_core.chado_nodes.api.inc, line 157
API to handle much of the common functionality implemented when creating a drupal node type.

Code

function chado_validate_node_form_triggering_element($form, &$form_state) {

  // We are going to inspect the post to determine what PHP knows is the triggering
  // element and if it doesn't agree with Drupal then we are actually going to
  // change it in Drupal.
  if ($_POST['_triggering_element_name'] != $form_state['triggering_element']['#name']) {
    $form_state['triggering_element']['#name'] = $_POST['_triggering_element_name'];
  }

}