[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