`cv status`: Reporting PHP version for HTTP server (vs CLI)

[dev-allinappli]

Hello,
When using the command "cv status", it retrieves the PHP version of the cli and not the version of the instance

in the image it shows 8.1 while the php version is 8.3.

[dev-allinappli]

https://github.com/civicrm/cv/blob/1192eea57ed197c5c3da0a07eeb0a31ddd10f76e/src/Command/StatusCommand.php

[mlutfy]

This seems like a normal behaviour to me. The CiviCRM instance itself does not have a setting for the PHP version. This is up to the webserver and CLI configurations. i.e. CiviCRM cannot chose which PHP version to run.

So if you have multiple PHP versions installed on your server, the CLI will use what was set by default in your $PATH. This is also the PHP version that would be used for running the CiviCRM cron.

[GuillaumeSorel]

I think we're not talking about the same thing.
What I find useful with the cv status command is to run it on one instance and know the values for this instance, like which version of CiviCRM is installed or which version of PHP is used on the server for this domain.
Maybe it's good that it also shows the global PHP version (here 8.1) used for the cv cli but I find more useful to know the PHP version used for the domain. Maybe both informations could be displayed.
And the request is to add 'PHP version used for the instance'.

[GuillaumeSorel]

this is what I'm interested to get with the cv status command

[dev-allinappli]

The value is also obtainable with the API, but it's another command to do with the previous and the value is a text that is parsable but it would be like scrapping data in a text, not efficient and easily breakable

[mlutfy]

I understand. So this is a feature request: to show the PHP version used by the webserver (the current behaviour is not a bug).

It would require doing an http query to the server, to a special/new endpoint that exposes environment data, perhaps with an authentication token (to not expose the PHP version to robots). To my knowledge, the cxn service did something like that, but it was removed from core (I can't find the PR at the moment, maybe Tim will have other ideas).

Running cv api system.check , for example, will return the same info as the screenshot above, but it will show the CLI version of PHP.

[GuillaumeSorel]

how is this called in code? CiviCRM knows how to check PHP version

[mlutfy]

It calls PHP's phpversion function

Ex: https://github.com/civicrm/civicrm-core/blob/master/CRM/Utils/Check/Component/Env.php

"Returns a string containing the version of the currently running PHP parser or extension."

So if the CLI runs PHP 8.1, it returns PHP 8.1.

[GuillaumeSorel]

that's weird because in my screenshot it returns 8.3

[mlutfy]

Yes, because the screenshot is running from www/fpm.

I'm pretty sure if you run cv api system.check from the CLI, you will see PHP 8.1.

The same way you would have different webservers for the same CiviCRM installation, and if both servers run different PHP versions, the system-check will display different versions.

[GuillaumeSorel]

I'm pretty sure if you run cv api system.check from the CLI, you will see PHP 8.1.

yes you're right. So is there a www/fpm side query useable with cv? (weird question)

[mlutfy]

That's the thing - as far as I know, it would require:

• Adding an URL endpoint (ex: /civicrm/stats) that exposes some stats
• Doing an http query to the server, to see what it responds with.

The symbiotic monitoring extension does something like that: https://lab.civicrm.org/extensions/symbiotic/-/blob/master/CRM/Symbiotic/Page/RemoteCheck.php

although in this case, it only returns visible monitoring alerts (the PHP check is an "info", so it would not be visible). We use this for monitoring clients who are not hosted on our servers (normally the check is run via CLI).

And then you would need a cv plugin that queries this endpoint (I suggest plugin, unless something is added to CiviCRM core).

[GuillaumeSorel]

ok so we'll keep on doing it the way we do with some Plesk commands, it looks way simpler

[totten]

Yeah, it would be nice to report the PHP versions used by both CLI and HTTP requests. Obviously, it's ideal if the two versions match to ensure that things run the same way -- but they can get mismatched for good+bad. (Ex: I often need to juggle different versions of PHP when diagnosing bugs -- so I definitely relate.)

(Aside: In the screenshot, it says php is 8.1.32 (cli, other) to clarify that it's only reporting PHP-CLI -- not PHP HTTP.)

Agree with mlutfy that the only reliable way to get the PHP version used by HTTP is to send a real HTTP request.

We almost have enough pieces to make that request (e.g. an HTTP request to APIv3 System.get with an authx JWT gets most of the way), but... to get past the permissions-checks... we need a --user name or similar service-principal). The request will likely add 200-800ms to cv status, and it needs guards (so that cv status remains useful even if HTTP is broken).

Going a step further, something like this (pseudocode) might be useful:

try {
  $localResult = civicrm_api3('System', 'get');
  $remoteRemote = POST(Civi::url('civicrm/ajax/rest?entity=System&action=get')->addQuery([
    '_authx' => createJwt(cliUserOrServicePrincipal);
  ]));
  // check for and report about differences between $localResult and $remoteRemote
} catch (Exception $e) {
  echo "WARNING: Unable to fetch information about HTTP services";
}