Problem

Issue is outcome of a problem I have in D7 + OG. I'd like to show a list of values on a select list based on the entity that the field is attached to. I can't do it now, as there is no context -- the entity isn't passed along.

Patch extracts this info which is available in options_field_widget_form() and passes it to _options_get_options().

API change

No

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Status: Needs review » Needs work

The last submitted patch, list-options-pass-entity.patch, failed testing.

amitaibu’s picture

Status: Needs work » Needs review
FileSize
1.59 KB

Let's test this one.

Damien Tournoud’s picture

Quick review:

  • I'm not a fan of using $form_state[$entity_type]. It is a common convention, but we are not enforcing it anywhere right now. Let's modify the Field API to add $element['#entity'].
  • During default editing, I doubt that we have an entity type, so $entity_type should probably be optional too.
  • We need to update the API documentation.
  • We probably want to update some tests.
amitaibu’s picture

> During default editing, I doubt that we have an entity type

According to my checks it seems we always have the entity type.

> We need to update the API documentation

done.

> We probably want to update some tests

Let's see if this patch passes.

amitaibu’s picture

> Let's see if this patch passes

Yes, it did :)

dww’s picture

chx and I ran into this exact same limitation when working on the D7 port of project_issue. We want a field on issue nodes (Component) that populates its allowed values via a field on the project an issue is attached to. Currently impossible without horrific hacks. This patch would enable it. Code looks good to my eyes, but it's late and I'm exhausted, so I'm not going to RTBC. But major +1 from me.

chx’s picture

Title: Pass entity-type and entity to hook_options_list() » Allow for a dynamic allowed value
Issue tags: +Needs backport to D7
FileSize
9.27 KB
9.49 KB

Thanks so much for the patch! But you stopped just where it started to become interesting. I continued by passing on the entity_type and entity you so nicely provided to allowed_valued_function. This allowed me to write a really purdy test.

Status: Needs review » Needs work

The last submitted patch, 1541792_7.patch, failed testing.

chx’s picture

Status: Needs work » Needs review
FileSize
9.24 KB

Boy, D8 moves fast.

Status: Needs review » Needs work

The last submitted patch, 1541792_8.patch, failed testing.

tim.plunkett’s picture

Status: Needs work » Needs review
FileSize
10.15 KB

This only added #entity for field_multiple_value_form, I think it should be in field_default_form as well.

There was also a call to list_allowed_values($field, $instance, $field, $instance) that I fixed.

Added @param docs where appropriate.

Status: Needs review » Needs work

The last submitted patch, drupal-1541792-11.patch, failed testing.

tim.plunkett’s picture

Status: Needs work » Needs review
FileSize
10.96 KB

Duh. field_multiple_value_form() doesn't have access to the $entity.

Shoved the $entity into $form just as a rough test. Marked with @todo.

Status: Needs review » Needs work

The last submitted patch, drupal-1541792-13.patch, failed testing.

tim.plunkett’s picture

Status: Needs work » Needs review
FileSize
10.98 KB

Test had LANGUAGE_NONE in it.
Still has the hacky bit in it.

Status: Needs review » Needs work

The last submitted patch, drupal-1541792-15.patch, failed testing.

tim.plunkett’s picture

Status: Needs work » Needs review
FileSize
10.99 KB

D'oh! The test didn't enable the list module. I think this might actually work now?

tim.plunkett’s picture

+++ b/core/modules/field/modules/list/tests/list.testundefined
@@ -113,6 +113,78 @@ class ListFieldTestCase extends FieldTestCase {
+    parent::setUp('list', 'field_test', 'list_test');

This should be parent::setUp(array('list', 'field_test', 'list_test')); on the next reroll.

+++ b/core/modules/field/field.form.incundefined
@@ -53,6 +53,8 @@ function field_default_form($entity_type, $entity, $field, $instance, $langcode,
+    // @todo.
+    $form['#' . $entity_type] = $entity;
+++ b/core/modules/field/field.form.incundefined
@@ -169,10 +172,13 @@ function field_multiple_value_form($field, $instance, $langcode, $items, &$form,
+    // @todo.
+    $entity = $form['#' . $instance['entity_type']];

This is likely not a good solution, but how else to get the $entity from one function to another?

tim.plunkett’s picture

Okay, merging this with the tests that chx wrote.

dww’s picture

Cool to see so much progress here, thanks!

It's not obvious what's going on with $cacheable. Can someone explain that? Perhaps via a code comment? Is the intention that $function() might alter $cacheable by reference if it needs to?

dww’s picture

p.s. And if that's right, should any API docs be updated accordingly, and if so, where do those live?

Thanks,
-Derek

Status: Needs review » Needs work

The last submitted patch, drupal-1541792-19-tests.patch, failed testing.

tim.plunkett’s picture

Status: Needs work » Needs review
FileSize
3.7 KB
12.39 KB
4.84 KB

Allowed values functions are poorly documented. And by poorly, I mean not at all. I will open a follow-up for better docs for those.

This adds better docs for $cacheable and cleans up the test. And adds default values for the new parameters in list_allowed_values.

tim.plunkett’s picture

Arggh. Interdiff was right, but the patches were wrong.

tim.plunkett’s picture

This should be a clean D7 backport. Just manually applying stuff because of docs changes or function_exists, and then swapping out LANGUAGE_NOT_SPECIFIED for LANGUAGE_NONE.

sun’s picture

Status: Needs review » Reviewed & tested by the community

Looks good to me.

Some classes and functions are missing phpDoc, but I'd say, d.o upgrade sprint progress > nitpicks, so let's get this in.

For the D8 patch, some more details about (optional/required) function arguments, argument order, etc.pp. have been answered in previous comments already, and those will be fixed in follow-up issues specifically for D8.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, drupal-1541792-24-tests.patch, failed testing.

jthorson’s picture

Status: Needs work » Reviewed & tested by the community

Failure was a tests-only patch ... reversing to previous status before testbot interfered.

chx’s picture

Moar doxygen. I rolled the D7 patch by applying the interdiff so there is no need for a D7 interdiff.

webchick’s picture

Title: Allow for a dynamic allowed value » Enable dynamic allowed list values function with additional context
Status: Reviewed & tested by the community » Fixed

Ok, got an in-person walkthrough of this code from chx and dww. :)

Adding the additional optional properties makes sense. I was a bit thrown off by the weird cacheable by reference stuff. chx explained that this is because we can't remove a drupal_static in a stable release of Drupal, and in order to enable the D7 fix to be committed sooner, we keep D7 and D8 the same and then open a follow-up issue to clean that up. And also make those properties required.

Committed and pushed to 8.x and 7.x. Thanks so much for the fast turnaround on this, folks! :D Drupal.org thanks you.

chx’s picture

Version: 8.x-dev » 7.x-dev
Status: Fixed » Reviewed & tested by the community
FileSize
1021 bytes

Opsie.

tim.plunkett’s picture

+1 on the RTBC, this was due to a mistake I made back in #25.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed that to get testbot working again.

Sorry folks. :\

chx’s picture

Version: 7.x-dev » 8.x-dev
Status: Fixed » Reviewed & tested by the community
FileSize
584 bytes
604 bytes

Let me reopen this once more. We have random failures (see #30) and I am fairly sure this solves them.

catch’s picture

Title: Enable dynamic allowed list values function with additional context » (random test failures) Enable dynamic allowed list values function with additional context
Version: 8.x-dev » 7.x-dev
Category: feature » bug
Priority: Normal » Critical
Status: Reviewed & tested by the community » Patch (to be ported)

Committed/pushed to 8.x, moving to 7.x for backport.

chx’s picture

Status: Patch (to be ported) » Reviewed & tested by the community

Erm. #35 had it.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Committed and pushed that too. Yeesh. :P

dww’s picture

Title: (random test failures) Enable dynamic allowed list values function with additional context » Enable dynamic allowed list values function with additional context
Issue tags: +project, +drupal.org D7

(For posterity.)

Thanks everyone, and sorry to webchick for the troubles this patch has caused. Drupal.org D7 loves you.

chx’s picture

Version: 7.x-dev » 8.x-dev
Status: Fixed » Needs review
FileSize
713 bytes
693 bytes

See...... the random failures were caused by $id and $vid sometimes having the same value in ListDynamicValuesTestCase::$test then being fed into drupal_map_assoc by list_test_dynamic_values_callback resulting in 3 values instead of 4. (The 4/5th is the _none).

In other words, we are doing drupal_map_assoc(array("randomstring",3,3,"test_bundle")));. OOOOOPSIE!

Berdir’s picture

Status: Needs review » Reviewed & tested by the community

Yes, this makes sense. Let's wait until the bot comes back, but this should be RTBC. In case you're confused like I was, the do-not-test.patch is the patch for 7.x.

xjm’s picture

Some classes and functions are missing phpDoc, but I'd say, d.o upgrade sprint progress > nitpicks, so let's get this in.

For the record, entirely missing doxygen is not a "nitpick"; it is missing documentation and shouldn't be acceptable any more than missing tests, per the core gates:

All functions, classes, files, constants, etc. that are added or updated must be documented.

Thanks chx for adding it.

Regarding #40, I was going to say it seemed a bit unreliable to say the value will always be less than 20, but I missed that the ID is right above it using rand(1, 10). ;) So it looks fine.

no_commit_credit’s picture

FileSize
685 bytes
713 bytes

This is what an actual nitpick looks like. ;)

no_commit_credit’s picture

FileSize
689 bytes
717 bytes

Or better, this.

webchick’s picture

Category: bug » task
Priority: Critical » Normal
Status: Reviewed & tested by the community » Fixed

Agreed w/ xjm on PHPDoc being an absolute requirement. I passed that along to chx verbally and that was taken care of before commit. :)

Thanks for the further comment clarification "no_commit_credit" ;)

Committed and pushed to 8.x and 7.x. Let's hope we're good now. :) Optimistically restoring status.

tim.plunkett’s picture

For those curious how this could be used, see http://drupal.org/project/dereference_list

Also, as a follow-up: #1548004: Allowed values functions are undocumented

webchick’s picture

This issue seems to be causing problems all over the place. :(

#1559410: Taxonomy module - Warning: Missing argument
#1559172: List module spawns error messages

I'm not sure why tests did not catch it. chx, could you take a look?

jthorson’s picture

webchick: I hate to point this out, since I don't have an explanation for it ... but it may provide some insight to your "why tests didn't catch it" question ... that, or, it could simply be a red herring.

The patches in #43 and #44, which were posted two minutes apart from each other, do not have the same test count. This is a pattern I've been suspecting, but this one makes it easy to confirm.

Looking in the review log for the two tests, the test count for the very first category do not match (Actions in an infinite loop: 26 tests passed versus 20 tests passed). Was there a commit removing a half dozen tests in the two minutes between these, or do we have an unknown testing issue?

... thus why I hesitate to point this out. ;)

webchick’s picture

Oh, man. :\ No, no commit that should've affected those actions tests. Aye-yi-yi.

Berdir’s picture

Status: Fixed » Needs work

While I have noticed the inconsistent test assertions numbers as well, I don't think this is the issue here.

+++ b/core/modules/field/modules/options/options.api.phpundefined
@@ -29,7 +34,7 @@
  */
-function hook_options_list($field, $instance) {
+function hook_options_list($field, $instance, $entity_type, $entity) {

+++ b/core/modules/field/modules/options/options.moduleundefined
@@ -237,9 +240,9 @@ function _options_properties($type, $multiple, $required, $has_value) {
  */
-function _options_get_options($field, $instance, $properties) {
+function _options_get_options($field, $instance, $properties, $entity_type, $entity) {
   // Get the list of options.
-  $options = (array) module_invoke($field['module'], 'options_list', $field, $instance);

This is the problem.

We have changed this hook and the helper function to receive two additional, required arguments. This is an API change.

If another module is calling either the hook directly or through this helper function, stuff breaks. Then this results in the warnings in those issues. The helper function is prefixed with _, so "private", so you might say this is ok, but not the hook imho.

They should be optional, just like in list_allowed_values()

webchick’s picture

Category: task » bug
Priority: Normal » Critical

Duh. This is why I should not commit patches at sprints. Escalating.

brad.bulger’s picture

re comment 50 - i can't find the relevant change, but compared to 7.12, all three additional arguments should be optional:

-function hook_options_list($field, $instance = NULL) {
+function hook_options_list($field, $instance, $entity_type, $entity) {
chx’s picture

The hook gets more arguments. function hook_options_list($field, $instance, $entity_type, $entity) is a documentation of what arguments you are getting. If you have an old hook implementation and you desire to receive fewer arguments then nothing ever happens. That's how PHP is. You need to call a change core function to break this. What function do you call? _options_get_options is a private function. list_allowed_values is public but the new arguments are optional there.

chx’s picture

Priority: Critical » Normal
Status: Needs work » Postponed (maintainer needs more info)

And, this is hardly critical because I have yet to see an actual bug report. If contrib modules are calling hook implementations (are there any??) and private functions that's not a core bug. Give me a core bug to fix.

chx’s picture

Also, the issue is extremely infuriating because now I am going to be left holding the bag just because people neither can write proper API using contrib modules nor file proper bug reports.

sun’s picture

re: #48: @jthorson/@webchick: Nope. See you in #1560028: Remove all calls to rand() from tests

brad.bulger’s picture

And, this is hardly critical because I have yet to see an actual bug report.

aren't there two of them in #47? it's the specific changes to the arguments for list_options_list() and taxonomy_options_list() that are causing problems.

from #1066274: hook_options_list should allow to pass the instance of a field the new second argument, $instance, was supposed to be added as optional in 7.x. it's required in 8.x, i think, so maybe this was a backport problem. but as of 7.13 those functions only took one argument, and now they are requiring four. that seems like a legitimate backward compatibility problem.

dww’s picture

@brad.bulger: the point is that contrib modules shouldn't be calling other module's hook implementations. taxonomy_options_list() is the taxonomy.module implementation of hook_options_list(). The only thing that should call that function is the part of options.module that invokes the hook. If other modules are invoking that function directly, they're to blame for warnings, not core itself.

Dave Reid’s picture

Hrm, no. Where have we ever said that hooks are not a public API that other modules cannot invoke?

dww’s picture

Other modules can do whatever they want. And if they get PHP warnings about it, they should fix them. That's not a core bug. ;) That's my point. If you're reaching into the internals of another module and invoking its hooks, you should potentially be prepared for changes. Implementing hooks invoked by other modules is a public API. However, invoking hooks on behalf of another module is not a public API, that's internal. Play with fire and you can get burned. At least, that's my take... I'm sure others will voraciously disagree with me, and that's fine.

Meanwhile, what's the bug here? I've read the other issues linked in #47 and no where is there any indication of what module(s) are actually invoking these hooks directly. The hook changed (for the better). I fail to see the core bug. If people are invoking those hooks themselves, those places need to be updated. The previous API made no sense. Higher up in the call chain we had the $entity_type and $entity, but just never bothered to pass them down the chain to this hook invocation, so many important things became impossible to implement without horrendous hacks. We're now providing enough context.

I don't think we've committed any major crimes here. And I definitely don't think reverting this change is the right solution. Nor is even making those additional arguments optional in the hook invocations. options.module decides what arguments it's passing when it invokes its own hooks. So those are going to be there when the hook is invoked. So it's pointless (and in fact, wrong) for a hook implementation like taxonomy_options_list() to declare those arguments as optional. The only point of that would be to protect against this edge case of a contrib module invoking that hook directly itself. I don't think that makes sense. If rules needs a new release to keep up with 7.14, so be it. That's what #1559172: List module spawns error messages is about. So, what else is broken?

We really do "need more info" here -- so I'm leaving the status as-is. People experiencing problems need to provide real details on what's actually broken. Yes, the internal API between options.module and taxonomy.module changed between 7.12 and 7.14. If people are getting warnings as a result, let's fix those places to keep up with progress. Please let's not say "since people are potentially doing weird things, we can't fix APIs that are broken since we might inconvenience the edge casers." which is what it seems is being implied here.

I don't want to start a flame war here or even pick a fight. I'd rather just get back to work making things better. So, if some contribs need to be patched to be squeaky-clean with 7.14, give me an issue nid and I'll try to give you a patch. Meanwhile, please don't re-break this API by reverting the fix.

Thanks,
-Derek

brad.bulger’s picture

@dww - i see your point. it's not just direct calls, though. so i guess the question is if it's OK to break a line of code like this

    return (array) module_invoke($field['module'], 'options_list', $field);

(example from Entity module)

to me, that seems like an API change that should at least be initially backward compatible. which is how the initial change was implemented.

webchick’s picture

Status: Postponed (maintainer needs more info) » Fixed

Ok, #1556192: Incorrect invocation of hook_options_list() This looks like it was coming from Entity API.

I guess setting this back to fixed, but Damien's right in that changing the hook signature on folks was not nice. I wonder if we want to make that = NULL at least in the hook documentation if nothing else.

dww’s picture

Cool, glad to see this resolved!

No, I still don't think documenting the hook with = NULL is a good idea, as I explained in paragraph 3 in #63...

Sorry for all the troubles this issue caused! Both stress and time spent for webchick, chx's freak-out about being wrongfully blamed, end users getting confusing warnings, etc. We were just trying to make progress, but sometimes change is difficult. ;)

Cheers,
-Derek

joelpittet’s picture

= NULL would be nicer, changing the API wasn't nice indeed.

@dww It's hard to say calling a hook from a contrib module an edge case. The release says "Includes bugfixes only (no new functionality)"

dgtlmoon’s picture

Im confused, is this the fix for the PHP warning "Missing argument 2 for taxonomy_options_list()" #1559410: Taxonomy module - Warning: Missing argument that appears since i've upgraded to latest Drupal-7?

webchick’s picture

This is the issue that caused it. More than likely, the solution is #1556192: Incorrect invocation of hook_options_list(). Else there's another contributed module out there calling an internal API function that needs to be fixed.

bago’s picture

@webchick: #1556192 is not yet a "solution" (proposed patches don't work yet).

webchick’s picture

Yeah, hopefully someone who uses that module and is having the problem can help debug and fix the patch over there. None of the core developers has been able to reproduce the problem as of yet.

Oceanman’s picture

I have tried to describe how I get the errors:

http://drupal.org/node/1556192#comment-5968824

I used the patch from #1 in the above mentioned thread to get rid of the errors. FYI: I am using Drupal core 7.14

dynamicdan’s picture

Status: Fixed » Active

Yes I made this active again...

function taxonomy_options_list($field, $instance=NULL, $entity_type=NULL, $entity=NULL) {..}

This fixed my problem (D7.14). My problem was that I got errors. Not that my modules were incompatible with the hook API and needed updates.

AT A MINIMUM I would expect that this problem is documented in the update notes along with "a temporary solution is xyz" (as above). Another thought would be to mark taxonomy_options_list($field) as deprecated and warn all devs to wake up and fix their modules. Still leave in the deprecated function until the key players (popular modules) have updated their modules. Would it be worth while adding a log msg like "The function 'xyz' is deprecated. Modules calling this will need to be updated before you can upgrade Drupal again".

tim.plunkett’s picture

Status: Active » Fixed

taxonomy_options_list is a hook. Any contrib module calling it directly probably shouldn't, and if so shoulders the responsibility of updating its calls.

The function is not deprecated.

#1556192: Incorrect invocation of hook_options_list() has already been committed to fix this in Entity API.

ilechcod’s picture

Sorry guys,
Sometimes we can get so technical with implementation details that we miss out the main point.

I'm a Drupal user, just upgraded to 7.14, and I'm getting the error

Warning: Missing argument 2 for taxonomy_options_list() in taxonomy_options_list() (line 1375 of /opt/lampp/htdocs/web/modules/taxonomy/taxonomy.module).

I have read 74 posts made about this error.
And simply NONE of them says: "This is the patch to use to fix this issue".
And so, after all the reading I have a Drupal site open in front of me, with my upgrade issues unsolved.
Would have so appareciated if there was a more formalized methodology of providing solutions to dedicated users of Drupal, while the tehnical talks go on.

For example, a message from "System Message" - this patch fixes the problem. Users can download and apply this patch (would also be quite helpful to mention which particular file(s) to patch) while we work on fixing this problem in newer releases.

Just some non-technical, but quite very useful suggestion.

Meanwhile, has anyone please trid any of these patches? Does any of them solve the problem (i.e stop the warning messages from showing, while the contrib modules are being fixed)?

Lot's of love...

dynamicdan’s picture

Component: field system » update.module
Category: bug » feature
Status: Fixed » Active

@ilechcod see #73. add =NULL

@tim.plunkett deprecation is the wrong word. Lets just agree that better documentation is needed to help users/admins/devs relax when they do an update and see lots of warning messages. Install/update notes should be updated with a link to this issue for further advice.

Is it possible to use the update.php page to add some update related comments? Would be user friendly. Would also fit in with the info about all the other SQL based actions being made that most read and review. I know this problem is not DB related, but update is called update. Not update-db.php.

BTW, changed all the issue values.. do we instead need a new issue for this?

tim.plunkett’s picture

Version: 8.x-dev » 7.x-dev
Component: update.module » field system
Category: feature » task
Status: Active » Fixed

Since this was originally a task that has been fixed and committed to both versions, let's leave this as is and if you feel the need, open a new issue.

ilechcod’s picture

Version: 7.x-dev » 8.x-dev
Category: task » bug

Dan, many thanks for the quick reply.

I've looked @ #73. I'm not sure this addresses what I'm trying to say in my previous post.

For example, what do I do with this line of code?

<?php
function taxonomy_options_list($field, $instance=NULL, $entity_type=NULL, $entity=NULL) {..}
?>

Do I replace an existing line of code in a file somewhere? Which file exactly? Will this file be overwritten sometime in future during an upgrade?
Assume for a moment I downloaded Drupal because I'm a non-techie, and wanted a robust platform prone more to CONFIGURATIOn than PROGRAMMING. How does #73 help me?

Please don't get me wrong, I SINCERELY appreciate your posts, and the entire Drupal Community.
But if I can be really SINCERE, I still don't have tha answer to the issue (even with #73).

Please assist.

Regards

tim.plunkett’s picture

Version: 8.x-dev » 7.x-dev
Category: bug » task

Cross post.

@ilechcod, yes you replace the existing taxonomy_options_list function declaration with that one. Look in modules/taxonomy/taxonomy.module, line 1375.

ilechcod’s picture

Version: 7.x-dev » 8.x-dev
Category: task » bug

Sorry Tim,
You mean the fix to this peoblem has been committed to 7.14?
Or 7.14.dev?

So I can redownload 7.14.tar.gx right now, and wont have these issues anymore?
Please clarify.

Thanks

tim.plunkett’s picture

Version: 8.x-dev » 7.x-dev
Category: bug » task

Refresh the page before commenting, or else you'll keep changing the status.

It has been committed to 7.x-dev. It will be in the next release. Once a release is created, it is never changed, so it will not be in 7.14.

ilechcod’s picture

Version: 7.x-dev » 8.x-dev
Category: task » bug

Ok,
Thanks

tim.plunkett’s picture

Version: 8.x-dev » 7.x-dev
Category: bug » task

*sigh*

brad.bulger’s picture

taxonomy_options_list is a hook. Any contrib module calling it directly probably shouldn't, and if so shoulders the responsibility of updating its calls.

again, that is not what was happening here. the contributed Entity module was invoking the 'options_list' hook on a list:

    return (array) module_invoke($field['module'], 'options_list', $field);

if you all are willing to break that line of code in order to implement a change, rather than ease it in by making new arguments optional, then that's your call.

this distinction between a "hook" being an internal thing which contributed modules should not use, and a "public API", is a new concept to me. perhaps i've misunderstood something all these years.

i thought taxonomy_options_list() was an *implementation* of the hook_options_list() hook.

tim.plunkett’s picture

Yes, I meant to say "taxonomy_options_list is an implementation of a hook".

Entity API module was invoking the hook of another module. See #1541792-63: Enable dynamic allowed list values function with additional context for a well-written explanation about how that's not core's problem.

Dave Reid’s picture

I'm still personally baffled that hook implementations are not valid public APIs that cannot be called by other modules via module_invoke(). When did this change happen?

ilechcod’s picture

@tim.plunkett, thanks
I fixed the issue by changing line 1375 in taxonomy.module (adding the NULL values).
But I now get this error (please see below):

Notice: Undefined index: #entity in options_field_widget_form() (line 83 of /opt/lampp/htdocs/web/modules/field/modules/options/options.module)

Apparently - it's still connected with the API change in Drupal 7.14. Any fix (even if quick) for this please?

Regards

ilechcod’s picture

Sorry guys,
I'm just trying to figure out which patch exactly to apply to my Drupal 7.14 installation.
Clicking on the patches above - information page says its for Drupal 8.x

@Berdir, the don-not-test.patch is a patch that patches the /modules/field/modules/list/tests/list.test file - is that what is required to solve this problem in Drupal 7.14 (tried it anyway - didnt change anything - still errors)

Please where is the patch for Drupal 7.14?

Regards,

bojanz’s picture

@ilechcod
The only patches here are the ones that caused your problem :)
Your problem is caused by a contrib module that needs updating. Probably Entity API (you need 7.x-1.x-dev, not RC2).
I know Commerce got updated in version 1.3. Not sure if any other contribs were affected.

Louis Bob’s picture

Updated Entity API module from RC2 to dev: no more errors, thanks Bojanz !

Status: Fixed » Closed (fixed)

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

effulgentsia’s picture

For people here with real world experience of what hook_options_list() and friends require, please provide some feedback on #1974444: Narrow the API of hook_options_list() and friends. Thanks!

yched’s picture

Issue summary: View changes

FYI : #2238085: [regression] options_allowed_values() signature doesn't allow for Views filter configuration questions whether we want to keep supporting that feature in D8.
See #35 / #37 over there.