The error below occurs when I try to add a content to a content type with conditional fields present (text, long text and term reference) and where these fields have some field permissions set (using the field permissions module.)

The error is showing to users that do not have permission to edit the fields. Users with permissions do not see the error message - all works as normal.

Fatal error: Function name must be a string in /public_html/sites/all/modules/conditional_fields/conditional_fields.module on line 583

Removing the code below from the module c.line 583 seems to fix the problem, but heaven only knows what else I could be breaking!

    // Execute custom behaviors.
    if (!empty($behaviors)) {
      foreach ($behaviors as $behavior) {
        // Custom behaviors are callbacks.
        $$behavior('edit', $form, $form_state, $dependent, $dependencies);
      }
    }

    unset($behaviors);

(Addition...just found out that removing the above breaks quite a lot! Conditional fields elsewhere, available to anonymous user have stopped working...)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Buckminster_Bond’s picture

Further investigation. Note that the error is on line 570 of a clean install (no patches)

I don't now think that this error has anything to do with field permissions (as I've removed that module.)

The error occurs when any condition is added into the user section. It is only anonymous users that are affected.

(example condition - field_logo is visible when field_add_contact_details has value "1".)

Rolling back to an earlier version of dev3 (10 August) fixes this issue.

However, the version on 10 August breaks my other conditional fields, as long text and term references weren't playing together nicely back then!

Any help appreciated!

Buckminster_Bond’s picture

It seems that this issue (and I can't change the title!) of anonymous users getting error messages was also in the D6 version.

There is a fix here for D6.

Can it be fixed for D7? My PHP skills are not up to it - I have tried!

apmsooner’s picture

Actually i do concur there is a conflict with field permissions module. With field permissions module enabled I get the following error when i try to create or edit dependencies:
EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7405 of /home/~/public_html/drupal7/includes/common.inc).

If i disable field permissions, the form opens and i can set dependencies and they appear to work as they should but I can't modify existing or add new dependencies while field permissions is enabled.

zhenjan’s picture

Priority: Normal » Major

any progress on it?

MostlyGhostly’s picture

Apparently not... Pity really.

john duff’s picture

If I can help: the error appears only if I check "Reset the dependent to its default values if the dependency is not triggered." in Node Edit options.

peterpoe’s picture

We made many fixes and changes lately, I suspect this issue is fixed, but could someone please confirm?

digitopo’s picture

I can confirm that it's not fixed... using following version of conditional fields module:

; Information added by drupal.org packaging script on 2012-05-05
version = "7.x-3.x-dev"
core = "7.x"
project = "conditional_fields"
datestamp = "1336176488"

and following version of field permissions:

; Information added by drupal.org packaging script on 2012-01-25
version = "7.x-1.0-beta2"
core = "7.x"
project = "field_permissions"
datestamp = "1327510549"

Any thoughts?

qasimzee’s picture

subscribe

digitopo’s picture

Still no update on this?

ah0’s picture

any update for this?
Issue still exists and it makes the module not usable.

AaronBauman’s picture

Status: Active » Needs review
FileSize
633 bytes

simple "function_exists" before calling a user function.

This does not address the root issue of *why* the behaviors array is malformed -- i didn't dig far enough to figure out the problem.
However, this fix should get in quickly, since this is rendering the module unusable.

AaronBauman’s picture

FWIW: in my case this issue appears when I set #access = false on two fields in a dependency pair.

peterpoe’s picture

Status: Needs review » Closed (cannot reproduce)

Ok, I committed the patch proposed in #12, but I was not able to reproduce the problem with Field Permissions. Anyway, checking if the callback actually exists seems reasonable. Thanks!

If anyone experiencing the problem could provide more information on the exact steps to reproduce it, I will reopen the issue and investigate it further.

peterpoe’s picture

Issue summary: View changes

(Addition...just found out that removing the above breaks quite a lot! Conditional fields elsewhere, available to anonymous user have stopped working...)

minorOffense’s picture

Title: Conflict with field permissions » Incomplete cleanup of behaviors when #access is set to false on a field
Issue summary: View changes
Status: Closed (cannot reproduce) » Active

I've managed to replicate the issue.

It happens when a field has a dependee which is supposed to reset the value if it is unchecked on submit. The way the logic is laid out, the clean up for the CONDITIONAL_FIELDS_FIELD_EDIT_RESET_UNTRIGGERED option is left stray in the $behaviors array. Then the value of "3" is attempted to be used as a function (which causes the warning).

See line 464

 if (empty($dependee_form_field) || (isset($dependee_form_field['#access']) && $dependee_form_field['#access'] == FALSE)) {
  ....
  unset($behaviors[CONDITIONAL_FIELDS_FIELD_EDIT_HIDE_UNTRIGGERED_ORPHAN]);
  unset($behaviors[CONDITIONAL_FIELDS_FIELD_EDIT_HIDE_ORPHAN]);

  continue;
}

Just before the continue there should be another line

 if (empty($dependee_form_field) || (isset($dependee_form_field['#access']) && $dependee_form_field['#access'] == FALSE)) {
  ....
  unset($behaviors[CONDITIONAL_FIELDS_FIELD_EDIT_HIDE_UNTRIGGERED_ORPHAN]);
  unset($behaviors[CONDITIONAL_FIELDS_FIELD_EDIT_HIDE_ORPHAN]);
  unset($behaviors[CONDITIONAL_FIELDS_FIELD_EDIT_RESET_UNTRIGGERED]);

  continue;
}

To remove that behavior as well. Otherwise the code down below near the end of the foreach, which is supposed to do the reset stuff, is never run (see line 576)

I'll provide a patch in my next comment.

minorOffense’s picture

Status: Active » Needs review
FileSize
1.27 KB
minorOffense’s picture

Component: Compatibility w/ other modules » Code

This isn't a bug with other modules, this is an issue with any dependee field with #access set to false with the reset value behavior enabled.

andrewbelcher’s picture

Status: Needs review » Needs work

This patch does the trick, though it looks like it's picked up some white space modifications?

minorOffense’s picture

Ah ok, well I'll have to reroll it.

No chance to just take the whitespace fixes :-D ?

minorOffense’s picture

Status: Needs work » Needs review
FileSize
518 bytes

See if just erasing those lines from the patch file works...

Status: Needs review » Needs work

The last submitted patch, 20: 1315366-incomplete-behavior-19.patch, failed testing.

minorOffense’s picture

Status: Needs work » Needs review
FileSize
520 bytes

Let's try that one more time...

andrewbelcher’s picture

Status: Needs review » Reviewed & tested by the community

Looks good! This patch works perfectly for me!

The last submitted patch, 12: conditional_fields-undefined_function_fatal-1315366-12.patch, failed testing.

peterpoe’s picture

Status: Reviewed & tested by the community » Fixed

Committed, thanks!

  • peterpoe committed e164e00 on 7.x-3.x authored by minorOffense
    Issue #1315366 by minorOffense: Fixed incomplete cleanup of behaviors...

Status: Fixed » Closed (fixed)

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