WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#20849 closed defect (bug) (invalid)

'ABSPATH' Invalid with Windows Servers

Reported by: admintiger Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.4
Component: Filesystem API Keywords:
Focuses: Cc:

Description (last modified by johnbillion)

The following code defines 'ABSPATH' with mixed backward and forward slashes (like this: 'C:\public\www.example.com/') six places within WordPress when run on a Windows server:

define('ABSPATH', dirname(__FILE__) . '/');

Additional path strings with forward slashes are subsequently concatenated many places in the core, in plugins, and sometimes in themes, resulting in many invalid filepaths similar to the following example:

C:\public\www.example.com/wp-includes/shortcodes.php

Mixed slashes like that cause a variety of malfunctions generally when WordPress is used on Windows servers, but especially when minifying and/or caching plugins are used.

I suggest changing:

define('ABSPATH', dirname(__FILE__) . '/');

to:

define('ABSPATH', str_replace(chr(92), '/', dirname(__FILE__)) . '/');

in each of the following places to correct those problems:

\wp-config-sample.php -> Line 87

\wp-load.php -> Line 22

\wp-admin\load-scripts.php -> Line 11

\wp-admin\load-styles.php -> Line 11

\wp-admin\setup-config.php -> Line 39

\wp-admin\gears-manifest.php -> Line 17

Change History (14)

comment:1 knutsp2 years ago

  • Cc knut@… added
  • Severity changed from major to normal

I haven't seen any malfunctions related to this mix of directory separators. Windows allows and respects both. So why is a path like

C:\public\www.example.com/wp-includes/shortcodes.php

invalid?

I don't use minifying plugins, but if they fail I would consider it a bug in the plugin, not WordPress core.

For caching I only use Wincache on Windows servers.

As the backslash is not legal in a file- or dirname on Unix/Linux (?) I guess that suggested change won't break anything. It will add some consistency in that all paths will use the same separator from left to right. This may make some file handling plugins start working on Windows servers without being tested on Windows.

comment:2 GaryJ2 years ago

The use of the PHP constant DIRECTORY_SEPARATOR would be better.

comment:3 knutsp2 years ago

Using DIRECTORY_SEPARATOR instead of chr(92) in the suggested str_replace function would be completely pointless. On non-Windows you will then replace all occurrences of "/" with "/".

WordPress core have standardized on using "/" for creating paths, and that's how it should be, regardless of the actual DIRECTORY_SEPARATOR.

The only usefulness of constant DIRECTORY_SEPARATOR is when parsing paths generated by the system, if you prefer not to substitute those before parsing.

comment:4 johnbillion2 years ago

  • Description modified (diff)

comment:5 in reply to: ↑ description ; follow-up: johnbillion2 years ago

Replying to admintiger:

Mixed slashes like that cause a variety of malfunctions generally when WordPress is used on Windows servers, but especially when minifying and/or caching plugins are used.

Which plugin(s) specifically malfunction on Windows? I'm running a couple of sites on Windows boxes and haven't experienced any problems with file paths.

comment:6 in reply to: ↑ 5 ; follow-up: GaryJ2 years ago

Replying to johnbillion:

Which plugin(s) specifically malfunction on Windows? I'm running a couple of sites on Windows boxes and haven't experienced any problems with file paths.

Not technically a plugin, but https://github.com/jaredatch/Custom-Metaboxes-and-Fields-for-WordPress/issues/31 shows one side-effect of using a "WordPress standard of /" instead of the PHP DIRECTORY_SEPARATOR constant - the very thing it was created for.

comment:7 knutsp2 years ago

In PHP on Windows "/" is a defacto valid directory separator. Some systems doesn't acknowledge that "/" and "\" are interchangeable. Is this something WordPress should fix? Maybe.

I guess that to solve this "side effect" completely we must change all the path building uses of "/" to DIRECTORY_SEPARATOR in core. I have doubts we ever will, but if we did, it seems to be some benefits.

comment:9 in reply to: ↑ 6 nacin2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Replying to GaryJ:

"WordPress standard of /" instead of the PHP DIRECTORY_SEPARATOR constant - the very thing it was created for.

That's not accurate. Building paths with DIRECTORY_SEPARATOR is extra characters, wordy, annoying, and also unnecessary.

A forward slash works fine on Windows, even when mixed with backwards slashes, such as in the case of C:\public\www.example.com/wp-includes/shortcodes.php. This is not an invalid path. It is a perfectly valid Windows path.

If DIRECTORY_SEPARATOR is not needed to build platform-independent paths, what is it good for? It is only really useful when you need to do operations against a path provided to you by the system, such as taking __FILE__ and exploding it by DIRECTORY_SEPARATOR. In some cases, it is still just easier to standardize on / with a find-replace first, depending on what you are trying to do.

If you don't believe me, that's fine, but there are comments and posts scattered about the web that will echo the same thing.

comment:10 follow-up: admintiger2 years ago

Problems arise with file-path string comparisons, file-path string searches, and file-path string search and replace operations where slashes can be of either type. Why not avoid the potential for all such problems by making forward slashes the WordPress standard throughout?

Version 0, edited 2 years ago by admintiger (next)

comment:11 knutsp2 years ago

@admintiger: Your cause was to make all paths using forward slashes, by normalizing that ABSPATH in case Windows. This is good, but not because those paths are invalid, but because it may have some benefits, right?

Do you have a case, a core function, a well-made plugin or theme, that does not work with mixed separators? Post it here, and reopen.

@nacin: It seems you closed this ticket because of the DIRECTORY_SEPARATOR issue that was brought in by commenter @GaryJ. But this ticket is not suggesting using it. It was suggesting using a consistent directory separator ("/") for ABSPATH on Windows, although we can agree that these are not invalid paths.

comment:12 in reply to: ↑ 10 SergeyBiryukov2 years ago

Replying to admintiger:

Problems arise with file-path string comparisons, file-path string searches, and file-path string search and replace operations where slashes can be of either type. Why not avoid the potential for all such problems by making forward slashes the WordPress standard throughout?

I doubt that would help much. Plenty of plugins would still use dirname(__FILE__) to get current path and perform comparisons and string operations on their own, just like they do now.

comment:13 nacin2 years ago

Replying to knutsp:

It was suggesting using a consistent directory separator ("/") for ABSPATH on Windows, although we can agree that these are not invalid paths.

The ticket is titled "'ABSPATH' Invalid with Windows Servers". It's not invalid, therefore, the ticket is invalid. "Fixing" it, as SergeyBiryukov's comment implies, is not practical. Especially when nothing is broken. :-)

comment:14 knutsp2 years ago

@nacin: Yes, the title makes this ticket invalid.

It's also a lesson in creating good tickets. Don't make things more severe than it is, especially not in the title, as this can't be modified later (and that's fine).

But the reporter has stated that things are broken, without being specific. I hope the reporter will come up with real examples, if they exist, and then create a ticket for an enhancement, something that could make certain tasks a lot easier, and/or make useful plugins more platform independent without having to take special care of the ABSPATH.

I also agreee with Sergey that (FILE) is the most used path generator.

Finally, there are several plugins that doesn't work well on Windows, mainly because the plugin author just assumes the platform is Linux. Those who set up WordPress, for development, on a Windows PC, usually doesn't bother with caching and minifying plugins. We, who run a lot of sites on IIS7 on a Windows server, in production, want more plugin compatibility for the platform, and we are concerned with (possible) issues like this.

Note: See TracTickets for help on using tickets.