| SYSTEM INFORMATION | |
|---|---|
| OS type and version | Ubuntu 22.04 LTS |
| Virtualmin version | 7.20.2.gpl-1 |
I need guide regarding changing PHP Version for a specific "Virtual Server ".
Basically, one website uses PHP version 7.4 but by default the version is set to latest. I only want to change PHP Version for that one server.
Thanks.
Thanks @Joe it worked
I wish that installed PHP versions management was done from within the Virtualmin GUI.
why ? the instructions are perfectly clear and to be fair there is no need to install different versions of PHP unless you are a developer wishing to check forwards/backwards compatibility of your project or you have installed some really old/new PHP application of which both is not really recommended
Then why use Virtualmin? Why make you life easier? Why does cPanel, Plesk and many other panels allow you to manage PHP versions from within the GUI?
Answer = people want this because it makes life easier. How many times has Joe and the team answered the question. This is going on my request list 
along with php module management.
@wms I have also asked this when I was starting out with Virtualmin so this is quite normal and welcome to the forum.
9/10 the request to add different PHP versions is misguided, it would be a better idea to go back to the application vendors and get them to fix the issue with their application that does not work with the version of PHP that is installed via the OS you have selected, rather than âfudgeâ it installing a version of PHP that your OS did not supply
This is just wrong. Are you going tell WHMCS.com that they should have their software compatible on PHP 8.3 so that it matches all of my WordPress sites running on PHP 8.3 or should I just upgrade all 100 of Wordpress hosting accounts to PHP 8.2 and then in 6 months upgrade them again to 8.3 for kicks.
Using Multiple PHP is recognised paradigm as part of your server topology and being able to manage it from the GUI is a much welcomed feature even if it was just for Pro users.
therefore donât use their software if itâs not compatible with the version of PHP that the OS supplier has set as the default just find an alternative that works with the version of PHP that is installed, WHMCS (whatever it is) should have produced a version that is compatible, which I do with every PHP project I do, OK this needs a shed load of switch statements in the code, but I have stuff that works on PHP 5.x through PHP 8.4 in the same file using this method
It is enough of a FAQ at this point that maybe, at minimum, a link to the documentation. But, yeah, you have to give the customers what they want sometimes.
Sure, but just how far back into history (and depreciated rubbish) makes sense ? do we start re-introducing security flaws/bugs
It isnât about what choice âweâ make for anyone else. The remi and sury repos are maintained. Making the server owner do a little digging and manual install might be the right amount of impediment while still offering choice.
Technically you can do everything inside the GUI.
*** Add Repos ***
*** Install Packages ***
*** PHP Options (if multiple versions of PHP are installed, you can change execution mode and/or PHP version here on a per website basis) ***
*** Manage PHP Configuration (you can manage virtually every PHP configuration) ***
So who says that you canât manage PHP from the panel⊠huh?
The point of:
Is to give you instructions for different distributions, as you do need to understand that Debian-based based systems source data differently then Ubuntu-based, and RedHat-based distros.
However, many of the command line steps that are noted in that documentation could technically be completed inside the panel.
I understand what is there and how to use it. I just want the option to select a php version and click install, all of the repos are taken care of and I can have a page of checkboxes to select the php modules.
Itâs not the job of Virtualmin to choose third-party repos for you. Which is basically what youâre setting up when you decide to upgrade outside of what the distro is packaged with.
However, Virtualmin does provide the tools for you do add third-party repos and adjust quite a few settings of your system through the GUI. Thatâs what it was built to do.
Iâm of mixed feelings on this. I think people should be aware of what theyâre doing when going outside of OS-provided packages. You lose the maintenance commitment.
Saying the Remi or Sury or whatever repos are âmaintainedâ is only sort of true. They are maintained in the sense that when updates become available from upstream, they will get rolled out to those repos. But, if youâre running a PHP version that is EOL upstream, Remi or Sury will not backport security fixes. Thatâs a huge job, and not something a small project could do, but it is something an OS vendor like Red Hat or Ubuntu can do (slightly less so for Debian, but Debian can borrow from the commercial vendors), because they have a large team.
Installing an old PHP version from a third-party repo is potentially quite dangerous. It might reach EOL at some point in the future and if you arenât paying attention, youâll be running an exploitable version at that point. With an OS-maintained version, you can be reasonably confident that wonât happen during the life of the OS.
Third-party packages should be used with caution and awareness about the trade offs you are making. Maybe our documentation needs to be more explicit about all that. But, the best choice is running only OS-provided packages. If you must diverge from that, youâll want to do so with careâŠmaybe keep an eye on PHP EOL notices.
I should also mention that any control panel that dumps a bunch of PHP versions on your system by default is putting you at risk, they arenât helping you. Nobody is seriously maintaining PHP beyond the upstream EOL except for the major Linux distros, so if youâre running a PHP version that is EOL upstream, and it came from anyone other than a major distro vendor, youâre probably at risk. PHP 7 is EOL. If youâre running a Remi or Suri version of PHP 7 or any other third party, youâre at risk. Likewise PHP 8.0.
Anyway, my concern is that if we put this behind a button, instead of requiring reading some docs, a whole lot of people are going to go hog wild and install a half dozen PHP versions, as though thatâs somehow better (itâs wasteful of memory, at the very least, even if you donât grab any insecure versions). We already find a lot of folks with a half-dozen versions of PHP, which doesnât even make sense. The vast majority of PHP software runs on a reasonably recent version, and very rarely do you need to go out of your way to get something really old or really new.
Just be careful out there when youâre going off-roading.
Yes @shoulders,
My clientâs application was built on an older version of PHP and most of the times this happen as it takes time and testing before upgrading to newer PHP versions.
This topic was automatically closed 8 days after the last reply. New replies are no longer allowed.
