Список полезных инструментов для php разработчика

Сегодня, уважаемый читатель, я предлагаю продолжить изучение программирования на php посредством фреймворка Kohana 3.1. Данную статью и видеоурок я посвящу теме публикации материалов из админки .

План действий на сегодня:

• В админке создать форму добавления материалов. Форма добавления будет содержать выпадающий список с именами категорий (в выбранную категорию будет добавляться публикуемый материал) и область ввода текстового содержимого самого материала (textarea).
• К области ввода содержимого материала прикрутить визуальный редактор CKEditor .
• Обезопасить вводимый материал от внедрения JavaScript-сценариев. Есть специальная библиотека, очищающая контент от JavaScript, называется HTML Purifier (проблема возможного внедрения вредоносного JavaScript в контент сайта описана ниже).

Видеоурок

С момента подключения визуального редактора возникает проблема возможного внедрения вредоносного JavaScript в контент . Дело в том, что визуальный редактор изменяет форматирование текста путем добавления HTML-тегов. Соответственно, для сохранения форматирования контента мы должны отправить в БД HTML-код, полученный в результате работы визуального редактора, без замены HTML-тегов текстовыми сущностями (иными словами без “прослешивания” PHP-функцией htmlspecialchars). На ряду с HTML-разметкой в БД запросто может быть отправлен вредоносный JavaScript, который успешно выполнится на странице отображения материала.

Решение проблемы внедрения JavaScript - подключение библиотеки фильтров HTML Purifier. Адаптированную версию Purifier для Kohana 3.1 можно скачать на GitHub .

Поясню процесс подключения HTML Purifier к Kohana 3.1:

• Скачанный с GitHub архив необходимо распакавать в папку kohana\www\modules\htmlpurifier\
• Скачать с оф. сайта HTML Purifier свежую версию библиотеки и скопировать ее содержимое в папку kohana\www\modules\htmlpurifier\vendor\htmlpurifier\
• Добавить инструкцию по подключению нового модуля Purifier в файл bootstrap.php: найти код "orm" => MODPATH."orm", и сразу под ним дописать строку "htmlpurifier" => MODPATH."htmlpurifier".

Теперь мы получили возможность использовать метод Security::xss_clean($content) для очистки содержимого переменной $content от JavaScript. Данный метод непосредственно будет применен в листинге 3 модели Materials (см. ниже).

Листинг 2. Код контроллера, обрабатывающий сохранение материала в БД

If(isset($_POST["materialsavebtn"])) { $categoryId = Arr::get($_POST, "categoryId", ""); $content = Arr::get($_POST, "content", ""); $material = ORM::factory("material"); $material->addMaterial($categoryId, $content); Request::initial()->redirect("admin"); }

Как видно из строки 7, модель Material (которую мы создавали в ) должна быть дополнена методом addMaterial(), непосредственно осуществляющего сохранение материала в БД. Код метода addMaterial() приведен в листинге 3.

Листинг 3. Метод сохранения материала, расширяющий возможности модели Material

Public function addMaterial($categoryId, $content) { $this->category_id = $categoryId; $this->content = Security::xss_clean($content); $this->save(); }

Видите новый метод в строке 4? Это как раз та самая защита от внедрения JavaScript в контент сайта. Теперь любой код, написанный в тегах ..., будет удален.

Пришло время показать очень удобный способ заполнения полей ctime и mtime таблицы materilals (поля хранят время создания и изменения материала соответственно).

Достаточно в начале объявления модели Material написать две строки:

Protected $_created_column = array("column" => "ctime", "format" => TRUE); protected $_updated_column = array("column" => "mtime", "format" => TRUE);

Kohana автоматически подставит время создания или модификации записи в БД в Unix time формате.

• Tutorial

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

Xdebug Debugger and Profiler Tool - расширение PHP. Требует установки на сервер и настройки. Может отображать: стек вызовов функций, распределение памяти. Возможности: профайлинг, анализ покрытия кода, защита от бесконечной рекурсии, интерактивная отладка скриптов. ПО для визуализации логов xdebug: Webgrind – веб-интерфейс для профайлинга Xdebug, написанный на PHP, MacGDBp – Mac OS X клиент, который позволяет отлаживать PHP приложения при помощи Xdebug. Linux GUI . Бесплатный. Интегрируется с многими IDE. См . При включении опции в php.ini:

Html_errors = On
будет форматировать вывод var_dump() и сообщения об ошибках.

Xhprof - расширение PHP от facebook. Требует установки на сервер и настройки. Позволяет собирать время выполнения каждой функции, использование памяти, время ожидания, количество вызовов и многое другое. Это расширение доступно из репозитория PECL . Почитать документацию можно тут [тыц] . Так же . Из преимуществ сильно не грузит систему, можно ставить на бой. Бесплатный.

DBG (PHP Debugger and Profiler) - расширение PHP. Требует установки на сервер и настройки. Позволяет работать на тестовом или/и рабочем сервере и отлаживать скрипты локально или удаленно, из IDE или консоли. Платная/бесплатная версии.

ZendDebug - расширение PHP, входит в состав Zend Studio (платная IDE). Требует установки на сервер и настройки. Позволяет практически все тоже, что и xdebug, GUI в IDE Zend Studio или Zend Server. Платный. Чуть ниже рассмотрим его более подробно.

Memtrack - расширение PHP. Позволяет искать утечки памяти. Удобно проверять скрипты запускаемые по крону или в качестве демона. Бесплатный. См. [тыц]

APD Advanced PHP debugger - расширение PHP. Слабый конкурент xdebug, но имеет в себе возможности memtrack. Плохо интегрируется с IDE, однако имеет консольный интерфейс (см. [тыц ]). Бесплатный.

DTrace + PHP - расширение PHP. Низкоуровневая отладка. См. [тыц] . Так же не нужно забывать о существовании и прочих системных отладчиков, которые порой способны показать где, так сказать, «собака порылась». Например
strace -p 1111
анализ системных вызов скрипта, с PID=1111. Также сетевые анализаторы wireshark (Windows), ngrep , tcpdump (Linux) - для анализа сетевого трафика, протоколов и т.д.

FirePHP - класс, написан на php + расширение для FireFox. Дает возможность посылать отладочные сообщения в консоль Firebug с помощью вызова php методов. Вся информация посылается через заголовки X-FirePHP-Data, тем самым не пересекаясь с основным контентом страниц. Бесплатный. См.

php-console - написан на php + расширение для Google Chrome. Аналог FirePHP, только для Google Chrome, но несколько с другим функционалом. Бесплатный. См. php-console

PHP_Debug класс, написан на php. Помогает в отладке PHP кода, показывает путь выполнения скрипта, отображает все переменные, время выполнения, включенные файлы, выполненные запросы, watch переменные… Эта информация собирается во время выполнения скрипта, и отображается по его завершению и потом может быть использована в любой момент. Бесплатный.

Pinba - сервис мониторинга и статистики в реальном времени. См

. Бесплатная.

Отладчики в современных CMS/CMF/Framework . Их не рассматриваем, т.к. зачастую они имеют специфику и разработаны под конкретную оболочку, что делает не возможным использование их извне (IDE) или применять без значительных изменений в своих разработках.

Для сбора и анализа узких мест в ваших приложениях иногда может пригодится методика централизованного хранении syslog, см .

Вернемся к ZendDebug. Так как я в основном пользуюсь Zend Studio, то мне наиболее удобно с ним работать. Он позволяет сразу понять ход выполнения скрипта, поддерживает навигацию по коду из IDE. Не нужны никакие сторонние инструменты, кроме IDE. Это действительно удобно, так сказать настроил один раз и пользуешься.

Отладка и профилирование скриптов в Zend Studio возможна как минимум двумя способами при помощи xdebug или ZendDebug. Только вот профилирование сайта с xdebug у меня не заработало, пишет что нельзя так - только отладка.

Про локальную отладку кода писали еще во времена Zend Studio 5.5 . С тех времен мало что изменилось. Но я столкнулся с проблемой, когда web сервер и отлаживаемый код находится на удаленном сервере. Часто такие песочницы закрыты извне, а отрыты только нужные для работы порты. Но если к такой песочнице есть доступ по SSH, то настроить ZendDebug все таки можно, не мешая фаерволу выполнять свою функцию.

Забегая вперед отмечу, что для этого нужно будет создать SSH туннель. Немного о том, зачем SSH туннель нужен в этом случае.

По умолчанию Zend Studio инициирует сеанс удаленной отладки, отправив HTTP запрос на отладочный сервер. Этот запрос содержит параметры обратного адреса (IP-адрес и номер порта), который ZendDebug (установленный на сервере) использует при запуске нового подключения к Zend Studio, чтобы ретранслировать информацию об отладке. Кстати, инициализировать сам сеанс отладки можно как из IDE, так и из браузера установив компонент, поставляемый вместе с Zend Studio, будет довольно удобно.

Обычная отладочная сессия будет иметь место, например, в случае, когда код, WEB сервер и IDE находятся на локальном компьютере.

Но зачастую WEB сервер разделен с IDE брандмауэрами, маршрутизаторами, прокси-серверами т.д. Тут-то и пригодится SSH туннель.

В случае с туннелем процесс установления сеанса отладки состоит из двух основных этапов:
- создания SSH туннеля;
- настройки Zend Debugger, для передачи своего трафика через SSH туннель.

Схема отладочной сессии через SSH туннель примет вид:


Обычная отладочная сессия через SSH туннель

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

Создание SSH туннеля в Linux или Mac OS X можно в командной строке:
ssh :127.0.0.1: @пример:

User@workstation:~> ssh -R 10137:127.0.0.1:10137 user@debugserver user@debugserver"s password: