[wp-trac] [WordPress Trac] #28811: Mixed slashes in windows paths cause issues downstream

WordPress Trac noreply at wordpress.org
Thu Jul 10 14:37:35 UTC 2014


#28811: Mixed slashes in windows paths cause issues downstream
----------------------------+------------------------------
 Reporter:  alightner       |       Owner:
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Filesystem API  |     Version:  3.9.1
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+------------------------------

Old description:

> There are issues caused downstream via the mixed slashes in windows
> paths.  While the initial calls to require_once() may cope fine with the
> mixed slashes, it is still beneficial to construct the paths correctly in
> the first place.  For example if someone uses a search and replace call
> to manipulate the path and the slashes don't match in the search or
> target string the substitution may fail unexpectedly on windows, giving
> odd behavior when the user tries to access that new path.
>
> This brings me to a common complaint with the nextgen gallery:
>
> [http://wordpress.org/support/topic/updated-wp-and-nextgen-gallery-
> to-207] (10 months ago)
> [http://wordpress.org/support/topic/wp-crash-after-moved-to-other-
> server-1] (1 month ago)
>
> I know that someone complained about this once before here:
> [https://core.trac.wordpress.org/ticket/20849] and it was closed as
> "invalid", but I would like to re-raise this issue, with an alternative
> solution.  I do understand that no one wants to make unnecessary
> search/replace calls to "correct" the slash for the Linux machines.
> However, I also hope that you can see the benefit with building the paths
> correctly in the first place with the DIRECTORY_SEPARATOR, so that things
> behave more consistently for both linux and windows users alike.
>
> My proposed fix is simple enough:
> Edit both: {DOCROOT}\wp_load.php & {DOCROOT}\wp_config.php (and any other
> place that defines ABSPATH)
>
> Find: define( 'ABSPATH', dirname(__FILE__) . '/' );
> Replace with: define('ABSPATH', dirname(__FILE__) . DIRECTORY_SEPARATOR);
>
> Be careful with the following "finds" you are looking for things that end
> in DIR NOT URL!!!
>
> Edit {DOCROOT}\wp-includes\default_constants.php
> Find: define( 'WP_PLUGIN_DIR', WP_CONTENT_DIR . '/plugins' );
> Replace with: define( 'WP_PLUGIN_DIR', WP_CONTENT_DIR .
> DIRECTORY_SEPARATOR . 'plugins' );
> Find: define( 'PLUGINDIR', 'wp-content/plugins' );
> Replace with: define( 'PLUGINDIR', 'wp-content'.DIRECTORY_SEPARATOR
> .'plugins' );
> Find: define( 'WPMU_PLUGIN_DIR', WP_CONTENT_DIR . '/mu-plugins' );
> Replace with: define( 'WPMU_PLUGIN_DIR', WP_CONTENT_DIR .
> DIRECTORY_SEPARATOR .'mu-plugins' );
> Find: define( 'MUPLUGINDIR', 'wp-content/mu-plugins' );
> Replace with: define( 'MUPLUGINDIR', 'wp-content'.DIRECTORY_SEPARATOR
> .'mu-plugins' );
>
> I can't say for certain how many places where the DIRECTORY_SEPARATOR is
> needed, but you get the idea what to do to fix it from that sampling of
> edits.
>
> Thanks!

New description:

 There are issues caused downstream via the mixed slashes in windows paths.
 While the initial calls to require_once() may cope fine with the mixed
 slashes, it is still beneficial to construct the paths correctly in the
 first place.  For example if someone uses a search and replace call to
 manipulate the path and the slashes don't match in the search or target
 string the substitution may fail unexpectedly on windows, giving odd
 behavior when the user tries to access that new path.

 This brings me to a common complaint with the nextgen gallery:

 [http://wordpress.org/support/topic/updated-wp-and-nextgen-gallery-to-207]
 (10 months ago)
 [http://wordpress.org/support/topic/wp-crash-after-moved-to-other-
 server-1] (1 month ago)

 I know that someone complained about this once before here: #20849 and it
 was closed as "invalid", but I would like to re-raise this issue, with an
 alternative solution.  I do understand that no one wants to make
 unnecessary search/replace calls to "correct" the slash for the Linux
 machines.  However, I also hope that you can see the benefit with building
 the paths correctly in the first place with the DIRECTORY_SEPARATOR, so
 that things behave more consistently for both linux and windows users
 alike.

 My proposed fix is simple enough:
 Edit both: `{DOCROOT}\wp_load.php` & `{DOCROOT}\wp_config.php` (and any
 other place that defines ABSPATH)

 Find: `define( 'ABSPATH', dirname(__FILE__) . '/' );`
 Replace with: `define('ABSPATH', dirname(__FILE__) .
 DIRECTORY_SEPARATOR);`

 Be careful with the following "finds" you are looking for things that end
 in DIR NOT URL!!!

 Edit `{DOCROOT}\wp-includes\default_constants.php`
 Find: `define( 'WP_PLUGIN_DIR', WP_CONTENT_DIR . '/plugins' );`
 Replace with: `define( 'WP_PLUGIN_DIR', WP_CONTENT_DIR .
 DIRECTORY_SEPARATOR . 'plugins' );`
 Find: `define( 'PLUGINDIR', 'wp-content/plugins' );`
 Replace with: `define( 'PLUGINDIR', 'wp-content'.DIRECTORY_SEPARATOR
 .'plugins' );`
 Find: `define( 'WPMU_PLUGIN_DIR', WP_CONTENT_DIR . '/mu-plugins' );`
 Replace with: `define( 'WPMU_PLUGIN_DIR', WP_CONTENT_DIR .
 DIRECTORY_SEPARATOR .'mu-plugins' );`
 Find: `define( 'MUPLUGINDIR', 'wp-content/mu-plugins' );`
 Replace with: `define( 'MUPLUGINDIR', 'wp-content'.DIRECTORY_SEPARATOR
 .'mu-plugins' );`

 I can't say for certain how many places where the DIRECTORY_SEPARATOR is
 needed, but you get the idea what to do to fix it from that sampling of
 edits.

 Thanks!

--

Comment (by SergeyBiryukov):

 Related: #15598, #16457, #17494, #20849.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28811#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list