zlacker

> PHP 8.2 is a major update of the PHP language.

Major update, awesome. /s

As someone who manages a network of 250+ WordPress websites - these PHP updates are killing me! As soon as I'm done helping clients upgrade/fix their incompatible themes/plugins and custom code, a new version is out! Even with great tools, the process for about 10% of my network is a nightmare.

While I appreciate the work, it's not very satisfying and for many clients very frustrating to pay for something they know nothing about, just to "keep the lights on".

>>josefr+(OP)
You're doing something wrong. WordPress isn't PHP 8 ready yet. Keep that stuff running on 7.4 and you will have had no problems. Plugins and themes don't move as fast..

Also not a PHP problem but a WordPress problem. It's not a healthy eco-system.

>>josefr+(OP)
Does Wordpress require the latest version of PHP? Is there not an LTS?

>>josefr+(OP)
I hope you charge for it.

That said there are languages where very little backward incompatible changes are made. Java comes to mind.

Also: putting each client in a sandbox (VM, VPS, etc) can help you to keep some clients on the old versions, and/or do PHP interpreter migrations on your own timeline.

>>josefr+(OP)
Older versions of PHP are supported with security fixes for a while. There's no need to upgrade to 8.2 right now, at all.

>>dncorn+r
> It's not a healthy eco-system.

I'd argue that's true for all of PHP. Sure it got better, but compared to other langugaes it is still a mess.

>>josefr+(OP)
Why do you feel compelled to update to every point release?

How do you deal with Nginx/Apache updates given they release more frequently than PHP?

You can always host at a managed hosting provider who will take care of this for you.

>>josefr+(OP)
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?

>>dncorn+r
WP is PHP 8 ready, but plugins aren't. Some hosts are dropping PHP 7.4 support in January, I know it's causing problems for those who haven't done good maintenance deals.

>>hacym+G
Let me put it this way: there are major plugins with millions of installs that do not support PHP 8.0.

I even host a few installs on the latest 7.x version.

I don't understand where this update hysteria comes from. PHP 8.1 security support ends in Nov 2024.

>>cies+V
Please provide arguments to support your claim.

>>cies+V
Disagree, composer exists, namespaces exist, autoloading exists. Enough quality frameworks.

I hope you can give some factual arguments why it's still a mess.

>>debesy+d1
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.

>>Cianti+m1
Also some themes or theme builders aren't compatible too.

>>adlpz+R
The 7 series is 'done' with security updates as of now. https://www.php.net/supported-versions.php

So there's some argument to be made to be in the 8.x series. It's probably not something you should be losing sleep over just yet, but at least have it on your roadmap to address in the coming months.

>>debesy+d1
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+22
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...

>>tiffan+b1
> Why do you feel compelled to update to every point release?

I don't. We just finished upgrades from 7.4 to 8.0. PHP 8 was release November 26, 2020 - two years ago!

> How do you deal with Nginx/Apache updates given they release more frequently than PHP?

My managed host deals with that.

> You can always host at a managed hosting provider who will take care of this for you.

I have a "managed" host and none of them will make your code compatible. It requires a software engineer and lots of unglamorous work.

>>josefr+(OP)
Similar boat for me, I manage a few hundred Drupal sites and I spend a lot of my time on Drupal updates and PHP updates. Just finished the upgrade to PHP 8.1, and now I know the start of my year will be PHP 8.2 and Drupal 10 upgrades.

>>adlpz+p1
Everyone lags behind but the pace in the last 2 years has quickened. Even if you lag (post 5x years), eventually you have to match the cadence.

>>cies+M
> I hope you charge for it.

I do and appreciate the job security but I respect my clients (small biz owners) and it's just not satisfying and for the 10% that have issues, costly.

>>Cianti+m1
> Some hosts are dropping PHP 7.4 support in January

Ding ding ding! This guys WordPresses. Even outside my network which is in decent shape, I have clients scrambling because they've ignored PHP updates for 2+ years. Sometimes burying your head in the sand is not the best strategy.

>>adlpz+R
Sadly, there is, kind of.

Shared webhosters (speaking for Germany) have started to disable support for PHP 7.x as there are no security patches anymore.

That made it necessary to upgrade lots of WordPress pages, especially older ones had some quirks in themes that broke with PHP 8.

I've updated around 25 sites for an old friend (she's more into the design/content part, not the dev part) and made good money with that. "Stupid" work nevertheless, would've preferred to do something better than run a PHP 8 linter and see where it breaks...

>>mobili+l3
Correct. Every decent theme and plugin publishes a handful of updates every year. Locking your WP site "in time" is not a viable option. If that's your strategy, just build a static HTML site.

>>martin+l6
> I've updated around 25 sites for an old friend (she's more into the design/content part, not the dev part) and made good money with that. "Stupid" work nevertheless, would've preferred to do something better than run a PHP 8 linter and see where it breaks

Exactly. It's work for our engineers but not something to get excited about. Plus you need to explain to the client why they're paying $1000 for something called "PHP" which they have no concept of.

>>invali+N5
I feel your pain cousin Drupal!

>>radioj+45
> 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.

>>mgkims+r4
There are nice improvements that make it worth it to upgrade, but yeah, and you can also just use a Linux distribution that provides support for older versions of PHP (such as Debian stable or the Sury packages).

We upgrade our clients in waves, so sites in dev get the latest PHP, which lets up contribute to upstream PHP projects to fix issues, and by the time it's merged upstream, we can update our older clients without any worries.

>>josefr+(OP)
Don’t worry WordPress doesn’t support 8.2

>>cies+M
> Java comes to mind.

Java used to be like that, but the migration to the module system has been very rocky for me personally when revisiting older projects.

>>martin+l6
Using a shared hosting provider is a choice you're making there though. If you know you're going to be managing legacy codebases for a while you're far better off spinning up your own box on cloudlinux, which has PHP security patches going back to the early 5.x releases.

It's unreasonable to expect standard hosting providers to cater to those kinds of needs IMO.

>>josefr+G6
> It's work for our engineers but not something to get excited about.

Totally not, yeah!

My friend also was surprised/shocked that there were changes in the code necessary to keep those old sites up and running.

Next thing was installing and setting up the "OMGF" plugin to cache Google fonts for GDPR compliance. Stupid work, but quite a few billable hours.

I think the WordPress ecosystem really is... "struggling" (lack of a better word) with how the modern web and the world around it evolves.

>>tiffan+b1
> How do you deal with Nginx/Apache updates given they release more frequently than PHP?

Can't speak for Nginx, but Apache updates very rarely screw with syntax, and those are always major releases. And for Apache, "syntax" just means config files.

PHP screws with syntax frequently, and often on point releases. And PHP is a programming language; syntax is the whole point of PHP.

>>cies+V
None of this is on PHP the language. The roadmap is extremely clear for PHP. The problem is the likes of Wordpress having no oversight on their plugin directory. Really they should've stopped accepting new listings / updates for plugins that dont support the latest release.

Wordpress has a lot to answer for here, but given the archaic and frankly idiotic way they operate they'll do nothing of the sort.

PHP is very backwards friendly and with a strong and stable ecosystem built around composer theres no excuses for majorly used (and often very profitable) wordpress plugins lagging so far behind.

>>josefr+G5
> and lots of unglamorous work.

This.

The PHP developers are trying to turn PHP into a decent, fairly modern language. This has involved quite a lot of breaking changes in the last few years, and upgrading website code just so it works with the latest version (i.e. no actual improvements) isn't appealing work.

>>debesy+d1
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...

>>dncorn+M1
I think GP was not talking about PHP ecosystem in general but about Wordpress ecosystem in particular. And I largely support this claim.

>>esskay+E8
Well, yeah, but if you're a two person design agency, which builds WordPress sites on top of $popularTheme in a pair with $Pagebuilder... You don't care that much about controlling your hosting environment...

But I get your point. :-)

>>debesy+d1
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

>>invali+N5
I still have an anxiety response just seeing the word Drupal.

>>josefr+u6
Theme and plugin updates keep rolling in.. I'm only locking the PHP version until all themes and plugins the site uses are compatible with 8.

A hosting provider that forces people to PHP 8 is not a good hosting platform for WordPress.

>>josefr+(OP)
Yeah I wish the focus was more on backwards compatibility at this point. Most PHP codebases are very old.

>>pacifi+k8
How do you mean? The meta ticket (https://core.trac.wordpress.org/ticket/56009#comment:27) is pretty clear that all unit tests are passing, the only issues left being deprecation notices, not errors. Have you tried it and found the core failed somewhere?

>>htag+qe
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.

>>josefr+(OP)
I think we need a LTS (long term support) version of PHP. One of the great things about it was the non-breaking upgrades for so many years. I mean no version of php7 is supported?

https://www.php.net/supported-versions.php

I know the web needs constant maintenance, but I wish it wasn't so much. PHP has been pretty good about not breaking changes, but I've noticed a few..

PHP is my goto. Its pretty great. It enabled a startup I was part of to get off the ground.

>>debesy+d1
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.

>>josefr+46
Don't update php and freeze the files and the database so they can't be hacked.

>>josefr+(OP)
Well, essentially you are getting paid because of that. So if it all went smoothly you'd be out of a job.

>>jacque+nX
This work represented about 1-2% of our revenue this past year. While not insignificant, we'd certainly have plenty of work even if these upgrades went perfectly.

>>acomje+YH
Distributions like Debian maintain their own LTS versions of PHP for many more years than the PHP people themselves, backporting applicable security fixes as necessary.

>>nerdbe+b91
I run a lot of WP sites on Debian for exactly this reason. Every now and then there's a feature that's unavailable though because someone's written something (usually in a plugin) for a bleeding edge version of PHP.

I think official LTS for PHP would still help, if only to drive a few of the larger developers to target those versions to ensure maximum ease of deployment and maintenance.

>>debesy+d1
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

>>lzaaz+FV
Sure, but what stops them from modifying the database?

>>josefr+Q7
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.