passing null to Format::explode() and php 8.1 (fix suggestion)

arcanum

Hello,

you're probably already aware of, but since php 8.1 passing null to explode() will result in a warning

Deprecated: explode(): Passing null to parameter #2 ($string) of type string is deprecated in [...]/DataTables/Editor/lib/Editor/Format.php on line 160

I was able to fix the warning by adding ?? '' (single quotes) to the stated line

return explode($char, $val ?? '');

rf1234

Thanks. It still seems to be like this in the Editor code. Just checked my version. I didn't notice it though when I migrated to PHP 8.1 a while ago.

I had to fix this the same way in my own code because I got warnings; or was it even an error?! Don't remember ...

return number_format($val ?? 0, $decimals, ',', '.');

@allan
Are you aware of this?

allan

I wasn't actually aware of that - thanks for flagging it up!

I've committed a fix for the issue and it will be in the next release of Editor

Allan

rf1234

Hi Allan!

The migration from PHP 7.4 to 8.1 was pretty much a nightmare for me. Partly I couldn't update third party software I am using and had to hack it myself to comply with these new PHP rules. Didn't have any problems with Editor and Data Tables though! Probably just luck ...

Roland

rf1234

This on is really ugly. I had to insert this line about 20 times into third party software I am using to avoid those notices. Might be relevant for you as well, Allan.

allan

Probably just luck ...

Haha - it's due to Colin's testing . We missed that one since we don't have anything that passes null in there. Good to hear it have been relatively painless.

Regarding #[\ReturnTypeWillChange] - oh my, that could be a massive headache! I actually don't fully understand it yet, but this SO post helps a bit. Basically, it seems that you either need to specify a return type on a function / method or use that new attribute. But the return type doesn't work prior to PHP 7. Oof! But (...) the PHP 8.1 compatibility notes show an example without a return type. I'm a little confused .

I really don't want to fork our code to support PHP 5.4 (you'd be gobsmacked at how many are still using it - even 5.3 in some cases) and putting attributes in front of every function is just as horrible.

It might force me to go PHP 7+ only and direct old PHP version uses to some old version of our libraries. There is a lot to like in newer PHP (not needing our static ::inst will be nice!) but darn!

Allan

rf1234

It might force me to go PHP 7+ only and direct old PHP version uses to some old version of our libraries. There is a lot to like in newer PHP (not needing our static ::inst will be nice!) but darn!

I am not a big expert on these things but that is probably the consequence of all of this. And Data Tables would not be the only one handling it that way.

Regarding PHP versions: Some of my clients require me to send them my IT documentation. And some of them even read it ...

I still had PHP 7.3 in there - and was promptly challenged that there are no security updates for PHP 7.3 any longer. I was lucky that I had only forgotten to update those docs - otherwise: They wouldn't have signed the contract if I hadn't been on PHP 8+!
https://www.php.net/supported-versions.php

allan

Agreed! it is nuts that people are still using 5.3/4 - but they pay me, so I'll carry supporting it from an Editor point of view. Can't say much about the state of their servers in general though...

Allan