[Console] PHP Fatal error: Call to a member function getId() on null

[ismailcherri]

[ERROR] PHP Fatal error: Call to a member function getId() on null in /core/modules/user/src/PrivateTempStore.php on line 204

Hi, I get this error when I try to execute any Console command with a custom block enabled on every page of my Drupal 8.2.5 installation.
The block in question try to extract variable from the user private temp store using class \Drupal\user\PrivateTempStoreFactory
The problem is in this line of code in User core module:

return $this->currentUser->id() ?: $this->requestStack->getCurrentRequest()->getSession()->getId();

The user module is trying to get a session but it seems that it doesn't exist on CLI of Console.
My workarround for now is to add a check if (php_sapi_name() !== 'cli') before trying to get the store.

My question is:
Is this a core bug or a console bug?

[jmolivas]

@ismailcherri Can you try with latest DC versionRC-15 and comment back if still happening.

[ismailcherri]

Hi,
I updated DC to rc-15 and I get the same error.
This is a very specific situation I know, but it happens if the front page has anything that uses \Drupal\user\PrivateTempStore class.
In my case, I'm starting a session for anonymous user and storing some data which I get in a block on the home page which triggers the error with Drupal Console.

So let me rephrase my original question, is what I'm doing wrong? Should I use another method to store temporary data for anonymous users? Or this is a console and/or core bug?

Thanks!

[sedax90]

Same configuration and same problems of @ismailcherri

[bkildow]

I'm also seeing the same issue with RC-16. In a custom module, I'm starting sessions for anonymous users, and using PrivateTempStore to get data out of it. I'm seeing the same error as above.

[bkildow]

I should note that this was being called from a cache context. I added a workaround similar to what @ismailcherri is doing with checking for 'cli'. Now I'm seeing a similar issue with the Masquerade module: Fatal error: Call to a member function has() on null in modules/contrib/masquerade/src/Cache/MasqueradeCacheContext.php on line 36

The offending code is:

  /**
   * {@inheritdoc}
   */
  public function getContext() {
    return $this->requestStack
      ->getCurrentRequest()
      ->getSession()
      ->has('masquerading');
  }

So I guess the question is, is it possible to get sessions and the requestStack working with Drupal Console? What's odd is that I was able to use Drupal Console previously, so I'll need to track down what changed. I believe we upgraded our version of Drupal Console recently.

[christofferbergj]

I suddenly can't use any drupal console commands either, getting a similar bug.

Error: Call to a member function getId() on null in /var/www/docroot/core/lib/Drupal/Core/Cache/Context/SessionCacheContext.php on line 25 #0 /var/www/docroot/core/lib/Drupal/Core/Cache/Context/CacheContextsManager.php(118): Drupal\Core\Cache\Context\SessionCacheContext->getContext(NULL)

Drupal core 8.3.1
Drupal Console 1.0.0-alpha1

[jmolivas]

@Christofferberg Drupal Console 1.0.0-alpha1 is kinda outdated could you update to latest version https://docs.drupalconsole.com/en/getting/project.html

[christofferbergj]

@jmolivas Sorry, that was my local version, my containerized drupal console is running version 1.0.0-rc16 and it's the same.

[noelrivasc]

I'm using version 1.0.0-rc18 and stumbled upon the same problem @Christofferberg had. I applied the if (php_sapi_name() !== 'cli') workaround as described by @ismailcherri and console is working again.

Additional info: this only happens when I have a particular theme enabled, a sub-theme of Gesso. There isn't any relevant code in the theme, so it is probably related to the presence of custom blocks.

[james-nesbitt]

Let's see if we can get a core d.org issue, to see if we can do some safe wrapping on that core context service.

[ArtuGit]

I have a similar issue:
Fatal error: Call to a member function getId() on null in /var/www/drupalvm/mysite/web/core/lib/Drupal/Core/Cache/Context/SessionCacheContext.php on line 25
on:

Drupal Console Launcher version 1.0.0-rc20
Drupal Console version 1.0.0-rc20
Drupal version 8.3.2 

@nelovishk Yes, it is the theme related issue. It happens only when my custom Bootstrap theme is activated.
it displays the theme source code before the listing of the errors.
The theme is in Debug Mode.

@ismailcherri's workaround works too in my case.

Thank you, the both.

How to solve it correctly?

[skvskv]

Same nasty issue with 1.0.0-rc21
The thing seems totally fucked up having no fix for half a year.

[jmolivas]

@skvskv We need a way to identify and replicate in order to have this fixed. Did the workaround works for you?

[ismailcherri]

@jmolivas In order to reproduce you need the following:

1. Create a custom module (drupal generate:module)
2. Create a custom block in the module (drupal generate:plugin:block)
3. Place the block into any region of the active theme leaving its visibility to all pages
4. Use the following code:

namespace Drupal\block_test\Plugin\Block;

use Drupal\Core\Block\BlockBase;
use Drupal\Core\Plugin\ContainerFactoryPluginInterface;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Drupal\user\PrivateTempStoreFactory;
use Drupal\Core\Session\AccountProxy;

/**
 * Provides a 'DefaultBlock' block.
 *
 * @Block(
 *  id = "default_block",
 *  admin_label = @Translation("Default block"),
 * )
 */
class DefaultBlock extends BlockBase implements ContainerFactoryPluginInterface {

  /**
   * Drupal\user\PrivateTempStoreFactory definition.
   *
   * @var \Drupal\user\PrivateTempStoreFactory
   */
  protected $userPrivateTempstore;
  /**
   * Drupal\Core\Session\AccountProxy definition.
   *
   * @var \Drupal\Core\Session\AccountProxy
   */
  protected $currentUser;
  /**
   * Constructs a new DefaultBlock object.
   *
   * @param array $configuration
   *   A configuration array containing information about the plugin instance.
   * @param string $plugin_id
   *   The plugin_id for the plugin instance.
   * @param string $plugin_definition
   *   The plugin implementation definition.
   */
  public function __construct(
        array $configuration,
        $plugin_id,
        $plugin_definition,
        PrivateTempStoreFactory $user_private_tempstore, 
	AccountProxy $current_user
  ) {
    parent::__construct($configuration, $plugin_id, $plugin_definition);
    $this->userPrivateTempstore = $user_private_tempstore;
    $this->currentUser = $current_user;
	$store = $this->userPrivateTempstore->get('block_test_data');
	$data = $store->get('some_dummy_data');
  }
  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
    return new static(
      $configuration,
      $plugin_id,
      $plugin_definition,
      $container->get('user.private_tempstore'),
      $container->get('current_user')
    );
  }
  /**
   * {@inheritdoc}
   */
  public function build() {
    $build = [];
    $build['default_block']['#markup'] = 'Implement DefaultBlock.';

    return $build;
  }

}

5. run any drupal console command afterwards... 😄

[tuag]

@jmolivas I can verify that what @ismailcherri reported is still present in DC version RC-23 (and Drupal 8.3.4). I have pretty much the same conditions he has described.

Looking into PrivateTempStore::getOwner() a little closer, it's not testing for a null session.
To me that looks like a core bug. I think it makes sense to add the check here rather than checking for cli in some higher level context.

[CaioBianchi]

@jmolivas This is still happening with the latest version of everything (Drupal core and console [rc-25])

PrivateTempStore::getOwner() error

[CaioBianchi]

This remains an issue on the 1.0.1 release. Is there a workaround for this without having to hack the core?

[sebas5384]

I can confirm that this issue still remains.

Maybe this could help: https://www.drupal.org/node/2839523

[sebas5384]

It appears to a be a module's problem, but I don't know why I never had that kind of problem with Drush.

Anyways here's my patch to the Miling List module, which was the problem in my case:
https://www.drupal.org/node/2908343

If you came here and you don't have the Mailing List module installed, check if there's any of your modules are using session even when is anonymous, and try to check if session is available before is used and then check if Drupal console is back again.

Cheers.

[lauriskuznecovs]

My solution was adding back language I removed and removing all the content in that particular language, also custom blocks needs to be deleted. Then you can safely remove language and no errors.

[skvskv]

Thank God I've finally quit developing for Drupal!
Hope all participants finally find their relief either way :-)

[citlacom]

Hi @ismailcherri and the other guys here,

I have experimented similar issues as described here and tried to solve with the suggested workaround but I found another issue: #3553

I have dedicated few days to try to make our project compatible with 1.0.2 and worked on a fix that I just requested pull request #3558 to @jmolivas or @enzolutions that you can help to test and confirm if solves your issues.

If you are interested to try here is the changes you need to do on your composer.json file:

Add my fork on your repositories:

    "repositories": {
      "console": {
        "type": "vcs",
        "url": "https://github.com/citlacom/drupal-console"
      }
    },

Change your require of drupal/console to:

"drupal/console": "dev-experimentation-fix-issue-3553 as 1.0.2",

Run the command:

composer update drupal/console --with-dependencies --prefer-source

Go to "vendor/drupal/console" or whatever is your vendor directory and ensure that composer have updated to my fork and fix branch "experimentation-fix-issue-3553". You can do that just running "git status" and look that you are "On branch experimentation-fix-issue-3553". In case composer do not upgrade to the fork try to remove the drupal vendor directory and it's contents and try again the composer update command.

Finally run your custom commands and confirm here if this issue go away.

Thanks.

[jmolivas]

@ismailcherri @CRYX2 @bkildow @Christofferberg @noel-rivas @james-nesbitt @ArtuGit @skvskv @tuag @CaioBianchi @sebas5384 @lauriskuznecovs @citlacom
PR by @citlacom including the fix was merged and a new release 1.1.0 tagged feel free to test and comment if the issues was fixed or still happening.

[ismailcherri]

@jmolivas Tested with version 1.1.0 and the issue is fixed.
Many thanks

[citlacom]

Hi @jmolivas - I have tested our custom Drupal Console commands after upgrade to 1.1.0 and worked perfectly. Many thanks for review the PR and released the new version. Have a great week!

[LOBsTerr]

@jmolivas The issue can be closed

[jmolivas]

Closing this one. Feel free to re-open if still happening after updating to the latest version.