Все +59

PHP → Отладка PHP средствами Firebug

FirePHP


Отладка PHP-скриптов определенно недостаточно освещена в интернете. Потому многие, очень многие довольствуются print_r-ками. Очевидный недостаток такого способа - нельзя отладить AJAX, SOAP-сервисы, генераторы картинок и вообще скрипты, не отдающие непосредственно HTML-документов.

Javascript-разработчики используют для отладки Firebug. Как я им всегда завидовал. Лепота - выделенная консоль, net-монитор, отладчик, и все это в любимом браузере.

Так вот, нашел такое расширение Firebug - FirePHP. Оно позволяет выводить информацию в консоль Firebug непосредственно из PHP. Делается это довольно простым вызовом:


  require('FirePHP.class.php');

  $firephp = FirePHP::getInstance(true);

  $firephp -> fb("hello world! i'm warning you!",FirePHP::WARN);

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

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

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

Насчет буферизации: на самом деле FirePHP хочет, чтобы до него никто ничего не писал в поток вывода. Логично, ведь он отправляет заголовки. Поскольку, вероятно, вы и так используете буферизацию, чтобы отправлять свои собственные заголовки, то это не проблема. Я имею ввиду, не обязательно использовать именно ob_start(), как в руководстве.

Не советую рассовывать вызовы fb() прямо в код. Подумайте, что будет с ними на продакшн-сервере. Правильнее внедрить FirePHP в систему отладки - например, уже есть расширения для Zend Framework и Symfony.

И я в свой отладчик интегрировал. Улет.

crossposted
+68
4 июля 2008, 23:10
coldFlame

комментарии (69)

  • В понедельник заюзаю, сенкс.
    • "Замечания" по юзабельности статьи. Для таких статей уже бы сразу вставляли кнопки популярных веб-закладок, чтобы прочитал и не отходя от статьи нажал добавить в закладки. :)
      Кроссбраузерный аналог не подскажите?
  • это то о чём я так всегда хотел?!!1111адинадин
    • вот такой вот неадекватный комментарий получился из-за переизбытка эмоций :(
  • Как это отладка недостаточно освещена?! Есть замечательные отладчики в PHPEd и Zend'е.
    • не совсем то ) есть масса людей, которые не используют эти среды. а вот подобные средства в самом браузере - класс
      • есть масса людей, которые пишут свой код, проекты разработаны с нуля и небольшой командой с ровными руками — у них дальше принтэр проблемы не доходят независомо от сложности проекта. А вот если в контору попадает допустим чужой комок индокода, где не знаешь откуда ноги растут, тогда и нужны отладчики, чтобы понять где какие переменные появляются/меняются.
        • Еше лучшие команды с более "ровными руками" используют var_dump, поскольку заботливо относятся к типизации.
          Ну и еще полезно знать про $e->getTrace() если код написан в стиле try/catch.
          • еще следует упомянуть error_log
            • Правильно, а если его перенаправить в syslog, например, на свой комп, будет тоже достаточно удобно.
          • один ньюанс - в PHP нет ни трай ни кэтч
            • да ну?
              • признаю, есть, застрелите меня
            • Уверяю, в пятом есть. Во всяком случае конструкции такие имеются :)
              • вы не поверите, но они даже работают :)
  • Да, в firefox можно добавить что угодно. С утра обязательно попробую.
  • Спасибо за находку, не всегда есть возможность заюзать extension ну удаленном сервере для дебага.
  • Интересное решение, спасибо. А преимущество в том, что все это в браузере.
    • Главное, что данные передаются в хедерах, а код самой страницы не портится.
  • здорово! интересно как оно окажется на практике.
  • вот если опишите, как её к какой нибудь CMS`ке подключить - будет круто!
    • ОК, завтра опишу. Изначально хотел выложить код своего дебаггера, но решил, что много букв :)

      А вообще, что в чужой CMSке отлаживать-то?
      • свои вставки на основе встроенных в CMSку функций и классов
  • Еще для FF есть Zend Studio Toolbar
  • $array = array("key1"=>"madesst","key2"=>"какой-то русский контент","key3"=>array(1,2,3));
    fb($array, "TestArray", FirePHP::LOG);
    // с русским языком у меня это чудо не дружит чего-то =\
    • Какая кодировка?
    • с юникодом отлично работает.
      FirePHP 0.1.0.1
      Firebug 1.2.0b3
  • > Отладка PHP-скриптов определенно недостаточно освещена в интернете. Потому многие, очень многие довольствуются print_r-ками.
    Меня лично вполне устраивает Xdebug в связке с Eclipse PDT. Хотя по сути это все таки немного другие задачи решает, так что FirePHP тоже может пригодиться.
  • Читал и даже на практике у нас на работе в цмску давно интегрирован (уж незнаю самописный или этот самый) вместе с XDebug, но на практике мне лично удобней сразу на экране видеть дебаг, чем открывать firebug-консоль. Если надо что-бы клиент не видел - так поставьте огрнаничение по IP или по лишнему GET параметру. Возможности Zend debugger'а увы не осилил.
  • Отличная штука!
    Можно использовать хоть с фреймворками, хоть просто с голым пхп. Да еще хоть через классы, хоть через процедуры. Дампы - просто красота. Очень универсально.
    Автору — спасибо! я даже не задумывался о возможности существования такого инструмента.
  • может быть я старомоден, но дальше try&catch и die(var_dump($var)); у меня не уходило =)
  • Эх! Отмечу 4 июля красным. Столько правильных и полезных постов на хабре.
  • А еще есть такая офигенная штука, как плагин к вижал студии, с отличным дебагером для пхп и джава скриптов, который зовется VS.Php. Все-таки на мой взгляд в студии несколько приятней работать чем в том же самом эклипсе.
    • Прелесть описанного в посте инструмента в том, что он позволяет вполне комфортно отлаживать скрипты не только на локальной машине, но и на реальном удаленном сервере!
      ЗЫ: после прочтения данной заметки почти всю ночь прикручивал FirePHP куда в голову стукнет, потом сидел и радовался)))
      • имхо, сомнительная затея отлаживать скрипты на боевом сервере :/
        • а если это необходимо? например, чтобы использовать боевое окружение?
          • не буду настаивать, каждый сам делает так, как считает нужным, но дебажить крупный проект на боевом сервере я никогда не стану, а когда что-то идет не так, точку падения можно и через логи узнать и решать проблему на отдельной машине =)
            • Дело вкуса, но мое мнение — удобнее увидеть в обозревателе практически в реальном времени чем копать логи. И вовсе не обязательно из этого делать дыру.
              Некоторые вещи от безысходности приходится делать вообще без средств отладки… но это уже к вебу не относится…
        • Когда что-то идет не так, то приходится и на боевом смотреть…
    • вот здорово! в студии безусловно удобнее. вот только стоит $100.
      • А кто сказал, что всё хорошее должно быть бесплатно? :)
        • может, Ричард Столлмен? :)
          на самом деле, не такие большие деньги, ибо VS сама по себе во многом удобнее эклипсы.
          • Ага, вот и я о том же...
  • Спасибо, установлю, испробую
  • PHPed всё равно удобнее=)
  • Клевая вещь, ме понравилось, что всякий мусор не вываливается непосредственно в тело сайта, а все, что нужно можно посмотреть в Firebug. Мы даже внедрили эту штуку в свой фрэймворк :-)
  • Давно искал нечто подобное. Большое человеческое спасибо!
  • Этот FirePHP огромная дыра в безопасности веб приложения! Не понимаю чего его так нахваливают....

    Удаленная отладка без авторизации значит, что каждый может дебажить вас, думаю врятли это хорошая идея. К тому-же код напичканный fb вызовами на продакшене это полохо.
    В чистом виде я бы его не использовал уж очень сыроват.
    FirePHP думаю отлично подойдет ленивым фрилансерам с кривыми проектами IMHO xD
    • По сути ты прав, только вот заглючил у меня зенд дебаг. Без локалки не хочет работать -хоть ты тресни. А бывает нужно просто строчку вывести чтоб не прерывать ничего.
    • это не дыра, а инструмент отладки.
      никто не заставляет использовать его без авторизации. все на усмотрение разработчика.
      про авторизацию, кстати, на официальном сайте сказано, типа, неплохо бы ее использовать.
      если уж говорить про дыры, то дырами является все что используется без головы.
    • А не надо его использовать на продакшене. И не будет дыры в безопасности.
  • Вот блин, никаких хидеров нету, почему так - непонятно. Все вроде работает, все повключал, а хидеров нету.
  • Поставил, удобный вывод отлаживаемых данных. Вопрос насколько он сильно используемый в реальной работе...
    По сути мы делаем те же принтр, только в более читабельной форме.
    Спасибо автору за статью.
  • Надо будет затестить на досуге.
    А ее самому уже не получится расширить?
    • Получится. А со стороны PHP к ней вообще можно накрутить все, что угодно.
      • тогда беру на вооружение сей инстрУмент
  • я пользуюсь своим классом на подобии log4j в java, где в конфиги приложения выставляю LEVEL: ERROR,DEBUG,WARN,INFO и сотвественно в моем коде пишу logger->info("log string"),logger->error("my errror") и тд
    • Zend_Log
      Как раз делает тоже самое.
    • Есть уже написанный log4php, как раз по мотивам )
      http://incubator.apache.org/log4php/
  • а что за расширение для симфони, не подскажете?
  • Дополнение.
    Расширение для фреймворка Code Igniter - здесь.
  • классно, спасибо
  • Это замечательно! Именно то, чего давно хотелось. Долой отладочные принт_р! :)
  • Действительно, хорошее решение.
    А касаемо ptint_r и var_dump - есть еще dBug.php (http://dbug.ospinto.com/).
    Бесплатно, с открытым кодом, наглядно.
    Для тех, кому FirePHP по каким-либо причинам не пришелся (может из-за огнеЛиса).
  • сложно как-то всё

    Drupal devel модуль использует Krumo.

    traceback, ob