PHP 8.1 - trim(): Passing null to parameter #1 ($string) of type string is deprecated.

[ThatStevensGuy]

Fixed by typecasting get_field() (string)$ret on line 2009, but probably not the ideal fix.

Deprecated: trim(): Passing null to parameter #1 ($string) of type string is deprecated in /Users/user/Sites/mysite/wp-content/plugins/feedwordpress/feedwordpress.php on line 2022

[GwynethLlewelyn]

Well, that obviously works, but it's nicer to check first to see why the error occurs in the first place.

In my experience, in almost all cases such as this one, the problem is not really the string itself, but rather the object that has that string somewhere as one of its class variables. The object has not been properly instantiated (for some reason or other), and the object is NULL — and, obviously, anything inside it is NULL as well.

So, what I do is to check first if the object is NULL or not. If it is, I return earlier with some sort of error message to be sent upstream to whoever has called that method. While this essentially pushes the errors to someplace else, it has several advantages:

If you force a typecast on a NULL, which comes from a "broken" object, and as a consequence some things will not give any errors any longer, then the caller will assume that everything is fine (an empty string is a valid string, after all). However, it might just have thrashed some essential functionality. Imagine that the called object is responsible for saving a new feed somewhere, but there was an error while setting things up, and the object never got properly initialised. Later on, at some point, a different object wants to get the feed URL to update it; it walks through the code as if everything is fine, but it just gets empty strings all over the place; but empty strings (or integers set to zero) are valid strings, so it tries to retrieve the feed from an empty string... also valid... but obviously nothing is returned, of course.

That's ok from the perspective of the caller. Ok, so I asked for the feed URL, I got an empty string, I tried to pull the RSS feed from that, it returned an empty string (what else?). Good, that feed is up to date, moving on to the next one.

No serious harm is done, of course, but the user will never even notice that this feed is broken (or didn't ever work!). It just happily plays around with empty strings, updates the time it last checked the feed, tells the user that all's fine — no new content to display that feed — but... nothing ever gets pulled from that feed.

By contrast, properly checking if all objects and (class) variables are not NULL — throwing an error or returning earlier with the appropriate message — also fixes the issue, but passes an error to the caller, such as "invalid object". Ok, now the caller knows something is wrong with that particular object (and never attempts to fetch anything from its feed again), and it can flag the user with some sort of visual error — e.g. "feed not found" or "feed broken" or something like that. That should catch the user's attention, and probably make them aware that something is seriously wrong with that feed. Even if the real reason may be obscure, it's better to get some feedback on an error than none at all and "pretend" that everything's fine. Printing "Unknown error 0x8badb33f" can be a very cryptic and probably useless for the end user, but it's far better than just "pretending" that no error ever existed and going ahead with the code.

Although I admit that PHP is my 2^nd most loved programming language — at least, before people started to go overboard with its OO functionality — it can lead to very, very sloppy programming. Fortunately, the worst nightmare of debugging PHP code — programmers who insisted to prefix every function giving an error with a @ (a.k.a. "the STFU operator") to make sure nothing would appear on the logs — has been sort-of-deprecated; and PHP 8.X (even 7.X) is good enough to frown upon certain constructs which must contain errors at some point and at least flag them as warnings or even deprecated functionality.

In any case, be wary, o ye PHP programmers of yore, because strict typing has come to PHP, and although not everything is yet supported (such as strictly typed arrays), with every new release, PHP adds a few more places where strict typing can be turned on. Sooner or later — in the interest of both programmers (who need to review code written by third parties) and the just-in-time PHP compiler (the stricter the types, the faster it runs, since less "guesswork" is required), I can assume that strict typing is the way ahead for PHP.

Granted, if they drop $ as the identifier for variables and . for string concatenation, then PHP would essentially be... JavaScript 😮 (or at least an even much closer C-like variant)

If that's good or bad, welllll.... the jury's still out.

But, of course, I digress!