Opened 21 months ago
Last modified 11 months ago
#18501 new defect (bug)
plugin_dir_path() returns unsanitized path on Windows installs
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | Plugins | Version: | 2.8 |
| Severity: | normal | Keywords: | needs-testing has-patch |
| Cc: | pavelevap@…, georgemamadashvili@… |
Description
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.
Attachments (1)
Change History (9)
johnjamesjacoby — 21 months ago
Probably right.
Possibly related: #4541
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.

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);