It pointless using strval on something that has a type of string. Adding the string type to utf8_strlen just moves and type errors from mb_strlen to utf8_strlen.

I suspect you were meaning to do something like.

function utf8_strlen($string) {
	return mb_strlen((string)$string);
}

It pointless using strval on something that has a type of string. Adding the string type to utf8_strlen just moves and type errors from mb_strlen to utf8_strlen.

I suspect you were meaning to do something like.

function utf8_strlen($string) {
	return mb_strlen((string)$string);
}

You shouldn't even call utf8_strlen with a non-string argument in the first place, the calling functions have to make sure it's a string.

The problem behind this is, some controllers (like login, register, forgotten, voucher, etc. >> see my PRs from yesterday) are not checking some values currently.
E.g. see #15063

And some are calling (and checking) the value length with utf8_strlen(..)

Due massive attacks on many of clients shops, bots try to register, ligon etc. without any value (empty).
Therefore utf8_strlen reports an error than!

This PR should minimize (eleminate) that errors/warning which are filling the error.log full.
Just a "fallback" if I fogot any controller ..

Right now not tested with OC 4.1.x version, but guess there will be the same "bug".

You shouldn't even call utf8_strlen with a non-string argument in the first place, the calling functions have to make sure it's a string.

Correct, but they do NOT - therefore my other PRs

@osworx : Your pull requests for a stricter validation of submitted form fields are now merged into the 3.0.x.x branch. This should reduce the amount of unnecessary entries in the OpenCart error.log. This is not however a full protection against spambots for which there are other plugins, from captchas to 3rd party extensions such as our SpamBot Buster.

This is not however a full protection against spambots for which there are other plugins, from captchas to 3rd party extensions such as our SpamBot Buster.

I know, there are some extensions (include HoneyPot from me) which can prevent such stupid and useless bots for 100%
While captchas will not prevent all bots .. those kiddies creating that crap are learning to solve captchas better and better.

This PR should minimize (eleminate) that errors/warning which are filling the error.log full. Just a "fallback" if I fogot any controller ..

@osworx As I have already commented. They change won't do that. It will just convert errors such as "Deprecated: mb_strlen(): Passing null to parameter #1 ($string) of type string is deprecated" into "Fatal error: Uncaught TypeError: utf8_strlen(): Argument #1 ($string) must be of type string, null given"

In fact the Fatal is even worse as execution will stop. You can test this yourself with the following code.

<?php 
function utf8_strlen($string) {
	return mb_strlen($string);
}

function utf8_strlen_new(string $string) {
	return mb_strlen(strval($string));
}

$input = [];

echo utf8_strlen($input['none']);
echo utf8_strlen_new($input['none']);

See how the original just throws a Deprecated message, but the new version causes a fatal error.