multiple php version switch with php-fpm

Howdy -- unfortunately, due to the nature of how PHP-FPM works, it's not possible to switch between multiple PHP versions. You'd need to be using CGI/FCGID for that.

It looks like you're using Virtualmin GPL there though... if you're using Virtualmin GPL, and you had any followup questions, you'd want to use the Forums for support.

We monitor the Forums, along with lots of wonderful folks in the community. Thanks!

In theory we might support this in future, but right now only one FPM version can be selected.

+1 for multiple php versions for fpm

@andreychek you are wrong. It is perfeclty possible to run multiple php-fpm versions on different ports/sockets, like one for each virtual server. (i thinks its already done the way that there is a fpm pool per virtual server, there is just no version switch, but i need to check).

This is the #1 feature for me, the only thing i am missing when coming from Plesk. In Plesk you can switch versions on per-domain (virtual server) basis, which is totally sufficient for most projects. Different FPM-Versions per Directory is a feature that i would'nt miss (while i also think that this is possible with php-fpm!).

Yes, multiple FPM versions is technically possible with the right configs - we just have to implement it in Virtualmin.

I would be very grateful if you could add this feature.

It's on our TODO list.

+1 on this. Glad to hear its on the todo!

Is PHP Switching through Virtualmin possible now, how soon can we get this feature.

I have tried FCGID but it does not reflect version I changed, do I need to do anything else before and after changing PHP version.

Multiple versions are still only supported in CGI and fCGId modes.

Hello,

I need to run php7.2, but I cannot make it work ;-( Is it possible? If yes what's the best way?

Thanks in advance.

We'd be happy to talk about PHP 7.2! Though that's a different issue than the posts above. Could you open a separate request for that? Then we won't get the topics here too mixed up. Thanks!

The Problem is that virtualmin sticks to one PHP Version for FPM. If you install i.e. PHP 7.2 in addition to 7.0 you are not able to select it for PHP-FPM. This can be worked around by uninstalling all other PHP-FPM variants (cgi and others can remain). If PHP 7.2 is the only PHP-FPM version left installed, it will be selected. A virtualmin Configuration check/rescan could be required.

Right, multiple FPM version support is still in the works.

If I have only php72 from remi installed, I can't select FPM mode: Failed to save website options : No PHP versions found for mode fpm FPM pool is running ok.

Only one php version in fpm should work. Even the remi one.

If you have somewhere config another in the fpm mode then no, that is virtualmin for the moment not supporting. No matter wich repo is used. UH normally you don;t have only one remi php , you still ( should) have the default virtualmin php's somewhere i think, while wiping them virtualmin php's completly wasn't working before.

You have to configure set first the default php version for the virtual server. Only after that you can switch / set for that virtualserver and php version to the fpm mode.

Don;t know by head were these 2 parts are in the panel, but at 2 diferent places , i have to search myself each time before i can set fpm, to have the php version set right at another places in the panel. ( so first select the php version , then go to the other place where you can choose the fpm mode.)

Yes, I have only one version - 7.2. Default 5.4 and 7.0 was removed. There is new install, only removed all php and installed new one. There is no any debug log from save_phpmode.cgi?mode=fpm , so I don't know what error inside.

Also there is no listen = /var/run/php-fpm.sock

Sure, one PHP version should work. Did you already open a separate bug for this?

Running Centos6, I have multiple php versions installed including php-fpm for php7.2 only. Selecting FPM as execution mode forces the php version to go to 5.3 which is obviously not ideal. Even changing the default PHP version to 7.12 makes no difference.

The real issue here is that Joomla is aggressively pushing a Php7.x min for the soon to be released versions and running 7.12 without FPM (for me at least) is unusable due to mem allocation erros such as this: https://www.virtualmin.com/node/36588).

In short... +1 for FMP support for multiple php setups.

Hi guys,

is there any ETA for that functionality?

thanks

It's on the todo list for the future, though we unfortunately don't have an ETA at the moment.

In the meantime you can select different PHP versions using FCGID/CGI.

Yes I know for selecting diff version via FCGID/CGI mode but fpm..

is there a way to do it manualy, or by cli? I'd tried something like this:

mv /etc/php/7.0/fpm/pool.d/1*.conf /etc/php/7.2/fpm/pool.d

systemctl -a restart php7.0-fpm && systemctl -a restart php7.2-fpm

and for now it works, but I have a filling that I'm missing something ..

Ok, after much work support for running multiple PHP-FPM versions and being able to select a version on a domain-by-domain basis has been implemented in Virtualmin. This will be included in the next release.

Great! looking forward for testing this.

This is great news! Many thanks for your work on this.

Great news,

thanks a bunch for this! Looking forward to this!

Is there any estimation regarding the release date where this is included? :)

Couple of weeks at most.

Hi,

my version is 6.06-gpl

great the mutable php-fpm has now been installed. however, this does not work in my installation. he does not recognize the other php versions.

these are all displayed as version 7.0.33. even switching between versions does not seem to work. Installed are 5.6, 7.0, 7.1, 7.2 and 7.3

If you go to System Settings -> Re-Check Configuration , what PHP-FPM versions does it report as being available?

Hi,

The following PHP-FPM versions are available on this system : 7.0.30 7.1.26 7.2.15 7.3.2 7.3.2 5.6.39 5.6.39

@fbeckma how did you get 6.06 version? I'm on 6.05 and no updates to newer version? thx

Hi,

http://webmin.com/vdownload.html

Virtualmin 6.0.6 When I re-check the config I get:

The following PHP versions are available : 7.0.33 (/usr/bin/php-cgi7.0), 7.1.26 (/usr/bin/php-cgi7.1), 7.2.15 (/usr/bin/php-cgi7.2) The following PHP-FPM versions are available on this system : 7.0

Of course the other FPM versions are installed too.

I have almost the same message saying:

The following PHP versions are available : 7.0.33 (/usr/bin/php-cgi7.0), 7.2.15 (/usr/bin/php-cgi7.2)
The following PHP-FPM versions are available on this system : 7.0

but systemctl status php7.2-fpm & systemctl status php7.0-fpm report FPM is enabled and active.

I have feeling virtualmin is not detecting fpm versions on system correctly?

I can second that - same here - two versions detected for cgi - one for fpm

So, I think I figured out why this detection issue is happening while troubleshooting this for our local (Debian) server.

There's a section of code in php-lib.pl that starts the detection of php-fpm versions by package name (currently this starts at line 1709):

That last variable is defined in virtual-server-lib.pl as: @all_possible_php_versions = (5, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 5.9,"7.0", 7.1, 7.2, 7.3);

The problem is, the "map" function in the above code means that any "dot" in the package name is stripped for the check - the code will look for a package named php72-fpm, but not php7.2-fpm. That's a huge problem for Debian, which distributes FPM using the latter naming style.

I was able to verify that I can get the config check to detect all installed versions with the code below. I have not tested further than this, and have reverted this change on my own machine. I'm putting this out there for others to review, with no guarantee it will work.

Note that the 5th line and 8th line of the code above differ (and it needs to be that way to parse). This basically does a check for the package versions "with dots" (5.6, 7.2, etc) after the one "without dots" (56, 72, etc).

Hopefully the maintainers can take a look a see if this is a valid solution, and something worth rolling into the production code.

Thanks for pointing this out - you're correct that a package named like php7.2-fpm won't be detected when it should be. We'll fix this in the next release.

Huge props draxius, for helping community and all users out there!

+1

I just updated php-lib.pl with the version in github, which shows a similar change (one that should be more efficient than what I wrote).

When I then run virtualmin check-config from the command line, I get the output: "The following PHP-FPM versions are available on this system : 7.0 7.0.33 7.2.15 7.3.2"

When I trigger System Settings->Re-Check Configuration through the Virtualmin portal, however, I'm still getting: "The following PHP-FPM versions are available on this system : 7.0"

I'm very confused as to why the output of these two versions of the config check would differ, but any guidance would be appreciated.

hi,

same here. "virtualmin check-config" from command line: The following PHP-FPM versions are available on this system : 5.6.39 5.6.39 5.6.39 7.0.30 on portal: The following PHP-FPM versions are available on this system : 7.0.30 7.1.26 7.2.15 7.3.2 7.3.2 5.6.39 5.6.39

portal -> Server configuration -> PHP Versions: available php versions are 5x 7.0.33 an 2x 5.6.39

I'm working with draxius on the same server. The command line / webUI disconnect was just a restart of miniserv to fix.

However, with the replacement of the one file (php-lib.pl) from the new checked-in version on github, we can try and flip sites to other versions of PHP-FPM. I see 7.0, 7.2, and 7.3 in the dropdown, I take a test site and flip it to 7.3. Looking in /etc/php/7.3/fpm/pool.d I see... nothing. I try 7.2, nothing. I drop a phpinfo.php in to the document root and nothing I do actually changes which PHP version it's using. So the dropdown is implemented, but it's not actually doing anything under the covers other than saving the php_fpm_version in the appropriate file in /etc/webmin/virtual-server/domains.

It appears that the problem we've been seeing (even after fixing the above issue with restarting the webmin miniserv - which is also required after the fix below) is based on how the version numbers are being parsed in the "Config directory for per-domain pool files" section of list_php_fpm_configs (this is also in php-lib.pl).

The function, as written, currently returns the first entry of @verdirs, rather than matching. The reason for this is because of the strings it is trying to match on: 'version' (7.2.15) and 'pkgversion' (72), ignoring 'shortversion' (7.2). Our Debian system consistently uses the format /etc/php/${shortversion}/fpm/pool.d for the pool directories, rather than the other two formats.

Below is the change-set I used to fix this:

IMPORTANT NOTE before trying to implement this change, you will need to revert any/all virtual hosts back to their original php-fpm versions, especially if you have 3+ versions on your system. If you don't, you will have an open port from your original version, which will prevent the newer version's master process from spawning at all.

As with the last time, I'm not guaranteeing this patch will work for you. I'll simply pointing out the quick fix we made on our end to get this un-jammed. YMMV.

here the pool config is indeed pushed into the correct version but it comes to an error:

"[20-Feb-2019 09:17:52] ERROR: unable to bind socket for address '8002': Address already in use (98) [20-Feb-2019 09:17:52] ERROR: FPM initialization failed "

Here also directly the question if you could not switch to socket. and also directly for all php versions the config is created, thus one can jump in the web between the php versions.

also here are still or again only the php versions "The following PHP-FPM versions are available on this system: 5.6.39 5.6.39 5.6.39 7.0.30" displayed.

that's me but a few 5.6er too much :)

System debian 9.7 php-fpm: 5.6, 7.0 7.1 7.2 7.3 config: /etc//fpm/pool.d/ 7.1-x.3 are optional packages binery are located in / opt / php- /

fbeckma,

I think you're running into two issues.

1) I suspect you applied the changes to the 6.06 release version of php-lib.pl, rather than an already updated version that incorporated the first fix. Here's a patch for the combined changes if you need it:

2) The "address already in use" error you are receiving is because the original pool configuration file (from before you made the code change) is probably still sitting in the old pool location. What we experienced (before this latest fix) was after we tried to move a site from 7.0->7.2, the 7.0 and 7.2 FPM master processes restarted. When we tried to move from 7.2 to 7.3, the 7.2 and 7.3 processes restarted. And so on.

The problem was, the pool file was not being written to the 7.2 or 7.3 directories until I changed the code (as per my prior post). Once I did, the 7.0 file was still left behind, because we kept trying to flip between 7.2 and 7.3 to prevent constant restarts on the (production) 7.0 pools. So when 7.2 restarted, we got the same "address already in use" error that you're seeing.

What you need to do to fix that is to find the old pool file that got left behind while you were trying to fix it, delete that file (or move it out of the way), and then restart the old php-fpm master daemon (in our case, this was php7.0-fpm). After that, you can try restarting the process that failed to run (the one you tried to move that virtual site to).

I still can't get it to work. Base version 6.0.6. I replaced the full php-lib.pl from github (https://github.com/virtualmin/virtualmin-gpl/blob/master/php-lib.pl) and then I applied the changes suggested by draxius

But on CLI:

And over the UI recheck-config:

I can second that as @geissweb, only one version for FPM is found!

Hi,

the error "Address already in use" is fixed.

however, the list still looks the same. PHP Versions In domain displays 6x7.0.33 and 3x5.6.39 However, it is as if the versions would be moved so the conf in the pools of the respective php version.

  Manage PHP Configuration /etc/php/7.0/fpm/pool.d/15507558235986.conf (FPM format) always points to php7.0 although I have selected version 7.2 (blind).

here again the question if it is possible to switch the pools to sock and not to run on TCP. advantage less overhead and it can run multiple PHP versions per domain.

Maybe a checklist where the available versions for the web can be turned on and off.

I just tested something. unfortunately the error with the old php version still exists the previous php-fpm will not be restarted. so that the port is still occupied.

@geissweb, @kpendic As a reminder, we discovered that after replacing php-lib.pl, we had to restart webmin before the UI used the updated version. Can you restart that and then Re-Check Configuration through the UI?

@fbeckma It sounds like you're running into the problem we were earlier (which was the whole point of comment #43), but it's not clear what changes you have in place on php-lib, so I can't really provide much more info without knowing what your state is.

Thanks @draxius for helping us here!

But unfortunately I restarted webmin several times, problem persists. I can only hope that this issue has high est priority for the developers...

I get the same output for the "virtualmin check-config".

I replaced and edited the php-lib.pl in /usr/share/webmin/virtual-server/ (Debian 9) - that is the correct location right?

I downloaded the php-lib.pl from github and then executed the patch from # 43.

here the diff

then I see several equal php versions.

@geissweb I'm happy to help as I have the time. This isn't a burning issue for us any more, but I'm able to squeak in a few responses here and there.

To be extremely specific, we're running webmin-virtual-server_6.06.gpl (via Debian package) on a Debian 9 server with all packages on the system up to date. The only file difference in the entire /usr/share/webmin/ tree is /usr/share/webmin/virtual-server/php-lib.pl (as detailed in comment #45).

The "list_php_fpm_configs" subroutine (starts line 1700 of php-lib.pl) is entirely dependent on which php-fpm packages you have installed on the system, and is based on the local package manager (dpkg). You should be able to list those with dpkg -l, and the desired output should include not just php-fpm as a package, but also php7.0-fpm and php7.2-fpm (at a minimum). If those packages do not exist, the version checker won't find the other versions.

@fbeckma Looking through the code, I'm not seeing why you'd have an issue detecting the correct php-fpm versions on the system. It definitely looks like you've got both code changes in place.

Let me know if you're still having issues with the socket/port side of things - I can walk you through what I did to get that fully resolved (it was a bit of a pain for me at first). We can at least get you back to a pristine state.

Thanks again @draxius, I've got it working now. I applied your complete patch on a 6.0.6 fresh version:

The following PHP-FPM versions are available on this system : 7.0 7.0.33 7.1.26 7.2.15 :)

The only problem now is that the config edit links are still referencing the old 7.0 version like /etc/php/7.0/fpm/pool.d/154695539811782.conf, but I can edit it manually in the /7.2/ folder.

We had that same problem at first @geissweb - this is what led to our initial "Address already in use" issue.

You want to make sure that 154695539811782.conf (to use your example) doesn't exist in both the 7.0 and 7.2 folders, otherwise you'll get the port conflict.

One approach you can take is edit the site that "should be" 7.2, but is displaying in 7.0 - if you set the site's PHP-FPM Version back to 7.0, you'll functionally re-sync reality with what Virtualmin things is going on. Then you can move the site back to 7.2 and it should work.

If you have moved more than one site already, this gets a little trickier - you'll want to revert all of them back to the pre-patch version (which I presume is 7.0.33) first before you reset any of them to 7.2. Any other setting customizations you've made should stay in place, so you shouldn't have to worry about that, but you obviously want to get back to a state where you can seamlessly slide between PHP versions without concern.

@draxius Yes, the conf is in the correct folder on the server. I had the sites running on fpm-7.0 before I did anything, it works well. I just mean the link to edit the fpm-conf in the virtualmin UI still points to the 7.0 folder, although the conf was placed correctly in the 7.2 folder. I hope that it will be addressed in the official release.

@fbeckma Don't use the latest github version. Just take a vanilla 6.0.6 php-lib.pl and apply the patch as stated in comment #45. Set your domains to use 7.0-fpm before you recheck the config.

Hi,

I have loaded the github php-lib.pl 6.0.6 and applied the patch from # 45.

unfortunately still the same result. Manage PHP Configuration /etc/php5/fpm/pool.d/155083067221739.conf (FPM format) here is the file to lie, but is in /etc/php/7.0/fpm/pool.d/

The following PHP-FPM versions are available on this system: 5.6.39 5.6.39 5.6.39 7.0.33

@draxius I would be interested in the config for socket

@fbmecka, it looks like the UI has (yet another) bug, as pointed out by @geissweb's last post. The test sites we've moved to 7.2 and 7.3 still show /etc/php/7.0/fpm/pool.d/ as the file path, and editing the config file manually through the UI no longer works on those sites.

To validate which config is really in use, just look for these two files: /etc/php5/fpm/pool.d/155083067221739.conf /etc/php/7.0/fpm/pool.d/155083067221739.conf

If only one exists, and your site is served properly, then then the patch I recommended handles getting things working generally, but I haven't even started looking at a solution for the "Manage PHP Configuration" page as of yet.

Found it!

In feature-web.pl (should be in the same folder as php-lib.pl Change line 2337 from:

    my $conf = &get_php_fpm_config();

to:

    my $conf = &get_php_fpm_config($d);

The current line returns the "default" fpm config, and the modified line returns the config for the virtual server you're configuring.

This is the function used to build the "PHP-FPM Configuration" link on the menu, which is why it gets all out of whack.

After editing this file, you must: 1) Restart the webmin miniserv (service webmin restart on Debian) 2) "Re-check configuration" through the UI again.

After that, the links should show up properly. Ideally, this will close the loop on this problem, but once again, no guarantees.

Thanks so much @draxius :)

Thanks for pointing out this bug in feature-web.pl - it will be fixed in the next release.

Unfortunately I think there is still work to do. I have got the update to 6.0.6-gpl2 on Debian9 on another server and with that version I even don't see FPM as option to run PHP on in the settings.

I only see mod_php (which is completely uninstalled on the server) and the cgi/fcgi options. Check config shows:

UPDATE:

I was able to get the FPM selection back after I changed the corresponding /etc/webmin/virtual-server/domains/.conf, from: php_fpm_version=5 to php_fpm_version=7.2

@geissweb I downloaded and extracted the files in gpl2, and it looks like this is a release to address other issues, not the PHP ones we've been discussing. GitHub still isn't caught up with all of the fixes above, and it looks like the new Debian package was released prior to that check-in.

@JamieCameron As we were discussing starting at comment #43, the file path detection for pool configurations seems to suffer from a similar "bug"(?) on Debian, where it cannot find the correct /etc/php/7.x/fpm/pool.d path. Below is a patch against that file that fixes this particular problem - this has been tested by several of us already, so it seems to work. Without this change, it looks for paths like /etc/php/7.0.33/ and /etc/php/70, but not /etc/php/7.0 (which is the path structure that Debian uses). Given the stream of text, I'm sure it was pretty easy to miss, though.

We're holding off on patching to the latest Debian package until all the pieces of this are sorted out (we have a working code-base right now, so there's no real rush on our end). To clarify our current state (which works fully), we are running:

• Fully patched Debian 9.8 system as of yesterday
• webmin-virtual-server package is webmin-virtual-server_6.06.gpl_all.deb
• php-lib.pl was updated to match version currently in GitHub (commit e1987a2), and then patched as detailed in the code block above
• feature-web.pl was updated to match version currently in GitHub (commit 9feb9dd)

If there's any other information I can provide, please let me know.

Many thanks @draxius

When will the official fix be out as my machine is messed as well due to this.

Not true on the fpm package.

I have php7.2-fpm installed and when running the VM PRO check I get this....

No PHP-FPM packages were found on this system.

hello @draxius , in your comment https://www.virtualmin.com/comment/809098#comment-809098

im struggling to make that work. I can change php versions, but the php-fpm will not change to the new version . So i check on my php7.0 pool.d directory and the files are there and never created in the new version of php (in this case php7.1)

your help is appreciated

Any news on this? I am facing the same problem on my server

@aschenbr - The changes I made in the referenced comment modified the version of php-lib.pl found here: https://github.com/virtualmin/virtualmin-gpl/blob/e1987a29dd4c88343ea5e6...

You'll also need the updated feature-web.pl - https://github.com/virtualmin/virtualmin-gpl/blob/9feb9dded0da06b0b186ce...

Those files are not updated in any debian-packaged version at the moment, and each includes a necessary piece of this puzzle. From there, you will need to apply the additional change here: https://www.virtualmin.com/comment/809098#comment-809098

Hopefully that can help get you straightened out.

This still isn't working on VM Pro even with the diff added. No PHP-FPM packages were found on this system. Is what I get when re-checking configuration.

NM I forgot to add the diff for php-lib.pl

I can confirm that VM Pro works with those changes.

The following PHP versions are available : 5.6.40 (/usr/bin/php-cgi5.6), 7.0.33 (/usr/bin/php-cgi7.0), 7.1.27 (/usr/bin/php-cgi7.1), 7.2.16 (/usr/bin/php-cgi7.2), 7.3.3 (/usr/bin/php-cgi7.3), 7.0 (mod_php)

The following PHP-FPM versions are available on this system : 7.2.16

Whoops spoke to soon. Yes VM Pro finds fpm now but in Website Options you don't have the option to use FPM.

Does edit_phpmode.cgi need to be edited ?

I followed this and it worked for me @aschenbr - The changes I made in the referenced comment modified the version of php-lib.pl found here: https://github.com/virtualmin/virtualmin-gpl/blob/e1987a29dd4c88343ea5e6...

You'll also need the updated feature-web.pl - https://github.com/virtualmin/virtualmin-gpl/blob/9feb9dded0da06b0b186ce...

Those files are not updated in any debian-packaged version at the moment, and each includes a necessary piece of this puzzle. From there, you will need to apply the additional change here: https://www.virtualmin.com/comment/809098#comment-809098

Hopefully that can help get you straightened out.

I made all those changes. Maybe there is a file in the VM Pro that needs to be changed still that isn't posted yet.

Patched a few Debian 9.x boxes as specified in this thread.

Result:

But can you select the FPM version under Website Options ?

Yes, I was able to flop from FPM or FCGI, and from PHP 7.0.x or 7.3.x

Patched and fix also on debian 9.8! YAY!

Just a short note if cli shows the version but web does not:

Restart your webmin server

I missed that :(

For everyone who is following this thread, I submitted a pull request (which has already been merged into the master) to add the Debian-friendly code - https://github.com/virtualmin/virtualmin-gpl/commit/3e2475f1ca3712785635...

With any luck, this should be part of the packaged 6.07 release for all platforms, but that's in the hands of the devs now.

One more debian 9 system got multi php-fpm. thanks! By the way. how to make fsgi + php fpm. As people write that's the most performance solution now

Hi, I think i did something wrong. I replaced files php-lib and feature-web and can change between php versions, but the config file is not switched. I back to the original php version and all the config in php config disapeared.... Should i install virtualmin from scratch?

the only change that i needed to make on the latest updates in debian and virtualmin was to edit the one file php-lib.pl as outlined by https://www.virtualmin.com/comment/808744#comment-808744

after doing that then reckecking configuration in Virtualmin, I am now able to select different releases of fpm (ie 7.0-7.3).

I did notice that virtualmin authentic theme has thrown an error after doing this...(the error dissapeared before i could copy it), so I am not sure if that is related to this php fpm change or not?

Any update on 6.07 availablity?

I am still not able to select fpm in 6.07 - am i doing something wrong or is it still not fixed after all those months?

Brutal still busted. i wish they would get their act together with this virtualmin, im ready to abandon after years of using them, as a paid customer.

okay - what seems to work for me is:

1. set php mode to fcgi
2. edit ne /etc/webmin/virtual-server/domains/ change php_fpm_version=7.x to php_fpm_version=7.3
3. set php mode to fpm

No clue why this can not be fixed.

Actully i just deleted that line, i think i may be depreciated

php_fpm_version=7.x

and it works, such a waste of time for lazy code

Not working for me - it is getting back with 7.2 if i delete it.

So for my instance Im only running 7.2.21, so it picks it up, but if you have multiple, you may have to put that in, I haven't been able to try that. And this is also on CentOS 7. Fyi.

This is not completely fixed...whilst one can manually change to php-fpm versions, i have still encountered a problem in server templates.

Virtualmin>System Settings>Edit Server Template>default template>Edit Template Section>php options (dropdown) - php versions = highest available (the drop down list shows available versions 7.0, 7.1,7.2,7.3)

However, when i provision a new virtual server, it keeps setting php-fpm to version 7.0.

Shouldnt "highest available" mean the last release in the list...ie v7.3?

this means every time a virtual server gets provisioned, i have to manually go in and change it. A flaming nightmare to be honest!

Offtopic joking sorry. IF this is giving you already a.   A flaming nightmare

I guess it is easy for your partner to give you very nice dreams to. ;)

If you choose the version 7.3 in that dropdown does it work well then.

I'm not from virtalmin supprt!

Same here. Would be nice if we can also use FPM for multiple php versions

php-fpm isn't changing at all, only php. when I go to virtualmin>services>php-fpm configuration, is still showing version 7.0 for new virtual servers. Only one of my virtual servers is 7.3...all the others 7.0 (so multiple versions is possible but the selector isn't working)

One thing I do note, if I recheck Virtualmin configuration, I get a number of "fixing port clash" lines, then any virtual server using php goes offline. I have to go into virtualmin>server configuration>website options and change php-fpm to fcgid and back again to bring them back online again (happens every time)...is this related to me having multiple fpm versions active on virtual servers?

Hey guys, I'm not sure why this would make a difference but the fix, as implemented above (and in version 6.0.8), has worked perfectly for me with any versions I've tried to use/add from php5.6, 7.0, 7.1, 7.3 & 7.3.

Now that 7.4 has just been released a few weeks ago, I added it to my system and did a "re-check", and it picks up 7.4 as a cgi option but it won't pickup it's FPM oddly enough.

I confirmed that the following directories/files exist:

Which, from what I understand from the code above in php-lib.pl are the directories that it checks for? Line 1747:

Odd that 7.4 would not be detected when multiple other versions are and the naming of the folder is not odd or any different, just a version number change?

Any ideas??

The issue here is that Virtualmin in the current release doesn't know to look for PHP 7.4 at all. This will be fixed in the next version though.

Tested on Debian 9, clean installs, latest Virtualmin 6.08 1) with apache -> it works 2) with ningx it does not work. I get the option to select and change the PHP version with FPM enabled but it reports "Failed to save PHP versions : The PHP version cannot be changed when in FPM mode"

Is support when using nginx being worked on?

Please, I try to change my PHP version and every time I try to change the PHP version I got. Failed to save PHP versions: The PHP version cannot be changed to any version except the default for Nginx websites. What should I do I need to change my PHP version? I run WordPress and Nginx, PHP FCGI

One year later, and the problem is not yet fixed.... https://www.virtualmin.com/comment/808744#comment-808744

One year later, and the problem is not yet fixed

What exactly doesn't work for you?

just misstyped a command and deleted a file. My fault. sorry

Automatically closed - issue fixed for 2 weeks with no activity.

Has this issue been fixed? Can I install multiple versions of PHP? I do not need to use 2 simultaneously, but what happens is when website start giving you warnings of old PHP, you want to switch the whole thing by going to the list, and picking new one, and automatically applying.

For example, all of my WordPress installs from 2015-16 were giving me 5.6 out of date errors, and I wanted to get them to 7.2, so I was hoping I could install PHP 7.2

sudo add-apt-repository ppa:ondrej/php

sudo apt-get update

sudo apt-get install php7.2

php -v PHP 7.2.13-1+ubuntu16.04.1+deb.sury.org+1

and then go into Virtualmin PHP version, and switch, and have all sites switch versions automatically. Is this not possible? Do I still need to go into Apache and:

sudo a2enmod php7.2

apachectl -t

sudo service apache2 restart

and then test with

user@test:~# ls /etc/apache2/mods-enabled/php* /etc/apache2/mods-enabled/php7.2.conf /etc/apache2/mods-enabled/php7.2.load

or if I can just switch in Vmin menu under PHP Versions.

Then usually I just

<?php
 phpinfo(); 
?>

You can tell which PHP version you are using by putting up a PHP Info page.

Then if you visit the page in the browser it should look something like this:

https://lwstatic-a.akamaihd.net/kb/wp-content/uploads/2019/01/phpinfo-mi...

If you had a site already up and running on the previous PHP version, test it out now and see if there are any issues. If your code isn’t compatible or showing errors, you can try to diagnose further or if you need the site back up right away you can downgrade the PHP version again by running the a2dismod and a2enmod commands to disable PHP 7.2 and then enable 7.0 or whichever previous version you had on the server then restart Apache again.

Some sites may now show an error saying a module is missing and can’t run, or if you are developing a new site and have a list of modules that are needed, then the next section can help you add new modules. Adding Modules to PHP 7.2

The switch to PHP 7.2 doesn’t automatically keep all the same modules from previous PHP versions. If you don’t need to compare the list to a previous PHP version then to install any basic modules you do need, first type the comannd below. But don’t press enter, if you press the TAB key twice you should get a list of available modules specific to 7.2::

@test:~# sudo apt-get install php7.2[tab][tab]

Example Output: php7.2 php7.2-enchant php7.2-mbstring php7.2-snmp php7.2-bcmath php7.2-fpm php7.2-mysql php7.2-soap php7.2-bz2 php7.2-gd php7.2-odbc php7.2-sqlite3 php7.2-cgi php7.2-gmp php7.2-opcache php7.2-sybase php7.2-cli php7.2-imap php7.2-pgsql php7.2-tidy php7.2-common php7.2-interbase php7.2-phpdbg php7.2-xml php7.2-curl php7.2-intl php7.2-pspell php7.2-xmlrpc php7.2-dba php7.2-json php7.2-readline php7.2-xsl php7.2-dev php7.2-ldap php7.2-recode php7.2-zip

This is not a complete list so you may need to look up how to install other modules you may need. You can type the modules you want, and you can add multiple in the same install command, like:

user@test:~# sudo apt-get install php7.2-opcache php7.2-mbstring php-memcached

If you did save the list of modules from a previous PHP version with the command earlier in the guide, you can save a list of the modules in PHP 7.2 and compare them with the previous version. Run:

php -m > /tmp/7.2.modulelist.txt

Then to compare it to the list that was created before, run:

user@test:~# diff /tmp/7.0.modulelist.txt /tmp/7.2.modulelist.txt 15,16d14 < mysqli < mysqlnd 21d18 < pdo_mysql 28d24 < soap 29a26

sodium

Or if you want a more visual way to compare the two lists, run:

user@test:~# vimdiff /tmp/7.0.modulelist.txt /tmp/7.2.modulelist.txt Run the vimdiff command to see the modules that are different from previous PHP versions.

Which will show a page like this in the terminal:

In this example, the various MySQL modules and soap show up on the list of 7.0 modules on the left but are missing from the 7.2 version on the right, and the sodium module is on 7.2 but wasn’t in 7.0.

So for this example, we can install the missing modules with:

user@test:~# sudo apt-get install php7.2-mysql php7.2-soap

After that installs, we can save an updated list of modules and can compare it again:

user@test:~# php -m > /tmp/7.2.modulelist.updated.txt diff /tmp/7.0.modulelist.txt /tmp/7.2.modulelist.updated.txt 29a30

sodium

Is that still necessary, or did we get it fixed? Sorry for longer question on closed topic but will help Google searches find Vmin Lol

For example, all of my WordPress installs from 2015-16 were giving me 5.6 out of date errors, and I wanted to get them to 7.2, so I was hoping I could install PHP 7.2 - sudo apt-get install php7.2

According to our manual, you need these packages installed as well -

apt-get install php7.2-mysql php7.2-cgi php7.2-cli php7.2-fpm

and then go into Virtualmin PHP version, and switch, and have all sites switch versions automatically.

After installing new PHP version run Re-Check Configuration from System Settings.

Do I still need to go into Apache and:

No.