PHP включают необходимую стратегию файла

Имейте сценарий конфигурации, который устанавливает "КОРЕНЬ УСТАНОВКИ" Вашего проекта, и затем используйте полные пути. Относительный путь с несколькими включает, головная боль в php.

ОПРЕДЕЛИТЕ ("INSTALL_ROOT", "/path/to/www/project")

require_once (INSTALL_ROOT. '/util1.php')

в моей конфигурации / файл настройки, я делаю что-то как

define('MYAPP_BASEDIR',realpath('.'));

затем я ссылаюсь на все относительно этого.

... если Ваш включать каталог имеет отношение конкретно к файлам класса, и Вы можете назвать их так, чтобы включать имя файла могло быть получено из класса, Вы хотели бы изучать spl_autoload_register().

эта последняя часть не является прямым ответом на Ваш вопрос, но очень удобно, если Вы делаете, включает для каждого класса, который Вы используете.

Следует иметь в виду, это запускается в текущем рабочем каталоге и затем просматривает включать пути. Если Вы хотите сослаться на все свои пути от некоторого центрального корневого каталога (или многие) можно добавить, что каталог в файле php.ini или можно сделать это программно с set_include_path( $path.PATH_SEPERATOR.get_include_path());

Вы правы, Ваши сценарии не должен знать физический путь, где Ваш включает.

IMO местоположение, где включение, должно быть настроено в файле PHP.INI (или .htaccess, если Вы предпочитаете).

Suponse Ваш включает (utils, и база данных хранятся здесь/home/scott/php_includes/).

PHP.INI:

include_path =.:/home/scott/php_includes/

Теперь Ваши сценарии могут включать библиотеки таким образом:

dbaccess/db1.php:

require_once 'utils/util1.php';

public/index.php

require_once 'dbaccess/db1.php';

public/blah/page.php:

require_once 'dbaccess/db1.php';

Много людей предоставило хорошие решения, но я только что получил один связанный с производительностью комментарий, в то время как разговор о включает и требует.

При запуске include'ing и require'ing много файлов может быть заманчиво использовать include_once или require_once. Cachegrinds сценариев, которые используют много _once, показали, что действительно замедляют производительность, поскольку сценарий должен остановить то, что его выполнение просканировать и удостовериться файл уже не был включен. При устранении стольких же из _once сколько Вы банка поможет много.

Для почему бы не требования его на основе, он - полный путь?

Например,/sharedhost/yourdomain.com/apache/www является Вашим корнем документа, итак, почему бы не использовать

require('/sharedhost/yourdomain.com/apache/www/dbutils.php');

Это также имеет преимущество Вас, способность сохранить Ваш включает за пределами Вашего wwwroot, таким образом, они, намного менее вероятно, будут inadvertenly, выставленным через сеть.

Вы могли также настроить глобальную переменную, равную/sharedhost/yourdomain.com/apache/части его так, можно переместить сайт.

require(WWWROOT . '/dbutils.php');

Лучший способ сделать, который должен создать гибкую систему автозагрузки.

Простая карта имен классов и собственных патчей. Затем любой внутренний require_* или include_* не нужны.

Существует, конечно, вопрос родственника/полного пути для автопогрузчика. Ну, абсолютный является самым эффективным системой, таким образом, в массиве я упомянул, прежде чем можно будет предварительно ожидать некоторую переменную {я использовал переменную Phing-стиля}, например.

<map>
    <path classname="MyClass">${project_directory}/libs/my_classes/MyClass.php</path>
    <path classname="OtherClass">${project_directory}/libs/some_new/Other.php</path>
    <!-- its so flexible that even external libraries fit in -->
    <path classname="Propel">${project_directory}/vendors/propel/Propel.php</path>
    <!-- etc -->
</map>

Это - xml (думайте о ini или yaml также), файл и требует компиляции к php во время первого запуска, но после, который любой путь является полным.

О, поскольку Вы не видите соглашения о присвоении имен файла, или расположение файла обязательно - его огромное преимущество.

С наилучшими пожеланиями, Alan.

Я предлагаю стратегию абстракции.

1. В Вашей области страницы приложения имейте единственный файл, который включают все страницы.

2. Это "локальное" включает файл, имеет одно задание: найдите включать файл, который является вне области страницы приложения. Это затем включает это. Это может, вероятно, быть столь же просто как <?php include dirname(__FILE__).'/../include/include.php/'; ?>

3. Этот второй файл является однократной точкой в Вашу структуру библиотеки. Это, или что-то еще, что это включает, имеет задание нахождения, где все и включая его.

Эта структура означает, что у Вас есть всего один файл как точка входа Вашей библиотеки и как это находит, что остальная часть библиотеки не является проблемой страниц приложения. Это также означает, что у Вас есть всего один файл в Вашей прикладной области, которая знает, как найти точку входа Вашей библиотеки.

Если бы Вам нужен путь к различным страницам приложения для загрузки разных вещей, я предложил бы подход модуляризации. Это может или быть глобальным массивом, который Вы устанавливаете перед ведущим устройством включают, или функция, которую можно вызвать для запроса библиотек по имени. Да, это - немного более необычный способ Вашего основного файла библиотеки, объявляя константу того, где все - но он удаляет искушение выполнения include LIBRARY_DIR.'/utils/util.php'; который сразу делает излишне трудным переместиться util.php из utils и в misc/util позднее.

Другое преимущество цепочечных файлов состоит в том, что затем намного легче сделать Вашу кодовую базу перемещаемой, который позволяет нескольким версиям быть выполнимым. И это позволяет иметь одно дерево для приложения и другого для Вашей библиотеки. Что означает, что другое приложение могло пользоваться Вашей библиотекой. На самом деле Вы могли расширить объединение в цепочку немного больше, если Вы хотите помочь с изоляцией далее.

Было идеальное решение - pecl расширение, названное "pwee" - это, разрешенный пользователь определяет его собственного экстерна суперглобальные константы / переменный XML-файл использования. Таким образом Вы смогли использовать полный путь, как я рекомендую в такой форме:

require_once APP_ROOT."/path/to/your/script.php";

Преимущество такого решения было:

• доступный отовсюду
• никакая загрузка сервера - все в памяти сервера

XML-файл содержится

  <Environments>
    <Application name="www.domain.com" namespace="">
      <Constants>
        <Constant name="APP_ROOT" value="/full/path/to/project/source" />
      </Constants>
      <Constants>
        <Constant name="WEB_ROOT" value="/full/path/to/project/public" />
      </Constants>
    </Application>
  </Environments>

свяжитесь с pwee проектом

Необходимо отличить эти случаи включения:

• автономная библиотека - все включает, должно быть относительным - чтобы позволить пользователю интегрировать его к его проекту легко
• исполняемые сценарии в Вашем общедоступном каталоге - содержат абсолютный, включает в файлы проекта и в автономные файлы общественности библиотек (который имеет родственника, включает внутри - очевидный для пользователя). Используя константу APP_ROOT изящный путь.
• a, ссылка, сценарий, элементы HTML формы и заголовок вперед должен использовать относительный путь при дайвинге в древовидную иерархию и полный путь при использовании общих файлов от более высоких уровней иерархии

В случае относительного пути используют эту форму:

  require_once "./relative/path/to/script.php";

Почему я использую прошедшее время? Поскольку проект больше не поддерживается - работы только с Php4. Если кто-либо знает аналогичное решение с поддержкой, сообщите мне.

Я использую

require '../path/to/file.ext';

без проблем.

Также потребуйте, оператор не функция, таким образом, это должно использоваться как

require '/path/to/file.ext';

нет

require('/path/to/file.ext');

Кажется, что каждый раз, когда я перемещаю свои простые скрипты с одного сервера на другой, мне приходится заново определять, где что находится.

Я настроил тестовую среду дома, построил несколько вещей и развернул их на общем хосте. В результате $ _ server ['DOCUMENT_ROOT'] был на две папки выше, чем папка public_html на одном сервере, а на другом сервере он был на одну папку выше.

Это исказило все мои ссылки. Поэтому я попробовал $ _ server ['WEB_ROOT'] и снова потерпел неудачу. Я думал, что веб-корень является ссылкой на корень общедоступных папок на сервере, но я ошибался.

Мне нужно бросить в кучу один, который сделал что-то очень простое, не добавляя много кода, который я не понимаю (я тоже не понимаю большую часть этого кода, я просто продолжал добавлять, когда читал правила и получал это работать).

Это дало мне ссылку на общедоступный веб-каталог на всех трех серверах, на которых я его пробовал. Теперь я могу переместить свою папку куда угодно, и она просто работает, файл конфигурации не требуется!

pub-doc-root.php:

<?php

//You only need to paste the following line into your script once,
//and it must come before you reference the public document root of your website.
//Use $pubroot.'/path_from_public_document_root_to_file/filename.php

$pubroot = (str_replace(($_SERVER['PHP_SELF']), '', (str_replace('\\', '/', (realpath(basename(getenv("SCRIPT_NAME"))))))));


//uncomment the next line to show the calculated public document root
//relative to the document root.

//echo ("$pubroot");
?>

Моя тестовая среда:

• php 5.3.1
• Apache 2.2.14 (Win32) mod_ssl 2.2.14 OpenSSL 0.9.8k
• ZendServer-CE- 5.0.0GA_RC181-5.3.1-Windows_x86