Как оформитить форму комментария в drupal 7

Форма комментария по умолчанию, содержит поля: имя, электронная почта, домашная страница, тему и комментарии. Электронную почту и домашнюю страницу можно отключить в настройках типа контента. Кроме того, можно добавить новые поля к форме и изменить некоторые свои параметры отображения. Но для более продвинутого оформления нужно копать глубже.

В Drupal 7 есть функция hook_form_alter для внесения изменений в форму, прежде чем она отобразится, но эта функция будет вызываться для каждой формы генерируемой Drupal. Поэтому, я предложу использовать функцию hook_form_FORM_ID_alter, так как она вызывается только для конкретной формы с идентификатором form_id. Плюс эта функция вызывается после всех функций переопределения, так что вы будете знать, что ваши изменения не будут отменены в другом месте. Нам остается узнать только form_id формы комментария.

Откат php 5.3.8 до 5.2.7 с поддержкой cgi на CentOS

Добавляем репу Atomic

wget -q -O - http://www.atomicorp.com/installers/atomic.sh | sh

Устанавливаем плагин для yum, который нам позволит устанавливать более старые версии продуктов

yum install yum-allowdowngrade

Сначала необходимо удалить уже установленную php, проверяем

rpm -qa | grep php-

Если что-то вывелось, удалим

yum erase php-*

Устанавливаем php

yum --allow-downgrade -enablerepo=atomic install php-5.2.17

и все зависимые модули: cli, common, gd, mbstring, mysql, pdo, xml. Если какая-то репа нам мешает, отключаем ее через -disablerepo=[reponame]

Совет: c centos.alt.ru php лучше не ставить — он собран с fpm и fastggi не работает с isp, поэтому ставим из atomic php.

Без установки реп, можно скачать сами пакеты и установить их через rpm:
Открываем www6.atomicorp.com/channels/atomic/centos/5/x86_64/RPMS/

Скачиваем пакеты

• php-5.2.17-1.el5.art.x86_64.rpm
• php-cli-5.2.17-1.el5.art.x86_64.rpm
• php-common-5.2.17-1.el5.art.x86_64.rpm
• php-devel-5.2.17-1.el5.art.x86_64.rpm
• php-gd-5.2.17-1.el5.art.x86_64.rpm
• php-imap-5.2.17-1.el5.art.x86_64.rpm
• php-mbstring-5.2.17-1.el5.art.x86_64.rpm
• php-mysql-5.2.17-1.el5.art.x86_64.rpm
• php-pdo-5.2.17-1.el5.art.x86_64.rpm
• php-xml-5.2.17-1.el5.art.x86_64.rpm

Устанавливаем:

rpm --oldpackage -Uvh php*

с разрешением всех проблем в зависимостях.

Проверяем версию php

php -v
PHP 5.2.17 (cli) (built: Jan  7 2011 10:39:29)
Copyright (c) 1997-2010 The PHP Group

Не забудьте рестарнуть apache

service httpd restart

Восстановите php.ini, содержимое прошлого сохранено в файле /etc/php.ini.rpmsave

Ошибки в логах с open_basedir - File() is not within the allowed path(s)

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

PHP Warning: require(): open_basedir restriction in effect. File() is not within the allowed path(s);
PHP Warning: Unknown: open_basedir restriction in effect. File() is not within the allowed path(s);

Оказалось, что проблема в eAccelerator (версия – 0.9.6.1). Для решения проблемы качаем исходники eAccelerator (eaccelerator-0.9.6.1.tar.bz2), открываем файл eaccelerator.c строка 867:


Было:

if (php_check_open_basedir(realname TSRMLS_CC)) {

Стало:

if (php_check_open_basedir(p->realfilename TSRMLS_CC)) {

Diff:

--- eaccelerator.c 2010-06-01 00:21:14.000000000 +0400
+++ eaccelerator.c 2011-06-30 15:24:37.277788184 +0400
@@ -864,7 +864,7 @@
EACCELERATOR_PROTECT();
if (p != NULL && p->op_array != NULL) {
/* only restore file when open_basedir allows it */
- if (php_check_open_basedir(realname TSRMLS_CC)) {
+ if (php_check_open_basedir(p->realfilename TSRMLS_CC)) {
return NULL;
}
EAG(class_entry) = NULL;

Заново компилируем eAccelerator и устанавливаем

phpize && ./configure && make && make install
service httpd restart

Установка Radiant CMS под Windows

Решил установить Radiant CMS работающую под Ruby on Rails.
Нетривиальная задача, превратилась в головоломку.


32-bit Windows
Radiant не работает с последней сборкой Ruby 1.9.1 p378 (RC2). Для стабильной работы лучше использовать Ruby 1.8.7 p249 (RC2) скачать можно Ruby 1.8.7-p249 RubyInstaller Windows.

Занимаемое место mysql

key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads

3 аспекта документирования

Всем известна стандартная мантра программирования «Документируй свой код!» (хотя некоторые разработчики, как оказывается, все еще не следуют ей). Первое, что приходит на ум PHP-программисту, как только речь заходит о документировании кода — это PHP DocBlocks.
DocBlocks — это система для обеспечения последовательности в ваших комментариях и благодатная почва для автоматического создания документации. К тому же, DocBlock, по своей природе, основан на принципах документирования API конкретных функций, классов и т.д., и в этом плане — это превосходная, очень удобная система.
Проблема же заключается в том, что документирование API-функций и их параметров, а также классов, и других аналогичных вещей — это только один из трех важных типов документации, которые необходимы.
В реальности же, слишком много PHP программистов ограничиваются лишь написанием DocBlock'ов, и считают, что их требования по документированию кода полностью выполнены. Используете ли вы PHP DocBlocks или нет, попробуйте сделать так, чтобы убедиться, что вы смогли охватить все три аспекта документирования вашего проекта:

• «Описание реализации» — рассказывает о том, с чего программисту следует начать для выполнения задачи, и как все устроено на высоком уровне.
• Документация API, которая описывает каждый класс и функции в деталях.
• Встроенные комментарии, которые описывают сам код.

Делаем простой Аудит сайта

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