Я отлаживаю проблему, которая является уникальной для Microsoft IIS, в частности IIS10, но я не знаю, есть ли другие проблемы IIS также с этой проблемой. У меня проблема с плагином WordPress, который работает правильно, когда я запускаю его на сервере Apache или в моей тестовой среде Local by Flywheel на любом из веб-серверов Apache / Linux / nginx.
Проблема связана со встроенной константой PHP __FILE__ в символически связанную папку.
Я создал символическую c ссылку на папку для разработки плагинов в следующем виде:
Website is here: c:\inetpub\my-web-site
The plugin lives here: c:\users\me\onedrive\plugins\my-plugin
Я создал символьную ссылку c в папке:
c:\inetpub\my-web-site\wp-content\plugins
, используя следующие команды в командной строке.
c:
cd \inetpub\my-web-site\wp-content\plugins
mklink /J my-plugin c:\users\me\onedrive\plugins\my-plugin
Веб-сервер видит папку плагина как:
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__ возвращает физический (целевой) путь к символически связанной папке с точки зрения операционной системы, а не физический путь к файлам с точки зрения веб-сервера.
В его нынешнем виде это полностью противоречит цели использования символически связанных папок в IIS.
Мой вопрос: кто-нибудь знает 1) Есть ли лекарство от этого? 2) есть ли обходной путь, который не предусматривает использование WP_CONTENT_DIR? и 3) я что-то упустил?