Confused about what to choose!
Announcement
Collapse
No announcement yet.
MultiPHP or Select PHP version (CL) ?
Collapse
X
-
Hi,
Im a bit confused on which to use or should both be used?
I have read docs from CL here. That will be quite confusing for customers that has two choices.
Why cant you provide different php versions for each domain like cPanel and multiphp ini editor?
It would be great to get some feedback from other users/companies on what they are using/planning to use and how?
-
I have to agree, it will be too complicated for end users. We are defenitly going to wait as long as possible before moving to EA4.
The current system just won work, I myself found it complicated just reading the documentation.
It needs to be made easier for the end user. End users arent sysadmins and it feels like you have to learn how it works to be able to use it. When that happens webhosts end up disabeling the feature as it creates to many support requests and makes the whole interface feel complated.
We currently disable cPanels native PHP version and need to keep it that way. We do not want users to be able to use cPanels PHP version.
We need a way for users to be able to set different PHP versions on different VHosts, but the different PHP versions must be PHPSelector versions only.
So the logical way would be to allow webhosts to hide cPanels PHP versions if they want to and to add CloudLinuxs PHP Selector PHP versions to cPanels Multi php manager.
Please try and get something like this working or at least fix the ability to set PHP Selectors PHP version in .htacess (so we would disable cPanels Multi PHP Selector and inform users about the line they have to use in their .htaccess to change the PHP version of a directory.
I was under the impression that we were heading towards something simpler, but it sadly seems alot more complicated.
Is it me or have you only made them work side by side without actually managing any integration between the two ?
Comment
-
I have been having some sleepless night lately about this, and after some thinking I will not provide access to MultiPHP from cPanel yet for our customers.
They are used to Selector form CL and a new system will only confuse them atm.
I love the ability provided by cPanel to change php version for diffrent domains in cPanel and aswell have a php.ini ediitor gui. But in my mind the companies should work togheter to provide an easier solution.
If that is not possible I hope CL can develop the php selector to easily change customers php version on folders/domains. And maybee provide a seperate php.ini editor?
I also had to use EA4 on all new servers because of cPanel 58 version, but Im not that happy with EA4 yet. Still alot of bugs and it will take some time to get used to it....
Comment
-
I feel your pain. EA4 / MultiPHP is a learning curve all by itself. If you run CL + CageFS + PHP Selector along with EA4, it becomes pretty unbearable to manage.
(NOTE: I have not yet performed an EA3-->EA4 migration. Ive only been testing EA4 on a test server deployed with 58 and EA4 as a default)
Supposedly if you want to have the cPanel user _only_ see / use PHP Selector, then as of now (8-27-2016) you have to do something like this:
1. Make sure you have CageFS / PHP Selector installed
2. Make sure all of your users are caged in CageFS
3. Make sure that none of your users have "native" selected in their PHP Selector
If "native" is available in PHP Selector and is selected, the user will be using MultiPHP defaut system PHP version. You wouldnt want that.
After making sure that none of your users have "native" selected in their PHP Selector, youll then want to disable "native" completely so that they do not even have an option to select it within PHP Selector. You would do that by going to WHM --> CloudLinux LVE Manager --> Selector.
Default PHP Version: set this to something other than "native"
Supported Versions: click "native" and disable
4. Go into MuliPHP Manager
a. select a default system PHP version
b. set all of your / your customers domains to "inherit"
5. Go into the Feature Manager --> Manage Feature List "disabled" and edit it
checkmark MultiPHP Manager and MultiPHP INI editor and save
This will make sure that MultiPHP INI editor and MultiPHP manager are not available in customers cPanel interface
Now all of your users are using PHP selector and only PHP selector -- and they cannot choose "native" in PHP Selector and cannot see MultiPHP Manager or MultiPHP INI Editor in their cPanel interface.
I had wondered what would happen when I add a new account, so I added one. After I added the new account, I looked in MultiPHP Editor and its domain was set to "inherit". So, thankfully, at least as of 8-27-2016, the MultiPHP Editor by default will set new domains to "inherit".
Mike
Comment
-
While that will work and that is what we will do. Cloudlinux has said that they were not working on fixing allowing customers to specify which PHP version in .htaccess like we used to be able to do because of EA4 comming.
As at the moment EA4 Multi PHP will have to be disabled to prevent users from being too confused, we need CloudLinux to fix the ability to have multiple PHP versions on a per .htaccess file basis as it was possible before.
We also need to know what Cloudlinuxs plans are about making EA4s Multi PHP able to only show Cloundlinuxs PHP versions and thus preventing confustion. If this will neever be possible, what are your plans about making the old system work again ? And what are your plans to create an interface to allow users to use the old system in a similar way as EA4 Multi PHP Works.
We had our hopes up for this, and were completly unaware that it was only going to be able to work along side and not actually be integrated. I do hope this is planned for a future version.
Comment
-
Richard,
I am sorry, there must be some misunderstanding. We have no intention of implementing multiple PHP per account in PHP Selector, because there is MultiPHP from cPanel.
Yet, there is no issue with .htaccess/customer specifying any version of PHP they want from our side.
The only limitation I know with .htaccess / php versioning is mod_fcgid. It just cannot do it from what I remember.
suPHP & mod_lsapi both support it, and that is why we can do PHP Selector & MultiPHP at the same time (for better or worse).
Comment
-
MultiPHP needs to only show PHP Selectors PHP versions and not cPanels PHP versions. Mixing cPanels PHP versions and Cloudlinuxs PHP versions is too complicated for customers. Customers need 5.4, 5.5, 5.6, 7.0 but not :
EA5.4
EA5.5
EA5.6
EA7.0
Inherit
With Inherit being PHP selector. You have to read the instructions to know that inherit is controled by PHP Selector.
What we need is to have no EA versions in MultiPHP and instead only have something like :
PHPSELECTOR 5.4
PHPSELECTOR 5.5
PHPSELECTOR 5.6
PHPSELECTOR 7.0
As for controling via .htaccess on our servers, when you do that you don get any of the modules selected in PHP Selector making it unusable. When this first stopped working we were told by your support it was EA4 that would fix this bug and that we had to wait. Should we contact support again about this ?
Is integrating PHP Selector PHP versions into EA MultiPHP something that CloudLinux needs to work on, or is this something that we should request on cPanels feature request system ?
If we can get PHP versions selected in .htaccess files working again, we might build our own plugin to allow customers to choose their PHP versions. Unless of course in future releases we get the ability to remove all EA PHP versions from MultPHP and have instead all of PHP Selectors PHP versions.
I think there is a really bad UX problem here that needs to be solved before MuliPHP becomes usable with PHP Selector.
Comment
-
There is an easy work-around for this. I already mentioned it in a previous post. If you dont want your users to see MultiPHP Manager / MultiPHP INI Editor, simple add those to the "disabled" feature list in the Feature Manager. Your customers will then never see MultiPHP and will only see PHP Selector. No confusion.
I understand that you want PHP Selector + multiple versions of PHP on the same account. Well, based upon what Igor says, that isnt going to happen the way you want it to happen. Personally, I dont mind as Ive already only ever given my customers the option of one PHP version accountwide. I do understand how/why you would want to support multiple versions of PHP though. But I wont personally bark about it because I have no need for it. And, if I did need it, I would simply allow that particular customer to see MultiPHP and not PHP Selector -- or allow them to see both. ( I have to presume that any customer who wants/needs multiple versions of PHP is likely savvy enough to navigate both MultiPHP and PHP Selector )
Mike
Comment
-
Having PHP Selector versions of PHP show up in MultiPHP would be a nightmare, simply because CL would then have to also incorporate the PHP Options section in there -- and only for PHP Selector versions. And that MultiPHP section is cPanel-specific/native.
In my opinion, for better or for worse, PHP Selector versions of PHP as well as PHP module options and PHP.ini stuff for PHP Selector all belong (eg: should remain) in PHP Selector -- and should be totally separate from MultiPHP like they are now.
CL / PHP Selector is not cPanel, and its features should not be inside the cPanel MultiPHP thing.
Mike
Comment
-
Richard,
Isn it true that if you did not enable mod_lsapi serverwide but instead enabled it per-user, that you would have the functionality in .htaccess to run multiple PHP versions via PHP Selector just like before.
I think I only lost the ability to do multiple versions of PHP in CL+PHP Selector when I switched from using per-user mod_lsapi to serverwide mod_lsapi.
Mike
Comment
-
We actuelly use LiteSpeed, and had the .htaccess PHP versions working using the public instructions that were in Cloudlinuxs documentation. Then an alt-php upgrade prevented user selected PHP modules from being used (removing things like mysql support). We still get the PHP version selected in the .htaccess file, but just without any PHP modules enabled.
Cloudlinux support said that their implementation with MultiPHP would resolve this issue so they were not going to fix the .htaccess problem.
Now we know that current MultiPHP implementation doesnt fix this problem we would like Cloudlinux to see if they can fix the problem and try to be sure that it will not happen again.
Comment
-
What your discussing belongs in a completely different thread man. Just my opinion. Adding it in here just clutters up an existing informative thread for those us using EA4+PHP Selector or those of us who will be migrating to EA4+PHP Selector in the future.
Mike
Comment
Comment