Я разрабатываю Zend MVC на своем локальном компьютере и использую сайт DreamHost для подготовки. Согласно краткому запуску Zend, на моем локальном машине я установил свой APPLICATION_ENV для разработки из файла .htaccess в общедоступном каталоге проекта, например:
myproject/public/.htaccess содержит эту строку,
SetEnv APPLICATION_ENV разработка
Это отлично работает локально. Но когда я пытаюсь использовать свой app_env на промежуточном сервере, его там нет. Этот поток предположил, что, возможно, suexec работает в фоновом режиме. Я немного покопался и, конечно же, Dreamhost блокирует пользовательские переменные среды.
Я попробовал первый обходной путь, предложенный DH, добавив HTTP_ перед APPLICATION_ENV, а затем добавив еще одно условие в public/index.php, чтобы проверить как оригинальную версию, так и версию Dreamhost.
// Define application environment
defined('APPLICATION_ENV') || define('APPLICATION_ENV',
(getenv('APPLICATION_ENV') ? getenv('APPLICATION_ENV') :
(getenv('HTTP_APPLICATION_ENV') ? getenv('HTTP_APPLICATION_ENV') : 'production')));
Это, похоже, не сработало для меня. Даже в ssh, когда я запускаю env в командной строке, моего application_env нет в списке. Поскольку я не работаю с CGI-скриптом, я не стал заморачиваться со вторым и третьим обходными путями.
tl;dr
Итак, насколько я понимаю, мои варианты состоят в том, чтобы либо создать свою собственную систему конфигурации (сохранить app_env в другой файл, загрузить этот файл в public/index.php, что кажется более трудоемким, чем вариант 2) или просто «жестко» кодирует app_env в положение по умолчанию — это означает, что вместо «производства» в приведенном выше примере кода будет просто указано «постановка». Если бы я выбрал последнее, мне пришлось бы .gitignore мой файл public/index.php, что кажется немного странным. До этого мне никогда не приходилось изменять этот файл, и я полагал, что лучше не возиться с ним, не говоря уже о том, чтобы полностью оставить его за пределами моего репозитория. Мысли? Предложения? Дальнейшие обходные пути?
