0

I am debugging a problem that is unique to Microsoft IIS, specifically IIS10, but I don't know whether other versions of IIS also have this problem. I have a problem with a WordPress plugin, that works correctly when I run it on an Apache server, or in my Local by Flywheel test environment on any of the Apache/Linux/nginx web servers.

The problem involves the PHP built-in constant __FILE__ to a symbolically linked folder.

I created symbolic link to my plugin development folder as the following:

Website is here:        c:\inetpub\my-web-site
The plugin lives here:  c:\users\me\onedrive\plugins\my-plugin

I created a symbolic link in the folder:

c:\inetpub\my-web-site\wp-content\plugins

using the following commands on the command line.

c:
cd \inetpub\my-web-site\wp-content\plugins
mklink /J my-plugin c:\users\me\onedrive\plugins\my-plugin

The web server sees the plugin folder as:

c:\inetpub\my-web-site\wp-content\plugins\my-plugin

That's the simple part.

In PHP, from inside a WordPress website, the PHP constant __FILE__ (IIS only) returns the wrong path. Specifically, calling PHP constant __FILE__ returns the wrong path.

Add this code:

$path = __FILE__;

To this file:

c:\inetpub\my-web-site\wp-content\plugins\my-plugin\my-plugin.php

Both $path will return:

c:\users\me\onedrive\plugins\my-plugin\my-plugin.php

I expected __FILE__ to return:

c:\inetpub\my-web-site\wp-content\plugins\my-plugin\my-plugin.php

In other words, on IIS10, the PHP constant __FILE__ returns the physical (target) path to the symbolically linked folder as seen by the operating system, not the physical path to the files as seen by the web server.

As it stands, this completely defeats the purpose of using symbolically linked folders in IIS.

My question: Does anybody know 1) Is there a remedy to this? 2) is there a work around which does not involve the use of WP_CONTENT_DIR? and 3) Am I missing something?

Paul Swarthout
  • 159
  • 7

1 Answers1

1

This is expected behavior from PHP and is documented. Magic constants for paths/filenames always resolve the path so that symlinks are replaced with their target paths.

The suggestion in that SO question is to use $_SERVER["SCRIPT_FILENAME"]. Though that may not not work if the file you are testing has been included via another PHP file in another directory. There are a couple other suggestions but ultimately the solution may come down to mounting the directory to a path (like you do a drive).

Jim
  • 3,210
  • 2
  • 17
  • 23
  • So it works in my Local by Flywheel Apache environment because it doesn't "see" it as a symbolically linked path. That's handled at the OS level and not visible to the VM. I chose to use $_SERVER['DOCUMENT_ROOT'] And then I rebuilt the path to the plugins by combining the result from $_SERVER['DOCUMENT_ROOT'] and plugins_url(). – Paul Swarthout Jan 22 '20 at 19:35