Incorrect invocation of hook_options_list()

patch seems to be working, subscribing

This patch works for me. Thanks.

thomas you are great! i will test the patch.

The patch solve my notices/warnings, thanks !

solved it here too. small and clear patch :)

Sorry about that. I specifically asked we don't change the function signature for hook implementations, but apparently that fell through the cracks.

This was introduced in #1541792: Enable dynamic allowed list values function with additional context. Sorry. :( The stance of chx and dww there are that hook implementations are internal functions that should not be called elsewhere, but i can see why Entity API does this.

Indeed, sorry for the trouble. However, the old function signature made no sense and made life difficult for people trying to use this API for something real (both OG and project_issue at least, probably many others).

So that will fix it, but seems a sub-optimal fix because it doesn't take advantage of these new contextual variables. Since entity module has to change either way, seems like it's better for it to provide the same context to other modules.

I tried to fix this, but I can't can't figure out a way to trigger the error. Stock D7 + Entity module doesn't do it, and even after adding some Commerce products with List fields, I still can't get it to fire.

This is, I believe, a better patch. It's still not perfect -- the views include calls this w/o any sensible context but what can one do. And I can't figure out either how to call this.

Less debug.

Patch from #12 has stopped the errors appearing for me.

Actually, after applying the patch from #12 and clearing caches it's created a fatal php issue.

Fatal error: Call to undefined method EntityListWrapper::getType() in .../entity/modules/callbacks.inc on line 445

I can't find any mention of that getType() method in the entity module's directory.

Nick (and chx and webchick), I had to look at the abstract superclass to find what I think are the proper methods. Ended up with this:
return (array) module_invoke($field['module'], 'options_list', $field, NULL, $entity ? $entity->type() : NULL, $entity ? $entity->value() : NULL);

I'm testing it right now, but so far so good.

I tried to fix this, but I can't can't figure out a way to trigger the error. Stock D7 + Entity module doesn't do it, and even after adding some Commerce products with List fields, I still can't get it to fire.

webchick, here's a shot of my stack trace. Dunno if it will help.

I see what Nick sees (#14). WSOD after clearing cache.

PHP Fatal error: Call to undefined method EntityValueWrapper::getType() in
.../sites/all/modules/entity/modules/callbacks.inc on line 447

Cleared cache a few more times and now I'm about to proceed with 7.14.

I was scared to do #12 after reading 13-17, but no problems with #12 for me.

**until 10 minutes later when I enabled the next module and poof WSOD, drush complained about the last line of the patch in #12 when trying to disable the module, so I reverted that line only, site came back from the land of white, re-applied the patch, and errors went away again.

Something to do with enabling or cc like #17 says, although I did clear cache without event.

Since my post #17, I tried proceeding. When I installed another module, I got the WSOD. I didn't try reverting only the last line of the patch, though, as suggested in #18. Instead, I rolled back to D7.12. Decided to skip the D7.14 update for now. There are a lot of issues possibly coming from other modules. Is very hard to tell what patch does/doesn't fix the errors at this early stage since the D7.14 release.

Applied #20 and warnings disappeared.

This may be compounding the issue but patch #20 threw this error after applying:
Call to undefined method EntityListWrapper::data()

And the stacktrace is pointing to Search API. I have attached the stacktrace for reference.

Drupal 7.14 upgrade with this option list warnings it created to any module hooking into it.
http://drupal.org/node/1541792

subscribed

Try $entity->value() in place of $entity->data().

It's in the abstract superclass EntityMetadataWrapper that EntityListWrapper inherits, line 81

public function value(array $options = array()) {
    if (!$this->dataAvailable() && isset($this->info['parent'])) {
      throw new EntityMetadataWrapperException('Missing data values.');
    }
    if (!isset($this->data) && isset($this->info['name'])) {
      $this->data = $this->info['parent']->getPropertyValue($this->info['name'], $this->info);
    }
    return $this->data;
  }

Patch from #25 + a cache clear produces the following error for me:

Additional uncaught exception thrown while handling exception.

Original

EntityMetadataWrapperException: Missing data values. in EntityMetadataWrapper->value() (line 83 of .../entity/includes/entity.wrapper.inc).

Additional

EntityMetadataWrapperException: Missing data values. in EntityMetadataWrapper->value() (line 83 of .../entity/includes/entity.wrapper.inc).

Following up from comment #26, a var_dump of $this just before that exception is thrown shows that $this->data = NULL, and thus $this->dataAvailable() returns FALSE.

Same here.. clearing caches breaks everything. Tried #25 and is broken too. Same exception found by #26.

You can always use #1. This might need actual Entity API maintainers to properly fix.

I am going with #1 for now to keep things functioning, was getting the same as #26

The patch in #1 works for me.

I have followed many threads to get here and see that many talented people are working on this but no one has explained how they get the errors so others can recreate them.

I am not sure if this is how you go about solving these issues but I hope this will help anyone trying to recreate this problem, here is how I get the error:
I think these are the relevant modules (I am using) while getting these errors.

• Drupal core 7.14
• Entity API 7.x-1.0-rc2
• Field collection 7.x-1.0-beta4
• Profile 2 7.x-1.2
• Rules 7.x-2.1

The errors only appear on one of my rules. This rule has 2 data comparisons and 2 negated Data value is empty. Here is the list of rules:

CONDITIONS
Data comparison:  
Parameter: Data to compare: [profile2:type], Data value: Student profile

Data comparison
Parameter: Data to compare: [profile2:field-profile-state], Data value: incomplete

NOT Data value is empty
Parameter: Data to check: [profile2:field-profile-subject:0]

NOT Data value is empty
Parameter: Data to check: [profile2:field-profile-personal]

ACTIONS
Set a data value
Parameter: Data: [profile2:field-profile-state], Value: visible

The list of Values for field-profile-state are visible, hidden, incomplete

Here are my errors:

Warning: Missing argument 2 for list_options_list() in list_options_list() (line 437 of /home1/pro/public_html/mysite/modules/field/modules/list/list.module).
Warning: Missing argument 3 for list_options_list() in list_options_list() (line 437 of /home1/pro/public_html/mysite/modules/field/modules/list/list.module).
Warning: Missing argument 4 for list_options_list() in list_options_list() (line 437 of /home1/pro/public_html/mysite/modules/field/modules/list/list.module).
Notice: Undefined variable: instance in list_options_list() (line 438 of /home1/pro/public_html/mysite/modules/field/modules/list/list.module).
Notice: Undefined variable: entity_type in list_options_list() (line 438 of /home1/pro/public_html/mysite/modules/field/modules/list/list.module).
Notice: Undefined variable: entity in list_options_list() (line 438 of /home1/pro/public_html/mysite/modules/field/modules/list/list.module).

#1 works perfectly for me

This can really flood your logs, updating priority.

Thanks, #1 sold the problem. Just to remind that if you upgrading the Entity API to latest release (which I did bevore applying the patch) - you need to upgrade i18n as well to 1.5! Otherwise after "clearing the cache" everything just stops working. No error messages, no warnings, no logs...

#1 works for me

I took a stab on that, patch attached. please test.

Fago -- tested your patch and it worked great -- errors are cleared up. Thank you.

@fago same here tested the patch and no issues, errors were caught. Thank you

Yep, this looks right to me.

#36 works here, too. Thank you.

thanks, committed.

How about rc3? :-)

#1 works for me too

@tregismoreira: please note that #1 is not a fix, but a temporary workaround. It simply pass "null" to avoid the warning, but it will break as soon as someone will start using the parameters and will find null. Please test #36, instead, as it is the patch that will be released.

Sorry, I changed the status by mistake... reverting.

#36 works for me, too. Thank you.

same here, #36 a success....thanks!