Verification: a143cc29221c9be0

Openserver путь к php интерпретатору

Openserver путь к php интерпретатору

Цветовые схемы

Monokai
Atom Dark Fusion
Base16 Tommorow Dark

В Notepad++ по умолчанию используется светлая цветовая схема, в Atom – темная. Надо признать, в Atom при темной схеме работать приятнее (лично мне). Но вот сама подсветка синтаксиса по умолчанию не понравилась. Поэтому я установил цветовую схему Monokai – самое оно!

Также отличные, на мой взгляд, цветовые схемы Atom Dark Fusion и Base16 Tommorow Dark – но в сравнении с Monokai они приглушены; Monokai имеет более выраженный цветовой контраст.

Выделение


Подсветка совпадений с выделением в Notepad++

В Notepad++  (и в Sublime Text, разумеется) есть удобная возможность – подсветка всех совпадений с выделением.

Чтобы подобное заработало и в Атом, надо установить пакет highlight-selected.

Подсветка совпадений в Atom

Иконки файлов


Иконки файлов

После установки пакета File Icons у файлов разных типов в дереве и в панели возле названий появляются свои иконки, что заметно упрощает навигацию.

Чтобы в дереве иконки выводились серым цветом, надо в настройках пакета установить опцию "On Changes" (отображать цветом только изменившиеся файлы).

Удаленное редактирование

Пакет Remote-FTP позволяет редактировать файлы по FTP/FTPS/SFTP (точнее, подключаться к серверу по указанным протоколам, скачивать файл, локально редактировать и загружать обратно на сервер при записи файла).

Миникарта

Миникарта 

Чтобы получить миникарту документа, как в Sublime Text (кстати, в Notepad++ она тоже есть), надо установить пакет Minimap. После установки сразу в настройках пакета задайте параметр Char Height в 1 (т.е. 1px, по умолчанию стоит 2) - и на карту будет помещаться заметно большая часть документа.

К слову, Minimap очень сильно упрощает быстрое передвижение внутри объемного документа. Медленное передвижение удобно выполнять с помощью колеса прокрутки мыши, а вот для быстрого передвижения сам Atom приспособлен плохо - у него узкая полоса скорллинга, и чтобы захватить ее надо хорошо прицеливаться курсором.

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

Проверка синтаксиса

Проверка синтаксиса в Atom

Atom - больше, чем просто редактор. Его функциональность зависит от установленных модулей (т.е. пакетов).

Одна из полезных возможностей - проверка синтаксиса. Другими словами, Atom может выводить предупреждения, когда находит ошибки в вашем коде (для примера на рисунке показана ошибка в коде JavaScript - лишняя фигурная скобка).

Чтобы Atom мог проверять синтаксис, вначале надо установить пакет Linter - это базовый пакет, он используется для проверки синтаксиса другими пакетами, под конкретный язык.

Ну а далее, надо ставить пакет под тот язык, который вам нужен, для примера:

  • CSS - linter-csslint
  • JavaScript - linter-jshint
  • PHP - linter-php

Стоит отметить, что пакет проверки синтаксиса PHP требует установленного PHP (в настройках пакета можно указать путь к исполняемому файлу PHP, это на тот случай, если вы не хотите прописывать данный путь в переменные среды окружения).

Кстати, на Хабре есть отличная статья, в которой рассказано об установке линтеров для Atom под разные языки программирования, включая C/C++, Python, Ruby и Java. В ней же рассказано и о том, как запускать написанный код прямо из Atom.

1: Установка PHP 7.3 и PHP 7.4

Выполнив предварительные требования к мануалу, мы можем установить PHP версий 7.3 и 7.4, а также PHP-FPM и несколько дополнительных расширений. Чтобы установить несколько версий PHP на один сервер, необходимо установить и включить репозиторий Remi. Этот репозиторий предлагает последние версии стека PHP для системы CentOS 8.

Вы можете добавить репозиторий в свою систему, используя следующую команду:

sudo dnf install http://rpms.remirepo.net/enterprise/remi-release-8.rpm

Приведенная выше команда также активирует репозиторий EPEL.

Сначала давайте узнаем, какие версии PHP 7 доступны в Remi:

sudo dnf module list php

Вы увидите такой результат:

Remi's Modular repository for Enterprise Linux 8 - x86_64
Name                     Stream                       Profiles                                       Summary

php                      remi-7.2                     common [d], devel, minimal                     PHP scripting language


php                      remi-7.3                     common [d], devel, minimal                     PHP scripting language


php                      remi-7.4                     common [d], devel, minimal                     PHP scripting language

Теперь отключите стандартный модуль PHP и активируйте модуль PHP7.3 из Remi:

sudo dnf module reset php
sudo dnf module enable php:remi-7.3

Давайте установим php73 и php73-php-fpm:

sudo dnf install php73 php73-php-fpm -y

  • php73 – это метапакет, который можно использовать для запуска приложения PHP.
  • php73-php-fpm предоставляет интерпретатор Fast Process Manager, который работает как демон и принимает запросы Fast/CGI.

Теперь повторите весь процесс для PHP версии 7.4. Установите php74 и php74-php-fpm.

sudo dnf module reset php
sudo dnf module enable php:remi-7.4
sudo dnf install php74 php74-php-fpm -y

После установки обеих версий PHP запустите сервис php73-php-fpm и включите его в автозагрузку с помощью следующих команд:

sudo systemctl start php73-php-fpm
sudo systemctl enable php73-php-fpm

Затем проверьте статус сервиса php73-php-fpm с помощью следующей команды:

sudo systemctl status php73-php-fpm

Вы увидите следующий результат:

php73-php-fpm.service - The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php73-php-fpm.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2020-04-22 05:14:46 UTC; 52s ago
Main PID: 14206 (php-fpm)
Status: "Processes active: 0, idle: 5, Requests: 0, slow: 0, Traffic: 0req/sec"
Tasks: 6 (limit: 5059)
Memory: 25.9M
CGroup: /system.slice/php73-php-fpm.service
├─14206 php-fpm: master process (/etc/opt/remi/php73/php-fpm.conf)
├─14207 php-fpm: pool www
├─14208 php-fpm: pool www
├─14209 php-fpm: pool www
├─14210 php-fpm: pool www
└─14211 php-fpm: pool www
Apr 22 05:14:46 centos-s-1vcpu-1gb-nyc3-01 systemd[1]: Starting The PHP FastCGI Process Manager...
Apr 22 05:14:46 centos-s-1vcpu-1gb-nyc3-01 systemd[1]: Started The PHP FastCGI Process Manager.

Повторите этот процесс для версии 7.4; запустите сервис php74-php-fpm и добавьте его в автозагрузку с помощью следующих команд:

sudo systemctl start php74-php-fpm
sudo systemctl enable php74-php-fpm

А затем проверьте состояние сервиса php74-php-fpm с помощью следующей команды:

sudo systemctl status php74-php-fpm

Вы увидите следующий результат:

php74-php-fpm.service - The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php74-php-fpm.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2020-04-22 05:16:16 UTC; 23s ago
Main PID: 14244 (php-fpm)
Status: "Processes active: 0, idle: 5, Requests: 0, slow: 0, Traffic: 0req/sec"
Tasks: 6 (limit: 5059)
Memory: 18.8M
CGroup: /system.slice/php74-php-fpm.service
├─14244 php-fpm: master process (/etc/opt/remi/php74/php-fpm.conf)
├─14245 php-fpm: pool www
├─14246 php-fpm: pool www
├─14247 php-fpm: pool www
├─14248 php-fpm: pool www
└─14249 php-fpm: pool www
Apr 22 05:16:15 centos-s-1vcpu-1gb-nyc3-01 systemd[1]: Starting The PHP FastCGI Process Manager...
Apr 22 05:16:16 centos-s-1vcpu-1gb-nyc3-01 systemd[1]: Started The PHP FastCGI Process Manager.

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

2: Создание структуры каталогов для сайтов

Теперь мы создадим корневые каталоги для каждого сайта, который будет развернут на этом сервере. В нашем мануале мы развернем 2 сайта: site1.your_domain и site2.your_domain. Создавая каталоги, укажите домены ваших сайтов.

sudo mkdir /var/www/site1.your_domain
sudo mkdir /var/www/site2.your_domain

По умолчанию веб-сервер Apache запускается как пользователь и группа apache. Чтобы убедиться, что права собственности и доступа на корневые каталоги сайтов установлены верно, выполните следующие команды:

sudo chown -R apache:apache /var/www/site1.your_domain
sudo chown -R apache:apache /var/www/site2.your_domain
sudo chmod -R 755 /var/www/site1.your_domain
sudo chmod -R 755 /var/www/site2.your_domain

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

Затем внутри каждого корневого каталога мы создадим файл info.php. Позже он поможет нам отобразить информацию о версии PHP каждого веб-сайта. Начните с site1:

sudo vi /var/www/site1.your_domain/info.php

Добавьте в файл следующую строку:

php phpinfo(); ?>

Сохраните и закройте файл. Теперь скопируйте созданный вами файл info.php для site2:

sudo cp /var/www/site1.your_domain/info.php /var/www/site2.your_domain/info.php

Теперь у вас есть корневые каталоги, необходимые каждому сайту для обслуживания данных. Затем мы настроим свой веб-сервер Apache для поддержки двух разных версий PHP.

3: Настройка Apache для поддержки двух сайтов

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

Чтобы Apache обслуживал этот контент, необходимо создать файл виртуального хоста с правильными директивами. Вы создадите два новых файла конфигурации виртуального хоста в каталоге /etc/httpd/conf.d/.

Сначала создайте новый конфигурационный файл виртуального хоста для сайта site1.your_domain. Здесь мы настроим Apache для обработки контента с помощью php7.3.

sudo vi /etc/httpd/conf.d/site1.your_domain.conf

Вставьте в файл такие строки. Убедитесь, что вы указали правильный путь к корневому каталогу, ServerName и версию PHP.


ServerAdmin admin@site1.your_domain
ServerName site1.your_domain
DocumentRoot /var/www/site1.your_domain
DirectoryIndex info.php
ErrorLog /var/log/httpd/site1.your_domain-error.log
CustomLog /var/log/httpd/site1.your_domain-access.log combined


SetHandler "proxy:unix:/var/opt/remi/php73/run/php-fpm/www.sock|fcgi://localhost"


В DocumentRoot укажите путь к корневому каталогу вашего веб-сайта. В ServerAdmin укажите адрес электронной почты для администратора сайта your_domain. В директиве ServerName определяется URL-адрес первого поддомена. В SetHandler нужно задать файл сокета PHP-FPM для php7.3.

Сохраните и закройте файл.

Затем создайте новый конфигурационный файл виртуального хоста для сайта site2.your_domain. Этот поддомен будет обслуживаться версией php7.4.

sudo vi /etc/httpd/conf.d/site2.your_domain.conf

Добавьте следующий код в файл. Убедитесь, что путь к корневому каталогу, ServerName и версия PHP соответствуют вашей конфигурации.


ServerAdmin admin@site2.your_domain
ServerName site2.your_domain
DocumentRoot /var/www/site2.your_domain
DirectoryIndex info.php
ErrorLog /var/log/httpd/site2.your_domain-error.log
CustomLog /var/log/httpd/site2.your_domain-access.log combined


SetHandler "proxy:unix:/var/opt/remi/php74/run/php-fpm/www.sock|fcgi://localhost"


Сохраните и закройте файл. Затем проверьте конфигурации Apache на наличие синтаксических ошибок с помощью следующей команды:

sudo apachectl configtest

Если ошибок нет, вы увидите вывод:

Syntax OK

Теперь можно перезапустить сервис Apache, чтобы изменения вступили в силу:

sudo systemctl restart httpd

Теперь, когда мы настроили Apache для обслуживания каждого сайта, мы должны протестировать их, чтобы убедиться, что все работает правильно.

4: Тестирование настройки

Итак, мы уже настроили два веб-сайта, которые работают на двух разных версиях PHP. Давайте проверим результаты.

Откройте браузер и посетите оба сайта.

http://site1.your_domain
http://site2.your_domain

Вы увидите две страницы с информацией о PHP. Обратите внимание на заголовки этих страниц. На первой странице указано, что site1.your_domain использует PHP версии 7.3. Вторая страница сообщает, что site2.your_domain развернул PHP версии 7.4.

Теперь, когда вы проверили свои сайты, удалите файлы info.php. Они содержат конфиденциальную информацию о вашем сервере и доступны неавторизованным пользователям – следовательно, они представляют собой уязвимость системы безопасности. Чтобы удалить оба файла, выполните следующие команды:

sudo rm -rf /var/www/site1.your_domain/info.php
sudo rm -rf /var/www/site2.your_domain/info.php

Теперь у вас есть сервер CentOS 8, обслуживающий два веб-сайта с двумя разными версиями PHP.

Вступительный урок. Что нужно для начала работы с PHP

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

Что нужно знать

  1. Перед началом изучения PHP, я бы порекомендовал вам изучить HTML.

  2. Также нужно знать как записывается PHP. В файле, PHP скрипт начинается со слова - . Все, что между это PHP код, запомните это.

  3. Файлы, в котором записан PHP код нужно сохранять под расширением .php

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

Программное обеспечение

  1. Первая программа, которая вам нужна, это браузер (то, в чем Вы сейчас находитесь :D)

  2. Веб-сервер. Для локального тестирования вам нужно установить веб-сервер. Я рекомендую поставить Open Server (Mini версии будет достаточно). Как установить Open Server. Open Server является портативным, т.е. вам нужно только разархивировать скачанный архив и запустить сервер через Open Server.exe. После старта программы вы увидите красный флажок в трее Windows (область возле системных часов). Чтобы включить непосредственно сам веб-сервер нажмите на флажок, далее выберите пункт меню Запустить.

    Чтобы создать новый домен вам нужно перейти в папку OpenServer/domains и создать папку с подходящим для вас названием, после создания новой папки нужно перезагрузить веб-сервер (нажать на флажок в трее, нажать Перезагрузить). После чего вы сможете получить доступ к своему локальному домену по адресу http://yourdomain

    Убедитесь, что в Open Server есть права на редактирование Windows hosts файла. Некоторые антивирусы могут блокировать доступ к этому файлу. В противном случае, вы не сможете создать локальные домены.

  3. Последняя программа, которая потребуется, это блокнот, он нужен для редактирования PHP кода. Но, я рекомендую поставить вам Notepad++ или Sublime Text, это лучше чем использовать обычный блокнот Windows.

После уроков

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

Если вы уже установили все необходимое программное обеспечение, то можете переходить к первому уроку

Уроки PHP. Урок 1. Начало работы, установка

Как начать работать с PHP?

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

Иначе говоря, существует целая область знаний обычно получаемых только с помощью практики. Я имею в виду особенности конкретной среды разработки, редактора, сферы запуска ваших приложений. Узкая привязанность всего этого дела к вашей личной деятельности понятна, — каждому присуще свое понимание мира и его особенностей. И программирование на PHP не стоит каким-то особняков среди этого всего буйства красок индивидуального мировосприятия.

Действительно, существует целая куча средств разработки, которые позволяют выполнить скрипт, получить результат. Однако некоторые из них громоздки, другие — работают в какой-то определенной операционной системе, и просто не переносятся в другие оболочки. Поэтому, я всегда рекомендую выбирать из всех средств разработки — наиболее простые. Конечно, не идет речь о программировании в «блокноте», которое так часто стает неким ориентиром простоты. На самом деле такая разработка — крайне сложна, и требует опыта и долгих часов при поиске ошибок.

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

Я использую лично и почти всегда рекомендую минимально оснащенный текстовый редактор, который позволяет выделять синтаксис, производить подстановки текста по горячим клавишам, выполнять поиск. Идеально, когда ваша среда разработки позволяет подключаться к FTP/SSH серверам, поскольку такая возможность является базовой при работе с удаленными сайтами, для работы с которыми PHP и предназначается.

На данный момент на рабочих местах наиболее распространены ОС семейства «Виндовс», которые фактически мало чем друг от друга отличаются, было бы правильно рассказать о том, каким образом начать разработку, а точнее обучение разработке, именно в этой среде. не мудрствую лукаво я расскажу исключительно про личный опыт, то есть все приведенные ниже рекомендации будут иметь историю их применения на практике.

Разработка в Windows

В операционной системе Windows я много лет использую для работы FAR, — фактически бесплатный вариант файлового менеджера, который вместе с встроенными модулями для подсветки синтаксиса позволяет довольно таки продуктивно работать над PHP скриптами. Кроме того такое решение позволяет проводить редактирование одиночных файлов непосредственно на ФТП сервере.

Решение достаточно удобное потому, что оно бесплатное, далее оно быстро разворачиваемое, и имеет некий, пускай и достаточно далекий, аналог в мире UNIX (идет речь про Midnight Commander).

Установка среды разработки состоит в закачке последней версии редактора с сайта http://www.farmanager.com/ и его установки. После того, как вы установили данный редактор запустите его, перейдите на ваш основной диск Windows, с помощью сочетания клавиш «Alt+F1», и выбора диска С:\ . Перейдите в корень диска С («Ctrl + \») и создайте в нем каталог php (клавиша — F7), название указывайте маленькими латинскими буквами. Это крайне важно запомнить, что использование лишь латинских символов, при создании файлов позволит вам избежать массы проблем. Аналогично и с положением каталога c:\php\ — очень правильно размещать его в корневой папке вашего диска. Это обычный подход. Следует четко запомнить, что помещение php в каталог подобный «С:\Мои программы\ПХП\php» может создать массу проблем в дальнейшем.

Чтобы сделать вашу работу в FAR именно с интерпретатором PHP более комфортной загрузите с сайта farmanager.com расширение Colorer. Оно позволяет подсвечивать синтаксис файлов PHP и значительно упрощает отлов неизбежных ошибок.

Кроме того, чтобы запуск конкретного PHP скрипта происходил более комфортно, необходимо указать в менеджере FAR то, что файлы с расширением *.php — исполняются с помощью интерпретатора PHP. Для этого надо в меню «Команды — Ассоциации Файлов» ввести новое расширение *.php, и для команды выполняемой по Enter — указать «c:\php\php.exe -q !.!». Данная строка указывает на то, что при запуске PHP скрипта, например C:\php\src\script.php из FAR вы будете фактически выполнять команду c:\php\php.exe -q C:\php\src\script.php. То есть файловый менеджер немного упростит вам разработку, путем ускорения запуска скриптов.

Разработка в UNIX

Я осознаю, что существует некоторое количество читателей данной книги, которые пользуются разнообразными версиями UNIX, и для которых использование платных ОС — не подходит. Хочу вас уверить, что все примеры, которые работают на Windows, заработают и в UNIX.

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

Для запуска скриптов, из командной строки, на UNIX необходимо добавлять в начало каждого файла отдельной строкой — следующее #!/usr/bin/php -q, и конечно же присваивать им права исполнения, например, таким образом — chmod +x ./test.php . Обратите внимание на ключ -q в заголовке, — он означает, что интерпретатору предлагается вести себя «тихо», то есть не выдавать заголовки, которые не нужны.

Отмечу, что в приведенной выше строке, которую надо добавлять — /usr/bin/php — это нормальное положение интерпретатора в вашем UNIX. Однако если он расположен в другом месте, в начало файла нужно указывать правильное положение. Для уточнения этого местоположения  рекомендуется использовать команду which php.

Установка PHP в ОС Windows

Итак, вы создали каталог c:\php\, собственно в него необходимо закачать и распаковать, при необходимости, дистрибутив интерпретатора PHP. Сам он бесплатно доступен на сайте php.net, и находиться в разделе Downloads, вот по этому адресу — http://php.net/downloads.php.

Правильно будет скачать самую последнюю версию PHP для Windows. Скачанный файл надо распаковать в каталог c:\php\. В итоге в этом каталоге у вас должен появиться файл php.exe, пару подкаталогов, другие файлы системы.

Для целей тестирования PHP-скриптов создайте подкаталог c:\php\src\ и прямо в него размещайте ваши примеры. Фактически, все примеры, которые будут рассмотрены в этой книге, создавались именно в этом каталоге.

Называть скрипты необходимо латинскими символами, например, таким образом, — lesson_01_01.php или же lesson_02_03.php. Теперь вы всегда сможете найти нужный вам пример в процессе чтения книги.

Разные версии PHP

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

Необходимо четко понимать, что некоторые возможности более новых версий PHP, невозможны для применения в более старых версиях. На практике это означает, что разработку, которая ведется локально, потом бывает очень трудно адаптировать к возможностям конкретного веб-сервера, поскольку он использует более древнюю версию PHP. Так, например, много новых возможностей появилось в PHP 5, потом подобный всплеск был в PHP 5.3.1. Однако до сих пор много хостинговых компаний предоставляют поддержку лишь PHP 5.0, а некоторые из них вообще, — только PHP4.

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

Именно поэтому вы можете совершенно спокойно скачивать и устанавливать последнюю версию интерпретатора. Ведь PHP крайне универсален. Кстати, это также означает, что практически все примеры, написанные под OC Windows, будут работать и в Linux, да и в других ОС, например — FreeBSD, MacOS.

Чем отличается консольный запуск  от применения PHP в среде веб-сервера.

В плане синтаксиса — язык абсолютно идентичен. На веб, вы сможете оперировать с разнообразными входными данными, например с передаваемыми данными форм и URL скрипта. Это делается обычно с помощью функций, и операциями с массивами, поэтому не является чем-то особенным.

Отмечу, что данная книга опирается на практическое применение PHP, поэтому разницы между применением полученных навыков в разных сферах использования — PHP не будет. В том случае, если вам действительно важно сделать упор на проверку работоспособности примеров на Windows именно с помощью веб-сервера, можно порекомендовать использовать denwer (http://www.denwer.ru/), — пакета, содержащего, все необходимое для запуска веб-сервера и интерпретатора.

В случае UNIX возможность запуска веб-сервера является вполне обычной. Например, Apache в среде Debian устанавливается в одну команду apt-get install apache2. Поэтому, я не буду останавливаться на вопросах настройки www-сервера, а лишь порекомендую обратиться к специализированной литературе, в случае возникновения проблем.

В заключении

Путь изучения PHP от минимального уровня до уровня мастера — может занять всю вашу жизнь, чтобы немного ускорить этот процесс очень важно понимать, что не надо создавать себе препятствия в виде операционных систем, средств разработки. Все это — препятствия на пути постижения языка. Настоящий мастер может программировать и в текстовом редакторе vi, и в навороченной среде новомодного IDE (IDE- Integrated Development Environment, интегрированная среда разработки), изобилующего классами и встроенными возможностями.

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Начинающему php программисту или как начать зарабатывать

Хочу разместить в помощь начинающим php программистам небольшую памятку. Что и как нужно делать чтобы изучить php и начать зарабатывать на своем ремесле. Если читающие хотят дать свой совет — прошу в камменты.

* Начнем с одного полезного тезиса — изучить php можно не тратя абсолютно никаких денег. Все необходимые материалы по php можно найти в сети, все ответы на вопросы можно найти на форумах… не нужно ходить на курсы, не нужно покупать книги (вообще книги стоит покупать если, лень искать материал в интернете) , не нужно тратить никаких денег. * Изобретайте велосипеды. Всегда пишите код самостоятельно — это поможет вам в дальнейшем. Если вам нужна гостевая книга — напишите ее, не используйте готовые варианты, даже если вы просмотрите и поймете ее код, это не заменит самого программирования, поиска багов, отладки, решения проблем, связанных с написанием. В последствии, когда вы станете профессионалом, можно и даже нужно будет использовать сторонний код, но на этапе изучения это окажет вам плохую услугу. Можно пользоваться примерами и использовать чужой код как способ решить задачу или найти правильный алгоритм. * Создавайте “домашние странички”. Это хорошая тренировка. Создание и развитие своей “домашней страницы” заставит вас постоянно совершенствовать свои умения, искать пути для улучшения сайта, соревноваться с другими обладателями “домашних страниц”. * Объединяйтесь в группы. Попробуйте создать какой-нибудь проект не один, а объединившись с другими программистами. Уменее работать в команде, понимать чужой код и правильно общаться с коллективом поможет вам найти хорошую работу. Многие фирмы ставят одним из главных требований при трудоустройстве — уменее работать в команде. * Не бросайте проект на пол пути. Старайтесь всегда доводить начатый проект до конца. Даже если надобность в нем отпала. Чем больше у вас законченных проектов, тем больший список работ вы можете написать в своем резюме. А ведь именно на готовые и законченные вещи работодатель смотрит в первую очередь. * Беритесь за “копеечную” работу. Если ваш послужной список не богат, не стоит отказываться от малооплачиваемой работы. Приведу пример из жизни, когда я только начинал программировать за деньги я вышел на работу в он-лайн игре. Предлагали в общем копейки — 2 000 в месяц. Но я взялся и по мере того как работал все больше изучал особенности веб программирования. Через семь месяцев моя зарплата была 10 000 рублей. А сколько опыта я приобрел — просто не счесть. * Создавайте большие проекты. Наличие в вашем послужном списке больших проектов — огромный вам плюс. * Не задерживайтесь на работе, если вам стало не интересно. Если ваша работа превратилась в рутину и не приносит ничего нового, никаких знаний — бросайте ее. Это путь в никуда. Всегда цепляйтесь только за интересные проекты. * Повышайте свои “общие” знания. Не стоит зацикливаться только на php, сейчас работодатель требует от программиста не только создания кода, но и уменее верстать страницы, настраивать сервер, составлять документацию, работать с javascript и многое другое. По большому счету сейчас никому не нужны просто веб программисты, а нужны веб мастера.

* Изучайте новые технологии. Новые технологии, такие как Ajax, всегда будут вашим козырем. Они производят на работодателя магическое действие.

Пожалуй на сегодня хватит. Есть еще много советов, но я дам их в других постах, если будет спрос 🙂

Общая информация о планировщике заданий cron OpenServer

Если вы являетесь пользователем UNIX-подобных систем, то программа «cron» должна быть вам знакома, т.к. это стандартный планировщик задач для данного класса операционных систем.

Первое, что бросается в глаза после общения со стандартным планировщиком задач Windows, – это то, что cron лишён графического интерфейса, и расписания задач нужно вносить в специальный файл crontab в соответствии с внутренним синтаксисом cron.

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

В плане функционала лично я никаких отличий от стандартного cron Unix не заметил. Повторюсь, что cron OpenServer служит для создания расписаний выполнения различных задач (скриптов, программ и т.д.), как и стандартные планировщики на уровне ОС. Поэтому без него вполне можно обойтись 🙂

Единственный его плюс – это возможность использовать планировщик cron на ОС Windows, что может порадовать фанатов Unix-систем, которые вынуждены работать на детище Билла Гейтса и компании Microsoft.

Также cron OpenServer может подойти тем, кому не очень нравится стандартный планировщик задач Windows. Основной причиной может служить бедность настроек времени выполнения, т.к. возможности Task Scheduler (стандартный планировщик Windows) ограничены фиксированным списком, в котором нельзя вводить произвольные значения (несколько раз в час, день, периодичность и т.д.).

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

Насколько я знаю, в стандартных планировщиках такой возможности нет. Если в UNIX cron задачу ещё можно приостановить, закомментировав её расписание в файле crontab, то в Windows вам придётся попросту удалять задачу и создавать её каждый раз, когда необходимо выполнять снова – всё это крайне неудобно.

Поэтому если вы, как и я, являетесь разработчиком, работающим с ОС Windows, то планировщик задач cron OpenServer будет для вас удобнее стандартного Task Scheduler.

Давайте теперь рассмотрим, как же его настроить и пользоваться.

Настройка cron OpenServer

Для начала нам необходимо запустить сам OpenServer, для чего запускаем OpenServer.exe из директории, в которую у вас был установлен данный софт. Если вы вдруг забыли, куда его устанавливали, напомню, что по умолчанию OpenServer устанавливается в директорию «C:\OpenServer».

После старта программы в панели инструментов Windows, рядом с часами, появится красный флажок OpenServer, сигнализирующий о том, что программа запущена, но сервер ещё не работает.

Перед запуском веб-сервера нажимаем на флажке любой кнопкой мыши и выбираем пункт «Настройки» для конфигурации планировщика задач cron OpenServer:

В открывшемся окне находим вкладку с названием «Планировщик заданий», которая выглядит так:

Как видите, интерфейс весьма незамысловатый. Для добавления новой задачи вам необходимо ввести периодичность запуска задачи, указать путь к скрипту или исполнительному файлу программы и нажать на кнопку «Добавить». После данных действий задача появится в блоке со списком всех запланированных заданий.

Теперь поговорим о синтаксисе заданий более подробно. Он такой же, как и для cron UNIX, т.е. для указания времени можно использовать цифры и символ «*», который означает «для всех».

Синтаксис cron OpenServer сильно упрощён, т.к. в оригинальном UNIX-планировщике, к примеру, для дней недели и месяцев доступны сокращённые варианты названий на английском. В нашем же случае такая запись приведёт к ошибке. Дни недели, к примеру, нужно будет указывать только цифрами, где 1 – это понедельник, а 7 – воскресенье.

Если поговорить о реальных примерах, то:

  • запись типа «1 * * * *» будет означать запуск задачи каждую первую минуту часа, т.е. она будет выполняться каждый час;
  • запись «*/2 * * * *» будет запускать задачу через каждые две минуты;
  • запись «2-4 * * * *» будет соответствовать запуску задачи 3 раза в течении каждого часа во 2,3 и 4 минуту;
  • запись «* * 1 * *» будет соответствовать ежемесячному запуску задачи первого числа месяца.

Думаю, что логика понятна. Если вы хотите больше примеров, то можете обратиться за помощью к Википедии, где есть очень неплохая и понятная (что редкость для вики 🙂 ) статья на русском языке по данному поводу.

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

При пользовании ресурсом не забывайте, что в качестве параметров времени запуска cron OpenServer принимает только числовые значения.

С временными параметрами выполнения задач cron OpenServer мы разобрались, теперь поговорим о том, как правильно задавать путь к запускаемому объекту.

Запуск php-скриптов с помощью планировщика задач cron в OpenServer

Объектом может быть как исполнительный (.exe) файл программы и php-скрипт, так и обычные файлы, которые будут открываться в тех программах, для которых они предназначены. ОС определяет последнее по ассоциациям расширений файлов и указанных для них программ, которые хранятся в системном реестре.

Поскольку планировщик задач cron встраивался в OpenServer для разработчиков (равно как сама WAMP-сборка создавалась для них же), то он, в первую очередь, предназначен для запуска программных скриптов.

Вообще идея написания сегодняшней статьи возникла у меня после моего недавнего знакомства с CMS/CMF Magento, в рамках которого мне необходимо было реализовать автоматическую отправку писем на email покупателей порциями через равные промежутки времени.

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

Путь к скрипту у меня был известен, но, указав его просто в cron-задаче в OpenServer, он просто открывался как обычный файл с интервалами, которые я указал.

Для того, чтобы произвести его запуск, потребовалось помимо пути к файлу прописать в описании задачи ещё и путь к PHP-интерпретатору, а также файлу конфигурации PHP. В итоге, получилась следующая строка:

%progdir%\modules\php\%phpdriver%\php-win.exe -c %progdir%\userdata\temp\config\php.ini -q -f %sitedir%\sitename.com\cron.php

Первая её часть – это путь к интерпретатору PHP, вторая – ссылка на файл конфигурации, а третья – это путь к самому скрипту, который нам необходимо будет запускать.

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

Также создатели OpenServer учли ситуацию, когда через cron необходимо будет запустить удалённый скрипт, т.е. доступ к нему будет осуществляться по url.

В данной ситуации необходимо будет воспользоваться встроенной в OpenServer утилитой WGet. Пример такой задачи будет выглядеть следующим образом:

%progdir%\modules\wget\bin\wget.exe -q --no-cache http://sitename.com/cron.php -O %progdir%\userdata\temp\temp.txt

В данном случае файл cron.php будет запрашиваться по протоколу http и ответ будет сохраняться во временный файл temp.txt, чтобы не скапливать мусор.

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

Возможность заманчивая, но в реальной практике её использование встречается не так уж и часто. Просто имейте ввиду, что данное действие возможно 😉

Возвращаясь к синтаксису задач cron OpenServer, вы могли заметить, что при описании задач допускается использовать предопределённые переменные. Они записываются в формате %переменная% и служат в качестве указателей различных директорий (каталога OpenServer, системного диска компьютера и т.д.)

С полным списком переменных и их значений вы можете познакомиться в официальной документации OpenServer.

Итак, на данном этапе вы ввели все необходимые данные для создания задачи для планировщика cron.

Перед сохранением конфигурации планировщика проверьте ещё раз список всех задач на экране настройки cron OpenServer и убедитесь, что объект с указанными вами ранее данными там присутствует.

Теперь нам остаётся нажать на кнопку «Сохранить», чтобы занести введённую нами информацию в файл конфигурации cron. После этого веб-сервер автоматически перезагрузится.

Если веб-сервер на этапе ввода задачи был остановлен, его необходимо будет запустить вручную, после чего все изменения сохраняться и задача начнёт выполняться.

После того, как мы добавили в cron OpenServer задачу, независимо от успешности её выполнения, автоматически начинают регистрироваться лог-файл планировщика.

Для доступа к нему необходимо в меню OpenServer выбрать пункт «Просмотр логов»:

В открывшемся окне ищем вкладку «Планировщик заданий» и видим там следующее:

Как видите, задача запустилась, причём, в путях к указанным файлам вместо внутренних переменных OpenServer появились реальные объекты.

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

Не зависимо от результатов выполнения задачи в логах постоянно пишется ошибка при чтении taskinfo.txt и выдается «result: 0».

Так что при возникновении каких-либо проблем с запуском задачи под cron OpenServer на логии надежды нет – можете не тратить время на их изучение и не прикреплять их к сообщениям на форумах и блогах 🙂

О запуске скриптов и отдельных файлов через определённые промежутки времени с помощью планировщика задач cron, входящего в комплект OpenServer, мы поговорили. Самое время рассмотреть, как можно запускать приложения с его помощью. И возможно ли это?

В чём будет заключаться настройка Laravel

Ну, вот мы и произвели установку Laravel. Теперь, казалось бы, остаётся радоваться жизни и начинать работу над реальными проектами… Но, не тут-то было 🙂

Файловая структура Laravel обладает одной раздражительной для новичков особенностью – файл index.php, который распознаётся web-серверами как точка входа на сайт, расположен не в корне проекта, а в папке «public».

Поэтому после установки Laravel на ваш веб-сервер и ввода в браузере доменного имени сайта вместо ожидаемой стартовой страницы вы увидите только список файлов.

Сайт, конечно, можно запустить, если вбить URL сайта в формате «http://localhost/laravel.corp/public», но вы только посмотрите на этот адрес… Сколько букв, а это всего лишь адрес корня сайта 🙂

Работать с такой простынёй в будущем будет крайне неудобно и ни о каком ЧПУ даже и думать не приходится.

Для того, чтобы сообщить серверу, что точка входа находится не в корне сайта, а в его директории public, нам необходимо либо изменить настройки самого сервера, либо, если вы используете Web-сервер Apache, отредактировать файл .htaccess.

А ещё, помимо чистых веб-серверов существуют различные сборки ПО для комфортной работы веб разработчиков. Они называются LAMP, WAMP, MAMP, XAMP.

Первая буква данных аббревиатур означает ОС, на которой сборка будет работать (Linux, Windows, MacOS, X- любая). А последние три — это заглавные буквы основных программ для создания сайтов, входящих в дистрибутив (Apache, MySQL, PHP).

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

И, хотя, сегодня активно применяются и другие средства для быстрого старта веб проектов — виртуализаторы и виртуальные среды разработки, о которых я упоминал в предыдущей статье об установке Laravel, я всё так же являюсь сторонником использования *AMP сборок.

Сам я веду разработку под ОС Windows и пользуюсь WAMP-сборкой OpenServer, о чём уже неоднократно говорил в статьях на данном блоге.

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

Ну, а поскольку я начал рассказывать об OpenServer, то и настройку Laravel для полноценного запуска проектов начну на его примере.

Установка Laravel на OpenServer

Прежде всего, хочу сказать, что использование OpenServer значительно упрощает запуск Laravel проектов, т.к. вам не нужно производить никаких манипуляций в консоли и тратить своё время на дополнительные настройки серверного ПО, необходимые для корректного взаимодействия друг с другом.

Для всего этого в OpenServer есть уже всё необходимое. Нужно только знать, где и что клацать 🙂

Итак, после установки OpenServer и его запуска нам нужно настроить Laravel для запуска проекта по прямому запросу к его доменному имени, а не к папке public.

Перед этим действием предполагается, что Laravel вы уже установили и разместили его файлы в папке domains на OpenServer, которая предназначена как раз для будущих сайтов, запускаемых с помощью сервера. В моём примере Laravel находится по пути «C:\openserver\domains\localhost\laravel.corp».

Запустить в браузере я его сейчас могу только послав запрос на URL «http://localhost/laravel.corp/public», что крайне неудобно. Итак, чтобы избавиться от этой неприятности, первым делом нам нужно зайти в настройки OpenServer, что можно сделать следующим образом:

В открывшемся окне переходим на вкладку «Домены» и в списке «Управление доменами» выбираем пункт «Ручное управление» или «Ручное + Автопоиск», чтобы можно было задавать своим проектам произвольные доменные имена.

В качестве примера я использовал первый вариант, но всё же рекомендую последний, т.к. он позволяет как добавлять произвольные доменные имена, так и запускать проекты из папки «openserver/domains», обращаясь к ним по их названиям каталогов.

При ручном управлении вы сможете запускать только те сайты, доменные имена которых будут прописаны на сервере со ссылками на соответствующие папки:

Итак, для добавления нового домена пропишите его имя в поле «Имя домена», а в поле «Папка домена» выберите каталог с файлами сайта. После этого не забудьте нажать кнопку «Добавить», а потом «Сохранить», после чего сервер перезапустится.

Кстати! При данном варианте добавления новых сайтов на сервер файлы ресурса могут быть расположены в любом месте, не обязательно в «openserver/domains».

Если вы всё сделали правильно, то при вводе в браузере доменного имени (laravel.portfolio в моём случае), которое вы добавили, вы увидите стандартную страницу приветствия Laravel:

Поздравляю, на этом установка Laravel на OpenServer подошла к концу. Сайт заработал, причём теперь исчезла необходимость обращаться к папке public!

Прежде всего, хотел бы порекомендовать вам сделать бэкап рабочего сайта на случай, что вы что-то сделаете неправильно и понадобится быстро вернуться к исходной точке.

Для этого просто скопируйте каталог с проектом или сделайте его архив в отдельном месте, кратко описав текущий функционал и дату создания.

Также не лишним будет сделать Git репозиторий для хранения списка изменений и быстрого их восстановления в будущем.

Если вы работаете самостоятельно (я имею ввиду, не в офисе) и у вас нет собственного Git сервера, то можете развернуть его на своей рабочей машине, сделав в отдельной директории bare-репозиторий, либо залить изменения на GitHub (думаю, что для ваших локальных целей вполне хватит публичного репозитория, т.к. приватный платный).

Как видите, сайт на Laravel из коробки выглядит так себе 🙂 В общем-то, страницу приветствия назвать сайтом можно при наличии определённой доли смелости и фантазии.

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

Но, это не беда. Стоит только начать… И, со временем, занимаясь разработкой сайтов на framework, у вас под рукой уже будет собственная мини-CMS благодаря готовым фрагментам кода и отдельным модулям.

А мы с вами начнём заниматься непосредственно разработкой уже в следующей статье, где я покажу вам, как «натянуть» чистый HTML-шаблон на фреймворк, на базе которого мы в дальнейшем создадим полнофункциональный сайт-визитку с админкой и возможностью ведения блога.

Поэтому подписывайтесь на обновления проекта, чтобы не пропустить самое интересное 🙂

Итак, для фанатов Windows и OpenServer мы Laravel настроили. А как же быть тем, кто пользуется Linux-дистрибутивами или MacOS, на которых OpenServer не работает?

Когда-то передо мной стояла подобная задача — настроить Laravel на Ubuntu сервере.

На stackoverflow.com каких только способов я не находил… вплоть до изменения файловой структуры самого Laravel проекта (способ хоть и рабочий, но не рекомендую им пользоваться, чтобы у других разработчиков при виде «сего творения» не вставали дыбом волосы) 🙂

Как же быть?

Достойным внимания является настройка виртуальных хостов, корнем которых будет являться папка public вашего Laravel проекта (по сути, это мы и сделали при запуске Laravel на OpenServer). Но, этот вариант подойдёт только для локального использования и на выделенных серверах.

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

Рассмотрим данные операции для различных веб-серверов.

Настройка Laravel проекта на различных веб-серверах

Поскольку самыми распространёнными программными веб серверами на сегодня являются Nginx и Apache, то рассмотрю данный процесс для них.

Настройка Laravel для Apache

Для Apache настройка Laravel может быть произведена двумя способами, каждый из которых мы подробно рассмотрим:

Способ 1.

Он будет заключаться в настройке Laravel в виде виртуального хоста. Лучше всего для этого воспользоваться консольным режимом (по крайней мере, так поступаю лично я) и будет выглядеть следующим образом:

1. Переходим в папку виртуальных хостов Apache: apache2/sitesavailable

2. Если вы ещё не создавали виртуальные хосты, то в данной папке у вас будет всего лишь один файл default. Откройте его для редактирования либо скопируйте и переименуйте его в название вашего будущего сайта. Например, laravelsite.local.

3. Внутри файла прописываем следующие настройки:


    
    ServerName laravelsite.local
    DocumentRoot "path_to_site/myapp/public"
        
    
        AllowOverride all
    

4. Если вы создавали новый файл в sites-available, то для активации виртуального хоста нужно будет сделать ссылку на файл из apache2/sitesavailable в apache2/sites-enabled (в Unix-подобных системах это производится с помощью команды ln). Если вы редактировали существующий файл default, то данные действия будут лишними.

5. Перезапускаем Apache.

Вот и всё, после запуска Apache сайт будет доступен по адресу http://laravelsite.local/. Если что-то пойдёт не так, то ищите текст ошибки в логах Apache.

Способ 2.

Благо, что Apache предоставляет ещё один, более простой способ настройки корня Laravel сайта на директорию public с помощью директив в файле .htaccess, размещённом в корне проекта. Я сам активно пользуюсь данным способом при разворачивании Laravel сайтов на shared хостингах, т.к. он максимально прост и быстр — достаточно однажды подготовить соответствующий файл — и вперёд 🙂

Код его должен быть следующим:

DirectoryIndex /public/index.php
RewriteEngine On

RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^(.+) $1 [L]

RewriteCond %{DOCUMENT_ROOT}/public%{REQUEST_URI} -f
RewriteRule ^(.+) /public/$1 [L]

Options +SymLinksIfOwnerMatch
RewriteRule ^(.*)$ /public/ [QSA,L]

Этот нужно разместить в папке с Laravel в .htaccess, который находится в корне самого проекта. Тот .htaccess, который лежит в директории public, трогать не нужно!

Всё, с настройкой Laravel для Apache мы разобрались. Теперь самое время сделать то же самое для Nginx, который также достаточно активно применяется для запуска веб-проектов ввиду своей фантастической скорости работы.

Настройка Laravel проекта на Nginx сервере

Итак, для настройки Laravel для Nginx, к сожалению, нет такого изобилия различных способов, как для Apache. По крайней мере, я знаю только один в виде настроек Laravel проекта в виде виртуального хоста.

Если вы знаете больше, то не отмалчивайтесь и поделитесь ими в комментариях со мной и всеми остальными 🙂

В случае с Nginx для настройки виртуальных хостов нужно произвести действия, аналогичные в случае с Apache:

1. Переходим в папку виртуальных хостов Nginx: nginx/sitesavailable.

2. Сделать файл нового виртуального хоста или отредактировать существующий default.

3. Внутри файла прописываем следующие настройки:

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only = on;
    root path_to_app/myapp/public;
    index index.php index.html index.htm;

    server_name server_domain_or_IP;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        try_files $uri /index.php = 404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

Учтите, что последний блок кода — это настройки PHP для запуска сайта: путь к интерпретатору, модули, расширения файлов и т.д. Если с данными настройками сайт не заработает, то отредактируйте их в соответствии со своей конфигурацией сервера. Подробный текст ошибок ищите в логах Nginx.

4. Если создавали новый виртуальный хост, то активируем его созданием ссылки на файл с настройками из папки sites-available в sites-enabled. Если новый хост вы не создавали, а редактировали существующий, то данный шаг пропускаем.

5. Перезапускаем Nginx.

Итак, после данных действий, при вводе в веб браузере адреса сайта (в моём примере он будет http://laravelsite.local/) вы увидите не список файлов, как прежде, а ожидаемую страницу приветствия Laravel.

Если этого не произошло, то ищите ответы на вопросе в логах вашего веб-сервера (Nginx или Apache, соответственно). Скорее всего, они будут вызваны неверными правами на различные папки (как проекта в целом, так и на отдельные внутренние каталоги). В таком случае всё, что вам потребуется, это установить их в 755 или 644 🙂

Если же вы найдёте что-то сложнее, то описывайте свою проблему в комментариях, постараюсь вам помочь.

Настройка Xdebug в PhpStorm

1. Отладка на локальном компьютере

Все настройки будут показаны на примере Ubuntu и интерпретатора PHP, настроенного вместе с Apache. Для других конфигураций пути к файлам могут отличаться, но суть останется та же. Давайте разберемся как это будет работать. Отладчик Xdebug позволяет приостанавливать выполнение кода, смотреть стек вызовов и содержимое переменных. Однако удобного интерфейса управления у него нет. Поэтому для управления отладкой будем использовать IDE. Но IDE не может никак сообщить отладчику что надо запустить отладку, потому что она отвечает только за код. Для этого понадобится ещё расширение для браузера Debug Helper, с помощью которого вы сможете включить режим отладки.

Сначала необходимо установить Xdebug. Для этого выполните:

sudo apt install xdebug

После завершения установки Xdebug надо настроить программу так, чтобы при запуске сеанса отладки она пыталась подключится к нашей IDE для управления отладкой. Для этого добавьте такие строчки в файл /etc/php/7.4/apache2/conf.d/20-xdebug.ini в версии Xdebug 2:

sudo vi /etc/php/7.4/apache2/conf.d/20-xdebug.ini

zend_extension=xdebug.so
xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_connect_back=1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_autostart=false

Для новой версии Xdebug 3 старая конфигурация тоже будет работать, но лучше использовать новый стандарт:

xdebug.mode=debug
xdebug.start_with_request=trigger
xdebug.discover_client_host = false
xdebug.client_host = 127.0.0.1
xdebug.client_port = 9000

Давайте рассмотрим эти настройки подробнее. Первый параметр xdebug.mode - режим отладки, возможные варианты:

  • develop - включает вывод дополнительной информации, переопределяет var_dump;
  • debug - режим построчного выполнения кода, именно он нужен в данном случае;
  • profile - профилирование;
  • trace - трассировка выполнения программы.

Если необходимо, вы можете включить несколько режимов, перечислив их через запятую. Вторая строчка xdebug.start_with_request определяет как будет запускаться отладчик для режимов debug, trace и им подобных:

  • yes - всегда, при запуске php скриптов;
  • no - запуск только из кода с помощью специальных функций;
  • trigger - по запросу, с помощью специальной переменной в $_ENV, $_POST, $COOKIE или в другом массиве. Этот вариант подходит лучше всего в данном случае чтобы отладчик не запускался когда в этом нет необходимости.

Если третья строка xdebug.discover_client_host имеет значение true, то xdebug пытается подключится к хосту, переданному в заголовке HTTP_X_FORWARDED_FOR. Но так как хост указывается в следующей строке, в данном случае эта возможность не нужна. Дальше указывается хост клиента, куда надо подключится для управления отладкой 127.0.0.1 и порт 9000. Именно этот порт используется в PhpStorm по умолчанию на данный момент. После сохранения настроек перезапустите Apache:

sudo systemctl restart apache2

Теперь надо настроить PhpStorm. Запустите программу, затем откройте меню Run -> Edit Configurations. Перед вами откроется окно, в котором надо настроить отладчик.

Нажмите кнопку + и в открывшемся списке выберите PHP Remote Debugger:

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

Если вам нужно изменить порт, к которому будет подключаться Xdebug откройте меню File -> Settings -> PHP -> Debug -> DBGp Proxy. Здесь можно указать нужный порт:

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

Дальше осталось настроить браузер. Для Chrome можно скачать это расширение. Установите его и откройте страницу, которую надо отлаживать. Кликните по значку расширения и выберите Debug. Значок расширения станет зеленым:

Обновите страницу и возвращайтесь к PHPStorm. Если всё было сделано верно, там запустится сеанс отладки. При первом запуске программа может попросить настроить соответствия локальных путей к файлам с удаленными. Для локального сервера здесь ничего настраивать не надо, достаточно нажать Accept:

Дальше отладчик остановит выполнение на выбранной точке останова и в программе появится интерфейс отладки:

Как видите всё довольно просто. Дальше давайте разберемся как настроить Xdebug PhpStorm и Docker.

2. Отладка Php в Docker

C Docker возникает одна сложность. Поскольку отладчик должен сам подключится к IDE, необходимо пробросить хост в контейнер. В windows это можно сделать с помощью адреса host.docker.internal. Но в Linux, по умолчанию это не происходит. Для того чтобы добавить такой адрес надо добавить в docker-compose такие строчки:

extra_hosts:
  host.docker.internal: host-gateway

Давайте для этого примера будем использовать такую структуру директорий:

Минимально необходимый docker-compose.yaml будет выглядеть вот так:

version: '3.5'
networks:
  losst-network:
services:
  nginx:
    image: nginx
    ports:
        - '8094:80'
    volumes:
        - ./www/:/var/www/
        - ./conf/nginx:/etc/nginx/conf.d
    networks:
        - losst-network
  php-fpm:
    build: 
      context: ./conf/php-fpm
    extra_hosts:
      host.docker.internal: host-gateway
    volumes:
      - ./www:/var/www/
    networks:
      - losst-network

Здесь объявляется два контейнера, nginx и php-fpm. В первый не надо вносить никакие изменения, поэтому можно просто брать официальный образ, монтировать папку с исходниками, конфигурационный файл и пробрасывать порт. Во второй контейнер надо установить и настроить Xdebug поэтому его придется собрать на основе официального контейнера php. Для этого же контейнера надо указать директиву extra_hosts, без неё ничего работать не будет. Конфигурация Nginx тоже вполне стандартная:

server {
  listen 80;
  server_name _ !default;
  root /var/www/;
  add_header X-Frame-Options "SAMEORIGIN";
  add_header X-XSS-Protection "1; mode=block";
  add_header X-Content-Type-Options "nosniff";
  index index.html index.htm index.php;
  charset utf-8;
  location / {
    try_files $uri $uri/ /index.php?$query_string;
  }
  error_page 404 /index.php;
  location ~ \.php$ {
    fastcgi_pass php-fpm:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
    include fastcgi_params;
  }
}

Здесь настроена обработка PHP скриптов в контейнере php-fpm, и редирект несуществующих URL на index.php, что вполне стандартно для многих фреймворков и CMS. Самое интересное - Dockerfile контейнера php-fpm, он выглядит вот так:

FROM php:8.0.3-fpm-buster
RUN pecl install xdebug \
&& docker-php-ext-enable xdebug
COPY xdebug.ini /usr/local/etc/php/conf.d/xdebug.ini

Здесь устанавливается xdebug с помощью pecl, а затем копируется его конфигурационный файл в контейнер. Вот этот конфигурационный файл:

xdebug.mode=debug
xdebug.start_with_request=trigger
xdebug.discover_client_host = false
xdebug.client_host = host.docker.internal
xdebug.client_port = 9000

В контейнере установлен Xdebug 3 для PHP 8, потому что старая версия с этой версией языка уже не работает, поэтому используется новый синтаксис конфигурации. Ну и хост, host.docker.internal, который раньше был прописан в docker-compose.yaml. Настройка xdebug PHPStorm docker завершена. Дальше вы можете запустить проект:

docker-compose up --build

Теперь, как и в предыдущем варианте вы можете включить в браузере режим отладки, обновить страницу и отладчик успешно подключится к IDE, не смотря на то, что он работает в Docker: