Handle null/falsy paths in wp_normalize_path without warnings

[zyphlar]

Without this modification, some plugins like username-updater (Easy Username Updater) may try to do something like call add_submenu_page(null, ...) which can result in an error like this filling up logs:

str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated

It stands to reason that a normalized null/false/empty path is still null/false/empty (or maybe an empty string) and we should just guard whiny functions like str_replace against unexpected input.

Github PR: ​https://github.com/WordPress/WordPress/pull/749

Patch:

diff --git a/wp-includes/functions.php b/wp-includes/functions.php
index 33b775e7182..5ffcaf432e5 100644
--- a/wp-includes/functions.php
+++ b/wp-includes/functions.php
@@ -2177,11 +2177,15 @@ function path_join( $base, $path ) {
  * @since 4.4.0 Ensures upper-case drive letters on Windows systems.
  * @since 4.5.0 Allows for Windows network shares.
  * @since 4.9.7 Allows for PHP file wrappers.
+ * @since latest TODO Allows for null/falsy paths (returns whatever was passed)
  *
  * @param string $path Path to normalize.
  * @return string Normalized path.
  */
 function wp_normalize_path( $path ) {
+        if (!$path) {
+                return $path;
+        }
 	$wrapper = '';
 
 	if ( wp_is_stream( $path ) ) {

[sabernhardt]

#57580 already reported the notices that result from a null value in add_submenu_page().

I tried 63403.patch with Easy Username Updater. If wp_normalize_path() returns a null $path, then plugin_basename() would still throw a deprecation notice when trying to run that through preg_replace().