Functional approach in PHP

The code snippet below will only work in PHP-5.3+!.
Isn’t it the famous functional programming with functions as first class citizens, closures and other functional bla-bla?

function one($a = 0) {
    return function(callable $b) use ($a) {
        return call_user_func($b, $a);
print_r(call_user_func(one(1), function ($x) { return $x + 4; } ));

This was created just for fun. As you may see, in place of callable you can put any valid PHP callable, a form ['Class', 'method']

Use your imagination for other real things, but also try to stay not cursed later by those who will inherit your untraversable codebase :LOL:

[SOLVED] Upgrading from PHP 5.5 to PHP 5.6 on Ubuntu 12.04 LTS

Recently I had to upgrade PHP version on the build server based on Ubuntu 12.04 LTS to PHP 5.6 At that moment there was PHP 5.5 installed on the server. Everything should have been as easy and promising as described, for example, in this post. Yes, it was going well to the moment

sudo apt-get dist-upgrade

Then dpkg claimed unmet dependencies… You know, as usual. I decided — f…k it, I will remove existing php and everything related. Simple removal with

sudo apt-get remove php*

did not work fine and stuck on removing phpmyadmin.

That guysexited with an error code 10 being reported from its post-remove script. After pretty short googling, I found the solution which worked for me.

The similar shit happened with php5-imagick package, so the solution I used was similar to phpmyadmin removal. Afterwards, I checked for presence anything starting with or inlcuding php:

sudo dpkg -l | grep php

Everything was clean. OK, here we go…

sudo apt-get clean && sudo apt-get autoclean
sudo apt-get udpate && sudo apt-get upgrade && sudo apt-get dist-upgrade

…and still the same error in result:

Reading package lists… Done Building dependency tree Reading state information… Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: php5 : Depends: libapache2-mod-php5 (>= but it is not going to be installed or libapache2-mod-php5filter (>= but it is not going to be installed or php5-cgi (>= but it is not going to be installed or php5-fpm (>= but it is not going to be installed E: Unable to correct problems, you have held broken packages.

I tried install with -f flag, package-by-package. Nothing worked. The final unmet dependency was:

sudo apt-get -f install php5-json
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
 php5-json : Depends: phpapi-20121212
E: Unable to correct problems, you have held broken packages.

And here I stuck, as googling at this point didn’t help me at all… I visited the home of php5.6 PPA hoping to find something there. And a brilliant idea came to my mind — I should check APT’s sources list! I saw this files inside /etc/apt/sources.list.d:

/etc/apt/sources.list.d$ ll
total 32
drwxr-xr-x 2 root root 4096 Jan  5 11:12 ./
drwxr-xr-x 6 root root 4096 Jan  5 11:11 ../
-rw-r--r-- 1 root root  138 Jan  5 10:32 chris-lea-node_js-precise.list
-rw-r--r-- 1 root root  138 Jan  5 10:32
-rw-r--r-- 1 root root   60 Jan  5 10:32 nginx-stable-lucid.list
-rw-r--r-- 1 root root   60 Jan  5 10:32
-rw-r--r-- 1 root root  134 Jan  5 10:32 ondrej-php5-5_6-precise.list
-rw-r--r-- 1 root root  134 Jan  5 10:32
-rw-r--r-- 1 root root  126 Jan  5 10:32 ondrej-php5-precise.list
-rw-r--r-- 1 root root  126 Jan  5 10:32

I realised, the problem could be that packages were overwritten from older php-5.5, which apparently was installed manually to the server some time earlier. Once I removed these two files:


and updated apt one more time, I was able to install PHP 5.6 as usual:

sudo apt-get install php5
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  shtool libc-client2007e node-node-uuid libicu52 libicu48 libv8- libmcrypt4 libt1-5 mlock libssl-dev libvpx1 libssl-doc zlib1g-dev libgd3 libev4 libv8-dev libc-ares2 libev-dev
Use 'apt-get autoremove' to remove them.
The following extra packages will be installed:
  libapache2-mod-php5 php5-cli php5-json php5-readline
Suggested packages:
The following NEW packages will be installed:
  libapache2-mod-php5 php5 php5-cli php5-json php5-readline
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.
Need to get 5,575 kB of archives.
After this operation, 18.9 MB of additional disk space will be used.
Do you want to continue [Y/n]? Y

The main idea of this story, before adding new custom repository for PHP, make sure you removed any other old ones! Good luck and happy coding!

PHP 5.4 установка из DotDeb

Если Вам вдруг захотелось использовать последнюю версию php-5.4.x на Debian squeeze (где по-умолчанию из пакетов устанавливается php-5.3.x),
будет проще и быстрее установить его с помощью apt-get.
Первым делом необходимо добавить новые источники пакетов в файл sources.list:

deb squeeze all
deb-src squeeze all
deb squeeze-php54 all
deb-src squeeze-php54 all

Вы может получить такую ошибку при обновлении кеша:

W: GPG error: stable Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY E9C74FEEA2098A6E
W: GPG error: squeeze Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY ABF5BD827BD9BF62

в этом случае необходимо добавить ключи и повторно обновить кеш:

gpg --keyserver --recv-key 89DF5277
gpg -a --export 89DF5277 | sudo apt-key add -
gpg --keyserver --recv-key ABF5BD827BD9BF62
gpg -a --export ABF5BD827BD9BF62 | sudo apt-key add -
sudo apt-get update

Ну а теперь просто обновите установленные пакеты и обязательно нужно проапгрейдить дистрибутив:

sudo apt-get upgrade
sudo apt-get dist-upgrade

Как скомпилировать и установить php-5.4.x на Debian OS (squeeze)

Недавно я попытался установить последнюю версию PHP 5.4.x (на момент написания статьи это было 5.4.10) на мою стабильную ОС Debian OS (v6.0-squeeze-32bit).
Как вы возможно знаете, стабильная версия Debian имеет по-умолчанию в своих репозиториях версию PHP-5.3.4. Я же захотел использовать встроенный в PHP-5.4 веб-сервер.
Тогда мне казалось, что установка PHP-5.4 будет более быстрым процессом, чем конфигурированию виртуального хоста Apache. Да, я настолько ленив! 🙂
Что ж, забегая наберед, должен сообщить, что вся процедура заняла у меня 2-2.5 часа времени пока я смог запустить свои скрипты.
По правде говоря, то был первый раз когда я компилировал PHP из исходников, зато теперь я чувствую, что получил замечательный опыт в этом деле!
Ладно, давайте пройдемся по процессу пошагово.

Во-первых, вам может понадобиться установка Linux библиотеки «libxml2-dev» (хотя я не помню зачем..)
А, вспомнил! Похоже, что вы не сможет сконфигурировать PHP установщик без этой библиотеки!

sudo apt-get install libxml2-dev

Также я уверен, что большинству веб-разработчиков прийдется работать с БД из скриптов (скажем, MySQL), а в частности с расширением PDO.
Поэтому, вам необходимо скомпилировать PHP с такими опциями:

configure --with-pdo-mysql --with-mysql

(обратитесь к за детальным пояснением)

Обычно, хороший разработчик активно использует дебаггер в его каждодневной работе. Как нам всем известно, самым популярным PHP отладчиком является xdebug. Это расширение может быть установлено из pecl репозиториев.
Но, прежде чем просить pecl установить для нас xdebug, удостовертесь, что у вас установлены пакет разработки php5-dev.
С этим пакетом поставляется phpize, что является необходимым условием для установки PHP пакетов через pecl.
Если у вас еще не установлен php5-dev, вы получите следующее сообщение об ошибке:

ERROR: `phpize’ failed

и вот вам команда в помощь:

sudo apt-get install php5-dev

После этого, вы сможет установить xdebug с помощью pecl:

sudo pecl install xdebug

Идем дальше. Скажем, вам приходится работать с документами, написаными не только на английском, но и на других языках (Итальянский, Португальский, Русский, Немецкий и т.д.). И предположим также, что вам необходимо обрабатывать даты в различиных форматах, который встречаются в таких документах (кстати, об этом будет моя другая публикация).
Здесь на помощь приходит расширение php5-intl! По этой ссылке — — вы найдете детальную информацию.
В двух словах, чтобы включить это расширение, необходимо указать опцию:

configure --enable-intl

Если вдруг конфигуратор PHP сообщит о следующей ошибке:

«configure: error: Unable to detect ICU prefix or no failed. Please verify ICU install prefix and make sure icu-config works.»

вам понадобится установить пакет Linux для работы с интернациональными данными (icu — International Components for Unicode):

apt-get install libicu-dev

Для того, чтобы иметь возможность загружать удаленные http ресурсы из ваших php скриптов, понадобится включить php5-curl.
У меня не получилось сделать это без дополнительных телодвижений, ибо я получил сообщение об ошибке следующего содержания:

configure: error: Please reinstall the libcurl distribution

Если у вас похожая ситуация, то попробуйте установить такие Linux пакеты:

sudo apt-get install libcurl4-gnutls-dev

(спасибо to

Если вам необходимо работать с мультибайтовыми кодировками и использовать функции PHP с префиксом mb_*,
понадобится включить и эту опцию:

configure --with-mbstring

Итого, после несколько часовой борьбы мне все же удалось сконфигурировать PHP необходимым образом.
Окончательный вариант выглядел так:

sudo ./configure --with-pdo-mysql --with-mysql --with-curl --enable-intl --enable-mbstring=all

Что ж, как я и сказал, я надеялся, что установка PHP-5.4 займет у меня меньше времени, чем конфигурирование виртуального хоста Apache.
Как же я ошибался!.. 🙂
Тем не менее, я ни капельки не сожалею о своем выборе, ибо теперь я чувствую себя намного уверенне в области конфигурирования и установки PHP.
Мой профессиоальный уровень вырос и я открыл для себя новые интересные вещи.

Буду рад ответить на ваши вопросы и комментарии.

Form builder — entity field: «Class BundleAliasName:EntityClassName does not exist «

После обновления symfony-2.1 до версии из транка (symfony-2.1.0-beta4) отвалилась форма, в которой я использовал поле типа entity, где в качестве класса сущности указал не полный путь к классу, а через bundle alias:

                 'class' => 'BundleAliasName:EntityClassName',
                 'multiple' => true

Код выбрасывал исключение с сообщением

«Class BundleAliasName:EntityClassName does not exist»

Если прописать полный путь через пространство имен:

    'class' => 'Full\Bundle\Path\Entity\EntityClassName',

то все работало хорошо.
Я открыл по этому поводу тикет и оказалось, что дело в версии Doctrine! Обновление до 2.3 решило проблему!
Огромное спасибо автору комментария на гитхабе Christophe Coevoet!

Как обновить проект с symfony-2.0 до symfony-2.1

Изначально я создавал свой проект на версии symfony 2.0 без vendors (standard edition). Все зависимости были установлены через

php bin/vendors install

Проект находился в git-репозитории.

Сразу оговорка — на момент написания статьи версия symfony 2.1 находилась в стадии бета-тестирования.
Тем не менее, основная тенденция уже была понятна и значительных изменений в АПИ не предвиделось.
Одно из ключевых нововведений в symfony 2.1 — использование Composer.
На вебсайте фреймворка Symfony можно найти описание процесса создания нового проекта, но нет информации как обновить существующий.

Итак, начнем-с.
Изначально я попытался просто скопировать содержимое файла composer.json, находящегося в директории фреймворка Symnofy на github, и выполнить команду

php composer.phar update

но там нет всех зависимостей, необходимых для нормального функционирования проекта.
Потому я просто решил создать новый «пустой» проект:

php composer.phar create-project symfony/framework-standard-edition path/

в отдельной ветке git-репозитория и потом перенести изменения из ветки с версией symfony-2.0.

Признаюсь, что пришлось порешать конфликты в файлах apps/AppKernel.php, файлах config.yml, security.yml и других.
Но это не было слишком сложным заданием.
Также необходимо проапгрейдить все дополнительные bundle, которые вы используете до соответствующих версий под symfony-2.1
К примеру, для FOSUserBundle (

    "require": {
        "friendsofsymfony/user-bundle": "*"

и далее выполнить команду

php composer.phar update

Таже необходимо сделать изменения согласно этой инструкции в файлах форм и других местах. Тут уже дело персональное — смотря кто какие фичи использовал в своем проекте.

Таким образом, после всех проделанных манипуляций проект запустился успешно.
Из видимых изменений — добавили красивостей к web-debug-toolbar — появились тултипы со сводной информацией по каждому из разделов, которые показываются при наведении мышью на соответствующую иконку.

П.С.: Вот на днях встретил другой вариант апгрейда до symfony-2.1:

Composer — minimum-stability по-умолчанию считается stable

Сегодня (4 июля 2012) Composer изменяет значение по-умолчанию свойства stability с dev на stable.
Подробнее здесь и здесь.
Что это значит? Что по-умолчанию Composer будет игнорировать пакеты RC, beta, alpha или dev.
Столкнулся я с этим, когда попытался проапдейтить зависимости проекта, использующего symfony-2.1.x, которая на момент написания заметки находится на стадии бета-тестирования.

rodush@debian:~/gtrs$ php composer.phar update
Updating dependencies
Your requirements could not be solved to an installable set of packages.

Вот что подсказал скрипт:

Potential causes:
— A typo in the package name
— The package is not available in a stable-enough version according to your minimum-stability setting
see for more details.

Чтобы обойти данную проблему, самый простой способ — это в файл composer.json добавить свойство
"minimum-stability": "dev"

symfony 2.0 FOSUserBundle — ошибка «Could not load type»

Если вы используете FOSUserBundle вместе с symfony 2.0 и вам понадобилось переопределить какую-либо из форм, идущих «в комплекте» с этим плагином,
то, без сомнения, вы прочитали эту заметку:
После обновления вашей страницы может случиться прискорбная ситуация — сообщение об ошибке «Could not load type ….» (вместо многоточия ваш alias для кастомной формы).
Вроде бы и в файле app/config.yml все верно с отступами (имеется ввиду конфигурация fos_user сервиса), и файл конфигурации вашего сервиса service.xml (service.yml) (в CustomUserBundle) описан правильно, и везде совпадает alias, getName() и т.п…. а все та же ошибка. Бывало? Не беда! 🙂 Есть решение вашей проблемы! Читайте далее, и все окажется просто!

Чтобы понимать и правильно использовать services и dependency injection в symfony 2.x, крайне рекомендую прочитать это и это. Суть в том, что для того, чтобы фреймворк symfony увидел ваши сервисы и расширения, необходимо предоставить информацию о конфигурации вашего bundle.
Сделать это можно двумя способами.

1. Стандартная конфигурация сервиса.
Вы можете описать ваши сервисы в файле конфигурации (services.yml, services.xml, etc.) который находится внутри вашего бандла и потом просто заимпортировать этот файл в основной файл конфигурации всего приложения. Это действительно простой, быстрый и неимоверно эффективный способ.

- { resource: parameters.ini }
- { resource: security.yml }
- { resource: @CustomUserBundle/Resources/config/services.xml }

2. Семантическое описание конфигурации.
Данный способ используется для конфигурации ядра symfony. Основная идея заключается в том, что вместо того, чтобы заставлять пользователя переопределять все параметры, вы предоставляете ему возможность задать лишь некоторые, специально созданные опции. Ваша роль, как разработчика банда, заключается в том, чтобы разобрать такую конфигурацию и подгрузить необходимые сервисы внутри класса «Extension». Используя данный метод, вам больше не нужно импортировать кофигурационные ресурсы в ваш основной файл конфигурации проекта — этим займется файл расширения (Extension).
Этот способ подробно описан во второй из приведенных выше ссылок.

Итак, возвращаясь к природе нашей ошибки. Суть дела вот в чем: может случиться так, что «кастомный» бандл для Пользователя (User) вы создавали вручную (путем копирования из существующего бандла необходимых файлов и директорий), а не при помощи консольной команды симфони (generate:bundle).
При этом, вы могли забыли создать директорию DependencyInjection и в ней файл CustomUserExtension.php и Configuration.php.
Или же, если вы не думали использовать возможности семантической конфигурации, то забыли заимпортировать файл конфигурации CustomUser сервиса в ваш основной файл проекта.

Вот и все. Теперь вы знаете о двух возможных путях решения данной проблемы. Дальше дело за вами, какой из способов выбрать — простой (через импорт) или гибкий (через расширение и сементическую конфигурацию).

Для PHP-5.4 Debian — нет suhosin, xcache, xdebug расширений

Сегодня проапгрейдил свою Debian OS 6.0 (настроено apt-pinning).
Среди прочих апдейтов при выполнении dist-upgrade привалили и обновления для ряда установленных модулей php5.  Обновился и сам PHP, собственно до версии 5.4.0-2. Но… тут начались непонятные проблемы — ни один локальный сайт не работал! В логах были непонятные ошибки, скажем, для сайта, основанного на фреймворке  YII было сообщение:

[Sun Mar 25 13:32:51 2012] [error] [client] PHP Fatal error:  Call to undefined function (null)() in /home/web/ccc/frontend/index.php on line 4

А на той строке 4 ничего не было особенного, окромя dirname(__FILE__)!
Порыскав-поискав в интернете похожие ошибки, не нашел ничего. Запостил баг на
Но дело-то неприятное! Ничегошеньки ведь не работает…
Начал копаться дальше. Попробовал запустить скрипты php из консоли, дабы проверить — неужто dirname() убрали? 🙂 И обнаружил еще ряд замечательных уведомлений warnings:

rodush@rdushko:/var/www$ php test.php
Failed loading /usr/lib/php5/20090626+lfs/ /usr/lib/php5/20090626+lfs/ cannot open shared object file: No such file or directory
PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib/php5/20100525+lfs/’ — /usr/lib/php5/20100525+lfs/ cannot open shared object file: No such file or directory in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library ‘/usr/lib/php5/20100525+lfs/’ — /usr/lib/php5/20100525+lfs/ cannot open shared object file: No such file or directory in Unknown on line 0

А дальше директива dirname() отработала и подключился файл, который я подключал.
Заглянув в директорию, указанную в сообщении, я обнаружил, что таких библиотек действительно нету!
Пока решил не морочить голову: допишут — обновлюсь; решил убрать конфиги php для данных библиотек.
Они расположены в директории /etc/php5/conf.d/
просто переименовал все конфиги, на которые не пришли обновления файлы с суффиксом «old» (на будущее пригодятся :), думаю)

suhosin.ini.old xdebug.ini.old xcache.ini.old xhprof.ini.old

Попробовал вызов из консоли — не ругается php. Попробовал зайти на сайты в броузере и — о чудо! — всё работает!!
Вот такие вот причуды могут быть, если php ругается на невозможность подключить дополнительные модули-библиотеки.

Отслеживание ошибок и уведомлений PHP

Иногда бывает необходимо отследить некритические ошибки, возникающие в работе РНР скрипта (E_WARNING, E_NOTICE, etc.) и куда-то их грамотно собрать.
К примеру, мы хотим сделать валидацию XML файла с помощью XMLReader (кстати, об этом, думаю, можно рассказать в отдельной публикации). В случае, если XML невалидный, то выбросить исключение, прекратив дальнейшую работу.
Все ошибки валидации выдаются через WARNING-сообщения.
Для того, чтобы получить такое сообщение можно поступить следующим образом:

// Track the errors (to be able to store the PHP error message)
$oldConfigValue = ini_set('track_errors', '1');
while ($xmlReader->read()) {} // полностью читаем XML
if (!$xmlReader->isValid())
  throw new Exception('XML does not conform to schema. ' . $php_errormsg);
// Set back track_errors setting:
ini_set('track_errors', $oldConfigValue);

Здесь мы сначала устанавливаем директиву РНР 'track_errors' (Отслеживать ошибки) в TRUE (1). А далее — magic! 🙂
Есть, оказывается, такая чудесная встроенная переменная $php_errormsg, которая и содержит в себе сообщения об ошибках (warnign, notice, и пр.)
Когда данная штуковина нам уже не нужна, мы можем вернуть прежнюю директиву на место, т.к. сохранили её предыдущее значение в переменной $oldConfigValue
Т.о. мы имеем осмысленное сообщение о том, почему же наш XML не прошел валидацию по нашей же схеме.