5 and more PHP versions

[tlife]

Hi, I found this link:



I would like to run more than 4 PHP versions in my Directadmin installation.

So I typed in directadmin.conf

num_php_versions = 5


I installed PHP version 7.4, but unfortunately in directadmin I do not have the choice of PHP version 7.4, only the original 4 versions that I installed earlier. How to run it?

Is the problem that I'm using CB2.0? Is there any possibility?

I ask for advice.

 

[Richard G]

You can't.
You found it here:

Changelog | Directadmin Docs

DirectAdmin Knowledge Base

www.directadmin.com

It clearly says that the current limit is 4. Also that more then 4 is proposed and the feature is stated (right side) as unfinished.
So you can't use it at the moment with more then 4.

 

[desfire]

Is more than 4 avaliable now?

 

[Zhenyapan]

Is more than 4 avaliable now?

not yet, https://www.directadmin.com/features.php?id=2545
it will in few weeks

 

[cichy]

@smtalk When client requirements more than 4 version we must compile extra version by hand. The problem exists for a long time. When it will be possible use that more over 4 php version?!

 

[DirectAdmin Sales]

@cichy

I agree there is some demand but it doesn't have as many upvotes as other features.

However... It might be a perfect Pro Pack candidate, and a great example of how the Pro Pack gives us resources to quickly add lesser-requested features.

Even better, it wouldn't take anything away from DA core users. PHP themselves never has more than 3-4 active versions, so the DA core already covers this. 5+ versions is more of a specialty/convenience feature so it fits right into the Pro Pack concept.

So this might be a good solution for those who want the feature very fast. I'll see if @smtalk has anything to add to this.

 

[cichy]

I completely disagree with you. My company pai for 200+ DA licences. If you want satisfy clients you must have more that current active PHP versions. Example please check WP PHP stats https://wordpress.org/about/stats/

The facts:
7.3 20.88%
7.2 11.70%
7.1 2.95%
7.0 4.14%
5.6 7.33%

Above versions isn't currently supported but users/clients demand that. If you have server with 100+ users many of this requitmens older PHP versions. But DA supports only 4. In that situation we must compile by hand.

PRO PACK?
PHP support is main feature...
We will not paid more for the bassic feature, never.

Please add the suport more that 4 versions and not generate service problems for share hosting

 

[BillyS]

Shared hosting running a php version that was published 7 years ago? Pretty sure that should be discouraged by the host and certainly would not rank high on a priority list for DA.

 

[Active8]

Shared hosting running a php version that was published 7 years ago

You will be amazed if you look what people still use these days for old stuff.
Purely because they are locked in by software vendors who didn't update their software for newer php/sql versions or went out of business.

Yes you can force them to go some elsewhere but that is then not good for your business

 

[kristian]

Personally I'd stick with only what's supported upstream by the PHP developers. If customers are stuck with ancient and non-upgradeable versions of their applications, we suggest they get a dedicated VPS with the old versions they need. The stability and security of the other customers on the shared server is more important to me than satisfying someone stuck in the past.

 

[BadSuzi]

You will be amazed if you look what people still use these days for old stuff.
Purely because they are locked in by software vendors who didn't update their software for newer php/sql versions or went out of business.

Yes you can force them to go some elsewhere but that is then not good for your business

Exactly this. In my company we have the same situation as @cichy mentioned. A lot of people uses old wordpress version/custom applications etc and we can't force them to update theirs stack - it's theirs application, but still, they are paying as for server and we are obliged to give them what they need to.
I don't believe that adding new PHP versions is so big trouble - we already have selector for 4 versions, adding 5,6,7 etc versions will take propably few lines of code more.

@DirectAdmin Sales
However... It might be a perfect Pro Pack candidate, and a great example of how the Pro Pack gives us resources to quickly add lesser-requested features.
Seriously? We already paying ~20USD per license and got plenty of them and if we want basic thing like selector for more PHP versions we have to pay extra for that? I understand to pay extra for custom plugins like i.e postgress support but smht like this? Come on...

 

[warg]

Personally I'd stick with only what's supported upstream by the PHP developers. If customers are stuck with ancient and non-upgradeable versions of their applications, we suggest they get a dedicated VPS with the old versions they need. The stability and security of the other customers on the shared server is more important to me than satisfying someone stuck in the past.

Another thing to add: It's very unlikely that scripts that were designed back then do fulfill the IT security obligations given by current laws or IT/business certifications nowadays. E. g. it's quite safe that the scripts wouldn't fulfill GDPR and thus couldn't be used in whole European Union or by companies who have customers from EU. I have such a case of an outdated script myself and for sure it's pity to run it somewhere now but doesn't change the fact that it's a bad idea and in many cases not legal.

 

[woktron]

I agree there is some demand but it doesn't have as many upvotes as other features.

However... It might be a perfect Pro Pack candidate, and a great example of how the Pro Pack gives us resources to quickly add lesser-requested features.

A lost opportunity for you guys would be that there is no way for internal lifetime/datacenter license holders to purchase the pro-pack. We are now using CloudLinux but would be more than happy to make the switch.

 

[cichy]

Shared hosting running a php version that was published 7 years ago? Pretty sure that should be discouraged by the host and certainly would not rank high on a priority list for DA.

The world isn't perfect... We tried not once our clients persuade to change PHP currently supported versions.

Example local very small hairdresser bought website 3-4 years ago on PHP 7.0 and paid 900$ but the site is encrypt by ioncube. In the above case we can terminate agreement but another company on the market get new client..

In the situation answer is easy. You must support more that 4 versions or comany wil be end.

 

[BadSuzi]

PHP 7.4 lost it's support in 10 months:

PHP: Supported Versions

www.php.net

So @warg - it's going to be violate the GDPR to use 7.4 when most of the market still uses 5.6 or slightly above?
The point is not about stack on servers but about having a choice. We are paying for lDA license and it would be nice, if this softaware meets our requirments.

 

[warg]

Maybe my statement was a bit unclear: I think v7.4 is fine due to still getting security updates. Anything that doesn't get security updates anymore wouldn't be fine in most cases. Of course it also depends on what you do run/develop. If your script itself is by chance GDPR-compliant or you don't have to care about GDPR because it doesn't apply to you or your customers, it's fine as well. It was just an example which would impact a lot of ppl. For example PHP <= v7.3 would be an issue in my point of view because it's out of support and thus a potential non-patchable security risk.

 

[Richard G]

You will be amazed if you look what people still use these days for old stuff.

And main reason for this is the refusal of hosting company's to tell their clients to update stuff to not EOL crap. Too afraid to loose customers, so now panels are forced to support ancient stuff? That's the world upside down.

Example please check WP PHP stats https://wordpress.org/about/stats/

Totally not interesting. Users must be pushed to upgrade. If that wasn't done, people would still run Windows Vista or worse. Or you had to keep RedHat 5 alive to keep things working. So that is really a non argument. Most of those with php 5.6 are the happy few afraid to loose customers and keep ancient and unsafe stuff running to keep their customers happy.
Taking 7.4 into calculation, then 7.4 and 7.4 is 68.3% of the market. With the whole 7 range (where 7.0 is also EOL for example) it's even more.
Statiscs are nice, but safety is more important. And EOL versions are totally not important, so it's already fine if 5 versions are supported, because normally you won't have any more versions needed.
Probably you are one of the exceptions, so that is where DA is talking about, some exceptions wich can pay extra for the pro pack. Or pay extra and go over to CPanel, because Plesk also only supports max. 5 versions as far as I've seen.

So there is no reason to push something like that up to all of us, because most won't like to pay extra for something like that, which is mostly not usefull and at least insecure to use.
5 PHP versions should be enough. You could keep 7.0 amongst these 5 for that one customer, but hey... it's a business, also in Windows you can't use some old programmed stuff anymore in many cases. Life goes on, development too. Businesses know that, that's part of business costs. Maybe the hairdresse should have another one create a new site with wordpress.

We tried not once our clients persuade to change PHP currently supported versions.

Then you created you issue yourself, don't push of your mistakes to the panel.

and we can't force them to update theirs stack - it's theirs application,

Same statement.
This is plain nonsense. Just that's were (delivery) agreements are for. We have in our agreements stated, that the customers is not to compromise the server in any way, also meaning that thay have to use up to date versions of software and applications when needed.
So when we left php 5.6, we warned the customers 6 months up front, they could update their wordpress. Running old wordpress is also unsafe. And then we upgraded php.
By not forcing users to upgrade their stuff, you guys help keeping things like compromised servers, spamming via leak scripts etc. in place.
Sorry that I say it like this, but this is really what I think.
And if you think the customer is more important, oke that is your right do to so, but then don't go expecting panels to keep EOL and unsafe things supported, that is very unrealistic.

Oh yes, I don't know who brought this up, but this all has totally nothing to do with GPDR.

 

[warg]

Oh yes, I don't know who brought this up, but this all has totally nothing to do with GPDR.

It was me . Indirect it does: According to my information and to what German authorities expect, this discussion/problem is considered under article 32 and 25 of the GDPR. Furthermore it would be hard to fulfill the documentation requirements of GDPR if you run a software without any support as you usually have to get in touch with your software vendor for very specific implementation/documentation questions regarding this. Of course this understanding might differ between the different authorities of the members of the EU but at least it's not a minority opinion but also shared by other EU countries.

 

[Richard G]

this discussion/problem is considered under article 32 and 25 of the GDPR.

I'm from the Netherlands and I don't think we differ that much in rules. GPDR is for all of Europe. I see what you mean now. The protection of data mainly, which is our responsibility and indeed is part of the GPDR.
This indeed also creates an obligation for us European hosters to not keep running unsupported EOL versions of applications. However, this also obliges us to prevent customers to keep running them, as otherwise we ourselves can't keep complied with GPDR rules (sorry for my bad English).

However, the GPDR does not apply for non-European or UK company's, as they are not part of the EU. Unless they have European customers on their servers, not sure how it works in that case.

 

[warg]

Oh well, I'm no native speaker as well and my English ain't great for sure so it's easy to misunderstand me!

Regarding your last sentence: In case you try to attract customers in EU, e. g. by providing a offer page in Dutch or German although your company is non-EU based, or in case you have customers from EU, you have to obey to the GDPR. So yep, even a company from e. g. Singapore has to keep GDPR in mind if it deals with EU customers or wants to have them as customer in future. I think it even applies to you if you only process data of EU-based customers abroad in favor/in liability of a different company, e. g. because you provide/sell some analytic service but that's still an ongoing discussion.