Allow up to 9 different PHP versions - 1.667
- Thread starter akadi81
- Start date
Imtek
Verified User
Just use CloudLinux?
https://docs.directadmin.com/changelog/version-1.667.html ... yihaa, indeed 
mhsolutions
Verified User
https://docs.directadmin.com/changelog/version-1.667.html ... yihaa, indeed
This is a real turning point of change
I would argue that this is the opposite of a good thing.
What are sane administrators going to do with 9 different PHP versions on a server?
Right now there are 3 PHP versions being supported by PHP.net. Another one (PHP 8.0) went end-of-life not quite a year ago.
Prior to that was PHP 7.4 which went end of life on November 2022, PHP 7.3 end of life December 2021, PHP 7.2 November 2020, PHP 7.1 December 2019, PHP 7.0 January 2019.
If you're using a script that hasn't been updated since PHP 7.4 or earlier, then that script has been abandoned by its developers a long, long time ago. How do you know that script isn't riddled with security holes and bugs? Who's going to patch it? Obviously the script's developer is not going to.
Now... if you want to argue that PHP versions have too short of a lifetime, I'll get behind that argument. But otherwise, I advocate for playing by the rules that PHP has given you. I'm willing to go about a year after a PHP version has reached it's end-of-life, but honestly any PHP developer worth their weight would know of these impending PHP end-of-life dates and if they want their script to continue to be used, would be insuring that the script is updated to work with these in-life versions of PHP.
The thing I hate most about so called "Hardened" end-of-life'd PHP versions is that it provides an environment that says "Have a 5 year old script that you don't want to update? That's fine! Use our hardened PHP and everything will be fine." Except it won't be. Using a hardened PHP does nothing to protect you against the security holes in an abandoned script (plugin/extension/component/theme).
What are sane administrators going to do with 9 different PHP versions on a server?
Right now there are 3 PHP versions being supported by PHP.net. Another one (PHP 8.0) went end-of-life not quite a year ago.
Prior to that was PHP 7.4 which went end of life on November 2022, PHP 7.3 end of life December 2021, PHP 7.2 November 2020, PHP 7.1 December 2019, PHP 7.0 January 2019.
If you're using a script that hasn't been updated since PHP 7.4 or earlier, then that script has been abandoned by its developers a long, long time ago. How do you know that script isn't riddled with security holes and bugs? Who's going to patch it? Obviously the script's developer is not going to.
Now... if you want to argue that PHP versions have too short of a lifetime, I'll get behind that argument. But otherwise, I advocate for playing by the rules that PHP has given you. I'm willing to go about a year after a PHP version has reached it's end-of-life, but honestly any PHP developer worth their weight would know of these impending PHP end-of-life dates and if they want their script to continue to be used, would be insuring that the script is updated to work with these in-life versions of PHP.
The thing I hate most about so called "Hardened" end-of-life'd PHP versions is that it provides an environment that says "Have a 5 year old script that you don't want to update? That's fine! Use our hardened PHP and everything will be fine." Except it won't be. Using a hardened PHP does nothing to protect you against the security holes in an abandoned script (plugin/extension/component/theme).
Richard G
Verified User
I fully agree with you. Too many people want to use old crap for their customers. If they wat to use old EOL stuff then they should at least take care that it's hardened, so pay for it and use Cloudlinux.
We won't need it and won't enable it ofcourse. But I hope DA will be very very clear that they only support to install those EOL php versions and nothing more, also no hardening, so every culprit with EOL php versions in custombuild, is at peoples own risk and responsibility.
A "hardened" PHP really doesn't do a whole lot. It's mostly a marketing scheme to make people feel safer.
There's really not a lot of security threats imposed in the PHP language itself. I won't say it's completely safe, but for the most part PHP 5 and PHP 7 don't really have a lot of avenues for directly exploiting.
It's the scripts that depend on these ancient PHP versions that pose the security risk. It's not so much that PHP 7.4 is insecure. It's the fact that if you are using a script that won't run on PHP 8.0 (even though 8.0 is end-of-life as well) or later then you're either using an outdated version of that script or the developer of the script (plugin/extension/component/theme) has quit developing it. People that develop in PHP are either going to keep their project in-line with current PHP offerings. If they're not, then they have abandoned the project.
This is why if you are paying someone for a script (plugin/extension/component/theme) you want to be sure that that someone is going to be constantly developing the script. And you need to be aware of what you are paying for. Are you paying just for that version of the script? Or are you paying for that script and subsequent updates?
When it comes to server security, spamming, and phishing abuse on your server a lot of these incidents can be traced back to someone exploiting a security flaw in an outdated or abandoned script (plugin/extension/component/theme). So while the ancient version of PHP may not be the root cause of the exploit, the fact that the server administrator allowed the ancient version to be used on their server so that outdated or abandoned script could continue to operate - that's the issue. Only allowing in-life versions of PHP on your server is a great way to root out these outdated/abandoned scripts (plugin/extension/component/theme).
Now... having said all of that, you also bring up a good point - that just because it's available in DirectAdmin doesn't mean everyone has to use it. That is certainly true. But I think making this available sends the signal that it's OK for people to enable these ancient versions of PHP.
.WordPress "requires" PHP 7.4 or higher. That doesn't mean it's recommended.
For the latest version of WordPress, WordPress 6.6 the recommendation is PHP 8.2
make.wordpress.org
I can vouch that WordPress operates just fine on PHP 8.2 (your plugins/extensions/components/themes may not... that's the key).
You can see a full list of this at:
make.wordpress.org
WordPress plays into this a little bit, they don't exactly provide a haven that promotes good security. WordPress will support all of their ancient releases... until they no longer do. When that is, nobody knows. That means that when a new minor release is made for WordPress... they'll release a new version for 6.6, 6.5, 6.4, 6.3, 6.2, 6.1, 6.0, 5.9, 5.8, 5.7, 5.6, 5.5, 5.4, 5.3, and so on.
If you ask WordPress what version they support, they'll tell you they only support the latest release - which as of the time of this writing is WordPress 6.6. Instead of ending the life of an ancient version of WordPress, say WordPress 4.9... they just continue to pump out updates while also stating that they don't support it.
This just further embellishes people and web hosting providers to never update anything. This leads to WordPress site owners refusing to update, and there by using old, outdated, and abandoned plugins/extensions/components/themes. And then web hosting providers placate them by continuing to allow ancient PHP versions to be in use.
WordPress follows the PHP way of releasing things. They'll release 3 new major versions in a calendar year. And rarely do those new major versions contain anything mind blowing new.
I would advocate for everything to slow their release schedule down. Maintain the software that you have instead of trying to add every new bell and whistle. The people that write these softwares often aren't the ones that are actually using it. The PHP developers are oblivious to just how many people are still using PHP 7.4 and PHP 8.0 - they just keep churning out new releases. WordPress developers are oblivious to how many people are using WordPress 6.2 or some such version, they just keep churning out new releases. Take a moment and step back and see that most people really don't want to update their software that often.
You could sort of kind of add DirectAdmin to this list. How much has really changed from DirectAdmin 1.650 to 1.666? Couldn't those changes just be maintenance releases to 1.650?
For the latest version of WordPress, WordPress 6.6 the recommendation is PHP 8.2
WordPress 6.6 Server Compatibility
So, here you have the compatibility information, this time, for WordPress 6.6.
I can vouch that WordPress operates just fine on PHP 8.2 (your plugins/extensions/components/themes may not... that's the key).
You can see a full list of this at:
WordPress Compatibility
The relationship between WordPress, PHP and MySQL / MariaDB is very close, and it is very important that the versions of these technologies match for proper operation. The following matrix is focus…
WordPress plays into this a little bit, they don't exactly provide a haven that promotes good security. WordPress will support all of their ancient releases... until they no longer do. When that is, nobody knows. That means that when a new minor release is made for WordPress... they'll release a new version for 6.6, 6.5, 6.4, 6.3, 6.2, 6.1, 6.0, 5.9, 5.8, 5.7, 5.6, 5.5, 5.4, 5.3, and so on.
If you ask WordPress what version they support, they'll tell you they only support the latest release - which as of the time of this writing is WordPress 6.6. Instead of ending the life of an ancient version of WordPress, say WordPress 4.9... they just continue to pump out updates while also stating that they don't support it.
This just further embellishes people and web hosting providers to never update anything. This leads to WordPress site owners refusing to update, and there by using old, outdated, and abandoned plugins/extensions/components/themes. And then web hosting providers placate them by continuing to allow ancient PHP versions to be in use.
WordPress follows the PHP way of releasing things. They'll release 3 new major versions in a calendar year. And rarely do those new major versions contain anything mind blowing new.
I would advocate for everything to slow their release schedule down. Maintain the software that you have instead of trying to add every new bell and whistle. The people that write these softwares often aren't the ones that are actually using it. The PHP developers are oblivious to just how many people are still using PHP 7.4 and PHP 8.0 - they just keep churning out new releases. WordPress developers are oblivious to how many people are using WordPress 6.2 or some such version, they just keep churning out new releases. Take a moment and step back and see that most people really don't want to update their software that often.
You could sort of kind of add DirectAdmin to this list. How much has really changed from DirectAdmin 1.650 to 1.666? Couldn't those changes just be maintenance releases to 1.650?
And this is what you see in that WordPress Compatibility page you mentioned:
"This table shows the versions available (and security supported) at the time of the WordPress release. It does not mean that WordPress provided 100% full support for those versions (but usually does)."
If you look further here:
make.wordpress.org
you will find that PHP 8.3 support is in beta state, 8.0, 8.1, 8.2 are working with exceptions and PHP 7.4 is last fully supported and recommended version - even in latest WP 6.6.
Of course, it doesn't mean that it Wordpress will not work properly on newer PHP versions but in case of problems it's good to have 7.4 to test.
And with easy access to more than 4 PHP versions it will be possible.
"This table shows the versions available (and security supported) at the time of the WordPress release. It does not mean that WordPress provided 100% full support for those versions (but usually does)."
If you look further here:
PHP Compatibility and WordPress Versions
WordPress aims to support new versions of PHP on the day they are released as much as possible. As a project, the process of supporting these new versions begins after each new PHP version has hit …
Of course, it doesn't mean that it Wordpress will not work properly on newer PHP versions but in case of problems it's good to have 7.4 to test.
And with easy access to more than 4 PHP versions it will be possible.
Last edited:
If WordPress really thinks that PHP 7.4 is a requirement nearly 2 years after PHP 7.4 reached end-of-life, then that's all the more reason for WordPress to die a slow and painful death.
The only projects that should be using PHP 7.4 (or PHP 8.0 for that matter) are enterprise level projects. Where the person that wrote the code running the project is employed by the company using the project.
You're either going to believe me on that statement or you're not. And I learned a long time ago to quit wasting time trying to get people to believe me when they are gung-ho about believing their own statements.
I'll just say that if you're using WordPress (more aptly a plugin or theme) that "requires" PHP 7.4 to operate in August 2024, then I'd ask that you don't go crying to any sane server administrator when the website is hacked, compromised, or exploited for abuse.
The only projects that should be using PHP 7.4 (or PHP 8.0 for that matter) are enterprise level projects. Where the person that wrote the code running the project is employed by the company using the project.
You're either going to believe me on that statement or you're not. And I learned a long time ago to quit wasting time trying to get people to believe me when they are gung-ho about believing their own statements.
I'll just say that if you're using WordPress (more aptly a plugin or theme) that "requires" PHP 7.4 to operate in August 2024, then I'd ask that you don't go crying to any sane server administrator when the website is hacked, compromised, or exploited for abuse.
mhsolutions
Verified User
Wp core can be compatible well, but the problem is not there, it lies in the themes, plugins, ioncube coding.
I sell hosting, there are customers who have been running for a long time.
Right now, many websites are still running php 7.4.
Unfortunately, php has too many versions, 7.4, 8.0, 8.1, 8.2, 8.3 (5 latest versions). Each customer has a different style, each time the theme is different, not everyone uses code compatible with the new php. and not everyone accepts old php.
The addition of these versions is really beneficial for us hosting providers.
I sell hosting, there are customers who have been running for a long time.
Right now, many websites are still running php 7.4.
Unfortunately, php has too many versions, 7.4, 8.0, 8.1, 8.2, 8.3 (5 latest versions). Each customer has a different style, each time the theme is different, not everyone uses code compatible with the new php. and not everyone accepts old php.
The addition of these versions is really beneficial for us hosting providers.
mhsolutions
Verified User
If I used Cloudlinux, I would have no reason to buy a new directadmin with propack. Why do I have to use 2 things with the same features.
I've been waiting for this for a long time, integrating all php versions so I can sell to customers more easily.
You should from a seller's perspective, we need to provide stability for customers, not all customers can upgrade their website regularly (this is something we have no right to intervene in).
LawsHosting
Verified User
As long as you state in your T&C "Use EOL versions at your own risk", you are covered........
I would prefer to drop the clients than having an old rogue script rooting a whole server.....
But that's me.
I would prefer to drop the clients than having an old rogue script rooting a whole server.....
But that's me.
how can? is there a php script rooting a a server?
It's probably less of a root-level compromise and more of a spamming/phishing/getting the server blacklisted issue.
And it's usually not so much the core script (such as WordPress) as it is the plugins/extension/components/themes being used.
A plugin with a security hole that allows an outside malicious user to obtain admin privileges on the WordPress site can then log int, install a File Manager plugin to the WordPress site, and root around throughout the entire account (even read the email that's stored on the web hosting account). And then they can upload a spamming script some where, use the account to do their spamming. Or host a phishing scam website on the account.
Whenever this happens the web hosting account owner ALWAYS comes back with "It wasn't me that did that!" No... it might not have been you that uploaded everything. But by choosing to continue to use an outdated script/plugin/extension/component/theme you aided and abetted in allowing that to happen.
If you want your website to be secure:
1) Use strong passwords.
2) Keep your computer and devices, the ones you log into the website from, free and clean of any malware/viruses/keyloggers.
3) Keep your scripts/plugins/extensions/components/themes up to date.
4) Use reputable scripts/plugins/extensions/components/themes. How do you know if a script/plugin/extension/component/theme is reputable? Well... if it's not being actively maintained, i.e. it requires an end-of-life version of PHP to operate, then it's not reputable. If the WordPress plugin page for the plugin says it was last updated 2 years ago... it's not being actively maintained. I might even argue if it's not been updated in 6 months, it's probably not being maintained. You just have to decide for yourself where that cutoff is for you. The longer it's been since a plugin has been updated the more I question it's reputation.
If you do all of that, it's going to be really difficult for someone to compromise your website.
And again, a "hardened" PHP isn't going to stop any of that from happening.
mhsolutions
Verified User
Of course, in terms of service, customers must bear the consequences. But if the version they are running well, you arbitrarily upgrade php, leading to errors on their website. The person complaining will be you.
Richard G
Verified User
Yes because DA php versions are not hardened and Cloudlinux is not a panel, it's just an addition to panels. So you would still have a reason to buy either CP or DA.
And I don't agree about what you think should be done. Stability is provided by using up to date versions with little risk for the customer. One can step over a line a little bit (so little time EOL) but customers should be protected for themselves too and that should be our job too.
Not only provide them what they want, creating risks not only for the servers but many people on the internet, who are receiving malware and spam by hacked ancient stuff.
Those who can't or won't upgrade, should get a VPS for themselves.
Richard G
Verified User
Which is why I teach my customers to keep up to date and if I arbitrary update my php, they still have 2 other older versions they can change too which will work for some time, and during that time they have the time to prepare their site for the newer php. I don't need to keep 5.6 running for that.
LawsHosting
Verified User
I gave my clients 6 months warning when PHP 5.6 was EOL that I'd be dropping it for 7......
In the days of mod_php (where most things needed chmod 777), there were occurrences where shell scripts were installed in /tmp/ - if they were managed to be run, that's another story.