Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#24 | entity.list-field-info.24.patch | 1009 bytes | sun |
#13 | 986046-13.field_info_alter.module_exists.patch | 2.55 KB | das-peter |
#10 | 986046.field_info_alter.module_exists.patch | 3.21 KB | rszrama |
#3 | entity-add-check-to-entity_metadata_field_info_alter-986046-3.patch | 3.16 KB | das-peter |
user-field_user_register-missing-check.patch | 651 bytes | das-peter | |
Comments
Comment #1
yched CreditAttribution: yched commentedhttp://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.
Comment #2
das-peter CreditAttribution: das-peter commentedThanks 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
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.
Comment #3
das-peter CreditAttribution: das-peter commentedTo stay as flexible as possible I guess we shouldn't introduce module dependencies.
Thus the attached patch adds checks in the hook implementation.
Comment #5
yched CreditAttribution: yched commentedSounds reasonable - Moving over to entity_api, then.
Comment #6
mgiffordsubscribe
Comment #7
fagoouch. Indeed, we really need this checks, however let's just check the providing modules with one module_exists() call per module.
Comment #8
rszrama CreditAttribution: rszrama commentedWonderful! 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.
Comment #9
rszrama CreditAttribution: rszrama commentedPatch 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. : ?
Comment #10
rszrama CreditAttribution: rszrama commentedSite error prevented patch from attaching in previous comment.
Comment #11
das-peter CreditAttribution: das-peter commentedThanks Ryan, your patch looks definitely better.
Just tested it and no evil surprises at all.
Comment #12
sunShould use [] syntax. Otherwise, this alter hook potentially overwrites an earlier alter hook.
Powered by Dreditor.
Comment #13
das-peter CreditAttribution: das-peter commentedHints from sun integrated.
Comment #14
sunLooks good, thanks!
Comment #15
mrfelton CreditAttribution: mrfelton commentedThis one stopped me from being able to migrate a site from beta3 to rc1. Patch in #13
resolved. Thanks.
Comment #16
fagothanks, committed!
Comment #17
tstoecklerIf I'm not missing something, both the patch and the commit are missing the following hunk (present in #10):
Comment #18
fagoIndeed, thanks - I corrected that.
Comment #19
yched CreditAttribution: yched commentedNote : that last hunk will need changes if we succeed in bringing sanity to the 'list' field types - #932502: Changing allowed values in "List" fields
Comment #20
rszrama CreditAttribution: rszrama commentedI 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. : ?
Comment #21
fagoHm, when would show this error messages? Do you know which problems do you ran over?
Comment #22
rszrama CreditAttribution: rszrama commentedMy 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. ; )
Comment #23
fagoSounds good, thanks!
Comment #24
sun#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:
Comment #25
fagoLooks 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.
Comment #26
fagoThis is ready though.
Comment #27
sunHm, 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:
or similar... didn't work with those yet.
Comment #28
fagothanks, 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 :(