zlacker

Is it really that bad to use older version of PHP for longer?

The plugin/theme developers usually develop with older versions of PHP in mind, lot's of plugins still work even with 5.x versions...

For my WP sites I just stick with "two major versions behind" workflow and I don't encounter many problems.

Am I doing it wrong?

>>debesy+(OP)
You are doing it right.

7.4 just ended its security support so you might argue that you should be at least on 8.0 just in case a bug is found and not backported.

Truth is: it's not likely.

But in any case theres no need whatsoever to use the latest version and even less when you are using WordPress which is notoriously bad at keeping up with PHP releases.

>>debesy+(OP)
It depends on your philosophy and your server setup. While my agency/host is proactive, most of my clients were running 7.4 up until a few months ago. 8.o was released two years ago, so you could argue we were/are already employing this strategy.

Eventually you have to upgrade. Do you want to go from 5.6 to 8.2 and possibly have to start over? Or do you want to go version by version, paying smaller amounts more frequently to stay current?

Also: WordPress + Themes + Plugins works best when you don't delay maintenance/upgrades. Everything needs to work in concert. You might be able to freeze your theme in time, but your plugins and the WP core will march on.

>>adlpz+P
When I tried updating my network of 200+ WordPress websites to 8.0, more than 40 websites broke directly. It's a bit better on 8.1 but in no way is WordPress ready for 8.x at this point.

PHP 8 is in "beta support" currently, but that's just Core. A lot of plugin developers are lightyears behind it seems:

https://make.wordpress.org/core/handbook/references/php-comp...

>>radioj+R3
> It's a bit better on 8.1 but in no way is WordPress ready for 8.x at this point.

WP Core is absolutely compatible. Its the themes, plugins and custom code (usually in functions.php) that isn't.

>>debesy+(OP)
The biggest issue is generally server support. Finding servers that support older versions or even package managers that still have the older unsupported versions can be miserable. Thankfully the Sury packages are still around as an alternative, but that's only valid if you're running a system you have full control over (ie a VPS).

A lot of cPanel or similar hosts are also retiring old versions as they hit EOL [1][2][3][4][5] (those all support 7.4 still but most have indicated that will be dropped next year as well). This has made hosting transfers more and more difficult if you don't want to go through the process of upgrading.

The process of upgrading Wordpress sites isn't so bad (generally there's no work, honestly). But not all CMSs are that simple and it can get more laborious when you want to upgrade a Laravel or Symfony site, especially if you've skipped a few versions.

Of course, at the end of the day, it's up to the client to provide budget for these things and if they don't/can't, you just have to push back on their other requests until they do.

1: https://in.godaddy.com/help/retiring-old-php-versions-41164 2: https://www.bluehost.com/hosting/help/php-version-selection-... 3: https://help.dreamhost.com/hc/en-us/articles/215082337-What-... 4: https://wpengine.com/support/php-guide/ 5: https://getflywheel.com/wordpress-support/php-on-flywheel/#p...

>>debesy+(OP)
In general yes, because of security support.

Moving from 7.4 -> 8.2 will be just as much refactoring as moving from 7.4->8.0->8.1->8.2. Security support is in general three years [0] so everything 7.X is now unsupported. Considering the security cadence you can skip one version, but if you skip two you'll probably be out of security support before you migrate to a new version. My philosophy is if you're going to need to do the work to upgrade anyway, you might as well do smaller chunks more frequently and be able to take advantage of the language goodies that come out earlier.

The amount of the language that gets deprecated every year is PHP's fundamental flaw, at least in the last five years.

[0] https://www.php.net/supported-versions.php

>>htag+dd
But you don't really need to care about upstream security support. Linux distros offer long-term support for specific versions they decided to freeze on, and there are well-known third-party repositories (sury, remi, cloudlinux) that offer even older versions with backported security fixes.

GP's problem seems to be that they have to support WordPress plugins and themes that they either can't or don't want to patch by themselves. This is a different situation from people who build & maintain in-house apps. In that case, always using the previous Ubuntu LTS is a perfectly viable solution. Stay 2-3 years behind the edge, giving enough time for the plugins and themes to get updated, while still receiving security patches and comfortably within the recommended range for WordPress Core.

>>debesy+(OP)
The person who says yes is wrong. 2 versions behind would still be able to get security updates so would be perfectly ok for production. 7.4 just went EOL with no security updates. This means 8.0, 8.1, and 8.2 are all receving security updates. 2 behind means you would be on 8.0 and ok.

>>debesy+(OP)
PHP 8.x vs 5.x is an order of magnitude performance increase [0] as long as you enable jit and opcache in php8 [1]

[0]https://www.cloudways.com/blog/wordpress-performance-on-php-...

[1] https://stitcher.io/blog/php-8-jit-setup

>>josefr+D6
I actually said that! A base install runs fine on 8.1, but plugin developers are lightyears behind it seems.

> but that's just Core. A lot of plugin developers are lightyears behind it seems.