IIS 上的 PHP __FILE__ 返回使用 MKLINK 创建的符号链接文件夹的错误路径

Question

我在调试一个微软IIS特有的问题，特别是IIS10，但是不知道其他版本的IIS是否也有这个问题。我有一个 WordPress 插件的问题，当我在 Apache 服务器上运行它时，或者在我的 Local by Flywheel 测试环境中的任何 Apache/Linux/nginx Web 服务器上运行它时，它可以正常工作。问题涉及到符号链接文件夹的 PHP 内置常量 __FILE__。我创建了指向我的插件开发文件夹的符号链接，如下所示：Website is here:        c:\inetpub\my-web-siteThe plugin lives here:  c:\users\me\onedrive\plugins\my-plugin我在文件夹中创建了一个符号链接：c:\inetpub\my-web-site\wp-content\plugins在命令行上使用以下命令。c:cd \inetpub\my-web-site\wp-content\pluginsmklink /J my-plugin c:\users\me\onedrive\plugins\my-pluginWeb 服务器将插件文件夹视为：c:\inetpub\my-web-site\wp-content\plugins\my-plugin这是简单的部分。在 PHP 中，从 WordPress 网站内部，PHP 常量 __FILE__（仅限 IIS）返回错误的路径。具体来说，调用 PHP 常量 __FILE__ 会返回错误的路径。添加此代码：$path = __FILE__;到这个文件：c:\inetpub\my-web-site\wp-content\plugins\my-plugin\my-plugin.php两个 $path 都将返回：c:\users\me\onedrive\plugins\my-plugin\my-plugin.php我预计 __FILE__ 会返回：c:\inetpub\my-web-site\wp-content\plugins\my-plugin\my-plugin.php换句话说，在 IIS10 上，PHP 常量 __FILE__ 返回操作系统看到的符号链接文件夹的物理（目标）路径，而不是 Web 服务器看到的文件的物理路径。就目前而言，这完全违背了在 IIS 中使用符号链接文件夹的目的。我的问题：有人知道吗 1）有补救办法吗？2) 是否有不涉及使用 WP_CONTENT_DIR 的解决方法？3）我错过了什么吗？

Answer 1

这是PHP的预期行为，并已记录在案。路径/文件名的魔术常量始终解析路径，以便将符号链接替换为其目标路径。

该 SO 问题中的建议是使用$_SERVER["SCRIPT_FILENAME"]. 虽然如果您正在测试的文件已通过另一个目录中的另一个 PHP 文件包含，这可能不起作用。还有其他一些建议，但最终解决方案可能归结为将目录安装到路径（就像你做一个驱动器一样）。