[wp-trac] [WordPress Trac] #43489: Strengthen resilience of wp_register_plugin_realpath to support Gutenberg
WordPress Trac
noreply at wordpress.org
Wed Mar 7 18:36:14 UTC 2018
#43489: Strengthen resilience of wp_register_plugin_realpath to support Gutenberg
--------------------------+------------------------------
Reporter: bobbingwide | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version:
Severity: normal | Resolution:
Keywords: needs-patch | Focuses:
--------------------------+------------------------------
Changes (by johnbillion):
* keywords: => needs-patch
* version: trunk =>
Old description:
> 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.
New description:
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.
--
--
Ticket URL: <https://core.trac.wordpress.org/ticket/43489#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list