Комментарии 79
Увы, не хватает кармы перенести в web разработку.
Интересно.
От себя добавлю, что использование $_SERVER[«DOCUMENT_ROOT»] — редкостное зло, имхо лучше указывать относительные пути.
От себя добавлю, что использование $_SERVER[«DOCUMENT_ROOT»] — редкостное зло, имхо лучше указывать относительные пути.
а ещё лучше в приложении указывать ручками полный абсолютный :)
как вариант.
Но т.к. на сервере уже пара десятков работающих проектов…….
(Автор текста)
Но т.к. на сервере уже пара десятков работающих проектов…….
(Автор текста)
ниразу не лучше — первый перенос на другой сервер Вам это докажет
за последние два месяца перенёс около 50ти сайтов — проблем не испытывал
почему редкостное зло?
а относительные не всегда прокатывают, например, скрипт (например, из библиотеки) будет лежать не там, где хочет разработчик…
а относительные не всегда прокатывают, например, скрипт (например, из библиотеки) будет лежать не там, где хочет разработчик…
library/megalib/lib.php — относительный путь относительно запущенного index.php
Сменили путь к папке на ../factory/library/megalib/lib.php
../library/megalib/lib.php — относительный путь относительно запущенного index.php
Можно и без абсолютного пути.
Зато когда вы будете перекидывать с девелоп машины на продакшн, то проблем будет меньше.
Сменили путь к папке на ../factory/library/megalib/lib.php
../library/megalib/lib.php — относительный путь относительно запущенного index.php
Можно и без абсолютного пути.
Зато когда вы будете перекидывать с девелоп машины на продакшн, то проблем будет меньше.
А если у нас структура например аж 5тиуровневая? :)
А если система модульная?
в общем относительные пути — отличный вариант когда проект невелик.
А если система модульная?
в общем относительные пути — отличный вариант когда проект невелик.
У правильного приложения одна точка входа — index.php в корне. И соответственно все относительные пути строить не вызывает проблем.
Лучше устанавливать все пути в конфигурационном файле, в котором использовать __FILE__ — и никаких проблем не будет.
Лучше устанавливать все пути в конфигурационном файле, в котором использовать __FILE__ — и никаких проблем не будет.
Не считаю такое приложение правильным. Даже наоборот сторонюсь такой архитектуры. Аналогии почему то с «Всё через ж...»
Вы домой тоже ведь не только через парадное, но и через балкон и форточки заходите?
Такая архитектура позволяет в одном месте приложения обрабатывать все входящие данные и доставлять их в нужные контроллеры/действия. И так у всех нормальных фреймворков сделано.
Такая архитектура позволяет в одном месте приложения обрабатывать все входящие данные и доставлять их в нужные контроллеры/действия. И так у всех нормальных фреймворков сделано.
Так сделано у большинства. Да. Но считаю перным использовать mod_rewrite и именно через него направлять разные запросы нужным скриптам…
Хотите скажу почему куча правил для mod_rewrite зло для такой задачи? А перенесите все это добро под lighttpd / nginx + php-cgi.
И я очень радуюсь когда приложения написаны действительно грамотно — их при этом не приходится пилить напильником.
Насчет единой точки входа — так и у больших фреймворков на php, так и у django/rails/merb.
И я очень радуюсь когда приложения написаны действительно грамотно — их при этом не приходится пилить напильником.
Насчет единой точки входа — так и у больших фреймворков на php, так и у django/rails/merb.
в nginx есть модуль rewrite.
Угу, есть, конечно. Только вот задолбаетесь переделывать пачку реврайтов в его формат. А потом захотели попробовать lighttpd — а у него описание правил опять отличается…
Поверьте, опыт большой — не зря советую. И себе и другим единая точка входа облегчает жизнь. И сильно.
Поверьте, опыт большой — не зря советую. И себе и другим единая точка входа облегчает жизнь. И сильно.
давайте отделять мух от котлет. единая точка входа имеет как преимущества, так и недостатки. преимущества вы назвали. главным из них является удобство для программиста и реализация модульности фреймворка. а теперь посчитайте недостатки. в виде (не редко) бесполезно загружаемых библиотек, заметного роста потребления памяти…
Опять же php не так эффективно потребялет ресурсы как mod_rewrite. так что для проекта имеющего большую нагрузку вы скорее всего будете рады написать правила для rewrite которые разрулят обращения к максимально урезанным скриптам.
Опять же php не так эффективно потребялет ресурсы как mod_rewrite. так что для проекта имеющего большую нагрузку вы скорее всего будете рады написать правила для rewrite которые разрулят обращения к максимально урезанным скриптам.
НЛО прилетело и опубликовало эту надпись здесь
Загрузку библиотек надо делать с умом — и все будут довольны.
Естественно PHP не настолько быстр как mod_rewrite. Но знаете что? Под нагрузкой и апач весьма убойная штука. Потому оно у меня бегало бы на nginx/lighttpd + fastcgi. А в таком случае я бы долго проклинал того разработчика, благодаря которому я бы сидел и давился над регекспами при переводе их для nginx/lighttpd.
Естественно PHP не настолько быстр как mod_rewrite. Но знаете что? Под нагрузкой и апач весьма убойная штука. Потому оно у меня бегало бы на nginx/lighttpd + fastcgi. А в таком случае я бы долго проклинал того разработчика, благодаря которому я бы сидел и давился над регекспами при переводе их для nginx/lighttpd.
Лучше сравнить не с личным домом(для домашней стринички это нормально да)…
лучше сравнить с гипермаркетом типа АШАН…
Приедставьте что там 1 касса…
лучше сравнить с гипермаркетом типа АШАН…
Приедставьте что там 1 касса…
Можно добавить нужные пути в include_path
Получить абс. путь к директории, в которой находится скрипт, можно так:
$dir = dirname(__FILE__);
Абсолютные пути бывают лучше относительных. Не всегда можно быть уверенным, что та или иная базовая директория (ну, например, "." — текущая директория) указана в include_path. Кроме того, поиск относительного пути в include_path — это медленнее, нежели точно указать абсолютный путь. Впрочем, такая спичечная экономия часто не нужна.
$dir = dirname(__FILE__);
Абсолютные пути бывают лучше относительных. Не всегда можно быть уверенным, что та или иная базовая директория (ну, например, "." — текущая директория) указана в include_path. Кроме того, поиск относительного пути в include_path — это медленнее, нежели точно указать абсолютный путь. Впрочем, такая спичечная экономия часто не нужна.
На сервере практически все проекты на CMS Битрикс.
А он требует правильного ДОКРУТа…
Притом мне нравится такой подход… это даёт затруднения только при кривых конфигах и если проект лежит не в корне…
А он требует правильного ДОКРУТа…
Притом мне нравится такой подход… это даёт затруднения только при кривых конфигах и если проект лежит не в корне…
Упаси Бог меня работать с Битрикс :)
Отчего так?
Слышу много негативных отзывов… но считаю что это просто от ленности поковырять и разобраться.
Если Битрикс изучить то он становится лучшим другом.
Я разрабатываю преимущественно под него уже около 4х лет… ещё с 3ей версии…
Слышу много негативных отзывов… но считаю что это просто от ленности поковырять и разобраться.
Если Битрикс изучить то он становится лучшим другом.
Я разрабатываю преимущественно под него уже около 4х лет… ещё с 3ей версии…
Проприетарный тяжелый, неподъемный, да много чего есть у его.
Что можно сделать на нем, чего нельзя сделать на том же Друпале?
А если человек знаком с ZF\Cake\etc то передним вообще нет преград.
Как можно разработать web-service на основе Битрикс?
Вообщем, флейм это все.
Что можно сделать на нем, чего нельзя сделать на том же Друпале?
А если человек знаком с ZF\Cake\etc то передним вообще нет преград.
Как можно разработать web-service на основе Битрикс?
Вообщем, флейм это все.
Думаю не стоит действительно разводить флейм на эту тему :) Везде свои плюсы везде свои минусы )
Про Битрикс напишу пару статей когда получу инвайт. Возможно чтото проясниться.
Про Битрикс напишу пару статей когда получу инвайт. Возможно чтото проясниться.
Вообщем, Вы знаете, не совсем правильно говорить «то можно сделать на нем, чего нельзя сделать на том же Друпале?».
Т.е. это совсем не правильно. Это похоже на юношеский максимализм (надеюсь на адекватное восприятие).
Есть инструмент, компании с помощью него решают свои задачи. Все довольны.
Т.е. это совсем не правильно. Это похоже на юношеский максимализм (надеюсь на адекватное восприятие).
Есть инструмент, компании с помощью него решают свои задачи. Все довольны.
Назовите мне 3 солидных компании.
ИМХО компании покупающие Битрикс, хотят сэкономить на разработчиках.
Чем отличается Битрикс от любой другой CMS?
Монструозностью разве что.
Битрикс — закрытая система, что мне уже не нравится.
ИМХО компании покупающие Битрикс, хотят сэкономить на разработчиках.
Чем отличается Битрикс от любой другой CMS?
Монструозностью разве что.
Битрикс — закрытая система, что мне уже не нравится.
> ИМХО компании покупающие Битрикс, хотят сэкономить на разработчиках.
И что в этом не правильного?
> Назовите мне 3 солидных компании.
Зайдите на битрикс и посмотрите в клиентах.
Я вообще на битрикс не работаю, и даже на php не пишу.
Я Вам не говорю про конкретные системы что либо. Я лишь говорю что говорить «то можно сделать на нем, чего нельзя сделать на том же Друпале?» не правильно.
И что в этом не правильного?
> Назовите мне 3 солидных компании.
Зайдите на битрикс и посмотрите в клиентах.
Я вообще на битрикс не работаю, и даже на php не пишу.
Я Вам не говорю про конкретные системы что либо. Я лишь говорю что говорить «то можно сделать на нем, чего нельзя сделать на том же Друпале?» не правильно.
Если можно сделать такой же продукт на другой CMS, то зачем платить за Битрикс?
На разработчиках нельзя экономить ;)
На разработчиках нельзя экономить ;)
Ваша позиция однобока.
Конечно однобока! Это позиция разработчика :)
Вот скажите, почему rutube не на битриксе? Почему vkontakte.ru не на битриксе?
Потому, что неудобно и не гибко.
Хотя с них станется сделать дистрибутив: «1С-Битрикс: Видео-портал», «Запустите свой youtube за 4 часа!»
Может быть со стороны менеджеров и прочего начальства это и хорошо, но со стороны разработчика (во всяком случае с моей), это плохо.
Каждый проект ИМХО должен быть написан именно под него.
Вот скажите, почему rutube не на битриксе? Почему vkontakte.ru не на битриксе?
Потому, что неудобно и не гибко.
Хотя с них станется сделать дистрибутив: «1С-Битрикс: Видео-портал», «Запустите свой youtube за 4 часа!»
Может быть со стороны менеджеров и прочего начальства это и хорошо, но со стороны разработчика (во всяком случае с моей), это плохо.
Каждый проект ИМХО должен быть написан именно под него.
> Конечно однобока!
О чем вообще можно с Вами разговаривать?
Тем более я об одном, вы о другом.
Прощайте.
p.s.
Кстати, для справки, в интернете много больше сайтов.
О чем вообще можно с Вами разговаривать?
Тем более я об одном, вы о другом.
Прощайте.
p.s.
Кстати, для справки, в интернете много больше сайтов.
Вы правы. Битрикс это система для решения только 95% задач…
Притом задач корпоративных заказчиков.
Я с Вами абсолютно согласен, что не стоит разрабатывать на Битрикс эксклюзивные проекты. Эксклюзивные проекты лучше разрабатывать с нуля используя какиелибо фрэймворки.
У Битрикса свои задачи :) Это корпоративные сайты, интернет магазины, порталы… не более…
Притом задач корпоративных заказчиков.
Я с Вами абсолютно согласен, что не стоит разрабатывать на Битрикс эксклюзивные проекты. Эксклюзивные проекты лучше разрабатывать с нуля используя какиелибо фрэймворки.
У Битрикса свои задачи :) Это корпоративные сайты, интернет магазины, порталы… не более…
За Битрикс платят потому, что это хорошо отлаженный бизнес.
И в ситуации, когда не понравилась одна фирма, поддерживающая сайт компании, сайт безболезненно переходит на поддержку к другой фирме, потому что другая фирма знает эту платформу и не начнет вытворять чудеса переноса сайта на никому не известную платформу.
А в остальном битрикс ничуть не лучше всех остальных говно CMS.
Все равно под большие нагрузки пишут специализированный софт, работающий на кластере серверов…
Хотя, если все закешировать на фронтэндах, то и битрикс можно использовать в качестве генератора…
PS: На битриксе ничего не делаю по причине аллергии к PHP.
И в ситуации, когда не понравилась одна фирма, поддерживающая сайт компании, сайт безболезненно переходит на поддержку к другой фирме, потому что другая фирма знает эту платформу и не начнет вытворять чудеса переноса сайта на никому не известную платформу.
А в остальном битрикс ничуть не лучше всех остальных говно CMS.
Все равно под большие нагрузки пишут специализированный софт, работающий на кластере серверов…
Хотя, если все закешировать на фронтэндах, то и битрикс можно использовать в качестве генератора…
PS: На битриксе ничего не делаю по причине аллергии к PHP.
Закрытая??? Т.е.? Исходники у меня все есть… они выдаются при покупке лицензии…
Компании покупающие Битрикс? Махаон, QSoft это те с которыми я лично сотрудничал.
А вообще студий более 2500(две с половиной тысячи): www.1c-bitrix.ru/partners/index.php
Это разработчики! Т.е. каждый из них разработал КАК МИНИМУМ 1 проект.
Кстати разработка на битрикс — ДОРОГАЯ! :) Тем и живём.
Чтобы понять плюсы Битрикса нужно его понять…
Вот чем отличается C# от любого другого языка программирования? )
Битрикс лично мне предоставляет удобный framework и сильную гибкость… а клиенту — удобную админку.
Но вообще — всё это офтопик. Пост про многосайтовый сервер :) В частности и для Битрикс как для неповоротливой ресурсоёмнкой и капризной CMS.
Компании покупающие Битрикс? Махаон, QSoft это те с которыми я лично сотрудничал.
А вообще студий более 2500(две с половиной тысячи): www.1c-bitrix.ru/partners/index.php
Это разработчики! Т.е. каждый из них разработал КАК МИНИМУМ 1 проект.
Кстати разработка на битрикс — ДОРОГАЯ! :) Тем и живём.
Чтобы понять плюсы Битрикса нужно его понять…
Вот чем отличается C# от любого другого языка программирования? )
Битрикс лично мне предоставляет удобный framework и сильную гибкость… а клиенту — удобную админку.
Но вообще — всё это офтопик. Пост про многосайтовый сервер :) В частности и для Битрикс как для неповоротливой ресурсоёмнкой и капризной CMS.
«редкостное зло»?
а я вот конфиги и прочее которые у меня над htdocs на уровень выше висят вот так подключаю, к примеру так: (ну, не совсем так, я утрирую)
$foo = include(dirname($_SERVER['DOCUMENT_ROOT']). "/req/config.inc.php");
И что мне, в случае смены сервера вручную переделывать проекты?
а я вот конфиги и прочее которые у меня над htdocs на уровень выше висят вот так подключаю, к примеру так: (ну, не совсем так, я утрирую)
$foo = include(dirname($_SERVER['DOCUMENT_ROOT']). "/req/config.inc.php");
И что мне, в случае смены сервера вручную переделывать проекты?
В config.php ежели он лежит в корне сайта, вполне можно прописать
$_SERVER[«DOCUMENT_ROOT»] = dirname(__FILE__)
$_SERVER[«DOCUMENT_ROOT»] = dirname(__FILE__)
Меня всегда спасает такая вот конструкция:
$inc_path = 'путь'; // если не нравится $_SERVER[«DOCUMENT_ROOT»] его можно вырезать например из __FILE__
set_include_path(get_include_path().PATH_SEPARATOR.$inc_path);
После этого скрипт ищет файлы именно там, где нужно.
$inc_path = 'путь'; // если не нравится $_SERVER[«DOCUMENT_ROOT»] его можно вырезать например из __FILE__
set_include_path(get_include_path().PATH_SEPARATOR.$inc_path);
После этого скрипт ищет файлы именно там, где нужно.
«Модель системы: linux -> nginx -> apache -> php -> mysql.»
Пытался представить логику, сломал голову :)
Пытался представить логику, сломал голову :)
Запрос получает Линукс… ) отправляет в Nginx и т.д…
Да вы что, а nginx висит на 80 порту и не подозревает, что запросы приходят ему совсем с другого конца…
Продолжайте в том же духе :)
Продолжайте в том же духе :)
Ну строго говоря nginx висит там потому что эту возможность дает ему система. В данном случае linux.
В моем случае еще была проблема с субдоменом www.
www.example.com по хорошему должен вести в ту же папку что и example.com.
У себя решил так:
set $p $host;
if ($host ~ www\.(.*)) { set $p $1; }
location / {
proxy_pass 127.0.0.1:81/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $p;
}
location ~* ^.+\.(jpg|jpeg|gif|png|css|zip|tgz|gz|rar|bz2|doc|xl
root /home/htdocs/$p/www;
gzip on;
sendfile on;
}
www.example.com по хорошему должен вести в ту же папку что и example.com.
У себя решил так:
set $p $host;
if ($host ~ www\.(.*)) { set $p $1; }
location / {
proxy_pass 127.0.0.1:81/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $p;
}
location ~* ^.+\.(jpg|jpeg|gif|png|css|zip|tgz|gz|rar|bz2|doc|xl
root /home/htdocs/$p/www;
gzip on;
sendfile on;
}
Для Апача можно использовать mod_macro — это для удобства.
А про конструкции типа «if (!-d /home/htdocs/$host/www ) {» в рассылке nginx-ru сообщали, что это — признак плохого тона, но если без этого никак нельзя — то можно.
А про конструкции типа «if (!-d /home/htdocs/$host/www ) {» в рассылке nginx-ru сообщали, что это — признак плохого тона, но если без этого никак нельзя — то можно.
Мне кажется, что нужно поискать решение без
php_admin_value auto_prepend_file /home/htdocs/fix_doc_root.php
php_admin_value auto_prepend_file /home/htdocs/fix_doc_root.php
и еще, по-моему, логи апача и нгинкса удобнее класть отдельно каждому домену в попапку Logs
НЛО прилетело и опубликовало эту надпись здесь
еще mod_rewrite может глючить при использовании mod_vhost_alias (причина все в том же docroot только тут его никак не поправить) :(
А зачем Вам apache? Может убрать его вообще и запустить PHP как FastCGI?
Толково, если доработать, то уже решение.
Очень полезный топик, но конфиги безжалостно покоцаны хабрапарсером.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мультидоменный сервер nginx -> apache