These forums are locked and archived, but all topics have been migrated to the new forum. You can search for this topic on the new forum: Search for PHP-FPM 7 on new install Centos 7 on the new forum.
Web Hosting and Cloud Computing Control Panels
PHP-FPM versions switching is still an ongoing thing...and version detection is a bit iffy, as well (it was supposed to use the latest available, and does on some platforms, but on CentOS, it's got that weird super long /opt/blah/blah/php path to all the binaries for PHP7, I guess Jamie missed it). For now, to use a different version than what Virtualmin detects and enables, you'll have to use the fcgid execution mode. We're still working on it, and it'll probably get sorted out in the next couple versions.
--
Check out the forum guidelines!
I wonder if the procedure in the thread, accounting for the fact that the service path is not init.d but /usr/lib/systemd/system would work.
https://www.virtualmin.com/node/48666
A long term fix is that with multiple PHP versions, Virtualmin should just run the highest one (FPM) since you can't have both running.
(FPM) since you can't have both running.why is that while it is and should be possible in hopefully near Future. ?But yes some troubles for now while testing VM6 CENTOS 7.4, switching and so on. but that is offtopic probably, i tested to remove a third party php package, but then didn't succeeded to get php virtualmin running correct anymore, i know no support but somewhere settings / config if something broke php real hard to repair. ( newbee guy no experience with virtualmin sorry)
But i also must say, beeing impressed what VM6 could do as Control Panel even in GPL. thumbs up keep on going.
It will eventually be possible to run both. PHP-FPM support, in the default install, is new; only tree revisions of Virtualmin, so far have had it. About six months. We're working on getting the bugs worked out, and making sure we really understand how people want to use it before adding more variables to the equation.
There's also the problem of complexity in the user interface. Because we still have to support mod_php and mod_fcgid for the foreseeable future, there's a ridiculous number of variables in a PHP config. We spend half the time troubleshooting just getting an idea of how people are trying to run their PHP before we can even start sorting out why it isn't working! It'd be ideal if we could get rid of one of the options (mod_php!) while introducing new ones, but for now, that's not do-able. We still have too many deployments running mod_php for us to kill it without angering a lot of people.
--
Check out the forum guidelines!
Is is possible to adopt for example CENTOS the REMI Multi PHP Distribution ( PHP parts), maybe some working together is less work and also easier to support. For sofar i Know that is a often used REPO.
So is only a idea, while as you say so may to think of, then if you adopt often used an well mantained third party packages sharing also some experience and support between the Teams, could be a win win.
BUT ok i don't know how much work it is to have separate PAckages to support for different OS;s for VM PANEL, and if the most important parts are common ( same as wanted / needed in VM) enough, to give it a try.
So what i mean is divide some for Support, so php to PHP persons / teams, not to be VM TEAM, only the integration part Support knowledge at both sides, the special knowledge there where needed the most.
Sorry i hope you understand my text.
So basics there where it should be, specials knowledge in commutity teams, support if then needed specials then payed a sort of high end....
Hmm sort of CSF ..
We currently prefer the SCL repos, for CentOS, for a variety of reasons. The original packages are derived from Remi packages, in the case of SCL. We're not seeking to support every version of PHP ever released. We'd like a good, tested, set of options to cover the folks who want "new" and for folks who want "old and stable". So, for us, having some PHP 5 version and some PHP 7 version, without much concern for the specific revision, is fine. It covers the majority of users in a way that is plausible for us to reliably support (though, even now, with the limited subset of versions and execution modes we're targeting, there's a lot of opportunity for things to go wrong).
It's a really valuable feature to have things Just Work. And, the more variables we introduce into the default install, the less likely everything is to Just Work. So, ideally, we won't support two dozen different PHP versions; we'll instead support a couple of PHP versions per distribution/version combo we support (which ends up being about a dozen different PHP versions). Realistically, that's already too many, as long as it's just the four of us. But, it's the minimum for covering what everybody wants (and we still have a couple of distributions that don't have a good option for either PHP5 or PHP7, so they only have one or the other...we'll sort that out eventually, I hope).
"BUT ok i don't know how much work it is to have separate PAckages to support for different OS;s for VM PANEL, and if the most important parts are common ( same as wanted / needed in VM) enough, to give it a try."
It's a lot of work. ;-)
--
Check out the forum guidelines!