DIRECTORY_SEPARATOR Issue

Firstly, let me say I’m aware that this has been reported before and that there’s a work-around. However, if the plug-in is upgraded or re-installed, then the work-around gets undone. Although not a show-stopper, it’s an annoyance. There are problems when the directory separator is \ rather than / . To my knowledge, this is only Windows platforms, but as that’s a popular platform, I think this is important. #### Steps to reproduce: Use a WordPress site running on a Windows host. Install and activate “Snow Storm”. Load a page. Examine the source code. #### Expected behaviour: The JavaScript file snow-storm.js to be loaded, e.g. <script type='text/javascript' src='/wp-content/plugins/snow-storm/snow-storm.js?ver=1.41'></script> The snow effect to be rendered. #### Actual behaviour: Incorrect script path specified, e.g. <script type='text/javascript' src='/wp-content/pluginssnow-stormsnow-storm.js?ver=1.41'></script> No snow effect. #### Analysis: File: snow-storm.php Func: snow_storm_enqueue_scripts() Line: 116 wp_enqueue_script('snow-storm', plugins_url() . DS . 'snow-storm' . DS . 'snow-storm.js', false, '1.41'); Due to the use of DS i.e. DIRECTORY_SEPARATOR , the resulting URL is: /wp-content/plugins\snow-storm\snow-storm.js This is causing problems later on in the processing, since the backslashes are not escaped, e.g. \\ . The result is that things like \s just end up as s . #### Recommendation: As Windows supports the use of / as a path separator, at least those versions since command.com was in use, then there’s no real need to use the DS constant. It could be removed from the plug-in’s code, or at least permanently set to / rather than DIRECTORY_SEPARATOR . In any case, scripts should be specified as URLs when using <script src="..."> , not file system paths, so DS should never have been used in this particular case. I hope this is helpful.