By slipit on

When running the update status module it produces the error "The PHP binary was not found. Scanning is not possible until this is resolved.)

is there a file in the 'update status' structure where this path can be defined?

⋅ Categories: Drupal 8.x

Comments

vm’s picture

vm commented

did you install via composer as the project page states to ensure all 3rd party libraries are also installed?

slipit’s picture

slipit commented

Can I locate and place the dependencies for this module in the lib folder? I can then come back around after the site is Drupal 9 to clean up the issues with composer. This was an 8.7.1 install. It just missed the cut to have all the composer framework installed in core and I am having trouble getting composer to work at the moment. This is why I am looking for a manual workaround in the interim.

mmjvb’s picture

mmjvb commented

Unfortunately there is no ludwig.json. So, `composer require` is your only option. It is not only about where to place the code. It is the autoload of composer that makes this work. To do that manually is not really an option.

slipit’s picture

slipit commented

The thing that is puzzling in this whole process is that I installed the 'upgrade status' module in a Drupal ^8.8 version and the CLI responded "Using version^3.11 for drupal/upgrade_status". This scenario produces the same error in status_upgrade. "The PHP binary was not found. Scanning is not possible until this is resolved."

This was installed with composer.

mmjvb’s picture

mmjvb commented 
docker@cli:/var/www$ whereis php
php: /usr/local/bin/php /usr/local/etc/php /usr/local/lib/php /usr/local/php
docker@cli:/var/www$

Normally your PATH environment variable includes one or more of those folders.

slipit’s picture

slipit commented

Before posting this issue. I ran "where is php" on the CLI to identify the bin files location. it returned  C:\bin\php\php7.4.9\php.exe.

The bin file exists. I am unclear why the module is not locating and using it?

mmjvb’s picture

mmjvb commented

The context when this happens is still unclear. Suggest to be more specific. Looks like it is trying to do something in a context where php.exe is not available. Make it available system wide.

The CLI and Web server are different environments. When the Web server starts a shell to call PHP it has its own shell environment. In that environment it needs to find php.exe, hence setting it system wide.

slipit’s picture

slipit commented

The error is being produced on the Upgrade Status module page. When I go to 'Reports' then 'Upgrade Status'.

It is at the very top of the page.

The php is installed on the system as witnessed by the 'where is php' run on the CLI. It produces a path to the file.

It's recognizing the PHP to run Drupal yet it is not finding the binary file for the status_upgrade module installed with composer.

I've included the results from the CLI requiring upgrade_status

C:\www\mdwebsite>composer require drupal/upgrade_status
Using version ^3.11 for drupal/upgrade_status
./composer.json has been updated
Running composer update drupal/upgrade_status
Loading composer repositories with package information
Updating dependencies
Lock file operations: 12 installs, 0 updates, 0 removals
  - Locking container-interop/container-interop (1.2.0)
  - Locking drupal/upgrade_status (3.11.0)
  - Locking laminas/laminas-servicemanager (3.10.0)
  - Locking laminas/laminas-text (2.8.1)
  - Locking mathieuviossat/arraytotexttable (v1.0.8)
  - Locking mglaman/phpstan-drupal (0.12.14)
  - Locking nette/finder (v2.5.2)
  - Locking nette/utils (v3.2.5)
  - Locking nikic/php-parser (v4.13.0)
  - Locking phpstan/phpstan (0.12.99)
  - Locking phpstan/phpstan-deprecation-rules (0.12.6)
  - Locking webflo/drupal-finder (1.2.2)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 12 installs, 0 updates, 0 removals
  - Installing webflo/drupal-finder (1.2.2): Extracting archive
  - Installing phpstan/phpstan (0.12.99): Extracting archive
  - Installing phpstan/phpstan-deprecation-rules (0.12.6): Extracting archive
  - Installing nikic/php-parser (v4.13.0): Extracting archive
  - Installing nette/utils (v3.2.5): Extracting archive
  - Installing nette/finder (v2.5.2): Extracting archive
  - Installing mglaman/phpstan-drupal (0.12.14): Extracting archive
  - Installing container-interop/container-interop (1.2.0): Extracting archive
  - Installing laminas/laminas-servicemanager (3.10.0): Extracting archive
  - Installing laminas/laminas-text (2.8.1): Extracting archive
  - Installing mathieuviossat/arraytotexttable (v1.0.8): Extracting archive
  - Installing drupal/upgrade_status (3.11.0): Extracting archive
1 package suggestions were added by new dependencies, use `composer suggest` to see details.
Package container-interop/container-interop is abandoned, you should avoid using it. Use psr/container instead.
Generating autoload files
Hardening vendor directory with .htaccess and web.config files.
28 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Cleaning vendor directory.

vm’s picture

vm commented

digging for this with google the only somewhat similar report is related to an empty composer.json file being in the /web/ directory. Worth a review perhaps.

slipit’s picture

slipit commented

Okay. I will investigate and report back.

So after several days removed from this issue I went back to the status upgrade page and it was now throwing multiple errors. It prompted me to run 'composer require drupal/upgrade_status' again. When returning to Reports/Upgrade Status the 'Binary file' error is no longer. It appears there was an issue detailed in this link https://www.drupal.org/project/upgrade_status/issues/3241362. My scenario is a local Windows install.

nofue’s picture

nofue commented

This also happened to me today, but I decided not to worry about this behaviour. Simply cleaning the cache using drush cr enables the scanning. Instead of searching for hours to fix a problem which will be gone once the upgrade is done I issue drush cr whenever I want the upgrade_status to scan the site. 

Norbert

-- form follows function

benjarlett’s picture

benjarlett commented

Sadly didn't work for me. I found when logging in to the server that if I ran:

whereis php

I get:

php:

... so I'm guessing that's the problem.. gonna try and work out how to add it to my path.
... in the meantime I can run a scan with the site on my local machine where it knows where php is, so I may just do that for now...

nofue’s picture

nofue commented

And how will f.e. Drupal run on that machine? 

Norbert

-- form follows function

benjarlett’s picture

benjarlett commented

I'm not sure,.. it does though. It's on an OVH vps.. and it's working running drupal, just not scanning.

nofue’s picture

nofue commented
  1. Go to the Status Report
  2. Look up the line PHP xx.xx.xx (more information)
  3. Click on "more information"

This should open php info and there you'll see the path Drupal is using.

 

Norbert

-- form follows function

benjarlett’s picture

benjarlett commented

Thanks.. but how to get Upgrade Status's scanning to know? That's the issue...

nofue’s picture

nofue commented

… it's hard to tell not knowing the configuration of your machine. From above procedure you should know where PHP is located. Next you can think about how you can access PHP from the shell -- maybe the paths needs to be set, or maybe you don't have the necessary access rights. As I said, the scanning thing failed on me as well, and it didn't add a line to the log. In no log, to be correct: Not in Drupal's, and not in any access log I am aware of. If I had to track this one, I'd start to see if my system is set up properly and try to make the tool to fail in way I can find it's existence in some log file … But first things first: make sure you know where PHP exists for your configuration. As it's late here y now, I can't promise to assist you before tomorrow morning. Good luck!

Norbert

-- form follows function

mmjvb’s picture

mmjvb commented

The module uses the system call (php)  to execute phpstan ( vendor/phpstan/phpstan/phpstan ) which is a /usr/bin/env php script. No problem for linux, but might need additional configuration to work on windows. The windows shell might not be configured to execute phpstan because it doesn't have an executable extension.

Try to execute ./vendor/phpstan/phpstan/phpstan

It should give: At least one path must be specified to analyse.

Which proves it can be executed. Sorry, no windows platform available, so I can't test.

EDIT: See also https://www.drupal.org/project/upgrade_status/issues/3241362

slipit’s picture

slipit commented

Nofue your point is taken on moving on and not spending the time.

I am not able to use drush at this time (not sure why it was installed in the projects folder using composer still working on this) (I cleared the cache multiple times instead but the error persisted; plus I didn't see clearing cache as being the same as a scan) at this time and on top of that I was hoping to resolve the issue to hopefully reveal more detail on Theme issue Drupal was not liking in the upgrade to 9. Plus I wanted this clean for future use.

As it turned out the issue went away after stepping away and coming back to it. The binary error is no more.

Thank you.

benjarlett’s picture

benjarlett commented

Great some clues there... thanks!

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

I met a similar issue, albeit with upgrade_status, and found both one cause and a workaround, which may be useful in similar situations: #3314917: PHP not found in a D9.4.8 composer project