All of this has to be change to the current code but I think it's not a blocker. It's only produces deprecation messages? and of course no error detection.

All of this has to be change to the current code but I think it's not a blocker. It's only produces deprecation messages? and of course no error detection.

No, it produces no messages at all and no error detection which in my book maks it a blocker

When need, we can capture the errors with set_error_handler https://www.php.net/manual/en/function.set-error-handler.php

But I do not see where that capture actualy happen in LanguageHelper::parseIniFile.
To me it doing nothing, just reset $php_errormsg which is deprecated also.

I suspect, no one will notice when we remove that :)

In SocketTransport it just do something like echo errormsg, wich can be done with trigger_error https://www.php.net/manual/en/function.trigger-error.
Idealy it should be an exception, but need to look how whole SocketTransport works.

Ah there already an exception

Not a blocker.

As far as I see it, then we do all the track_error handeling because we want to catch the error message in $php_errormsg. But $php_errormsg is deprecated with 7.2.0 and "Relying on this feature is highly discouraged". " track_errors" has been removed with 8.0. I would remove all this entirely.

Regarding LanguageHelper and parse_ini_file:

We can suppress the E_WARNING and use recommended error_get_last():

@parse_ini_string('ERROR_CODE=1"');
var_dump(error_get_last());

Regarding SocketTransport and fsockopen:

We can suppress the E_WARNING and rely on $error_message or error_get_last() as well, test this:

@fsockopen('invalid-domain', 80, $error_code, $error_message);
var_dump($error_message);
var_dump(error_get_last());

Can create PR if required.

we should never (if possible) use @ to suppress warnings. If you can create a PR which replace all this $php_errormsg with the correct new code it would be really help full (throwing exception would make sense), btw. we already have an issue or pr where we talked about this. I think it's part of the File and Folder refactoring done by @Hackwar but can't remember the number

Found these issues and pull requests #25789 #17856 #33185

@HLeithner Please advise should it be a 5.0-dev PR? or 4.3-dev PR?

@ suppressing can be avoided via set_error_handler(), example:

set_error_handler(static function($errno, $errstr) {
    throw new Exception($errstr);
}, \E_WARNING);

try {
    fsockopen('invalid-domain', 80);
} catch(Exception $e) {
    var_dump($e->getMessage());
} finally {
    restore_error_handler();
}

Joomla 5.0 is fine, we can back port when 4.4 RMs have time for it.

@HLeithner @brianteeman Please check #41908

Closing as having a pull request. Please test #41908 . Thanks in advance.