Problem/Motivation

PHPStand command failed while trying to check for deprecated drupal 8 code.

Steps to reproduce

In our semi composer set up, we have modules/custom. When trying to check against them, they all throw this error.
Problem is that following is TRUE and not a class.
/** @var \Composer\Autoload\ClassLoader $loader */
$loader = require __DIR__ . '/../../autoload.php';

Running drupal-check gives me the same issue:

wodby@php.container:/var/www/html/drupal/vendor/bin $ ./drupal-check -ad ../../modules/custom/ --drupal-root=/var/www/html/drupal
Error thrown in /var/www/html/drupal/core/tests/bootstrap.php on line 141 while loading bootstrap file /var/www/html/drupal/vendor/mglaman/phpstan-drupal/drupal-autoloader.php: Call to a member function add() on bool

Am I the only one facing this?

Comments

ichionid created an issue. See original summary.

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy at Acquia commented

Are you running upgrade status with drush or on the UI? Does this only happen for custom modules and not contributed projects?

ichionid’s picture

ichionid CreditAttribution: ichionid commented
Issue summary: View changes
ichionid’s picture

ichionid CreditAttribution: ichionid commented

Only for custom modules in the UI. Happens also in the console. Contrib modules reside in my composer.json file.

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy at Acquia commented

Hm, why does it use core/tests/bootstrap.php? Did you add the phpunit test dependencies as per the project page?

ichionid’s picture

ichionid CreditAttribution: ichionid commented

Done nothing special rather than running the modules. There are phpunit dependencies in code. But could it be that it is only working for composer based installations? I noticed, trying to use composerize, that it removed the autoload.php file fx. Makes me wonder if the standard non-composer is not supported.

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy at Acquia commented

The project page explains how to set up a composer based setup for testing if your site is not using composer. Did you follow that? I wonder how did you install the module without composer if you are not using composer?

ichionid’s picture

ichionid CreditAttribution: ichionid commented

Maybe I am not getting through. We're using a composer set up. We're however not having the same structure as https://github.com/drupal-composer/drupal-project
We have our modules under modules/custom and not web/modules/custom fx
I did follow the instruction for moving my modules/custom to web/modules/custom but it does not make any difference.

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy at Acquia commented

Hm, that IMHO should not change how the module finds things. Your custom modules could be in web/modules/foo/bar/modules/modules/foo or whatnot. As long as Drupal understands that they are there (ie. they were installed from there).

ichionid’s picture

ichionid CreditAttribution: ichionid commented

Ended up using a dockerized version of drupal-check. This is very weird.

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy at Acquia commented

Hm, does that work?

ichionid’s picture

ichionid CreditAttribution: ichionid commented

Yes my workaround is to use the dockerized version and move all my custom modules to a fresh composer project just to run the checks there. Workaround to this madness :p

mglaman’s picture

mglaman
Primary language English
Location WI, USA
CreditAttribution: mglaman at Bluehorn Digital for Palantir.net commented

Due to some fancy PHPUnit bridge work in Drupal, we need to call the PHPUnit bootstrap script to fix some namespaces. I have tried avoiding this but cannot seem to get it to work just right.

It looks like require is returning true because the autoloader in /web or /docroot has already been loaded: Actually, returning TRUE is the behavior of include_once or require_once. So I am not sure why it would return TRUE over anything else.

  /** @var \Composer\Autoload\ClassLoader $loader */
  $loader = require __DIR__ . '/../../autoload.php';

OR! Are you not on a Composer based build and this is a general problem since the Drupal "fake" autoloader is the main one?

Here is where phpstan-drupal includes the bootstrap.php to work around PHPUnit bridge problems

https://github.com/mglaman/phpstan-drupal/blob/main/src/Drupal/DrupalAut...

        // @todo stop requiring the bootstrap.php and just copy what is needed.
        if (interface_exists(\PHPUnit\Framework\Test::class)) {
            require_once $this->drupalRoot . '/core/tests/bootstrap.php';

Actually, did I screw up by calling require_once above? Which broke later inclusions.

mglaman’s picture

mglaman
Primary language English
Location WI, USA
CreditAttribution: mglaman at Bluehorn Digital for Palantir.net commented

I made this PR to clean up part of the loading to see if require_once is needed or not, because maybe that's the problem: https://github.com/mglaman/phpstan-drupal/pull/203

@ichionid can you hack your local files to replace require_once with require in the phpstan-drupal DrupaAutoloader to see if that makes a difference?

ichionid’s picture

ichionid CreditAttribution: ichionid commented

@mglaman thanks! Will follow up shortly next week :)

mglaman’s picture

mglaman
Primary language English
Location WI, USA
CreditAttribution: mglaman at Bluehorn Digital for Palantir.net commented
Status: Active » Postponed (maintainer needs more info)

Cool, thanks @ichionid! I'm pushing to needs more info for now, to make the queue easier to manage.

mglaman’s picture

mglaman
Primary language English
Location WI, USA
CreditAttribution: mglaman at Bluehorn Digital for Palantir.net commented

I merged the PR anyways since tests were green. A new release will be out with the fix. Let me know if its still a problem.

ichionid’s picture

ichionid CreditAttribution: ichionid commented

First thing tomorrow. Thanks! :)

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy at Acquia commented
Category: Support request » Bug report
Status: Postponed (maintainer needs more info) » Fixed

@ichionid had other priorities I think :) It looks like we can close this though as the underlying issue has been fixed.

Status: Fixed » Closed (fixed)

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