To celebrate the PHP 8.2 release today, @Njames penned an Ode to PHP
https://24daysindecember.net/2022/12/08/an-ode-to-php/
#24DaysInDecember

@panigrc fortunately, it's not that kind of a project. No global variables, composer is there from long, long time ago. But, there are a few usages of "extract()" that are spawning so much crap... 😅

However, due to the sheer size of the project, there are quite a lot of composer dependencies. Some of them will most likely become private forks because they're literally dead for years and just happen to work with 7.2.

@oliver Wow 10 years!

How do you manage to keep it up to date? Probably back then you didn't even use composer and all the files were included. Which is a pain to find all the dependencies.

The worst thing is also using global variables and not knowing wherever they are used.

#beentheredonethat #php #legacy_code

@panigrc rector did help a lot when we were upgrading another service to 7.4. however, with this true monolithic codebase, having bits of code older than 10 years - we're still at the stage when employing anything automatic is quite far.

Any server-side framework that conflates GET parameters and POST body parameters into a single input array/dictionary is fundamentally broken. Don't @ me.

What a mission to migrate a huge project from #PHP 7.2 to 8.1 (or maybe even 8.2 - this is going to take months).

Upgrading from 5.6 had a leftover: suppressing the warning "declaration of X should be compatible with Y" in a custom error handler. At that time it was not an option to delay the upgrade further, and it wasn't an option to fix all those issues myself either.

Now, there are 200+ tickets with 300+ actual issues to fix, and that's only for this single error (it's a fatal error in 8).

Happy that the transition at work from 7.4 to 8.0 (WordPress) and to 8.1 (Drupal) is complete for the 500 ish sites under my purview. Here’s hoping the inevitable jump to 8.2 is an easy one.

Two phrases to avoid in talk proposals (because they're way overused):

- "Join me on a journey..."
- "Let me take you on a whirlwind tour..."

Disappointment Lake, Boundary Waters Canoe Area Wilderness, Minnesota, USA
Ink and alcohol-based marker

#cartography #HandDrawnMap #Maps #Minnesota #bwcaw

@syntaxseed @michael @wizards @phpc there’s a fair chance they need it for their own internal or even user-facing dashboard. I nearly went to work for a hosting company and its own internal tooling was outrageously big. It’s probably easier to support the old language than upgrade their own stuff.

TIL: The registry of the information handled in POSIX locales (LC_ALL et al) is managed by the danish unix usergroup!

Yes! I am having fun preparing a new talk about the technicalities of i18n and l10n!

#usergrouppower

The attack on Pearl Harbor was on this day in 1941:
https://en.wikipedia.org/wiki/Attack_on_Pearl_Harbor

The interesting thing about Mastodon not doing full-text search is searchability is very much opt-in, via hashtags. So if you want to avoid being dogpiled for something controversial, omitting hot-button hashtags will go a long ways toward that goal.

Yet another example of Mastodon and the like giving a lot more moderation ability to individuals, on top of decent abilities at the admin level.

#MastoAdmin

Look at these cool clips I bought at Lee Valley for hanging things on brick without drilling holes. 🤩

Man, humans can solve anything! 😁

Read @ewbarnard@twitter.com’s book to learn how an experienced developer thinks regardless of programming language https://www.phparch.com/books/the-fizz-buzz-fix/

@jrf_nl @wizards

As a twenty year veteran of PHP and a solo dev I understand the arguments, but there's no way I can sell my type of SMEs client on major code rewrites. I have enough trouble justifying obvious new features.

I use PHP because it just gets the job done, and that's also the reason my clients hire me.

Also arguing for a complete rewrite of old code might also imply my clients should review their overall dev set up and I'm not keen on that idea.

@jrf_nl @derickr @Girgias @syntaxseed @wizards @afilina Node has the same as PHP with 36 month for supported versions. Python has 60 months for their versions. Maybe there is some middle ground? We could bump it to 42 months or about 3.5 years. 🐘 Hopefully that would be enough time for Wordpress to get their shit together. Not officially supporting 8.0 yet is a freaking joke. Having to rely on third parties for PHP supported versions beyond EOL is not ideal. ❤️

@syntaxseed @michael @wizards Where I work they had this one particular team who were still maintaining security fixes for some servers that were on 5.3 until at least about last year.

I finished migrating all of my office's stuff off that clown car of a server about two years ago, so I'm no longer on listservs or paying attention ... but it *might* still be running.

@michael @stuherbert @shawnhooper @wizards

It's been unfortunate that #PHP has part of its good & bad reputation based on its stability. For a long time that meant stagnation.

We need to do more to push PHP's other strengths: its flexibility, easy tooling, ubiquity and easy provisioning.

And as severless grows in popularity & server-side rendering makes a comeback, PHP can step up as best-suited here.

@stuherbert @shawnhooper @syntaxseed @wizards

Oh yes, I fully agree. Never intended to imply it's all WP's fault, just that WP is a big part of it, with its wide spread use and slow adoption of PHP8.

To be fair: even if WP core had adopted PHP8 sooner, that would've likely still left a large number of widely used plugins incompatible with PHP8, and a large number of smaller blogs who wouldn't have upgraded either way.

But what you say goes back to a point I tried to make yesterday: I suspect a large part of the reason why PHP is (still) so popular, is because of its stability. Now that we are losing this stability, I wonder what that'll do to its popularity.

Only time will tell.

But I'm not even sure what the alternatives are.