Strengthen resilience of wp_register_plugin_realpath to support Gutenberg

[bobbingwide]

For many years now I've been working in a Windows development environment with multiple subdirectory installs referencing plugins using symlinks.

Every now and then I get problems due to plugin files apparently not being present when they quite clearly are. I have not been able to track it down. I think it's a bug in PHP associated with OpCache.

Anyway, the bottom line is that sometimes this problem, or something similar, results in the $wp_plugin_paths array containing entries with a null value for $realdir.

This can lead to the following:

Warning: strpos(): Empty needle in C:\apache\htdocs\hm\wp-includes\plugin.php on line 658.

This message has the uncanny knack of happening at the most inappropriate times.

Now, with Gutenberg looming, the problem is further reducing my ability to create content locally; Gutenberg can't handle the unexpected Warnings and Notices from a development server and fails. See ​https://github.com/WordPress/gutenberg/issues/5439

To reduce the likelihood of the problem I'd like to propose a change to wp_register_plugin_path() to cater for a false value being returned from the realpath() PHP function.

The proposal being that if $plugin_realpath does appear to be null, then don't add an entry in $wp_plugin_paths.

This change will prevent the warning message being issued from plugin_basename()'s test

if ( strpos( $file, $realdir ) === 0 ) {

and therefore increases the robustness of the system.

Bottom line.

• realpath() may return false.
• This should be catered for.

[bobbingwide]

I think I've discovered the root cause of the problem. This may at least allow others to reproduce the very much unwanted bad behaviour that my system has been exhibiting for longer than I can wish to remember.

It's a PHP configuration parameter problem. The default value was far too low.

realpath_cache_size = 16k

See ​https://github.com/bobbingwide/oik/issues/56#issuecomment-377702556

[peterwilsoncc]

This was discussed in a triage session today.

It seems reasonable to account for realpath() returning false, I've added a needs tests keyword and moved this to the Plugins component.

​Per the documentation, realpath() returns false in the following circumstances:

• the file does not exist
• the script does not have execute permissions on all directories in the hierarchy