На localhost. У меня есть следующая структура каталогов:
/share/www/trunk/wp-content/plugins/otherfolders
/share/www/portfolio/wp-content/symlink
Где symlink
символьная ссылка на /trunk/.../plugins/
. В основном это вызвано тем, что я должен протестировать несколько установок WordPress и настроить их, но я не хочу должным быть перемещать плагины и копировать и вставлять их везде.
Однако иногда я должен ползти вверх по дереву каталогов для включения файла конфигурации:
$root = dirname(dirname(dirname(dirname(__FILE__))));
if (file_exists($root.'/wp-load.php')) {
// WP 2.6
require_once($root.'/wp-load.php');
}
Папка всегда разрешает:
/share/www/trunk
Даже когда плагин выполняется и включается в
/share/www/portfolio/
.
Действительно ли возможно в PHP включать файлы в share/www/portfolio
каталог из сценария, выполняющегося в символьной ссылке на /share/www/trunk/.../plugins
каталог?
В то время как эта проблема только происходит на моем тестовом сервере, я хотел бы иметь безопасно распространяемое решение, настолько ползущий вверх дополнительный уровень не является опцией.
Проблема, которую я вижу в вашем коде, заключается в том, что __ FILE __
автоматически разрешает символические ссылки.
Из руководства PHP по Магические константы
... Начиная с PHP 4.0.2,
__ FILE __
всегда содержит абсолютный путь с разрешенными символическими ссылками ...
Вы можете попробовать использовать $ _ SERVER ["SCRIPT_FILENAME"]
вместо этого.
$root = realpath(dirname(dirname(dirname(dirname($_SERVER["SCRIPT_FILENAME"])))));
if (file_exists($root.'/wp-load.php')) {
// WP 2.6
require_once($root.'/wp-load.php');
}
Обратите внимание, что я добавил функцию realpath ()
в корневой каталог. В зависимости от ваших настроек он может вам понадобиться, а может и не понадобиться.
РЕДАКТИРОВАТЬ: Используйте $ _ SERVER ["SCRIPT_FILENAME"]
вместо $ _ SERVER ["PHP_SELF"]
в качестве пути к файловой системе.
Если бы я пытался решить эту проблему, я бы разделил __ FILE __
по битам пути и создал SplFileInfo для каждого по пути, проверьте с помощью isDir и isLink , затем попытайтесь определить, как обрабатывать реконструкцию пути, если известно, что он отличается от ожидаемого, чтобы вы могли извлечь из правильного каталога. (Если вы больше относитесь к процедурному типу, то есть is_dir и is_link .)
При этом, я думаю, вы уже дисквалифицировали это решение. Может быть, инструменты достаточно умны, чтобы сделать это за вас.Попробуйте сравнить результат getRealPath с getPath ? getRealPath прямо говорит, что он разрешает символические ссылки, а getPath прямо этого не говорит.
Даже в этом случае такое сниффинг может быть небезопасным на клиентских сайтах, в зависимости от того, кто является хостом. Я видел довольно креативные файловые системы общего хостинга. Вы можете добавить проверку к php_uname и вытащить имя хоста машины, и если это не ваш ящик разработчика, не выполняйте лишнюю работу.
Интерпретатор PHP разрешает символические ссылки перед их обработкой. Вы можете сделать это самостоятельно с помощью функции readlink
. PHP разрешает ссылки, потому что он более эффективен для функций * _ once
и кешей кода, таких как APC, Xcache и т. Д.
Вероятно, вам понадобится еще один способ найти, где конкретная установка хранит свои файлы. Я бы рекомендовал использовать {$ _ SERVER ['DOCUMENT_ROOT']} / wp-content / wp-load.php
, предполагая, что / share / www / портфолио
является корнем документа.