Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.I got this error on installing a custom module, that includes a custom product variation type:
PHP Fatal error: Call to a member function getId() on null in /var/www/drupalv/drupal/modules/commerce/src/Resolver/DefaultLocaleResolver.php on line 45
Drush command terminated abnormally due to an unrecoverable error. [error]
Error: Call to a member function getId() on null in
/var/www/drupalvm/drupal/modules/commerce/src/Resolver/DefaultLocaleResolver.phpAs soon as I set the price field to "hidden" in both entity form display AND entity view display, the installation of my module suceeds. Afterwards I can enable the price field via admin UI without any problems.
The strange thing is, when you look at the source code, that the simple call to $this->languageManager->getConfigOverrideLanguage() seems to return NULL -> how is this possible? Should this ever be possible to happen? Is this a core bug? Or a configuration problem? However, I've never experienced this or a similar problem with any other configuration entity I include in any of our my modules.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | call_to_a_member-2683993-11.patch | 2.08 KB | borisson_ |
| #7 | 2683993-7.patch | 1.63 KB | agoradesign |
Comments
Comment #2
bojanz CreditAttribution: bojanz at Centarro commentedYeah, looks like it's the same as in #2665322: Adding Price field having many languages cause DefaultLocaleResolver issue.
Our code makes an assumption that getConfigOverrideLanguage() is never NULL, we need to investigate if/why that is incorrect.
Comment #3
agoradesign CreditAttribution: agoradesign commentedWell, that's understandable. When looking into getConfigOverrideLanguage(), one should think, that this should really never happen, as internally (LanguageManager) $this->getCurrentLanguage() gets called, which itself calls getDefaultLanguage(). It's rather unlogical, that this can end up in NULL
Comment #4
XanoComment #5
XanoOn multilingual sites,
ConfigurableLanguageManageris used instead.Comment #6
agoradesign CreditAttribution: agoradesign commentedThanks for clarification - I've already guessed that, when I had a look at your patch - which seems to work for me. But I haven't tried the exactly same situation as described above, so I can't confirm this for 100%.
Comment #7
agoradesign CreditAttribution: agoradesign commentedAs I don't want to use the patch/workaround from #2684873: ConfigurableLanguageManager::getConfigOverrideLanguage() returns NULL anymore, I've created a patch that I currently use to add the fallback within Commerce. I can add a test to DefaultLocaleResolverTest too, but at the moment I only have the patch itself, so that others can benefit from it in the meantime and I've a publicly available patch for my build process :D
Comment #8
bojanz CreditAttribution: bojanz at Centarro commentedBetter title. Marked #2665322: Adding Price field having many languages cause DefaultLocaleResolver issue as duplicate.
Comment #9
bojanz CreditAttribution: bojanz at Centarro commentedThe core issue never landed, looks like we're going to need to add a workaround after all.
Comment #10
borisson_I'll have a look at this.
Comment #11
borisson_I didn't notice that there was already a patch provided. I did pretty much the same thing and tested that it works. Want me to open a PR for this?
Comment #12
borisson_Unassigning.
Comment #13
bojanz CreditAttribution: bojanz at Centarro commentedOkay, let's see.
Comment #15
bojanz CreditAttribution: bojanz at Centarro commentedCommitted a variant of #7, with a bit of additional cleanup. Thanks, everyone.
Comment #16
agoradesign CreditAttribution: agoradesign commentedYeaaaaaah! Finally, the oldest of my applied Commerce patches is gone, an old and reliable companion is gone :D :)