Deprecation warnings for resulting from a call to plugin_dir_url

[geistesblitzer]

The function plugin_dir_url( $file ) calls plugins_url with an empty string as the $path parameter. This in turn leads to two PHP 8.1 deprecation warnings:

Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in <path>/wp-includes/functions.php on line 2187

Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in <path>/wp-includes/functions.php on line 7241

Both warnings can, e.g., be seen when using the ACF Pro plugin and making a call to get_field(). While these warnings result from a function call from the plugin, the problem lies within WordPress core, as these core functions cannot be used without producing deprecation warnings.

[hellofromTonya]

Reproduction Report

This report validates if the issue can be reproduced.

Environment

• OS: macOS 14.1.1
• Web Server: Nginx
• PHP: 8.2.10
• WordPress: 6.4.1
• Theme: Twenty Twenty-Four
• Active Plugins: None
• Must-use: ​Install this file into `wp-content/mu-plugins/`, as it'll output different combinations to test empty strings and null.

Actual Results

• ✅ Passing __FILE__ to plugin_dir_url() returns http://wpdev.local/wp-content/mu-plugins/ with no deprecation raised.
• ✅ Passing an empty string to plugin_dir_url() returns http://wpdev.local/wp-content/mu-plugins/ with no deprecation raised.
• ✅ Passing 2 empty strings to plugins_url() returns http://wpdev.local/wp-content/mu-plugins/ with no deprecation raised.
• ✅ Passing an empty string to wp_normalize_path() returns an empty string with no deprecation raised.

• ❌ Passingnull to plugin_dir_url() returns http://wpdev.local/wp-content/mu-plugins/ but also raises both deprecation notices:

Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in ../wp-includes/functions.php on line 7241

Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in ..c/wp-includes/functions.php on line 2187

• ❌ Passingnull to wp_normalize_path() returns an empty string and also both deprecation notices:

Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in ../wp-includes/functions.php on line 7241

Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in ..c/wp-includes/functions.php on line 2187

Additional Notes

Cannot reproduce the reported issue when passing empty strings. Though null does raise the deprecations, both functions require a string and are not nullable.

[hellofromTonya]

Hello @geistesblitzer,

Welcome to WordPress Core's Trac :) Thanks for the report.

The function plugin_dir_url( $file ) calls plugins_url with an empty string as the $path parameter.

To test what happens when passing an empty string to the $path, I set up a ​must-use plugin that invokes the functions in question. Results:

• Passing an empty string does not raise the deprecations.
• Passing null does raise both deprecations.

Something is passing null when it should be passing a string. The functions do require a string for the $path, i.e. null is not valid input for these functions.

Looking more closely at the deprecations, both are indicating that null was passed instead of a string:

Deprecated: strpos(): Passing null to parameter #1 ($haystack) of type string is deprecated in <path>/wp-includes/functions.php on line 7241

Indicates the value passed $path when wp_is_stream() is invoked is null.

Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in <path>/wp-includes/functions.php on line 2187

Indicates the value passed to $path when invoking wp_normalize_path() is also null.

Likely a plugin, theme, and/or must-use script is invoking wp_normalize_path() or a function that invokes it and passing a null rather than with a string.

ACF Pro plugin and making a call to get_field()

You identify the deprecation gets raised when ACF's get_field() is invoked. Next step would be to reach out to ACF on their support forum ​https://wordpress.org/support/plugin/advanced-custom-fields/.

Other ways to troubleshoot:

• Do a full backtrace to determine the call stack.
• Use tracking tools such as Xdebug to step through the code to find what could be passing null to one of these functions.

I'll close this ticket as the issue appears to be code outside of Core that passing null instead of string. If after further investigation the root cause appears to be within Core itself, please reopen this ticket and provide the information gathered to help contributors continue their investigation. Thank you :)

[charlestonsw]

User Story
Determining the fully qualified URL of a must-use plugin main loader file is necessary to build future links within the app.

Use Case
After plugins have been loaded set the URL:

mu-plugins/pluginname/pluginname.php

defined( 'SLPLUS_FILE' )

define( 'SLPLUS_FILE', FILE ); set the file to full path of running code

mu-plugins/pluginsname/include/otherclass.php

defined( 'SLPLUS_PLUGINURL' )

define( 'SLPLUS_PLUGINURL', plugins_url( , SLPLUS_FILE ) );

Result with PHP 8.2.3 - PHP deprecated warning "null passed".

Call Stack

plugins_url( , <fully_qualified_filename> )
wp_normalize_path( )
wp_is_stream( )

Possible Resolutions

A) Remove optional status on first param of plugins_url()

plugins_url() has the first optional parameter set to a default of . This will fail with the above warning if no parameters are passed.

Make first param required. Not desired, will break backwards compatibility.

Make first param required only if second param is present. Not desired, will break backwards compatibility.

Fire "doing it wrong" if second param is set but not first param.

B) wp_normalize_path() modify processing if incoming path is

Skip wp_is_stream() test if path is :

if ( ($path !== ) && wp_is_stream( $path ) ) {

list( $wrapper, $path ) = explode( ':', $path, 2 );

$wrapper .= ':';

}

C) wp_is_stream() short circuit if path is empty string

At start of wp_is_stream add:
if ( $path === ) { return false; }

or is_null($path) or empty($path) -- the above matches the specificity if the real world situation.

[charlestonsw]

-revised from original report - problem is not the plugins_url(...') first parm. My IDE (phpStorm) had an issue with rendering content from a second tab (AJAX heartbeat) in the first tab debugging session for plugins_url()

The problem was not stemming from plugins_url() calls but from a separate process that was calling the submenu page routine with null as a first param from another plugin. A common practice that appeared in many dev guides on other sites, but passing null to a string should not happen.

Issue is in the other plugin not WP Core and the plugins_url() stack reported here.