Как говорится - "баян", наверное, но таки для меня стало новостью )
Недавно копал параметры запуска PHP с командной строки и с удивлением обнаружил, что в интерпретатор PHP ещё аж с 5.4.0 встроен собственный простенький HTTP-сервер: http://php.net/manual/ru/features.commandline.webserver.php
Встроен в CLI-версию интерпретатора (т.е. версию для парсинга через интерфейс командной строки). Запуск сервера через параметр -S с указанием любого порта:
$ php -S localhost:8000
и/или доменного имени, а также корневой директории (параметр -t), а также с собственным (не глобальным) php.ini
$ php -S somedomain:8000 -t my_root_folder/ -c php.ini
Побаловавшись немного, выяснил, что:
- phpinfo() показывает Server API: Built-in HTTP server , а php_sapi_name() показывает cli-server
- работает быстро, быстрее Apache(впрочем в ущерб привычному функционалу апача, типа mod_rewrite, ограничение доступа и т.д.).
- сервер слушает только один домен и один порт
- DOCUMENT_ROOT и, возможно, какие-то другие переменные апача отсутствуют, поэтому нужно их предварительно устанавливать используя .bat или .sh (если планируется их использование из php-кода)
- Drupal запускать на нём не пробовал, если что )
Практическое (в смысле - серьёзное) применение этого сервера под сомнением, конечно. Собственно, в документации написано, что сервер встроен только для тестовых нужд. Однако, в некоторых случаях фича может позволить держать в "одном флаконе" какую-то ограниченную по функционалу демонстрационную сборку или "мобильный" набор утилит, написанных на PHP и запускать на машине, пока не имеющей установленной связки AMP. В совокупности с sqlite можно сделать даже ещё один шаг вперёд, подключив SQL )
Комментарии
https://drushcommands.com/drush-8x/runserver/runserver/
О, как! Не обращал внимание на эту команду. Ну и как D себя чувствует на таком сервере?
Для разработки, в принципе, хватает.
Знаю точно, что некоторые именно этот сервер и используют для работы с проектом. Лично я - по старинке, с апачиком.
Просто первое, с чём я столкнулся - не инициализированная переменная DOCUMENT_ROOT (я запускал под Windows). Поэтому как бы были сомнения, что сервер обрабатывает и выставляет всё необходимое для Друпала окружение.
Под Win нет возможности проверить. На лине - отрабатывает на ура (ПЫХ 7.1, fpm, Ubuntu).
На всякий спрошу: в корне Друпала запускаете команду?
Да.
Значит у сервера что-то не бьет.
я обычно для разработки держу виртуальную машину с настроенным сервером, как то опенсервер перестал удовлетворять нуждам да под виндой не весь инструментарий работает как надо, так что все таки под винду виртуалка это спасение.
В последнее время работаю чаще под windows. Не использую ни openserver, ни denver, ни прочие all-in-one пакеты. Все сервера и компоненты поставлены и настроены вручную по отдельности. Каких-либо серьёзных проблем пока не отмечал, кстати.
Хотя согласен, что под линуксом веб разработка таки кошернее по ряду параметров.
Да, как уточнил Антон:
drush rs
И можно спокойно работать с экземпляром друпал через веб.
Локально, только так и делаю,
отдельный виртуальный хост для nginx поднимаю очень редко.
Возможно, имеет смысл при запуске явно указать абсолютный путь к корню ключем
--root=/PATH/TO/DRU
А вариант дружить их с browser-sync'ом? У меня так-то проксируется локалхостик, и можно малювать.
я вообще больше про такой подход думаю:
https://github.com/manuelro/webpack-everest
https://github.com/wieni/drupack
Крутецкие штуки - пасиба!
Я с drush-версией пока не экспериментировал, все написанное относится к CLI SAPI в чистом виде. Там ключ -t. Ну то есть - да, пробовал.
Повторюсь, это может быть баг только win-версии. Я просто установил DOCUMENT_ROOT вручную перед запуском сервера.