Brad Padgett
Well-known member
CPanel is also not default CentOs.![]()
I was just mentioning that's what I use. There's a major performance improvement from PHP 5.4 to PHP 7 or 7.2
It's worth the upgrade.
CPanel is also not default CentOs.![]()
I'd expect that too, but it would be only expectation. As long as you guys don't force the devs to use 7.x or higher, the safe way is "don't touch a running system".We'd expect developers to test and ensure compatibility of their own code to support the same versions.
Kinda ironic, isn't it? Uncomfortable using a custom repo (of which there are some which are just the de-facto standard and have the highest reputations) but perfectly comfortable using extremely outdated and potentially insecure software (though I appreciate most default repos are likely tested for security and stability).Default CentOS 7.5 (brand-new) is still on PHP 5.4. Some people won't be comfortable to upgrade using a custom repo.
There's an easy way to be sure. Clone your live site and run it locally or on a test server running PHP 7. Of course right now you're open to the opposite of the problem too. It's not uncommon for devs to sometimes get carried away and add code that is only supported by newer PHP versions, unintentionally.I'd expect that too, but it would be only expectation. As long as you guys don't force the devs to use 7.x or higher, the safe way is "don't touch a running system".
And from what I have seen in this thread, there were problems with a lot of addons but it seems the problems disappeared in most cases, but still not sure if it is safe enough.
Well , yes and no.Kinda ironic, isn't it?
For CentOS I'd highly recommend centminmod by @eva2000 anyway.
I quite like that idea though we do already display a warning in 2.0 when upgrading which reflects the new upcoming minimum. I suspect we should change it in 2.1 to do the same for any version below 7.0 though it's not a done deal that we'd be requiring a specific 7.x version, yet, it really depends how much the adoption improves:You might want to consider giving people a bright red warning on the top of their ACP that they're not running php7 or higher yet, and that you are about to drop support for it in the future. Give 'em some information on what that fuss is all about, how they might be able to upgrade, and why they should upgrade, and make disabling the notification hard by only allowing that through the config.php file, and people will start becoming active.
Your server is running an outdated and unsupported version of PHP ({version}). If possible, you should upgrade to PHP 5.6 or newer (we recommend PHP 7.2) to benefit from improved security and performance.
And thus the blanket PHP 5.6 minimum requirement of DBTech addons was born.There's an easy way to be sure. Clone your live site and run it locally or on a test server running PHP 7. Of course right now you're open to the opposite of the problem too. It's not uncommon for devs to sometimes get carried away and add code that is only supported by newer PHP versions, unintentionally.
const
variables. Who knew. Minor pushback the first week, and the occasional unicorn, but largely no problem Currently 5.6 but only because when I tried switching to 7.2 I got a 500 error generated when trying to access the XF install and I haven't tracked down why yet (and, yes, plugins were disabled in config file). I suspect I've got a module or something else installed with the 5.6 build that I missed with the 7.2 build.Are you still using PHP 5.x? Why?
Default CentOS 7.5 (brand-new) is still on PHP 5.4. Some people won't be comfortable to upgrade using a custom repo.
Currently 5.6 but only because when I tried switching to 7.2 I got a 500 error generated when trying to access the XF install and I haven't tracked down why yet (and, yes, plugins were disabled in config file). I suspect I've got a module or something else installed with the 5.6 build that I missed with the 7.2 build.![]()
.... and there's my motivation to figure out what the problem is.As a bit of further encouragement for people to start upgrading their PHP, there's an important new feature coming in XF 2.1 which, unfortunately, requires PHP 7.0 or above. The rest of the software will work on PHP 5.6, but this one feature can only be enabled in options if you're using PHP 7.x.
This is unfortunate and something we attempted to avoid but it was the lesser of two evils. The feature is partly powered by a library which requires PHP 7.0 or above. They have an older version which is compatible with PHP 5.6 but the really frustrating thing is that it wasn't compatible with PHP 7.2I think it's the right thing to do to block PHP 5.6 in this instance rather than blocking PHP 7.2.
There's an easy way to be sure. Clone your live site and run it locally or on a test server running PHP 7. Of course right now you're open to the opposite of the problem too.
It is not the effort part the problem (although it can scarry newbies like me), but more so the question if developer x will support sufficiently when there is a problem with his code. Cause in many cases it is difficult to get reliable support, which meant "don't break a running system".There's a bit of effort required to test if your site is fully PHP 7.0 compatible but the performance improvements alone are well worth it.
To be honest I have not encountered one XF specific case where this happened (other than in the early stages of XF). BUT...It's not uncommon for devs to sometimes get carried away and add code that is only supported by newer PHP versions, unintentionally.
As a bit of further encouragement for people to start upgrading their PHP, there's an important new feature coming in XF 2.1 which, unfortunately, requires PHP 7.0 or above. The rest of the software will work on PHP 5.6, but this one feature can only be enabled in options if you're using PHP 7.x.
By the way, although these benchmarks aren't XF specific, in case you needed actual evidence that PHP 7.x is faster than PHP 5.6 then check this out:
https://community.centminmod.com/th...7-0-26-vs-5-6-32-benchmarks.13590/#post-57672
Credit to @eva2000 of course.
It's a no brainer.
We use essential cookies to make this site work, and optional cookies to enhance your experience.