Комментарии 24
И всё это добро упаковать в phar
Вот интересно уже вышла PHP 5.4.8 кто-то реально юзает этот встроенный сервер в разработке? Опоздали с этой фичей лет на 10. Уже даже на винде всё окружение поднимается в пару кликов (а в том же Open Server, можно еще и несколько веток софта держать для тестов).
На убунте поднять апач и настроить хосты до сих пор задача непростая и рутинная. На винде проще, да.
Ну вот и в случаях где хосты насраивать лениво, такой сервер штука вполне удобная. Но пока ещё слабая и глючная, да.
Ну вот и в случаях где хосты насраивать лениво, такой сервер штука вполне удобная. Но пока ещё слабая и глючная, да.
Рутинная? Для себя давно решил это дело так:
echo «address=/.dev/127.0.0.1» >> /etc/dnsmasq.conf
в конфиге nginx'a:
server_name "~^(?.+)\.dev$";
root /usr/share/nginx/$domain;
Всё. Любая дира в /usr/share/nginx/directory доступна по адресу directory.dev. Никаких телодвижений.
echo «address=/.dev/127.0.0.1» >> /etc/dnsmasq.conf
в конфиге nginx'a:
server_name "~^(?.+)\.dev$";
root /usr/share/nginx/$domain;
Всё. Любая дира в /usr/share/nginx/directory доступна по адресу directory.dev. Никаких телодвижений.
Ну отлично, что у вас есть лайфаки, у меня лично их нет.
Кроме того, иногда нужно на гостевой системе что-то запустить. Там тоже сервер становится удобной штукой.
Также, я не представляю как без него тестировать веб проекты через тот же Travis-CI.
Кроме того, иногда нужно на гостевой системе что-то запустить. Там тоже сервер становится удобной штукой.
Также, я не представляю как без него тестировать веб проекты через тот же Travis-CI.
На убунте поднять апач и настроить хосты до сих пор задача непростая и рутинная. На винде проще, да.Отсыпьте. Нужно всего поставить один пакет и сделать несколько вариаций sites-enabled/000-default, в самом простом случае. Для тестирования одного веб-приложения можно вообще конфиги не править, а держать все в /var/www
# apt-get install apache2 libapache2-mod-php5
Я пользуюсь встроенным в PHP веб сервером с момента выхода 5.4
Для небольших проектов очень удобно. все распространенные фреймворки (Yii, Symfony, Zend) запускаются сразу же без дополнительных настроек.
Для небольших проектов очень удобно. все распространенные фреймворки (Yii, Symfony, Zend) запускаются сразу же без дополнительных настроек.
Хотел однажды использовать его для прогона UI-тестов через Zombie.js и столкнулся с тем, что этот самый отладочный сервер немилосердно выплёвывает segfault при любом отклонении от стандартного HTTP. В подробности не углублялся, похоже что это вина zombie.js, однако сегфолт вебсервера от ошибки протокола клиента — некрасивый поступок
Спасибо за анонс.
Только вот глаз режет — в скрипте start.sh вместо $(pwd) стоит использовать $(dirname $0), а ещё лучше $(dirname $(readlink -f $0)). В последнем случае мы всегда будем иметь дело с абсолютными путями, хотя и упрщённый способ тоже действует прекрасно. Т.о. мы не привязаны к выполнению скрипта именно из его каталога.
Только вот глаз режет — в скрипте start.sh вместо $(pwd) стоит использовать $(dirname $0), а ещё лучше $(dirname $(readlink -f $0)). В последнем случае мы всегда будем иметь дело с абсолютными путями, хотя и упрщённый способ тоже действует прекрасно. Т.о. мы не привязаны к выполнению скрипта именно из его каталога.
>Со встроенным web-сервером я могу протестировать приложение прямо из папки «downloads» или временной папки и переместить в обычную среду, только тогда, когда это будет необходимо.
К сожалению большинство современных WEB-приложений требуют специфичный .htaccess, а я активно использую специфичный nginx.conf
твоя статья позновательна и полезна, но не является серебряной пулей, как ты ее представил
К сожалению большинство современных WEB-приложений требуют специфичный .htaccess, а я активно использую специфичный nginx.conf
твоя статья позновательна и полезна, но не является серебряной пулей, как ты ее представил
Пишете РНР 5.4, а до сих пор используете dirname(__FILE__). Есть же __DIR__
Встроенный веб-сервер удобно использовать, когда есть кучка мелких проектов, под которые нет необходимости настраивать отдельные vhost'ы. Или разные ветки одного проекта, которые удобнее держать в отдельных папках, а не переключать внутри одного докрута.
Я рельсовый вебрик с самого его появления так использую, и то, что такой сервер наконец появился в PHP — это прекрасно. Не прошло и 10 лет, действительно =)
Я рельсовый вебрик с самого его появления так использую, и то, что такой сервер наконец появился в PHP — это прекрасно. Не прошло и 10 лет, действительно =)
Прочел статью, где преимущества? Может для «hello world» то да, для мало мальского проекта это бесполезная хрень.
Преимущества перед чем? Перед поднятием связки ngninx+php-fpm или apache+mod-php локально? Плюс виртхосты для каждого проекта?
Пост называется «Использование преимуществ встроенного PHP сервера» вот и у меня возникает вопрос — перед чем?
то же самое но другими словами habrahabr.ru/post/155853/#comment_5323505
Вначале чтения подумал, что спрятать бы это dev-веб-сервер за nginx-ом, и получим… что-то такое, более похожее на живое решение.
Но — заголовки (их отсутствие), привычка делать segfault (вместо самостоятельного выкручивания из проблемы и вывода юзеру сообщения о том, что же не так) — все это нифига не смотрится на чем-то отличном от 127.0.0.1/hello_world.php. Мне php-fpm ближе :)
Но — заголовки (их отсутствие), привычка делать segfault (вместо самостоятельного выкручивания из проблемы и вывода юзеру сообщения о том, что же не так) — все это нифига не смотрится на чем-то отличном от 127.0.0.1/hello_world.php. Мне php-fpm ближе :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование преимуществ встроенного PHP сервера