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.Problem/Motivation
error:
Vendor binary path not correct or phpstan is not installed there. Did you install Upgrade Status with composer? Checked: /var/www/html/docroot/vendor/bin/phpstan
Steps to reproduce
- using ddev multisite
- core 8.9.3
- Upgrade Status was installed using composer require 'drupal/upgrade_status:^2.0'
- upgrade_status module was enable
- on the Upgrade Status page: /admin/reports/upgrade-status , there is a warning:
Vendor binary path not correct or phpstan is not installed there. Did you install Upgrade Status with composer? Checked: /var/www/html/docroot/vendor/bin/phpstan
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #28 | 3164067-28.patch | 5.12 KB | Gábor Hojtsy |
| #28 | interdiff.txt | 1.64 KB | Gábor Hojtsy |
| #26 | Screenshot 2021-01-26 at 18.49.14.png | 41.87 KB | ronaldtebrake |
| #25 | interdiff.txt | 4.03 KB | Gábor Hojtsy |
| #25 | 3164067-25.patch | 5.04 KB | Gábor Hojtsy |
Comments
Comment #2
Gábor HojtsyIs phpstan actually in
/var/www/html/docroot/vendor/bin/phpstan? If not, what would be the vendor directory to find it in?Comment #3
mario.elias CreditAttribution: mario.elias commentedOn my environment the file is under /var/www/html/vendor/bin/phpstan
I used composer to install. Below are the files added
git diff --name-only da3477f52 8c4d91bf9
Comment #4
lambch CreditAttribution: lambch commentedI am also getting this exact message.
The message asks "did you install with Composer", when yes, I definitely did.
The /vendor/bin/phpstan binary is definitely there. Or rather, as an alias for /phpstan/phpstan/phpstan
Within command-line I browse to both of the above mentioned locations and running
php phpstanworks.My local dev is a Vagrant based VM.
Comment #5
powlessn CreditAttribution: powlessn commentedI had the same problem. The module couldn't find my vendor/bin folder because it's outside my web root/DRUPAL_ROOT.
According to a related issue[1], you can specify a /bin path in composer.json. In my case, I added this to the composer.json
file that was inside my web root/DRUPAL_ROOT.
[1] https://www.drupal.org/project/upgrade_status/issues/3129430
Comment #6
Dennis Cohn CreditAttribution: Dennis Cohn at ezCompany, iO commentedI've got the same problem as @lambch
Did you found any solution?
Edit:
Our composer.json file is also outside the root folder.
When I copy our data from the composer.json into the composer.json within the root folder, and changed the vender folder...
It works...But this is not really THE solution I think.
Comment #7
lambch CreditAttribution: lambch commentedThank you @powlessn. What you suggested works.
I modified the composer.json file what's in the drupal root folder and added `"bin-dir": "../vendor/bin",` in the config section.
The Upgrade Status module works as expected.
For the record, the composter project I am using builds itself from one folder higher. So phpstan must end up in the vendor directory in there, unable to be found by the module when it's needed.
I also do not feel that manually editing the drupal/core composer.json file is a great long-term solution. It'll only get overwritten when my project gets scaffolded.
So I'd either have to patch it post-scaffold... Or completely redo my scaffold (more likely, ugh).
These are problems for another day.
At least the module is working on my local dev, allowing me to use it for its purpose.
This composer stuff is confusing.
Comment #8
Gábor HojtsySomehow Upgrade Status needs to find the binary. See
DeprecationAnalyzer::findBinPath():Would updating the exception message help to point people to the right direction to suggest updating your composer.json? @lambch do you have suggestions on how would the module find your path without you telling it about it?
Comment #9
Gábor HojtsyNote that we are using https://github.com/webflo/drupal-finder to find the Drupal composer file. @Dennis Cohn could that project do something better to find the "right" composer file for you? How would it tell which one is the right one?
Comment #10
lambch CreditAttribution: lambch commentedThe thing that dead-ended me with that error message was where it said "Did you install Upgrade Status with composer?"
Because, yes I did. The exception message suggests that using composer is the right way to do it. But even so, it doesn't always work.
Personally I didn't mind having to add that extra line to Drupal's composer file to repoint it to the correct vendor binary directory. It's just that the prompts that this was the actual solution were not obvious.
Helpful error messages are great. But more generally it's better when things 'just work'.
Comment #11
fundawangcn CreditAttribution: fundawangcn commentedSame here.
But after disabling selinux, the error went out.
Comment #12
StepanISK CreditAttribution: StepanISK commentedI am getting the same error. But in my case, the problem is in the direction of slashes. I have Windows with an OpenServer.
i added changes to
the problem is gone. But a new one appeared
how can I solve this problem?
I think that this problem will most likely not be on the server. Nuances for local build.
Comment #13
brunodboRan into this as well. I found https://github.com/webflo/drupal-finder/pull/55, which might help us.
Comment #14
fgmSimilar issue:
Result:
On the CLI:
On admin/reports/upgrade-status
The error is obvious: phpstan is in (project)/vendor/bin/phpstan instead. The problem materializes in DeprecationAnalyzer::initEnvironment() where DrupalFinder->getVendorDir() returns an incorrect directory with this layout: (project)/web/vendor instead of (project)/vendor. DrupalFinder sets vendorDir from composerRoot, incorrectly assuming composerRoot == drupalRoot, which is only true with the drupal/drupal layout.
Comment #15
Gábor HojtsyHm, is there a way to make DrupalFinder able to find Drupal in these cases?
Comment #16
fgmThe thing is, DrupalFinder does find Drupal. What it doesn't find is the vendor dir.
The drupal-finder PR 55 mentioned in #13 would allow it to use environment variables for that purpose. However, I think that a better approach would be to either:
Comment #17
Gábor Hojtsyre @fgm in #14: as I copied the code in #8, Upgrade Status already supports reading the bin-dir from composer.json (does not need composer itself present in the environment) and uses that if the vendor path returned by DrupalFinder was not correct.
re @StepanISK in #12, I would try specifying the path in composer.json with a regular slash, that should work with PHP. The backslash is an escape sequence in JSON, so that should not be used as path separator. See https://stackoverflow.com/a/19176131
We can definitely improve the error text here to point people to the right direction. What about this?
Comment #18
fgmre @Gábor Hojtsy then it's very strange; did you do this change since 8.x-3.1 ? I'm asking because :
What fixed the issue somehow was creating a (project)/web/vendor/bin directory and symlinking (project)/vendor/bin/phpstan there. This allows the scan to run somehow, although it seems to be missing configuration for phpstan because some well-known deprecations were not being picked up, and running drush us-a returned errors about missing configuration (which did not happen in the web UI).
OTOH, symlinking (project)/vendor below (project)/web allowed it to run from the Web UI, but then drush no longer worked, looping indefinitely on a relaunch on the local version.
One thing I didn't try was using an absolute path for bin-dir: I used "./vendor/bin" and "vendor/bin", though.
Comment #19
Gábor Hojtsy@fgm, no 3.0 already has bin-dir support: https://git.drupalcode.org/project/upgrade_status/-/blob/8.x-3.0/src/Dep... -- if the bin-dir was found in the composer.json structure, the "Checked: ..." part should display both the attempted vendor path from DrupalFinder as well as the vendor path based on bin-dir, that is two entries. So if your error message does not list two paths attempted, then the bin-dir was not found in composer.json.
Comment #20
Gábor HojtsyWent off to refactor this entirely for much better error handling. Now checking the most specific options first and then the least specific. We may also just want to bail if the most specific one did not work out instead of keeping to try? Either way, this should give much better guidance as to what to do if the phpstan binary was not found at one of the three places checked. I did un-abstract the vendor directory detection from DrupalFinder here for better error messages for the specific cases.
What do you all think?
Comment #22
Gábor HojtsyMeh, protected method.
Comment #24
Gábor HojtsyShould I try my patches before posting them? I should :D
Comment #25
Gábor HojtsyYeah I think we should bail as early as we can because otherwise we may end up using a binary that is different from what the developer intended based on the configuration. So yeah if the configuration does not result in finding phpstan, we should tell right away. Also we use the vendor directory at one more location, we also need to bail there if the actual files were not found as the results will be practically empty without that. (This is for the case when a non-standard vendor directory is used but not properly configured in composer.json or if only the bin-dir was specified, which makes phpstan capable to run, but not the configuration assembly that requires vendor-dir to be set). So also modified the error in the binpath check to only suggest setting up vendor-dir, because that solves for both problems, not just the binary.
Would really welcome manual testing of this in non-default scenarios even if the tests pass on the default scenario :)
Comment #26
ronaldtebrake CreditAttribution: ronaldtebrake as a volunteer and at Open Social for Open Social commentedCan confirm this patch works for Open Social although our scenario is very much default so my review might not really weigh in on that.
It already worked before (and still works after applying the patch).
Manually moving and altering paths seemed to work as expected, what I can tell I like the DX experience here :)
So will just leave the status as is for others to provide there input.
Thanks for these helpful insights!
Comment #27
fgmI just tested with patch #25.
With "vendor-dir" set to "vendor", "./vendor", "/(projectpath)/vendor", or not set ;
with "bin-dir": "./vendor/bin", as well as with no "bin-dir", and with "bin-dir": "/(projectpath)/vendor/bin", the result remains the same:
I checked what happened, and the problem is that even this patch assumes that DrupalFinder successfully finds the project composer.json, whereas it works more naively than that, and returns the composer.json below the web root, not the project composer.json, and everything is wrong after that: the line
$this->finder->locateRoot(DRUPAL_ROOT);is the root of the issue.AFAICS, there are only two reasonably safe ways to access the composer information in any project layout: (1) during install/update operations, (2) within the autoloader.
The former is problematic because it either complexifies instructions, because dependency scripts are ignored during an install/update except for plugins; the latter is problematic because it will rely on undocumented features of specific autoloaders.
Which leaves three likely paths: (a) have the standard scaffold inject layout information somewhere below drupal root, e.g. in private files (b) make a series of guesses starting from drupal root and moving up one directory for both the legacy and current projects, which is fragile (c) allow the path to be configured manually if discovery fails.
Comment #28
Gábor HojtsyThanks, good feedback. I think this improvement is still good, even if it does not fix all cases. Making location of composer.json more specific for now. I'll commit this for an interim fix if it is fine then we can continue looking at figuring out how to find the right composer.json and thus vendor directory better. At lease this would make the error much cleaner for people telling them which composer.json we considered and which value we considered from there.
Comment #30
Gábor HojtsyCommitted this but leaving open for figuring out the composer.json location problem.
Comment #31
Gábor HojtsyBetter for issue management, I copied the conclusions from @fgm to #3194911: Composer file only found in webroot, DrupalFinder assumption is not necessarily correct and credited all of you there too. Let's move over there.
Comment #33
leewbutler CreditAttribution: leewbutler commentedFor anyone developing using Lando, in terminal try doing a "lando composer install" as opposed to simply a "composer install". According to this issue post for the Lando project it "will create new sim-links in vendor/bin" which fixed the issue for me: https://github.com/lando/lando/issues/2328#issuecomment-638744838
Comment #34
Gábor Hojtsy@leewbutler: hm, https://www.drupal.org/project/upgrade_status does not mention
composer install, do you mean composer require?Comment #35
jim22 CreditAttribution: jim22 commentedI had the same issue with phpstan not able to find vendor+bin. I was able to get upgrade_status scanning working by adding 2 lines to the Drupal root composer.json file (app/docroot/composer.json)
I hope this saves someone else a couple hours of time.
Comment #36
Gábor Hojtsy@jim22: Great tip! I believe our error message already suggests to specify the vendor-dir? If that is not the case, it would be great if you could open an issue for that. Thanks a lot!
Comment #37
jim22 CreditAttribution: jim22 commentedThanks, Gábor!
I just wanted to be sure to explain that using my "main" app root composer.json (including specifying vendor-dir) had no affect on this issue. To fix this, I needed to add the `vendor-dir`/`bin-dir` settings in the Drupal/web root composer file, which is unusual. I'm not sure why it wouldn't locate the correct composer.json file, but I do have a nested Drupal directory... so not sure if that was the reason. Either way, I wasted some time updating the wrong composer file and figured this extra detail might save friends some time.
Thanks again! Have a great day!
Comment #38
3CWebDev CreditAttribution: 3CWebDev commentedMy issue was that my installation had an (empty) composer.json file in the /web directory that was throwing off the finding of PHPStan. Removing the composer.json file fixed the issue.
Comment #39
fgmFWIW, it just started again. I've been working on the same D9 install for over one month and suddenly today it stopped working after a brew upgrade, saying it could not find PHP.
Stopping the brew php service and restarting it fixed the problem. It seems there is an attempt to find the exact same php binary as the one used to serve the report page, which is not the case when upgrading.