cd /tmp
mkdir php5mysql5
ln -s /opt/local/lib/mysql5 php5mysql5/lib
ln -s /opt/local/include/mysql5 php5mysql5/include

PDO_OCI: Не выбирается Clob при работе в связке nginx+php-fpm

При переносе проекта с apache+mod_php на nginx+php-fpm, столкнулся с довольно непонятной проблемой при работе с Ораклом через PDO. Дело в том что, как я писал раннее, чтобы выбрать значение *LOB поля из Оракла, нужно сделать определенные манипуляции, и получив при fetch’e php_stream, сами данные получить путем stream_get_contents. Так вот, один и тот-же код под apache возвращает валидный stream, и соответственно все хорошо работает, а под nginx + php-fpm - пустую строку. Где копать непонятно, гугл очень немного знает про связку оракл+pdo+php-fpm, не говоря уже об nginx. Может быть у кого-то есть идеи?

Код такой:

function getNewsContent($id) {
    $newsq = $this->DBO->prepare("select id,subject,news_body,create_date,owner_id from news where id=:id");
    $newsq->execute(array(":id" => $id));
    $data = $newsq->fetch(PDO::FETCH_OBJ);
    $data->NEWS_BODY = stream_get_contents($data->NEWS_BODY);
    return $data;
}

если последовать мануалу, и добавить туда bindParam() таким образом:

function getNewsContent($id) {
    $newsq = $this->DBO->prepare("select id,subject,news_body,create_date,owner_id from news where id=:id");
    $newsq->execute(array(":id" => $id));
    #$newsq->bindColumn(3, $lob, PDO::PARAM_LOB);
    $data = $newsq->fetch(PDO::FETCH_OBJ);
    $data->NEWS_BODY = stream_get_contents($lob);
    return $data;
}

то php-fpm вообще вылетает с дампом памяти в логе, и ошибкой OCI-21500, которая по сути является “внутренней ошибкой без описания”. Вобщем вилы, куда копать непонятно, но врагу не сдается наш гордый варяг ))
Если кто-то в курсе, или работал в такой связке - помогите пожалуйста )))

Хозяйке на заметку, или кратко об очевидном, кажущимся неочевидным

Отсутствующие локали

При отсутствии на сервере нужной локали, например ru_RU.CP1251, можно легко её добавить:

localedef ru_RU.CP1251 -i ru_RU -f CP1251

после этого проверяем, появилась ли она, командой

locale -a | grep ru

Переменные окружения

Как известно, большая часть неочевидных проблем в линуксе связана с переменными окружения. Чтобы понять, как так случилось что из консоли ваш демон запускается и работает правильно, а при запуске из init.d что-то не так (например у меня переставал коннектиться к Ораклу, или слетала локаль), достаточно сделать тестовый вывод переменных среды окружения в инит скрипте.

На примере стартового скрипта php-fpm, добавляем в него после #/bin/bash следующую строку:

export > /tmp/envvars

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

Rewrite Rule для CodeIgniter и nginx

В интернетах куча вариантов этих rewrite-rule’ов, у меня же заработал такой вариант (полный конфиг vhost’а):

server {
   listen 80;
   server_name yourhost.com;
   index index.php;
   root /www/yourhost.com/htdocs;
   access_log  logs/yourhost.com_access.log;

   location / {
      #error_page 404 = 404.html;

        if (-f $request_filename) {
            expires max;
            break;
        }

        if ($request_filename !~ (js|css|images|robots\.txt|index\.php.*) ) {
            rewrite ^/(.*)$ /index.php/$1 last;
        }
   }

   location ~ .php$ {
      fastcgi_pass 127.0.0.1:9000;
      fastcgi_index index.php;
      include /usr/local/nginx/conf/fastcgi_params;
   }

  location ~ /index.php/
  {
    include /usr/local/nginx/conf/fastcgi_params;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /www/yourhost.com/htdocs/index.php;
    fastcgi_param  REQUEST_URI      $request_uri;
    fastcgi_param  QUERY_STRING     $query_string;
    fastcgi_param  REQUEST_METHOD   $request_method;
    fastcgi_param  CONTENT_TYPE     $content_type;
    fastcgi_param  CONTENT_LENGTH   $content_length;
    fastcgi_param  HTTP_REFERER     $http_referer;
    fastcgi_pass   127.0.0.1:9000;
  }

}

Ну и в конфиге самого CodeIgniter’a нужно указать что

$config['uri_protocol'] = "REQUEST_URI";

ZCE: Zend Certified Engineer

Поздравьте меня, теперь я - Zend Certified Engineer :)

Экзамен сдавал в Москве, в центре тестирования Интерфейс. Очень хороший, внимательный и отзывчивый персонал. Пришел раньше, меня напоили кофе пока регистрировали, потом отвели в отдельный кабинет с видеокамерами и начался тест :) Скажу сразу, что реальный тест мне показался более сложным чем тестовые которые можно купить на сайте Zend, и к концу теста я был уверен что завалил :) Но оказалось нет, видимо интуиция спасла меня в тех вопросах, ответов на которые я не знал. В целом впечатление от теста непонятные - периодически настолько необоснованно сложные вопросы были, что я разводил руками… Вопросы плана “Какую оциональную переменную (константу)  можно передать такой-то функции, чтобы получилось то-то”. Причем функции супер-редкие, которые не так часто используются. Я считаю что программист - это всетаки не тот, кто вызубрил названия всех функций и аргументов к ним, а тот кто может адекватно проектировать ПО, и грамотно пользоваться мануалами при написании. Не понимаю к чему такое фанатичное стремление сделать из программиста живой мануал по языку.

Но в целом, спасибо Zend’у, Pearson Vue, и Interface.ru - благодаря вам, я - второй в Казахстане сертифицированный PHP Developer :)

P.S. Если кто планирует сдавать - пишите в каменты, я могу выложить набор книжек в PDF для этого дела.

CodeExtinguisher - гламурная административная панель для сайта в два клика

Когда я ругал CodeIgniter за наличие в нем бесполезного scaffolding’а, я не брал во внимание что эта идея даст развитие таким проектам как CodeExtinguisher. А зря. Потому что CodeExtinguisher - инструмент для быстрой генерации административных панелей, что-то вроде скафолдинга, но уже с авторизацией, кучей плагинов и всего прочего. Очень удобно, скажу я вам, очень удобно. Особенно для всевозможных своих сайтов, управление которыми не рассчитано на дурака. Проект довольно некисло развивается, посмотрим что из этого выйдет.

еще один php framework в копилку

onPHP

Xdebug как он есть

Подробнейшее описание конфига XDebug

Баги в Kohana

На часах 7.42 утра, а я еще не уходил с работы…
Очень срочно нужно доделывать проект, в 11 утра презентация.
Зато параллельно с работой над этим проектом нашел очень неприятный баг в Kohana, заключается он в том что глобальный XSS фильтр, на который многие пользователи надеятся, не работает. Совсем. Подробнее здесь.

Обновления Kohana

PHP фреймворк Kohana о котором я уже писал обновился наконец до полноценной версии 2.0.

Для тех кто не в курсе, версия 1.0 была по сути копией CodeIgniter'a, и никаких особых бенефитов не давала. Теперь же полноценный релиз, новый сайт фреймворка, и ожидание нормальной документации. Пробую её в своём новом проекте, посмотрим что из этого получится. По возможности буду описывать свои впечатления. Пока нравятся следующие вещи (в сравнении с CodeIgniter):

• Helpers теперь статические объекты, т.е. есть имитация чего-то вроде NameSpace'ов. Таким образом вы можете иметь одноименные методы в разных хелперах, наследовать их и прочее.
• Поддержка только PHP5. Это очень хорошо, что многие вещи делаются без оглядки на поддержку php4. Я в своих проектах использую только php 5.2+, так что поддержка php4 мне абсолютно не нужна.
• Продуманное именование контроллеров и моделей, таким образом мы можем иметь одноименные модели и контроллеры, в CI приходилось делать например контроллер News, и модель к нему NewsModel. Теперь благодаря тому что контроллеры должны назваться NAME_Controller, а модели NAME_Model, мы можем иметь одноименные модели и контроллеры. Кроме того, логичнее сделано наследование системных классов. Все системные классы имеют суффикс _Core, хотя в вашем коде эти суффиксы нигде не используются. Т.е. скажем ваш контроллер имеет такое определение: class Welcome_Controller extends Controller { } и создав половину контроллеров вы вдруг решили что вам нужно переопределить этот родительский контроллер, унаследовав системный и добавив некоторые функции. В CodeIgniter'e вам бы пришлось создать класс с таким кодом: class MY_Controller extends Controller { } и описывать работу в нем, а во всех своих контроллерах менять class X extends Controller на class X extends MY_Controller. Теперь же, с учетом того что системные классы имеют суффикс _Core, вы просто переопределяете класс Controller таким образом: class Controller extends Controller_Core { } и больше нигде ничего менять не нужно, потому что у вас и так везде шло наследование от класса Controller, просто вместо него подставлялся Controller_Core

Вобщем сделали многое чуть лучше, минусов пока я вижу всего три:

• Очень слабая документация, т.е. её практически нет, только API автоматически сгенерированный из кода
• Слабое по сравнению с CI комьюнити, ввиду малой распространенности
• Есть еще один минус на мой взгляд - этот фреймворк контроллируется комьюнити, а соответственно он очень сильно уязвим к кривым рукам, людей которые не получают за работу над ним заработную плату. Спорно конечно, может быть это и плюс, но мне кажется что CI всетаки более безопасный в этом плане, и количество потенциальных багов в нем должно быть на порядок меньше чем в аналогичном продукте от сообщества энтузиастов.

Еще один framework который стоит посмотреть

Хочу сам не забыть посмотреть, и с вами поделиться заодно: Framework.php (Frog)