Beta 6: Check PhpExecutableFinder Version about platform HOT 5 CLOSED

Hi @astorm,

Well done on the diagnostic !

A properly configured production server will not expose such a configuration, but it's a valid use case for a dev environment

Unfortunately, checking for the CLI PHP version is not a good idea, as it still not deterministic enough.
I can have several PHP installed on my dev environment with the same version (or compatible version) but with different configuration or even compile time options.

So I may suppose that my PHP 5.4.4 with my needed extension is used (because that's what I use for my web server), but instead the first PHP compatible version will be used (which could be the PHP 5.5 I'm using to test new stuff), and it will fail as well.

So your best solution is to set the PHP_PATH environment variable in your virtualhost to your PHP CLI path in order for the PhpExecutableFinder to use it.

I think some lines about that in the README.md will be welcomed ;)

I agree that "shelling out" (even if does not involve any shell) is almost always a bad idea, but there's some case on the plateform where it's useful, like in the BatchBundle, as we need to launch background processes for heavy import and export.

In the case of the installer, I'm not quite sure it's needed, as a Symfony2 Command can be executed from the webserver without launching an external process, as it's done at several locations in the platform.

from platform.

I agree something should go in the README about PHP_PATH, but disagree the installer checks aren't needed.

If the system uses a particular command-line binary, it needs to check that the command line binary is compatible with what it wants to do.

In my particular case the lack of these installer checks led to an installation that seemed to install correctly, but led to a broken OroCRM installation. If I had been a regular user (and not already invested in the platform) I would have looked at that and said "guess this thing isn't fully baked yet" and not adopted the platform.

Just because a fully deterministic method of identifying which PHP needs to run doesn't mean additional heuristic wouldn't be useful.

from platform.

I didn't say that installer checks on proc aren't needed, I said there were not enough to have a valid PHP version.

Two things here:

• the installer should not execute external process and should use the Command object directly in the webserver process
• there's some valid case where external processes need to be spawn. In these cases, we need to be sure to execute the right PHP installation. And checking version is not enough, as it could break stuff as explained before

In fact, there's no way to automatically detect the right version of PHP CLI that needs to be used. So the installer should provide a configuration for the PHP CLI for the user to specify it.

It could pre-set the with the value found by the PhpExecutableFinder or from the PHP_PATH, and of course checked for version too.

from platform.

And a supplementary detail: it's totally possible to have a system with mod-php and without PHP CLI. In this case, the installer should warn the user.

Having a mandatory parameter with the PHP CLI path (and checks on existence and version) will solve this case as well.

from platform.

Hi, @astorm!

I've added two improvements related to this issue.
First one is environment variable to configure custom php path for console commands and second one is requirements check for console command. So when your cli version differs from web servers one we will check all requirements.

We will include both improvements in one of our nearest releases. Thanks!

from platform.