forrest :: Blog

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

Отладка 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 хочет, чтобы до него никто ничего не писал в поток вывода. Логично, ведь он отправ

Keywords: php, отладка

Rating: [ 0 ]

ТЕХНИЧЕСКАЯ ДОКУМЕНТАЦИЯ

Cron — запуск программ пользователя в указанное время

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

Как настраивать cron
Примеры использования cron
Как запускать PHP-скрипты по расписанию
Как получать сообщения об ошибках от программ, запускаемых cron
Ограничения
Полезные ссылки

Как настраивать cron

Конфигурирование сценариев cron производится через unix shell. Прежде всего нужно определить какие программы вы хотите запускать и узнать полные пути к ним на диске сервера. Для этого перейдите с помощью команды cd в каталог где находится запускаемая программа и узнайте полный путь к этому каталогу с помощью команды pwd. Путь может выглядеть например как /home/u12345/scripts/script.pl. Убедитесь что файл, который вы хотите запускать, имеет права на чтение+исполнение (r+x) для владельца файла.

Поменять права на нужные можно командой: chmod 750 script.pl

Далее выполните команду crontab -e. Вы окажетесь в текстовом редакторе vi, где сможете вводить текст сценария для cron. Краткая справка по редактору vi:

для вставки текста нажмите i, затем вводите текст
для удаления символов нажмите ESC, а затем наберите x
для выхода из vi без сохранения изменений нажмите ESC, а затем наберите :q!
для сохранения и выхода нажмите ESC, а затем наберите :wq

Задания для cron пишутся по одному в строке. После каждой строки, в том числе после последней или единственной, обязательно нужно нажать enter — иначе задания работать не будут.

Задание для cron выглядит как строка, в начале находятся пять обязательных полей для указания периодичности задания, а далее следует команда, которую нужно запускать: поле1 поле2 поле3 поле4 поле5 команда

Значения первых пяти полей:

минуты — число от 0 до 59
часы — число от 0 до 23
день месяца — число от 1 до 31
номер месяца в году — число от 1 до 12
день недели — число от 0 до 7 (0-Вс,1-Пн,2-Вт,3-Ср,4-Чт,5-Пт,6-Сб,7-Вс)

Для каждого конкретного параметра можно задать несколько значений через запятую. Например, если в поле «часы» написать 1,4,22, то задание будет запущено в 1 час ночи, в 4 часа утра и в 22 часа. Можно задать интервал — 4-9 будет означать, что программу нужно запускать каждый час в период с 4 до 9 часов включительно. Символ '*' означает «все возможные значения». Например, указание '*' в поле «часы» будет означать «запускать каждый час». Символ '/' служит для указания дополнительной периодичности задания. Например, '*/3' в поле «часы» означает «каждые три часа».

Итак, как выглядит простейший сценарий cron: 0 */3 * * 2,5 /home/u12345/script.pl

Скрипт /home/u12345/script.pl будет автоматически запускаться каждые три часа во вторник и в пятницу. Введя такой сценарий в редакторе vi выйдите с сохранением результатов редактирования и, если вы не допустили ошибок, задание будет поставлено на выполнение с указанной периодичностью. Если при редактировании были допущены ошибки, cron сообщит вам о них. Например: /tmp/crontab.xxxxxxx: 1 строк, 9 символов crontab: installing new crontab "/tmp/crontab.xxxxxxx":1: bad minute crontab: errors in crontab file, can't install Do you want to retry the same edit?

Исправьте ошибки и попробуйте сохранить задание опять.

Посмотреть список уже установленных в cron сценариев можно командой crontab -l: -bash-2.05b$ crontab -l 0 */3 * * 2,5 /home/u12345/script.pl

Рекомендация: если требуется запускать какую-то программу один раз в день, особенно если она требует для выполнения больших ресурсов, выполняйте такое задание ночью, в период с 2 до 8 часов — нагрузка на серверы в это время минимальна.

Примеры использования cron

Ниже приводятся примеры заданий для cron. Надеемся, эта информация поможет вам лучше понять работу этой программы. # выполнять задание раз в час в 0 минут 0 */1 * * * /home/u12345/script.pl # выполнять задание каждые три часа в 0 минут 0 */3 * * * /home/u12345/script.pl # выполнять задание по понедельникам в 1 час 15 минут ночи 15 1 * * 1 /home/u12345/script.pl # выполнять задание 5 апреля в 0 часов 1 минуту каждый год 1 0 5 4 * /home/u12345/script.pl # выполнять задание в пятницу 13 числа в 13 часов 13 минут 13 13 13 * 5 /home/u12345/script.pl # выполнять задание ежемесячно 1 числа в 6 часов 10 минут 10 6 1 * * /home/u12345/script.pl

Как запускать PHP-скрипты по расписанию

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

Поскольку не все PHP-программы могут работать через CLI SAPI без предварительной модификации, можно запускать их через wget. Например: /usr/local/bin/wget -O /dev/null -q http://mydomain.mhost.ru/cron.php?action=123

Если в скрипте используются функции require, include, причём в них указаны относительные пути, то в начале выполняемого скрипта используйте вызов функции chdir(), которая задаст текущую рабочую директорию.

Как получать сообщения об ошибках от программ, запускаемых cron

Если при выполнении программы, которая запускается из cron, возникли ошибки, наверняка вы захотите получать сообщения об этих ошибках, чтобы полностью контролировать работу периодически запускаемых заданий. Для этого в начале cron-сценария поместите такую строку: MAILTO=адрес@домен.ru

Конечно, адрес@домен.ru нужно заменить на реально существующий адрес электронной почты куда надо будет доставлять уведомления. Если нужно получать сообщения об ошибках на несколько адресов, укажите все эти адреса через запятую.

Обратите внимание на то, что cron будет присылать по почте то, что выводят запускаемые скрипты. Например, если вы напишете скрипт, который будет печатать строчку «Hello, world» и поставите его на выполнение через cron, вы будете получать по почте письмо со строкой «Hello, world» каждый раз, когда cron будет запускать такой скрипт.

Чтобы избежать этого, например когда текст, выводимый скриптом, вам не нужен, надо добавить в конец строки-сценария для cron символы > /dev/null 2>&1

Полностью строка для cron будет выглядеть так:

Для PHP4:
0 1 * * * /usr/local/php4-clicgi-so/bin/php-cli -q $HOME/script.php > /dev/null 2>&1
Для PHP5:
0 1 * * * /usr/local/php5-clicgi-so/bin/php-cli -q $HOME/script.php > /dev/null 2>&1

Рекомендуем проверять корректность синтаксиса скриптов, которые вы устанавливаете на выполнение через cron. Скрипты могут содержать ошибку, могут неодинаково работать при запуске через веб-сервер и через cron и так далее. Для того, чтобы убедиться что скрипт будет правильно работать через cron, предварительно проверьте его такой командой в unix shell:

Для PHP4:
/usr/local/php4-clicgi-so/bin/php-cli -l script.php
Для PHP5:
/usr/local/php5-clicgi-so/bin/php-cli -l script.php

Если ошибок в скрипте нет, вы увидите сообщение «No syntax errors detected in script.php».

Ограничения

Для программ, которые запускаются через cron, действуют такие же ограничения по потребляемым ресурсам, как для процессов, запускаемых пользователем в unix shell. Речь идет об

Keywords: cron, linux

Rating: [ 0 ]

Permanent logins with PHP sessions

16:09, Monday May 3rd, 2004 • feeling webmasterly

Disclaimer: I think this works, but it's only endured light testing so far. I may be wrong. Please let me know if you think I am.

PHP sessions are a great addition to the application programming environment. The first time I used cookies I used PHP's setcookie() function to roll my own system, which can only be described as flaky. Browsers seem to have an overwhelming disdain for cookies in general, each one requiring a complex set of chicken dances to work. PHP sessions may or may not do lots of clever stuff under the hood to address these problems, but they have always worked 100% reliably for me and that confidence has been enough for me to deploy and forget the technology, something which is critical if we are to get on with the business of developing actual software and not constantly writing our own libraries.

But eventually the time came when I wanted to have the option for people to be logged in permanently (or at least for a very long time, let's say 90 days). Finding a solution to this problem took me a little while, so I thought I'd write it up. I got quite a lot of help from this discussion at the Experts Exchange and obviously the sessions section of the PHP manual.

First piece of knowledge: PHP garbage collects session files when their modified time reaches a predefined timeout, the default being 1440 seconds - about 24 minutes. PHP has a series of INI file settings that govern the sessions system. These allow you, amongst other things, to control this garbage collection, by either raising the timeout, or reducing the probability of collection after that timeout has expired. For my purposes, I wanted the session files to remain intact on disk for up to 90 days (7776000 seconds). The php.ini key for garbage collection is session.gc_maxlifetime. If you have control over your php.ini file, simply locate and alter that value. If you don't, you can change these options via a .htaccess file (see below). It's not enough to change these options using the ini_set function as the value needs to be maintained for all instances of PHP that are working in the session dir.

According to one expert at the Experts Exchange, changing your session.gc_maxlifetime will cause problems when PHP instances running other scripts (e.g. belonging to others on a shared server). This can be fixed by moving the session save path to a different location. This can be acheived with session.save_path parameter.

Presumably, if you set your session.gc_maxlifetime and then move your session path with ini_set(), your sessions will be untouched by other PHP instances, meaning you can use just ini_set to do the initial lifetime change. I haven't tested this however.

I also decided to specify that my sessions should use cookies only. I set both session.use_cookies and session.use_only_cookies to "on" and session.use_trans_sid to "off".

As I don't have access to the php.ini on my production server, I put the following block into the .htaccess for my application:

php_value session.gc_maxlifetime "7776000" php_value session.save_path "sessions" php_value session.use_cookies "on" php_value session.use_only_cookies "on" php_value session.use_trans_sid "off"

OK, so now a user's session will be waiting on the server for them to come back, we have to ensure that the other half of the equation - the browser cookie - will wait just as long.

Second piece of knowledge: session_start() always sends a Set-Cookie header with the default path and no expiry time. No expiry time means that the cookie will be removed when the browser is closed. If session_start() sends a cookie with an expiry we don't want, don't we have something of a chicken egg situation? We need to run session_start() before we can access our session data, but to make the cookie optionally permanent you have to store that somebody wants a permanent cookie somewhere: the session. There are other options, but they are less then ideal. For example you could store the option in a database, but what if the user wants to be permanently logged in on their home machine, but not when they visit your site from a net café?

The solution is to stop and then restart the session with the new timeout parameter. The algorithm looks like this:

Call session_start(), this sends a duff cookie, but it does give us access to $_SESSION
Look in the session for the permanent flag, and copy it
If the user wants a permanent login:
1. Run session_write_close(), this commits the session to file and closes it
2. Use session_set_cookie_params() with just one argument to set the cookie timeout, 7776000 seconds in our case.
3. Run session_start again, this time it sends a good cookie

All you need to do when the user logs in is create the permanent flag in the session if they want it.

This solution has been tested and works on Mozilla, IE5/Mac, Safari, IE6/PC and IE5/PC.

Because two Set-Cookie headers are sent with each response, it's conceivable, even likely, that some browser somewhere will get confused and set the expiry time wrong. In this case it should be possible to do the work of the original session_start() call manually. Get the cookie using the $_COOKIE array, find the session file, parse the file for the perma flag (unserialize() didn't work as I hoped it might have done) and then resume the original process at step 3. I haven't implemented such a system myself as yet, so this approach is untested.

Rating: [ 0 ]

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

«Убийца» Blu-ray уже на подходе

ТЕХНИЧЕСКАЯ ДОКУМЕНТАЦИЯ

Cron — запуск программ пользователя в указанное время

Как настраивать cron

Примеры использования cron

Как запускать PHP-скрипты по расписанию

Как получать сообщения об ошибках от программ, запускаемых cron

Для PHP4:

Для PHP5:

Для PHP4:

Для PHP5:

Ограничения

Permanent logins with PHP sessions