Openserver не работает xdebug

Разное → Настройка PhpStorm + Xdebug 2 + Open Server

Настроил Xdebug в PhpStorm? Напиши на хабр! (с) хаброкоммент

Настройка Open Server

1. Редактируем php.ini:

Настройка PhpStorm

Убеждаемся, что в Settings → Languages & Frameworks → PHP → Debug для Xdebug прописан порт 9000 и включена опция Can accept external connections:

С помощью меню Run → Web Server Debug Validation проверяем настройку отладчика:

Настройка браузера

Для старта отладки из браузера я использую Chrome расширение Xdebug helper, для других браузеров должно быть что-то похожее.

Процесс отладки

В PhpStorm включаем прослушку порта отладчика:

В нужном месте ставим брикпойнт:

В браузере открываем сайт и стартуем отладочную сессию:

Перезагружаем страницу.

При первом старте отладчика, PhpStorm предложит принять входящее соединение, жмём Accept:

Источник

Связка Xdebug в PhpStorm с Openserver

1. Для используемых версий PHP открываем php.ini (например в меню OpenServer Дополнительно->Конфигурация->PHP-7.2-x64) и редактируем настройки:
чтобы получилось примерно так: 2. Перезапускаем OpenServer.

Настройка PhpStorm

Убеждаемся, что в Settings → Languages & Frameworks → PHP → Debug для Xdebug прописан порт 9000 и включена опция Can accept external connections:

С помощью меню Run → Web Server Debug Validation проверяем настройку отладчика (введите данные отлаживаемого сайта)

Настройка браузера

Для старта отладки из браузера я использую Chrome расширение Xdebug helper, для других браузеров должно быть что-то похожее.

Процесс отладки

В PhpStorm включаем прослушку порта отладчика:

В нужном месте ставим брейкпойнт:

В браузере открываем сайт и стартуем отладочную сессию:

При первом старте отладчика, PhpStorm предложит принять входящее соединение, жмём Accept:

И попадаем в отладочный режим:

P.S: Если вам нужно запускать отладку простых php-скриптов прямо из PhpStorm, то нужно в Settings → Languages & Frameworks → PHP добавить список используемых версий PHP и выбрать текущую версию интерпретатора (опция Interpreter).

Друзья! Приглашаем вас к обсуждению. Если у вас есть своё мнение, напишите нам в комментарии.

Источник

Форум

Пошаговая настройка Xdebug + OpenServer + PHPStorm

Пошаговая настройка Xdebug + OpenServer + PHPStorm

1. Подготовка
Xdebug уже встроен в OpenServer и качать нам его не понадобится

Если все же нужен другой релиз xdebug его можно скачать отсюда http://xdebug.org/download.php
и переместить в
e:\OpenServer\modules\php\PHP-5.4.17\ext\
не забыв прописать в php.ini путь к нему (zend_extension)

2. Редактируем php.ini (e:\OpenServer\userdata\config\PHP-5.4.17_php.ini)
Должны быть эти обязательные настройки Перезапускаем OpenServer
Смотрим чтобы была временная папка xdebug >
e:\OpenServer\userdata\temp\xdebug\

3. Добавляем в браузер закладки со страницы http://www.jetbrains.com/phpstorm/marklets/ после нажатия Generate (IDE key: PHPSTORM)

Код закладок имеет такой вид >

Start debugger Stop debugger Debug this page Start profiler Stop profiler Start tracer Stop tracer В гугл хроме после добавления закладок используем ctrl+shift+O для перемещения их в удобное место — отмечаем на шифте их и перетягиваем в начало списка закладок
Ctrl+Shift+B отображает / скрывает панель закладок сверху страницы

4. Настройка PHPStorm

File > Settings > PHP >
PHP language level: > выбираем соответствующую версию пхп (5.4)
Interpreter > кликаем на .
PHP Home > корневой путь к пхп (E:\OpenServer\modules\php\PHP-5.4.17)
Debugger > Xdebug
Name > PHP (можно любое другое)

File > Settings > PHP > Servers >
Name: > домен создаваемого сайта
Host > домен создаваемого сайта (например: myblog.loc)
Port > 80

Желательно чтобы название сервера совпадало с хостом (так шторм по-умолчанию прописывает, если ранее не указали).
Указываем сами чтобы избежать вопроса о расположении файлов при запуске первой отладки.

5. Открываем нужную страницу в браузере которую будем отлаживать
Нажимаем с закладок Start debugger (у меня start Xdebug, кому как удобно название)

В phpstorm включаем Listen PHP Debug Connections (значок телефонной трубки)
В коде сайта определяем точку остановки > Ctrl + F8

ОБНОВЛЯЕМ страницу в браузере, тем самым увидели остановку сайта и перехват штормом всех данных, которые получили до точки прерывания

6. Профилирование в phpstorm
Нажимаем с нужной страницы сайта Start profiler, обновляем, переходим по страницам сайта для отслеживания их работы.
Этим мы записали лог выполнения скриптов страниц в файлы > e:\OpenServer\userdata\temp\xdebug\cachegrind.out.[путь_к_странице]
где каждой странице создается файл.
Если обновить или зайти по уже ранее открытой странице сайта, обновится содержимое лог-файла.
Когда прекратили сбор информации нажимаем с закладок Stop profiler

Нажимаем в шторме
Tools > Analyze Xdebug Profiler Snapshot > выбираем файл профилирования
(E:\OpenServer\userdata\temp\xdebug\cachegrind.out. )

Все файлы логов работы страниц будут храниться во временной папке . \userdata\temp\xdebug до очередного запуска OpenServer (то есть сотрутся если нажать перезапустить сервер или остановить, запустить)
Но после остановки сервера файлы профилирования все еще сохраняются!

7. Не забываем чтобы была указана необходимая версия PHP в OpServ-e > Настройки — Модули.

Опенсервер последний (4.8.9)
ПХП 5.5.4

Простите но я вас не понял.
ПХПШторм установлен отдельно.
Что значит запущен не из закладок Опенсервера?
Автор описал настройки ПХП.ини в п.2 туториала.

Так же ПХПШторм утверждает что модуль Хдебаг не подключен:

PHP version: 5.5.4

Loaded extensions: bcmath, calendar, Core, ctype, date, dom, ereg, filter, ftp, hash, iconv, json, libxml, mcrypt, mhash, mysqlnd, odbc, pcre, PDO, Phar, Reflection, session, SimpleXML, SPL, standard, tokenizer, wddx, xml, xmlreader, xmlwriter, zip, zlib

Так и есть.
Добавил ПХПШторм в закладки и Хдебаг определился.
Спасибо!

Возможно ли настроить так что бы нормально запускалось с ярлыка?

Я расскажу как я пользуюсь дебагером в phpstorm в связке с Open Server, по моему так намного проще:
Моя конфигурация: Open Server 4.9.0, PhpStorm 6.0.3, Windows 7.
1. Открываем проект в шторме
2. Открываем файл проекта который необходимо продебажить
3. Ставим брейкпоинт в участке кода который будем дебажить

4. Нажимаем на «Start Listen PHP Debug Connections» (ищем в подменю «Run» или на панели toolbar, иконка в виде трубки)

5. Теперь переходим в браузер Firefox и устанавливаем расширение easy Xdebug
6. Открываем в Firefox страницу которую будем дебажить
7. Включаем панель дополнений если она еще не включена
8. Находим на панели дополнений иконки плагина easy Xdebug

9. Запускаем xdebug сессию нажатием на жучка

10. Нажимаем F5 на нашей странице
11. Если все прошло удачно в PhpStorm должно всплыть следующее окно

12. Нажимаем Accept и все готово, можно дебажить

Источник

Проблема с запуском XDEBUG на OpenServer

Недавно я столкнулся с проблемой запуска xdebug на openserver с PHP7.2. Проблема заключалась в том, что, даже, при попытке включения расширения xdebug в php.ini, оно по-прежнему не загружалось. В этой статье я продемонстрирую все шаги, которым я следовал, чтобы решить проблемы с запуском xdebug на openserver.

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

Поиск проблемы

После попытки установить xdebug, первый, обязательный шаг, который нужно проделать — выполнить phpinfo() . И ответ должен содержать секцию xdebug :

Если её нет, то очевидны проблемы при установке, или конфигурации.

Теперь, нужно открыть файл php.ini . Его можно открыть прямо из панели OpenServer:

И в этом файле нужно найти секцию [Xdebug] , в которой посмотреть путь, где PHP ищет само расширение xdebug:

Теперь мне нужно проверить, существует ли это расширение в этой папке.

Папка, в которую нужно смотреть — зависит от версии PHP, и корневой папки, куда был установлен OpenServer. У меня же эта папка — C:\OSPanel\modules\php\PHP-7.2-x64\ext

В итоге, в этой папке отсутствует файл php_xdebug.dll . Что и было причиной того, что xdebug не запускался.

Установка Xdebug в OpenServer вручную

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

В моём случае, нужно PHP7.2 (64 разрядной системы). На момент написания статьи, максимальная альфа версия (которую я и выбрал) — 2.7, и стабильная — 2.6.

После скачивания расширения, его нужно установить. Для этого, в папку, в которой ранее искали это самое расширение, нужно скопировать скачанный файл.
Файл, который вы скачали, имеет имя, похожее на php_xdebug-2.6.0-7.2-vc15.dll , вы же, после копирования, переименуйте его в php_xdebug.dll

Теперь, осталось перезагрузить OpenServer, и настроить само расширение и IDE под ваши требования. Или, же, как было продемонстрировано ранее в статье — по использованию и настройке xdebug.

Резюме

Эта статья должна была помочь по установке xdebug на openserver, и решению проблем с запуском xdebug. Если же эта статья не помогла, то, с вероятностью в 99%, проблема с конфигурацией расширения.
Надеюсь, у вас всё получилось. Отлаженного кода вам!

Subscribe to Блог php программиста: статьи по PHP, JavaScript, MySql

Get the latest posts delivered right to your inbox

Источник

Ускорение сайта путём выявления проблемных участков кода: xDebug + phpStorm

Привет, Хабр! Это мой первый пост, поэтому поделюсь с вами кейсом ускорения работы одного сайта на WP + WooCommerce. Сам занимаюсь веб-разработкой, последние два года только на фрилансе. Не претендную на идеальную статью, я сам каждый день учусь новому, но в статье максимально стараюсь избегать неточностей.

Статья будет полезна джунам и миддлам кто разрабатывает сайты, кто занимается оптимизацией сайтов и кто хочет посмотреть на работу php кода «с высоты». Для себя из полезного можно узнать как связать вместе OpenServer, PhpStorm и xDebug. Один раз настраиваете и можно потом запросто делать отладку. И так, начнём.

Описание проблемы

Есть сайт. Работает на WP + wooCommerce. Количество продуктов

21 000, категорий

4 000. Куча своих таксономий, пользовательских типов записей. Генерация одной страницы занимает 4-5 секунд, иногда доходит до 10. Пользователи со всей статикой и с задержками сети ждут ещё 2-3 секунды. Задача: надо выявить что так тормозит сайт.

Конфигурация сервера: CentOS 8, ISPmanager 6 Lite. RAM 16 Гб, 4 процессора (именно какие не смог узнать, там VDS не показал с теми доступами что у меня были, а я сильно не интересовался, ну тут это не особо важной роли играет).

Для такой конфигурации и трафика который не превышает в сутки 500 уников такая долгая генерация однозначно патология. Взялся изучать.

Первичный анализ

Для начала сделал бекапы. Установил плагин Query Monitor который абы как показывает запросы в БД. Зацепка есть: около

У WooCommerce есть такая проблема — по умолчанию при выводе категорий он показывает сколько там находится продуктов рядом с названием категории в скобках. Если кому интересно, issue. Так вот, Query Monitor сможет показать свойственный этой особенности запросы и одной строчкой можно исправить ситуацию. Но на этот раз проблема в другом.

На первый взгялд не понять в чем проблема. Тяжелых плагинов нет, тема не на каком-то Elementor или WP Bakery, создан с нуля и расширена плагином Advanced Custom Fields, все файлы разбиты по папкам и названы адекватно. Копаем глубже.

Разворачиваем среду отладки

С помощью плагина Duplicator быстро взял копию сайта. Исключил все медиа, изображения, архивы и папку wp-content/uploads целиком. Они нам не нужны для анализа, но могут здорово раздуть архив что сервер упрётся в лимит, либо браузер покажет 504 Gateway time out.

У меня установлен OpenServer версии 5.3.8, создаю директорию, закидываю файл с архивом и с файлом installer.php что выдаёт duplicator. Перехожу по адресу mydevsite.domain/installer.php и заполняю все данные что просит dup-installer. Не буду тут долго останавливаться, поднять копию сайта проще простого.

Открываю проект в phpStorm. IDE довольно удобный, но для текущего кейса можно было и без него обойтись. Поэтому если у вас другой IDE не торопитесь уходить, нам он нужен только для просмотра логов xDebug.

Включить xDebug в OpenServer

Если у вас как и у меня установлен OpenServer то отдельно устанавливать расширение xDebug не надо, он уже установлен, достаточно в конфигурации php.ini раскомментировать нужные строчки и немного настроить. Если что-то другое документация к xdebug тут.

Чтобы открыть php.ini надо проделать следующее:

Клик по иконке OpenServer в нижнем меню -> Дополнительно -> Конфигурация -> php7.4.

У меня php версии 7.4, если у вас другая версия там будет соответствующее название.

В открывшемся окне с конфигами находим строчку ;zend_extension = xdebug и убираем с начала строки точку с запятой (раскомментируем). Чуть ниже в окне будут уже сами конфиги xdebug. Опускаемся или находим поиском строку [xdebug] и вносим правки ниже:

Читайте также:  Что пьют когда не работает желудок

Тут xdebug.mode указывает что мы хотим профилировать и трассировать код. По умолчанию там стоит off. Есть ещё другие режимы, но на них не буду останавливаться, этих двух нам достаточно. xdebug.start_with_request указывает что включать режим отладки надо не всегда, а только если передать специальный параметр (через POST, GET или COOKIE, удобнее всего GET параметр). И да, этот параметр по умолчанию закомментирован, не забудьте раскомментировать.

Как выглядит конфиг php.ini у меня.

Всё. xDebug готов, перезапускаем OpenServer. Теперь при переходе на любую страницу нам достаточно прописать ключ get параметра XDEBUG_PROFILE и php будет собирать отладочную информацию и записывать в папку что указан по пути xdebug.output_dir (у меня стоит путь по умолчанию). Про другие особенности можно прочитать тут.

Вид URL будет иметь такой вид mydevsite.domain/?XDEBUG_PROFILE если надо собрать информацию с главной страницы. В моем случае я снял снепшот с главной страницы.

Просмотр логов в красивом виде

Для просмотра логов я использую phpStorm. Но гугл подсказывает что для vsCode или Atom тоже есть решения. В самом верхнем меню находим раздел Tools и в списке Analyze Xdebug Profiler Snapshot. Нас попросит выбрать файл, переходим по пути где указали запись файлов, у меня по умолчанию это << папка openServer где он установлен >>/userdata/temp/xdebug/

Если всё сделано правильно там будет записанный файл с названием cachegrind.out.<< какие-то цифры >> . Выбираем, ждём когда phpStorm обработает всё и вуаля, у нас есть работа скриптов с высоты.

Выявляем проблемный участок кода

phpStorm показывает логи в красивом и удобном виде. На первом окне смотрим сколько вообще времени заняло выполнение скрипта. Но нас интересует вкладка Call Tree (ниже выделил куда кликать).

И так у нас уже есть какие-то цифры. Раскрываем по одному файлы чтобы понять где лежит проблемный участок. Нас интересует ветка с файлом template-loader.php, нам надо ускорить написанную с нуля тему, а не копать в сторону ядра WP/

Ориентируясь цифрами, сколько процентов какая ветка сожрала, опускаемся до нужного файла и участка кода. В моем случае функция get_heder использовала 42% от всего времени. Смотря ещё глубже нахожу что это функция get_catalog_menu который жрал 36%. Кавабанга!

Файл header.php Опускаемся ниже и находим функцию тяжеловес

Находим файл в котором находится функция. Можно кликнуть по ПКМ и сделать jump to source. В нашем случае это оказался файл menu.php.

Вкратце — функция выбирает каждый раз все 4 000 категории и как-то делая проверки строит из них меню. Каждая проверка условии для одной категории это одно обращение к БД. В целом кусок кода довольно тяжелый.

Разработчик учёл что эта функция сильно нагружает код и сделал кеширование через WP Object Cache. Но не учёл что кеш работает только если сервер поддерживает кеширование и на сайте WP установлен плагин для объектного кеширования. А в моем случае на сервере он не работал и кеш не создавался. Про эту особенность можно прочитать тут.

Решение

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

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

Поверх всего провёл ещё ряд других оптимизаций и настройку сервера (сжатие gzip, время жизни кеша для статики, апдейт версии php до 8.0, очистка базы данных от мусора, вынесение стилей и скриптов в отдельные файлы).

9 секунд на выполнение. Результат после. Выполение занимает

Результаты до/после тут только после исправления всего двух функций. После были выполнены ещё другие мелкие оптимизации, настроен плагин полностраничного кеширования и суммарно для конечного пользователя сайт работает раза 4-5 быстрее. Отклик кешированных страниц занимает

400мс, а не кешированных в зависимости от типа 1,5-2 секунд.

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

Источник