PHP 8.1 - PHP Deprecated: strpos(): /wp-includes/functions.php on line 7053 PHP Deprecated: str_replace(): /wp-includes/functions.php on line 2165

[collieit]

After Upgrading from 7.4 to PHP 8.1 I got the Deprecated Warning for strpos() and str_replace(). After I looked in the code I found out that no check will made if Path is really a Path/string. For example WooCommerce and Blog2social call this methods with incorrect parameters and produced some errors.
I suggest that to add a check on the path (/wp-includes/functions.php on line 2165) like

<?php
function wp_normalize_path( $path ) {
        $wrapper = '';
        if((isset($path) && is_string($path) && strlen($path) >0)){
                
                if ( wp_is_stream( $path ) ) {
                        list( $wrapper, $path ) = explode( '://', $path, 2 );

                        $wrapper .= '://';
                }

                // Standardize all paths to use '/'.
                $path = str_replace( '\\', '/', $path );

                // Replace multiple slashes down to a singular, allowing for network shares having two slashes.
                $path = preg_replace( '|(?<=.)/+|', '/', $path );

                // Windows paths should uppercase the drive letter.
                if ( ':' === substr( $path, 1, 1 ) ) {
                        $path = ucfirst( $path );
                }
        }else{
                $path ="";
        }

        return $wrapper . $path;
}

or for the strpos (/wp-includes/functions.php on line 7053 ) a return false like so

<?php
function wp_is_stream( $path ) {
        if(!(isset($path) && is_string($path) && strlen($path) >0)){
                return false;
        }
        $scheme_separator = strpos( $path, '://' );

        if ( false === $scheme_separator ) {
                // $path isn't a stream.
                return false;
        }

        $stream = substr( $path, 0, $scheme_separator );

        return in_array( $stream, stream_get_wrappers(), true );
}

to use.

[jrf]

@collieit Thank you for reporting this. I presume you are talking about "passing null to non-nullable" notices ?

While I appreciate your suggestion for adding more defensive coding, these issues should really be fixed in the plugins making the incorrect function call, which passes the null, while the WP functions, as documented, expect a non-null value.

If more defensive coding would be added in the WP Core functions, it should be accompanied by a _doing_it_wrong(), which means we'd be effectively replacing an informative deprecation notice, with another notice, where the second notice has a higher error level.

Please make sure you are using the latest versions of the involved plugins and if the notices are still there, please report them to the plugin authors.

[hellofromTonya]

Hello @collieit,

Welcome to Core's Trac!

I agree with @jrf that the issue needs to fixed in the theme or plugin(s) that are causing it. #58728 identified Blog2Social is one of the plugins that has the incompatibility. Please reach out to the plugin authors to report the issue.

Also noting, there will be an architectural discussion for input (parameter / property) validation across all of Core's source code. As strict types and type declarations are likely not possible in Core, a Core specific structured approach is needed for handling situations as you've noted where for example a string is expected and required, but a null is given.

For now, the native PHP notices are alerting to the issue, albeit it takes more digging to find the root cause.