Error on call to getLocality() on null

The odd thing is, we already have a check:

    $value = $this->getValue($values);
    if (empty($value) || empty($this->options['display_name'])) {
      return $this->sanitizeValue($value);
    }

If the subdivision value is empty, we stop right there.
The question is, how can the subdivision value be non-empty, but the parent address be empty.
Could you var_dump $value, to check what's there?

No further information provided.

I'm having the same issue on 8.x-1.8

attached patch fixed the issue for me

I have come across this error on a client's website.

Steps to reproduce:

1. Enable multisite and address module
2. Add address field onto a content type (make field translatable)
3. Create a content and translate it to another language
4. Add the address field content to both languages
5. Remove the address field content from the original language
6. Create a view listing the address fields on the translated language

Patch on #4 worked for me.

I'm having this issue on my project using version 2.0.2.
Not sure exactly which steps could be taken to reproduce it yet.

Here's the exact error message :

Message	Error: Call to a member function getLocality() on null in Drupal\address\Plugin\views\field\Subdivision->render() (line 103 of /var/www/html/web/modules/contrib/address/src/Plugin/views/field/Subdivision.php).
Severity	Error
Backtrace	
#0 /var/www/html/web/core/modules/views/src/Plugin/views/field/FieldPluginBase.php(1202): Drupal\address\Plugin\views\field\Subdivision->render()
#1 /var/www/html/web/core/modules/views/views.theme.inc(238): Drupal\views\Plugin\views\field\FieldPluginBase->advancedRender()
#2 [internal function]: template_preprocess_views_view_field()
#3 /var/www/html/web/core/lib/Drupal/Core/Theme/ThemeManager.php(261): call_user_func_array()
#4 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(491): Drupal\Core\Theme\ThemeManager->render()
#5 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(248): Drupal\Core\Render\Renderer->doRender()
#6 /var/www/html/web/core/modules/views/src/Plugin/views/field/FieldPluginBase.php(1796): Drupal\Core\Render\Renderer->render()
#7 /var/www/html/web/core/modules/views/src/Plugin/views/style/StylePluginBase.php(769): Drupal\views\Plugin\views\field\FieldPluginBase->theme()
#8 [internal function]: Drupal\views\Plugin\views\style\StylePluginBase->elementPreRenderRow()
#9 /var/www/html/web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(113): call_user_func_array()
#10 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(870): Drupal\Core\Render\Renderer->doTrustedCallback()
#11 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(432): Drupal\Core\Render\Renderer->doCallback()
#12 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(248): Drupal\Core\Render\Renderer->doRender()
#13 /var/www/html/web/core/modules/views/src/Plugin/views/style/StylePluginBase.php(708): Drupal\Core\Render\Renderer->render()
#14 /var/www/html/web/core/modules/views/src/Plugin/views/style/StylePluginBase.php(574): Drupal\views\Plugin\views\style\StylePluginBase->renderFields()
#15 /var/www/html/web/core/modules/views/src/Plugin/views/style/StylePluginBase.php(465): Drupal\views\Plugin\views\style\StylePluginBase->renderGrouping()
#16 /var/www/html/web/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php(2177): Drupal\views\Plugin\views\style\StylePluginBase->render()
#17 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1593): Drupal\views\Plugin\views\display\DisplayPluginBase->render()
#18 /var/www/html/web/core/modules/views/src/Plugin/views/display/Page.php(201): Drupal\views\ViewExecutable->render()
#19 /var/www/html/web/core/modules/views/src/ViewExecutable.php(1690): Drupal\views\Plugin\views\display\Page->execute()
#20 /var/www/html/web/core/modules/views/src/Element/View.php(81): Drupal\views\ViewExecutable->executeDisplay()
#21 [internal function]: Drupal\views\Element\View::preRenderViewElement()
#22 /var/www/html/web/core/lib/Drupal/Core/Security/DoTrustedCallbackTrait.php(113): call_user_func_array()
#23 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(870): Drupal\Core\Render\Renderer->doTrustedCallback()
#24 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(432): Drupal\Core\Render\Renderer->doCallback()
#25 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(248): Drupal\Core\Render\Renderer->doRender()
#26 /var/www/html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(238): Drupal\Core\Render\Renderer->render()
#27 /var/www/html/web/core/lib/Drupal/Core/Render/Renderer.php(638): Drupal\Core\Render\MainContent\HtmlRenderer->Drupal\Core\Render\MainContent\{closure}()
#28 /var/www/html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(239): Drupal\Core\Render\Renderer->executeInRenderContext()
#29 /var/www/html/web/core/lib/Drupal/Core/Render/MainContent/HtmlRenderer.php(128): Drupal\Core\Render\MainContent\HtmlRenderer->prepare()
#30 /var/www/html/web/core/lib/Drupal/Core/EventSubscriber/MainContentViewSubscriber.php(90): Drupal\Core\Render\MainContent\HtmlRenderer->renderResponse()
#31 /var/www/html/web/modules/contrib/tracer/src/EventDispatcher/TraceableEventDispatcher.php(97): Drupal\Core\EventSubscriber\MainContentViewSubscriber->onViewRenderArray()
#32 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(186): Drupal\tracer\EventDispatcher\TraceableEventDispatcher->dispatch()
#33 /var/www/html/vendor/symfony/http-kernel/HttpKernel.php(76): Symfony\Component\HttpKernel\HttpKernel->handleRaw()
#34 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/Session.php(53): Symfony\Component\HttpKernel\HttpKernel->handle()
#35 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(48): Drupal\Core\StackMiddleware\Session->handle()
#36 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ContentLength.php(28): Drupal\Core\StackMiddleware\KernelPreHandle->handle()
#37 /var/www/html/web/core/modules/big_pipe/src/StackMiddleware/ContentLength.php(32): Drupal\Core\StackMiddleware\ContentLength->handle()
#38 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\big_pipe\StackMiddleware\ContentLength->handle()
#39 /var/www/html/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass()
#40 /var/www/html/vendor/asm89/stack-cors/src/Cors.php(53): Drupal\page_cache\StackMiddleware\PageCache->handle()
#41 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(48): Asm89\Stack\Cors->handle()
#42 /var/www/html/web/modules/contrib/tracer/src/StackMiddleware/TracesMiddleware.php(38): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle()
#43 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(51): Drupal\tracer\StackMiddleware\TracesMiddleware->handle()
#44 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/AjaxPageState.php(36): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle()
#45 /var/www/html/web/modules/contrib/remove_http_headers/src/StackMiddleware/RemoveHttpHeadersMiddleware.php(49): Drupal\Core\StackMiddleware\AjaxPageState->handle()
#46 /var/www/html/web/core/lib/Drupal/Core/StackMiddleware/StackedHttpKernel.php(51): Drupal\remove_http_headers\StackMiddleware\RemoveHttpHeadersMiddleware->handle()
#47 /var/www/html/web/core/lib/Drupal/Core/DrupalKernel.php(741): Drupal\Core\StackMiddleware\StackedHttpKernel->handle()
#48 /var/www/html/web/index.php(19): Drupal\Core\DrupalKernel->handle()
#49 {main}

After checking branch 2.1.x, I see that no null checks are made on the ItemList->first() function which, contrary to documentation, can return null. This is found in /src/Plugin/views/field/Subdivision.php
The error occurs when trying to access a view page having an address field.
Most probably, the data I have came from some Migrate import, which could explain why not all fields were filled in.

I suggest adding null-handling in the code.

I encountered the same error when attempting to add address subfields like "Content: Address:locality" in Drupal Views. The error message is: Error: Call to a member function getLocality() on null in Drupal\address\Plugin\views\field\Subdivision->render() (line 103 of /var/www/html/web/modules/contrib/address/src/Plugin/views/field/Subdivision.php).
I have re-roll the patch with 2.0.x branch.

I encountered the same issue, after migrating.
Manually implementing patch as described in #12 solved the issue. (automatic patch application with composer did not work).
Will this get integrated in the next release of the address module?

#11 is right, I received a bug report with the following error logged:

Error: Call to a member function first() on null in Drupal\address\Plugin\views\field\Subdivision->render() (line 91 of modules/contrib/address/src/Plugin/views/field/Subdivision.php).

According to the bug report it happened during a very long CSV export of 40000 records. I did not have the patience to replicate it, but the solution seems clear, we have to check the return value as proposed by @kenowax.

I will update the MR.

Created new MR against 2.0.x. It looks like 2.1.x has not been worked on for a long time, and 2.0.x is more recent. I can rebase against 2.1.x if needed.

Hiding patches, drupal.org is moving to merge requests. See Using Gitlab to contribute to Drupal.

I was able to reproduce it thanks to comment #5. However, the solution in the MR didn't cover the case when the translation has a value for "address" while the original language doesn't. With this type of scenario, the condition if (empty($value) || empty($this->options['display_name'])) { will not pass and code will proceed. But, $entity = $this->getEntity($values); will return the original entity even if the interface language is different. This leads to an empty result in the views, while it really exists.
I've modified the MR to return the 'value' instead of an empty string, so we don't lose it.

Looks good to me!

Thanks for working on this.

Side note: we don't need separate MRs for 2.1.x and 2.0.x unless there are conflicts or something. Would have been happy to continue in !75 instead of opening an identical !89 that targets a different branch.

That said, I'm not terribly psyched about committing "fixes" like this. This code is a views plugin for an address field. Why wouldn't we have an address field?

    // Skip if the address is not populated on the field for some reason.

This "fix" seems like it's only further hiding some deeper bug that's going to be even harder to find and fix if we commit this. I'd rather we spent the effort to figure out what "some reason" actually is and correct that, not just wrap it in ?-> and further confuse people who are expecting a subdivision in their view and getting nothing instead. I'm not going to go so far as to say we should throw an Exception here and completely blow up in someone's face if they've gotten into whatever situation causes this. But I'm not really in favor of silently ignoring uncomfortable situations where reality doesn't match the code's expectations.

@dww, the main issue here, at least in a way that I was able to reproduce it based on comment #5, is that the getEntity method loads the entity with the default language. The default views field plugin (EntityField) loads the entity translation in the getValue and gets the value from it instead of the original entity, which is used in Subdivision. I'm unsure if we can extend EntityField instead of FieldPluginBase, or if it's better to duplicate the logic and try to get the translated entity first.