-
Notifications
You must be signed in to change notification settings - Fork 416
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PHP 8.1 compatibility - Deprecation notice #499
Comments
It seems to me that |
So far, I've seen it occurring on a development server and on localhost. On other sites, it doesn't happen. However, a safeguard should be easy to implement. |
In general, implementing a workaround without understanding what caused the problem can lead to more bugs in the future. As far as I know, |
I don't have an update URL without a path. The URL and the path are always the same in all cases. Anyway, not a big deal, I will see what's the difference between the sites that work and the one that raises the notice. |
In that case, it seems that If you can find a code sample that reliably triggers this notice, that would be useful. |
Actually, the issue is simple to reproduce:
Possible fixes
I think the first option would be the least "invasive", so to speak. |
That is all true, and I'll add a string cast for unusual situations like that. However, that only applies if you're using a metadata URL that does not have a path or a trailing slash after the domain name. If your URL does include a path, and you're still getting that deprecation notice, that means there must be something else going on. Fixing the problem for URLs that don't have a path may or may not do anything to solve whatever the root cause is in your case. |
That's precisely what I'm checking now. So far, the two sites where the issue occurs have the URL without the trailing slash. I'm checking the other ones, to see if, by any chance, they have the slash. That could be the simplest explanation to why the notice appears only in some cases. |
In the (unlikely) case where the update metadata URL does not include a path, the getVcsService() method could previously trigger a deprecation notice like "preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated". This is because parse_url() returns NULL when the specified component is not present. Fixed by always casting the $path to string. The VCS detection code doesn't care about the difference between "empty path" and "no path" - it should correctly return NULL (= no VCS host found) anyway. Also, let's cast $host to a string as well to avoid another potential notice if the URL somehow has a path but no domain name. Initially reported in #499.
There seems to be a minor glitch when using this library and PHP 8.1. On that version, the following deprecation appears:
Deprecated: preg_match(): Passing null to parameter #2 ($subject) of type string is deprecated in path/to/yahnis-elsts/plugin-update-checker\Puc\v4p13\Factory.php on line 268
Which refers to the following:
If
$path
isnull
, the deprecation notice appears. I reckon that typecasting the path to a string, as in$path = (string)parse_url($metadataUrl, PHP_URL_PATH);
could be sufficient to remove the deprecation notice.The text was updated successfully, but these errors were encountered: