Are you still using PHP 5.x? Why?

So, if you're still in the 45.2% of XF2 customers (there's potentially many more still using XF1...) who are using PHP 5.x, why is that? Do you run other software that isn't yet PHP 7.x compatible? Does your host not provide the option to upgrade? Do you manage the server yourself, and you're unsure how to perform the upgrade yourself? Have you just not got time? Some other reason?
Possible reasons are either
  1. Other PHP scripts non-xenforo requiring lower PHP versions
  2. XF addons not supporting PHP 7.x
  3. Restricted by hosting environment choices i.e. shared hosting and not having full control over what is used
  4. Pure fear of upgrades breaking stuff and not knowing what to do - easy solution for that though is never do upgrades on live servers but instead setup a cloned copy of your site on a separate test server and test upgrades there first
Running multiple PHP versions on same server is nice only when all PHP versions are getting security updates at least. Once security updates are EOL then it becomes a risk running multiple PHP versions on same server. If you need to run a PHP version that isn't getting any security updates any more i.e. PHP 5.4/5.5 then probably best to split that off to it's own separate server from your other PHP apps. So you have one server running PHP 7.x and one PHP 5.6 and maybe one PHP 5.5 and below.

For folks reading this, PHP 7.x is much better performing so you should update if you can. Here's some quick comparison benchmarks I did for PHP 7.2 vs 7.1 vs 7.0 vs 5.6 for both Centmin Mod LEMP stack built PHP-FPM vs 3rd party Remi YUM repo PHP-FPM on CentOS 7 64bit https://community.centminmod.com/th...7-0-26-vs-5-6-32-benchmarks.13590/#post-57618
 
My initial install was on 5.4 due to the other software I was running. Since the install two month ago I have upgraded (spent a fortune) and now running version 7.1 on both sets of software. The difference is incredible in terms of speed.
 
I have been running php 5.6 purely because that seemed to be a stable option when I set up my server (CentOS 7 so I had to use the remi repo to upgrade). At the time there seemed to be the occasional bug reported here by folks using php 7 and, as XenForo only required php 5.3 then I thought that was fine.

Now that @Chris D has mentioned a new feature of XF 2.1 requiring php 7, I have now upgraded to php 7.2. All I need now is for add-on authors of a few add-ons I use to update these (Xen Notices and Xen Pushover being two, hint hint ;) ) and I'll then upgrade my XF 1.5.x site to XF2. :)
 
Like a few people have said, I reckon a lot of sites probably haven't bothered to upgrade because there's been no real incentive to, and if it ain't broke don't mess with it.

However if it was actively encouraged and advocated by XF in the form of some kind of ACP notice linking off to a page explaining the benefits of upgrading and how they could do it (even if it's just means instructing them to get in touch with their host), then I'm sure a lot of admins would be willing to do what needs to be done to make the upgrade.

Especially if the page highlighted any speed and security security benefits, as well as the potential of a speedier rollout of new and better XF features as a result if more admins make the jump.
 
Quite a few wordpress plugins have status pages that show the admin server info and informs them if anything is in a warning or misconfigured state so they know what needs to be enabled/configured for optimal performance. You could do something like that.

You could have a warning on any servers with below optimal settings, linking off to info about how the user can update their server to the best settings.

This is from WooCommerce:

1526671436648.webp


This is from the Avada WP theme. You can see the one setting in red that they recommend I change, linking off to instructions on how to alter it:

1526671544269.webp

1526671489162.webp
 
At the time I think I increased it to cater to large video and other file uploads as I was having issues with them timing out.
 
Last edited:
I'm on Php 5.6 (nginx+php-fpm).

Why? Because I can use only one version of PHP on the VPS (Virtualmin+Nginx can't have multiple PHP version right now) and I have 1 website that is not compatible with php7... but it's a matter of time because I'm updating it.
 
Possible reasons are either
  1. Other PHP scripts non-xenforo requiring lower PHP versions
  2. XF addons not supporting PHP 7.x
  3. Restricted by hosting environment choices i.e. shared hosting and not having full control over what is used
  4. Pure fear of upgrades breaking stuff and not knowing what to do - easy solution for that though is never do upgrades on live servers but instead setup a cloned copy of your site on a separate test server and test upgrades there first
I would like to add:

5. requiring your old vbulletin/IPB/etc site to be accessible because the XF scripts do not import all needed data or XF has erased the imported data. For example: user account history, moderator log, IP data. Some of that data can be vital. For example when it comes to account upgrades done in the old system. Or to check promotions/demotions in the old system. IP data & account data can be important to let long lost members into their account. I use my old vb install very frequently.

That being said, I run PHP7 on any site I can.
 
Or to check promotions/demotions in the old system. IP data & account data can be important to let long lost members into their account. I use my old vb install very frequently.
If it's just direct access to vB database data, that can be done by pure SSH command like running queries directly against the vB database bypassing any PHP code/versions and would actually be faster.
 
Literally because of MSSQL support, which was a pain in the ass in the first place, and has been more of a pain in the ass when dealing with Apache, PHP7 and Linux <-> Windows communication.
 
If it's just direct access to vB database data, that can be done by pure SSH command like running queries directly against the vB database bypassing any PHP code/versions and would actually be faster.
Mostly its a matter of going to a vbulletin user account, checking the overview of related data and then taking action on the XF account.
I know vb like the back of my hand and know how to find the data. While I do use SSH for various things and am comfortable with light database work, I would not know how to generate useful overviews of the needed data through SSH db queries. I would probably end up with lists of unix time stamps.
 
Mostly its a matter of going to a vbulletin user account, checking the overview of related data and then taking action on the XF account.
I know vb like the back of my hand and know how to find the data. While I do use SSH for various things and am comfortable with light database work, I would not know how to generate useful overviews of the needed data through SSH db queries. I would probably end up with lists of unix time stamps.
If you're not familiar with sql queries you can build them off navigated/gui phpmyadmin searches which show the sql query that was used when using phpmyadmin gui - just remove all the back ticks `` for SSH command line usage.
 
Right now we're on PHP 7.1 (because vB4 didn't support PHP 7.2, we just migrated to XF2). Will update to PHP 7.2 in a couple of weeks. :cool:
 
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.2 :rolleyes: I think it's the right thing to do to block PHP 5.6 in this instance rather than blocking PHP 7.2.
Just a bit of warning; this feature may end up actually requiring PHP 7.1 afterall so please consider 7.1 or ideally 7.2 if you’re thinking of preparing for 2.1.
 
Top Bottom