plugin_dir_path() returns unsanitized path on Windows installs

[johnjamesjacoby]

Currently plugin_dir_path() only returns the result of dirname( $file ), which can produce mixed results on local Windows installations.

Attached patch takes pieces from plugin_basename() and plugins_url() to guarantee a working and accurate plugin directory path is returned in all operating systems.

See ​#BB1596 (and associated revisions) for back-story.

[nacin]

Doubt there's a need to fix plugin_dir_path() -- more likely, the issue is this code in search_theme_directories():

$theme_loc = str_replace(WP_CONTENT_DIR, '', $theme_root);

[johnjamesjacoby]

Probably right.

Possibly related: #4541

[dd32]

I believe this issue mainly arises from the fact that some constants on windows environments contain a mixture of \ and / in the paths (which stems from define( 'ABSPATH', dirname(__FILE__) . '/' ); using \), whilst most core functions standardise on / in created paths.. and even some of the API's do a str_replace('\\','/'..

ideally fixing this as low as possible would be better IMHO.

[ramiy]

#19200 - Related?

[nacin]

Replying to nacin:

$theme_loc = str_replace(WP_CONTENT_DIR, '', $theme_root);

This is actually dead code. $theme_loc is set up but never used. It will be removed in #20103.

[callumbw95]

Hi All,
I have taken a look into this, and it looks like the issue with paths not working properly was resolved in 3.9 when the function wp_normalize_path() and has been expanded upon since (​docs). Unfortunately, I don't have a Windows environment to test this. However, given that this ticket was opened a long time ago and we haven't received any other complaints on this topic, I'm confident that the issue has since been resolved. I'm going to close this ticket as invalid as it is no longer relevant in the latest release, however if you do have anything more to add to this conversation please reopen this ticket. 😃