I've just updated all the code to the latest version.
When I started my installation profile I came across this error message:
Fatal error: Unsupported operand types in drupal\modules\user\user.module on line 185
Since the install profile worked just fine before I assume the issue is related to the new alter hook user_field_info_alter introduced by #501408: Display user fields on registration form.
I suppose to add a check like if (isset($info[$field_type]['instance_settings'])) { in the loop.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

yched’s picture

http://api.drupal.org/api/drupal/modules--field--field.info.inc/function...

_field_info_collate_types() takes care of initializing $info[$field_type]['instance_settings'] to an empty array before calling drupal_alter('field_info'), so this should normally not be needed.

das-peter’s picture

Thanks yched for the hint - brought me on the right trace.

Within a installation profile it can happen, that the order of installing modules is "special". In my case it looks like the entity module is installed before the basic modules for list, text, taxaonomy and integer fields are enabled.
Now the entity module implements

entity_metadata_field_info_alter/code> and that in a static way:
<code>
function entity_metadata_field_info_alter(&$field_info) {
  // Field API lists are key/value pairs but not multiple valued by default.
  $field_info['list']['property_type'] = 'integer';
  $field_info['list_boolean']['property_type'] = 'boolean';
...

This explains the sudden occurrence of fields without the basic setup as provided by _field_info_collate_types. :|

Approaches to solve this I see at the moment:
- Add dependencies to these modules in the entity module.
- Add an appropriate check if the field exists in entity_metadata_field_info_alter.

I'll take a look with fago how we wanna proceed.

das-peter’s picture

To stay as flexible as possible I guess we shouldn't introduce module dependencies.
Thus the attached patch adds checks in the hook implementation.

Status: Needs review » Needs work
yched’s picture

Project: Drupal core » Entity API
Version: 7.x-dev » 7.x-1.x-dev
Component: user system » Entity Metadata - main

Sounds reasonable - Moving over to entity_api, then.

mgifford’s picture

subscribe

fago’s picture

ouch. Indeed, we really need this checks, however let's just check the providing modules with one module_exists() call per module.

rszrama’s picture

Wonderful! I've literally been beating my head against this all afternoon and was planning on staying up late to find a solution. Glad to see Peter was already digging it out. : )

Will see if I can rewrite per fago's comment #7.

rszrama’s picture

Title: Display user fields on registration form - missing check » Check for modules to prevent altering non-existent field info arrays
Status: Needs work » Needs review

Patch attached. I took out the inline comment, because I had no clue what it meant and didn't see how it was relevant to the code in there now. : ?

rszrama’s picture

Site error prevented patch from attaching in previous comment.

das-peter’s picture

Status: Needs review » Reviewed & tested by the community

Thanks Ryan, your patch looks definitely better.
Just tested it and no evil surprises at all.

sun’s picture

Status: Reviewed & tested by the community » Needs work
+++ entity_metadata/entity_metadata.module	2 Dec 2010 05:06:38 -0000
@@ -217,25 +217,36 @@ function entity_metadata_get_list($data,
+    $field_info['text']['property_callbacks'] = array('entity_metadata_field_text_property_callback');
...
+    $field_info['text_long']['property_callbacks'] = array('entity_metadata_field_text_property_callback');
...
+    $field_info['text_with_summary']['property_callbacks'] = array('entity_metadata_field_text_property_callback');
...
+    $field_info['taxonomy_term_reference']['property_callbacks'] = array('entity_metadata_field_term_reference_callback');

Should use [] syntax. Otherwise, this alter hook potentially overwrites an earlier alter hook.

Powered by Dreditor.

das-peter’s picture

Status: Needs work » Needs review
FileSize
2.55 KB

Hints from sun integrated.

sun’s picture

Status: Needs review » Reviewed & tested by the community

Looks good, thanks!

mrfelton’s picture

This one stopped me from being able to migrate a site from beta3 to rc1. Patch in #13
resolved. Thanks.

fago’s picture

Status: Reviewed & tested by the community » Fixed

thanks, committed!

tstoeckler’s picture

Status: Fixed » Needs work

If I'm not missing something, both the patch and the commit are missing the following hunk (present in #10):

+++ entity_metadata/entity_metadata.module	2 Dec 2010 05:06:38 -0000
@@ -217,25 +217,36 @@ function entity_metadata_get_list($data,
+  if (module_exists('list')) {
+    $field_info['list']['property_type'] = 'integer';
+    $field_info['list_boolean']['property_type'] = 'boolean';
+    $field_info['list_number']['property_type'] = 'decimal';
+    $field_info['list_text']['property_type'] = 'text';
+  }
fago’s picture

Status: Needs work » Fixed

Indeed, thanks - I corrected that.

yched’s picture

Note : that last hunk will need changes if we succeed in bringing sanity to the 'list' field types - #932502: Changing allowed values in "List" fields

rszrama’s picture

I was worried about that. Entity's alterations to field info and I believe token info arrays have caused unexpected problems before... altering can be so brittle. I wonder if there could be a way to provide meaningful error messages from this module when altering goes awry. : ?

fago’s picture

Hm, when would show this error messages? Do you know which problems do you ran over?

rszrama’s picture

My problems were with data in the Token info before. I'm not really sure how to develop an intelligent error message for that, though... it's a general Drupal problem, really, of knowing what module is altering a structured info array first. Being able to pinpoint when alterations are causing problems is difficult, because you don't really know if it's a problem with the code using the data or the code altering it.

So... I guess I don't know, but if anything comes to mind I'll be sure to give it a shot and post an issue. ; )

fago’s picture

Sounds good, thanks!

sun’s picture

Status: Fixed » Needs review
FileSize
1009 bytes

#932502: Changing allowed values in "List" fields has been committed yesterday, so this code needs an update, as I'm getting the following fatal error/WSOD now:

Fatal error: Unsupported operand types in modules\user\user.module on line 186
fago’s picture

Looks good, thanks.

However, I'd like to roll another beta release asap, once #988780: Merge both modules into one has been fixed. But I guess the release should be still compatible with the latest RC, so I think it's best to postpone this fix until we have the next beta out. Weird.

fago’s picture

Status: Needs review » Reviewed & tested by the community

This is ready though.

sun’s picture

the release should be still compatible with the latest RC

Hm, tough question. In reality, the d.o project release system would need to allow for a more specific core compatibility; i.e., DRUPAL-7--0-RC2--1--0-BETA2 UGH.

However, in general, I'd rather recommend to commit this; optionally add a note to the project page that latest HEAD is required until D7.0.

Actually, I think it may also be technically enforced through the .info file:

; Ensure that we are on Drupal 7 >RC2.
dependencies[] = system (>7.0-RC2-1.x)

or similar... didn't work with those yet.

fago’s picture

Status: Reviewed & tested by the community » Fixed

thanks, I just rolled the release and committed this. So the dev version is now compatible with d7 HEAD, while beta4 works with RC2.

@info file:
Yep, that would be great. Had no time to have a closer look at it either :(

Status: Fixed » Closed (fixed)

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