Closed (fixed)
Project:
Upgrade Status
Version:
8.x-3.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
16 Jun 2020 at 10:32 UTC
Updated:
2 Oct 2020 at 12:49 UTC
Jump to comment: Most recent, Most recent file

Comments
Comment #2
maxilein commentedComment #3
maxilein commentedIt is preceded by a batch error from upgrade_status:
Message: PHPStan failed:
but that's it.
Comment #4
gábor hojtsyThe phpstan failure message should be recorded in your log. If you have dblog module enabled you will find it there. Can you post that here? Also which project was being scanned while this error happened?
Normally Upgrade Status will try its best to wrap the phpstan parsing itself in a HTTP request sandbox, so if it fails, the batch does not fail at all. Your logs should also contain info as to what method was used. A message like
Processing projects without HTTP sandboxing. @errorwhere@erroris an error message or another kind of "Processing projects..." log message from Upgrade Status.Would need these pieces of info to move forward. Thanks!
Comment #5
maxilein commentedThere is nothing else logged - I have even enabled backtracing for errors ...
Comment #6
gábor hojtsyAre you using the latest version of the module? For me these messages preceed scanning any single project:
The two above messages should help understand which project it was failing on and which mode of processing it chose based on your environment.
Comment #7
scrumorg commentedThis same PHPStan error is happening for us too so I thought I'd post our logs in case it's helpful. I was scanning two contrib modules: config_filter and config_split.
It looks like there's two different errors. One says "Undefined variable: result" and the other is "Undefined index: errors"
Upgrade Status Version: 2.9
Config Filter Version: 1.5.0
Config Split Version: 1.0-beta1
Drupal Version: 8.9.1
Here's what I see in the logs...
---
Processing projects with HTTP sandboxing.---
Processing /var/www/html/modules/contrib/config_filter.---
---
PHPStan failed:---
Processing /var/www/html/modules/contrib/config_split.---
---
PHPStan failed:---
---
Comment #8
arno2mars commentedHello,
I have exactly the same issue on my site.
For each scanned module, I have systematically 2 errors logged in dblog:
1- upgrade_status - PHPStan failed:
2- php - Notice: Undefined variable: result in Drupal\upgrade_status\DeprecationAnalyzer->analyze() (line 276 of \modules\contrib\upgrade_status\src\DeprecationAnalyzer.php)
And often, I also have this one (but not systematically):
3- upgrade_status - Notice: Undefined index: errors in Drupal\upgrade_status\DeprecationAnalyzer->analyze() (line 341 of \modules\contrib\upgrade_status\src\DeprecationAnalyzer.php)
I am using:
- laminas/laminas-servicemanager (3.4.1)
- laminas/laminas-text (2.7.1)
- mathieuviossat/arraytotexttable (v1.0.8)
- phpstan/phpstan (0.12.33)
- phpstan/phpstan-deprecation-rules (0.12.5)
- nette/utils (v3.1.2)
- nette/finder (v2.5.2)
- mglaman/phpstan-drupal (0.12.4)
- drupal/upgrade_status (2.9.0)
I have tried to uninstall and re-install the module with all above listed dependencies using composer (+ cache has been cleared). But after that the logs are still there.
To note that my vendor folder containing phpstan is one level up of my drupal root (don't know if it has any influence). All my scanned modules are in my root/modules/contrib folder (incl Upgrade status).
It seems that the scan result always detects missing core version requirement in *info.yml file + deprecated libraries, however it doesn't report any other deprecated functions for the 150 modules installed on my site. In the end, my scan results only have warnings but no errors. This looks surprisingly optimistic.
Does it mean that some deprecations may not be reported?
Thanks!
Comment #9
arno2mars commentedHello,
Hallelujah!
After hours of researches, I have found what was the source of the PHPStan fail on my site, so I post here the solution that worked for me in case it helps the other users.
I have a drupal recommended-project installation, meaning that my vendor folder and composer json file are located at my project root, outside of my site root which is in a web folder. Like this:
- My-project-root
------ Vendor
------ Composer.json
------ web
---------- core
---------- modules
---------- sites
---------- ...
When updating drupal core via composer, it seems that the new core release comes with a composer json which gets inserted in the web folder. It seems that the presence of this composer json file disturbed the search of the vendor/bin/phpstan folder done in the DeprecationAnalyzer.php file.
After removing this composer json file in the web folder (keeping of course my project composer json at the root of my project) the issue disappeared and the module works now like a charm (all deprecations reported and no more errors in the log).
Hope this would help and save time to others.
Thanks again for the huge job done with this module!
Regards,
Comment #10
gábor hojtsyHm, we already have safeguards against that though?
https://git.drupalcode.org/project/upgrade_status/-/blob/8.x-2.x/src/Dep... bails out with an exception of phpstan was not found in the bin path it identified. That is then caught in https://git.drupalcode.org/project/upgrade_status/-/blob/8.x-2.x/src/For... and turned into a proper Drupal error message alongside disabling the ability to submit the form with any of the submit buttons.
Why is that not taking effect for you then?
Comment #11
siramsay commentedI am getting the same error, but notice is Notice: Undefined offset: 1
The rest of the dblog is identical as #7
Is this considered different?
Some notes/ observations
Modules with Errors / 4 out of 14 on the install I am testing
Chaos Tools 8.x-3.4 / ctools
Entity Print 8.x-2.2 / entity_print
Feeds 8.x-3.0-alpha9 / feeds
Twig Tweak 8.x-2.6 / twig_tweak
Attached it the inline error I get
Notice: Undefined offset: 1 in Drupal\upgrade_status\DeprecationAnalyzer->analyze() (line 293
Notice: Undefined offset: 1 in Drupal\upgrade_status\DeprecationAnalyzer->analyze() (line 290
System
Drupal 8.9.2
Apache/2.4.29 (Ubuntu)
PHP 7.3.18-1+ubuntu18.04.1+deb.sury.org+1
Comment #12
dbielke1986 commentedI am getting the same error when trying to analyse the libraries-module.
The error
cames from a bug within the "DeprecationAnalyzer.php".
If the $output is empty it is trying to output an $result which is never be filled before (see the attached image).
All the inputs to the
seems to be fine for me. Probable an PhpStan error itself.
Comment #13
Arngrim commentedIn my case the problem was the entity_update module, which defines drush_log and drush_print, because apparently drush gets loaded after the entity_update module.
I found out about this by logging the full phpStan exec path in DeprecationAnalyzer.php (around line 275) like this:
$phpStanCommand = $this->binPath . '/phpstan analyse --error-format=json -c ' . $this->phpstanNeonPath . ' ' . $project_dir;
\Drupal::logger('YOUR_MODULE')->notice($phpStanCommand);
exec($phpStanCommand, $output);
Pasting the $phpStanCommand into a shell, I got this:
PHP Fatal error: Cannot redeclare drush_log() (previously declared in C:\htdocs\wac\web\modules\contrib\entity_update\tests\modules\entity_update_tests\entity_update_tests.module:16) in C:\htdocs\wac\vendor\drush\drush\includes\drush.inc on line 68
So I commented out the redefinitions in the entity_update module and everything works as expected.
Perhaps something similar happens to the others here?
Comment #14
rohnjeynolds commentedThe condition described in #12 is what causes the AJAX errors I'm seeing, which include the one reported in the original issue, and which all have to do with $result and an 'errors' key inside that array being undefined. The attached patch initializes those variables and suppresses the errors for me, allowing scans to complete. Admittedly, in trying to make the module code more resilient against underlying PHPStan issues, this patch might be papering over a root cause.
Comment #15
gábor hojtsyThe 'errors' key is indeed not defined for the case when phpstan fails. It is also somewhat silent to the result side as we only log it but don't expose the fail in the results. We should. So I also changed the silent case to save the error as if it was a phpstan file error (tied to the info file in this case which is the only file we can be sure exists for an extension).
Fixing the $results key to be empty and then using it to log an empty error message is not helpful. The $results in the log was supposed to be $output. This is already fixed in the 3.x branch. Moving this issue there.
How does this look like? We cannot really test a phpstan fail condition in the test suite, so we'll need manual testing. (It should definitely fix the missing errors key, I have no doubt).
Comment #16
gábor hojtsyUpgradeStatusForm::parseProject() also has a similar failure fallback logic BTW. Taking more inspiration from there to use a fake file name as well to designate the error better. Also adding a human readable intro to the error log so people get a general idea of what is going on.
Comment #17
rohnjeynolds commentedThe patch in #15 didn't apply to version 8.x-2.x for me, but when I applied manually and ran a scan, I still got errors because (a) the change from $result to $output on line 276 isn't in the patch, and (b) $output is an array but is treated as a string on line 280. The attached patch resolves those two issue and allows me to scan all projects in my site error-free.
Comment #18
gábor hojtsyThanks for the manual testing!
Comment #22
gábor hojtsyThanks all! This should resolve both the undefined 'errors' index and $results variable.