Старая знакомая ситуация: есть что-то, какой-то сервис, отдающий массивы PHP в формате функции var_export(), либо исторически сложилось так что что-то в системе отдает оформленные в код PHP массивы.
Например, ваш скрипт получает строки вида:
$test = "array('gmt' => 'Europe/Moscow',
'sudia3' => '',
'sudia1' => '',
'sudia2' => '',
'pos1' => '4-2-3-1',
'color1' => '#f00',
'pos2' => '4-4-1-1',
'color2' => '#000',
);";
2 марта тихо и незаметно выпустили PHP 5.4.0, Новый релиз PHP.
Основные вещи которые нас затронут, и которые надо учитывать при настройке серверного ПО в том числе:
Данная ситуация довольно редкая, однако все же встречается. Есть некая переменная, для которой надо посмотреть ее структуру.
Мы начинаем делать
var_dump($fields);
и садимся в лужу, видя сообщение в логе сервера:
[Thu Feb 23 16:21:07 2012] [error] [client 127.0.0.1] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 78045652 bytes) in /web/site1/includes/theme.inc on line 1080, referer: http://localhost/site1/
Не считаю, что тестирование в принципе может что-то показать о знаниях, тем не менее:
Можно немного размять мозги. :)
Пришлось настраивать Drupal, работающий в следующей конфигурации:
В интернет открыт легковесный https-прокси(nginx), а сам Drupal вертится на сервере apache2 с mod_php. На apache поднят mod_rpaf, все как полагается, однако, сложность такой схемы в том, что соединение с вебсервером Apache2 идет по протоколу HTTP, а не HTTPS. Соответсвенно работающие на сервере скрипты PHP, в нашем случае Drupal, работают так, словно взаимодействие идет по HTTP, что проявляется в некорректных URL на сайте, невозможности авторизоваться и других проблемах.
После анализа модуля i18n было решено его установить и провести эксперимент с переводом части содержимого сайта на английский язык.
Теперь, по мере моих возможностей, каждая новая статья на русском языке, будет сопровождаться на ее переводом на английский. На данный момент есть определенные проблемы "целостности" контента, но я полагаю, они будут решены, а англоязычные пользователи смогут читать статьи сразу на английском здесь.
Согласно статистике на drupal.org, за последние 2 недели было порядка 40 инсталляций моего модуля для правильной работы с временными зонами - dst. Модуль был сделан для Drupal 5 и Drupal 6, которые нормально не поддерживали работу с местным временем. В Drupal 7 эта проблема была решена на уровне ядра, и надо признать более красиво, чем я ее решал с моим модулем :).(правда я делал такой патч, чтобы минимально затронуть текущий функционал и ничего не сломать).
Задача: в Drupal 6 есть модуль, для которого надо написать обработчик меню, выводящий контент таким образом, что загружены все системные CSS и JS, но при этом от между тэгами <body> и </body> находится только контент хандлера меню.
Данная задача нужна, например когда необходимо вывести определенный контент без оформления в iframe или в отдельном окне, но при этом сохранить полную работоспобность Javascript.
Решение оказалось на поверхности.(далее код для drupal 6)
Пусть модуль называется mymod.
Git - мощнейшая система ведения версий исходных кодов, написанная автором ядра Linux, Линусом Торвальдсом.
Одна из разработчиков ядра - Анжела Байрон, известная на drupal.org под ником webchick, описала очень удобный поиск "ошибочного" коммита, который привел к появлению бага в программе с использованием команды git bisect.
Я полагаю, что пример будет полезен тем, кто работает с гитом. Читать здесь.
