Ars Longa, Vita Brevis » ошибка

Core Control: лечим некорректное отображение методов в модуле cron

Vladimir — Fri, 10 Sep 2010 16:18:52 +0000

Есть один замечательный плагин для разработчиков, называется Core Control. Данный плагин позволяет контролировать различные аспекты работы WordPress: транспорт HTTP (например, расширение PHP HTTP, cURL, потоки PHP и т.п.), протоколирование HTTP-запросов, контроль обновлений ядра, плагинов и тем, способы доступа к файловой системе, а также отображение запланированных задач.

Работая над одним плагином, в котором усиленно использовалось планирование заданий, мы столкнулись с проблемой, что cron-модуль плагина Core Control неправильно отображает запланированные задания, если задание представлено не обычной функцией, а методом класса:

К счастью, исправляется довольно легко.

--- core-control/modules/core_control_cron.php.orig 2010-09-10 09:20:08.000000000 -0400
+++ core-control/modules/core_control_cron.php 2010-09-10 09:31:38.000000000 -0400
@@ -138,8 +138,23 @@
if ( isset($GLOBALS['wp_filter'][$hook]) ) {
$functions = array();
foreach ( (array)$GLOBALS['wp_filter'][$hook] as $priority => $function ) {
- foreach ( $function as $hook_details )
- $functions[] = (isset($hook_details['class']) ? $hook_details['class'] . '::' : '') . $hook_details['function'] . '()';
+ foreach ( $function as $hook_details ) {
+ $hook = '';
+ $f = $hook_details['function'];
+ if (is_array($f)) {
+ if (is_object($f[0])) {
+ $hook = get_class($f[0]);
+ }
+ else {
+ $hook = $f[0];
+ }
+ $hook .= '::' . $f[1];
+ }
+ else {
+ $hook = $f;
+ }
+ $functions[] = $hook . '()';
+ }
}
echo '
Hooked functions: ' . implode(', ', $functions);
}

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

Связанные записи

Как заставить Google XML Sitemaps дружить с WordPress MultiSite

Wandering Soul — Mon, 23 Aug 2010 15:35:56 +0000

При попытке использования плагина Google XML Sitemaps с WordPress 3.0 в конфигурации multisite, плагин обижается и работать категорически отказывается:

Google XML Sitemaps is not multisite compatible.
Unfortunately the Google XML Sitemaps plugin was not tested with the multisite feature of WordPress 3.0 yet. The plugin will not be active until you disable the multisite mode. Otherwise go to active plugins and deactivate the Google XML Sitemaps plugin to make this message disappear.

Это раздражает. Но к счастью, проблема решаема.

Открываем файл wp-content/plugins/google-sitemap-generator/sitemap.php, ищем строки:

//Check for 3.0 multisite, NOT supported yet!
if((defined('WP_ALLOW_MULTISITE') && WP_ALLOW_MULTISITE) || (function_exists('is_multisite') && is_multisite())) {
if(function_exists('is_super_admin') && is_super_admin()) {
add_action('admin_notices', array('GoogleSitemapGeneratorLoader', 'AddMultisiteWarning'));
}
return;
}

и комментируем их. Должно получиться нечто такое:

/*
//Check for 3.0 multisite, NOT supported yet!
if((defined('WP_ALLOW_MULTISITE') && WP_ALLOW_MULTISITE) || (function_exists('is_multisite') && is_multisite())) {
if(function_exists('is_super_admin') && is_super_admin()) {
add_action('admin_notices', array('GoogleSitemapGeneratorLoader', 'AddMultisiteWarning'));
}
return;
}
*/

Сохраняем, наслаждаемся.

Связанные записи

DoS для PHP через imap_fetchbody

Wandering Soul — Mon, 16 Aug 2010 07:04:55 +0000

Как оказалось, если передать функции imap_fetchbody() параметр $secton, длина которого больше 1004 байт, PHP падает по segmentation fault. На некоторых конфигурациях с применением некоторых усилий (подробности, понятное дело, разглашаться не будут) получалось вместе с PHP положить и Apache.

Пример кода, убивающего PHP:

imap_fetchbody($imap_handle, $message_number, "3.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.0");

Предполагается, что $imap_handle — ресурс, возвращенный функцией imap_open(), $message_number — номер существующего сообщения в почтовом ящике.

Анализ посмертного дампа памяти показывает, где происходит сбой:

$ gdb /usr/bin/php core
...
Program terminated with signal 11, Segmentation fault.
#0 memcpy () at ../sysdeps/x86_64/memcpy.S:398
398 ../sysdeps/x86_64/memcpy.S: Нет такого файла или каталога.
in ../sysdeps/x86_64/memcpy.S
(gdb) bt full
#0 memcpy () at ../sysdeps/x86_64/memcpy.S:398
No locals.
#1 0x0000000000678788 in _estrndup (s=0x7ff1797aaf4e "", length=2136037704) at /usr/include/bits/string3.h:52
No locals.
#2 0x00007ff1799ce292 in zif_imap_fetchbody () from /usr/lib/php5/20090626/imap.so
No symbol table info available.
#3 0x00000000006e611a in zend_do_fcall_common_helper_SPEC (execute_data=0x7ff17f3e3068) at /build/buildd/php5-5.3.2/Zend/zend_vm_execute.h:313
opline = 0x7ff17f5141a8
should_change_scope = 200 '\310'
...

Видно, что ошибка произошла в функции zif_imap_fetchbody() (что соответствует PHP-функции imap_fetchbody()), когда та вызвала функцию estrndup() для пустой строки (адрес строки — 0x7ff1797aaf4e), но при этом передав ошибочную длину строки (length=2136037704). Значение length примерно равное двум гигабайтам в любом случае должно настораживать.

Пересоберём php5-imap с отладочной информацией:

CFLAGS="-g3 -O2"
export CFLAGS
phpize
./configure --with-kerberos --with-imap-ssl PHP_OPENSSL="yes"
make && sudo make install

Повторим тест. PHP по-прежнему должен упасть. На этот раз у нас будет больше информации о сбое:

(gdb) bt full
#0 memcpy () at ../sysdeps/x86_64/memcpy.S:398
No locals.
#1 0x0000000000678788 in _estrndup (s=0x7ff8881ddf4e "", length=2381609288) at /usr/include/bits/string3.h:52
No locals.
#2 0x00007ff8884013c2 in zif_imap_fetchbody (ht=3, return_value=0x7ff88df465d0, return_value_ptr=, this_ptr=, return_value_used=) at /opt/php-imap-5.3.2/php_imap.c:2361
streamind = 0x7ff88df46670
msgno = 1
flags = 0
body = 0x0
sec = 0x7ff88df468c8 "3.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1."...
sec_len = 1005
len = 140705510226248

Теперь у нас есть номер строки, где произошел сбой (файл /opt/php-imap-5.3.2/php_imap.c, строка 2361).

(gdb) frame 2
#2 0x00007ff8884013c2 in zif_imap_fetchbody (ht=3, return_value=0x7ff88df465d0, return_value_ptr=, this_ptr=, return_value_used=) at /opt/php-imap-5.3.2/php_imap.c:2361
2361 RETVAL_STRINGL(body, len, 1);
(gdb) print len
$1 = 140705510226248
(gdb) print &len
$2 = (long unsigned int *) 0x7ffffa9bdd80
(gdb) frame 1
#1 0x0000000000678788 in _estrndup (s=0x7ff8881ddf4e "", length=2381609288) at /usr/include/bits/string3.h:52
warning: Source file is more recent than executable.
52 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest));
(gdb) print s
$3 = 0x7ff8881ddf4e ""
(gdb) print length
$4 = 2381609288

О локальной переменной len сказать что-либо трудно, так как функция __builtin___memcpy_chk() могла ее перетереть. Придется исправлять код.

Находим в php_imap.c в функции imap_fetchbody строку

body = mail_fetchbody_full(imap_le_struct->imap_stream, msgno, sec, &len, (argc == 4 ? flags : NIL));

и исправляем её на

printf("len before = %ld\n", len);
body = mail_fetchbody_full(imap_le_struct->imap_stream, msgno, sec, &len, (argc == 4 ? flags : NIL));
printf("len after = %ld\n", len);

Пересобираем, запускаем, получаем:

len before = 140425249339720
len after = 140425249339720
Segmentation fault (core dumped)

Становится видно, что по каким-то причинам функция mail_fetchbody_full() может вернуть пустую строку, но при этом не установить len в 0.

Исправление тривиально: находим

unsigned long len;

Заменяем на

unsigned long len = 0;

Пересобираем, устанавливаем, запускаем — voilà, ошибка исчезла, php больше не падает.

Результат: полчаса потраченного времени, ошибка исправлена, php не падает.

Связанные записи

Исправление ошибки в INSERT INTO … SELECT в Kohana 3 при использовании конфигурации базы данных, отличной от default

Wandering Soul — Thu, 12 Aug 2010 07:40:55 +0000

Ситуация: нужно выполнить запрос вида

INSERT INTO `table` (`col1`, `col2`) SELECT * FROM `table` WHERE `col1` <> 0;

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

Например:

// application/config/database.php
// Важно, чтобы в конфигурации default нельзя было подключиться к серверу
return array(
'test' => array(
'type' => 'mysql',
'connection' => array(
'hostname' => 'localhost',
'database' => 'test',
'username' => 'username',
'password' => 'password',
'persistent' => FALSE,
),
'table_prefix' => '',
'charset' => 'utf8',
'caching' => FALSE,
'profiling' => TRUE,
),
);
?>

// application/classes/controller/welcome.php

class Controller_Welcome extends Controller
{
public function action_index()
{
$this->request->response = DB::insert('test', array('col1', 'col2'))
->select(DB::select()->from('test')->where('column1', '<>', '0'))
->compile(Database::instance('test')) . "\n";
}
}

?>

Важно, чтобы правая часть условия в where() была строкой.

В результате если мы запустим проект, то получим что-то вида:

INSERT INTO `test` (`column1`, `column2`) ErrorException [ 2 ]: mysql_connect(): Access denied for user 'www-data'@'localhost' (using password: NO) ~ MODPATH/database/classes/kohana/database/mysql.php [ 56 ]

Связано это с особенностью реализации метода Kohana_Database_Query_Builder_Insert::compile():

public function compile(Database $db)
{
// Start an insertion query
$query = 'INSERT INTO '.$db->quote_table($this->_table);

// Не интересно
// …

if (is_array($this->_values))
{
// Не интересно
// …
$query .= 'VALUES '.implode(', ', $groups);
}
else
{
// Add the sub-query
$query .= (string) $this->_values;
}

return $query;
}

Строка $query .= (string) $this->_values; вызывает метод compile() для SELECT, но так как конфигурация базы данных не передаётся, используется конфигурация default.

Самое простое исправление очевидно: заменить строку

$query .= (string) $this->_values;

на

$query .= $this->_values->compile($db);

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

Связанные записи

Upstart, fork и daemon

Vladimir — Fri, 23 Apr 2010 22:49:10 +0000

У Upstart есть одна известная ошибка: неверное использование expect fork/expect daemon может подвесить initctl, после чего всякие start/stop/restart/reload просто перестанут работать. Для полноты картины отмечу, что такой подвисший сервис не получится остановить и через /usr/sbin/service или /etc/init.d. Весёлая ошибка, но это еще не всё.

Есть еще одна тонкость: если программа использует fork(), то в конфигурационном файле upstart должна присутствовать строка expect fork. По аналогии можно подумать, что если программа использует daemon(), то в конфигурационном файле upstart должна присутствовать строка expect daemon. А вот и нет!

Я всегда полагал, что вызов daemon() — это, грубо говоря, последовательность fork() + setsid() + fork(). Даже неоднократно видел такую реализация daemon() в скриптах autotools.

Но, как оказалось (по крайней мере в eglibc), daemon() выполняет только один вызов fork():

int
daemon(nochdir, noclose)
int nochdir, noclose;
{
int fd;

switch (__fork()) {
case -1:
return (-1);
case 0:
break;
default:
_exit(0);
}

if (__setsid() == -1)
return (-1);

if (!nochdir)
(void)__chdir("/");

if (!noclose) {
struct stat64 st;

if ((fd = open_not_cancel(_PATH_DEVNULL, O_RDWR, 0)) != -1
&& (__builtin_expect (__fxstat64 (_STAT_VER, fd, &st), 0)
== 0)) {
if (__builtin_expect (S_ISCHR (st.st_mode), 1) != 0
#if defined DEV_NULL_MAJOR && defined DEV_NULL_MINOR
&& (st.st_rdev
== makedev (DEV_NULL_MAJOR, DEV_NULL_MINOR))
#endif
) {
(void)__dup2(fd, STDIN_FILENO);
(void)__dup2(fd, STDOUT_FILENO);
(void)__dup2(fd, STDERR_FILENO);
if (fd > 2)
(void)__close (fd);
} else {
/* We must set an errno value since no
function call actually failed. */
close_not_cancel_no_status (fd);
__set_errno (ENODEV);
return -1;
}
} else {
close_not_cancel_no_status (fd);
return -1;
}
}
return (0);
}

Таким образом, если программа использует daemon() для демонизации, безопаснее начинать с expect fork. Или смотреть в реализацию daemon(). Другой вариант — не использовать upstart, пока его не допилят до вменяемого состояния.

Мне нравится сама идея upstart, но текущая реализация во многом оставляет желать лучшего. В результате имеем зоопарк: традиционные initrc-скрипты (которые далеко не всегда просто перевести в upstart) и скрипты upstart. Грустно.

Связанные записи

Как подружить Yet Another Photoblog и объектный кэш

Vladimir — Thu, 08 Apr 2010 00:18:47 +0000

Один из пользователей плагина WP File Cache сообщил о конфликте с плагином Yet Another Photoblog (YAPB), проявляющейся в выдаче сообщения об ошибке вида

Catchable fatal error: Object of class YapbImage could not be converted to string in /wp-includes/formatting.php on line 427

Хотя с первого взгляда на код YAPB становится ясно, что виноват ну никак не WP File Cache, проблема тем не менее остаётся и требует решения.

Для локализации подобных проблем нужно получить трассу вызовов при помощи функции debug_backtrace(): результат, как правило, подсказывает, в каком направлении нужно копать.

В данном случае мы видим, что функция esc_attr() получает вместо строки объект класса YapbImage. Это происходит из-за того, что в объекте, переданном функции sanitize_post(), присутствует еще один объект (поле image).

Сам по себе объект внутри объекта записи/страницы в кэш попасть не может. Следовательно он либо помещается специально, либо по незнанию. Идём в функцию get_posts() и смотрим, из какой группы кэша берутся данные. Из группы posts ($_post = wp_cache_get($post, 'posts')). Дальше дело техники: смотрим, где используется wp_cache_xxx() с группой posts и какие фильтры, могущие повлиять на результат, вызываются. Смотрим, на какие события вешает фильтры плагин, анализируем результат. И приходим к месту ошибки. Просто, когда знать, как.

Есть в WordPress особый фильтр — называется the_posts. Он вызывается после получения данных о записях из БД, но перед помещением результата в кэш. Соответственно, все изменения над записями, внесённые данным фильтром, при использовании объектного кэша будут глобальными. В частности, такое происходило с плагином auto_more.

YAPB устанавливает свой обработчик для данного фильтра:

В этом обработчике в объект записи и добавляется тот злополучный YapbImage, о который спотыкается esc_attr().

С причиной ошибки разобрались, переходим к лечению.

Целью метода _filter_the_posts() было добавление объекта с информацией о картинке к записям, которые будут отображаться на странице (честно говоря, я не совсем понимаю, почему это нельзя было сделать в обработчике the_content).

В данном случае можно вместо фильтра the_posts использовать событие loop_start. В общем случае они не эквивалентны, но если записи выводятся только внутри The Loop, то работать будет.

Открываем файл lib/Yapb.class.php, ищем строку

add_filter('the_posts', array(&$this, '_filter_the_posts'));

Заменяем на

add_action('loop_start', array(&$this, '_filter_the_posts'));

Затем ищем метод _filter_the_posts и исправляем его на такой:

Очищаем кэш и наслаждаемся прекрасной работой

PS: актуально для любого плагина объектного кэширования, будь то WP File Cache, SJ Object Cache или любой другой плагин.

Связанные записи

Быдлокодеры хреновы :-(

Vladimir — Sat, 27 Mar 2010 14:26:58 +0000

Возился сейчас с расширением Memcache; после очередного изменения кода сервер ушёл в глухую защиту и отказался реагировать на внешние раздражители.

Лог Apache пестрил записями [error] child died with signal 11, в логах ядра было сказано, что PHP было очень плохо:

Mar 27 07:20:02 snowboarding kernel: [501607.032560] php5[11934]: segfault at 7fc86965d190 ip 00007fc86965d190 sp 00007fc8689850e8 error 14 in libgpg-error.so.0.4.0[7fc86c916000+3000]
Mar 27 09:35:02 snowboarding kernel: [509707.070086] php5[870]: segfault at 7f58775f7190 ip 00007f58775f7190 sp 00007f587691f0e8 error 14 in librt-2.10.1.so[7f587b60e000+7000]

Причём PHP мог вызвать сегфолт в любой библиотеке, что придавало охоте на баг особую пикантность. К счастью, откат кода помог локализовать баг.

Ошибка сегментации вызывалась следующим кодом:

$this->memcache = new Memcache();
$result = false;
if (!empty($data['server'])) {
foreach ($data['server'] as $x) {
$result |= $this->memcache->addServer($x['h'], $x['p'], true, $x['w']);
}
}

Опытным путём было установлено, что когда $x['w'] (вероятность выбора данного сервера) равна нулю, PHP вылетал с ошибкой сегментации при первом же вызове Memcache::get() (кстати, при отрицательном значении веса выдаётся предупреждение и PHP остаётся жив). Не поленились разработчики проверить на отрицательное значение. Но почему проверку на ноль не реализовали? Могли бы хотя бы указать допустимый диапазон значений. Козлы

Буду пробовать вместо Memcache расширение Memcached — надеюсь, что там есть нормальная проверка на ошибки.

Мораль наступающим на те же грабли: данные нужно проверять. А то результату можно не обрадоваться.

Update: bug report.

Связанные записи

Simple Tags 1.7.4.4: The New Bugs

Vladimir — Tue, 23 Mar 2010 14:04:55 +0000

Сегодня наконец-то появилось время обновить старые плагины; в их числе оказался и Simple Tags. Честно говоря, версия 1.7.4.4 меня разочаровала: автор сломал автоматические ссылки меток. Теперь они не работают даже для английского языка.

Резюмируя: в данной версии нужно исправить:

автоматические ссылки меток;
поддержку многобайтовых символов в автоматических ссылках;
вызов register_uninstall_hook() при каждом обращении к блогу.

Проблема с автоматическими ссылками возникла из-за невнимательности автора:

$this->randomArray($this->link_tags);

//...

// only continue if the database actually returned any links
if ( isset($link_tags) && is_array($link_tags) && count($link_tags) > 0 ) {

Метод randomArray() теперь не возвращает массив (как это было в предыдущих версиях плагина), а изменяет тот массив, который передан ему в параметрах ($this->link_tags). Но если раньше результат $this->randomArray($this->link_tags) присваивался переменной $link_tags, то теперь эта переменная исчезла, и условие в if теперь всегда ложно.

Патч для плагина (unified diff):

diff -uwdBrN simple-tags/inc/client.php simple-tags.new/inc/client.php
--- simple-tags/inc/client.php 2010-03-23 14:01:55.000000000 +0200
+++ simple-tags.new/inc/client.php 2010-03-23 15:14:40.000000000 +0200
@@ -122,8 +122,8 @@
}

// Shuffle array
- $this->randomArray($this->link_tags);
-
+ $link_tags = $this->link_tags;
+ $this->randomArray($link_tags);

// HTML Rel (tag/no-follow)
$rel = $this->buildRel( $this->options['no_follow'] );
@@ -157,8 +157,9 @@
}

$filtered = ''; // will filter text token by token
- $match = "/\b" . preg_quote($term_name, "/") . "\b/".$case;
- $substitute = '( sprintf( __('Posts tagged with %s', 'simpletags'), $term_name ) )."\">$0";
+ $quoted = preg_quote($term_name, "/");
+ $match = '/(\PL|\A)(' . $quoted . ')(\PL|\Z)/u'.$case;
+ $substitute = '$1( sprintf( __('Posts tagged with %s', 'simpletags'), $term_name ) )."\">$2$3";

// for efficiency only tokenize if forced to do so
if ( $must_tokenize ) {
diff -uwdBrN simple-tags/inc/inc.functions.php simple-tags.new/inc/inc.functions.php
--- simple-tags/inc/inc.functions.php 2010-03-23 14:01:55.000000000 +0200
+++ simple-tags.new/inc/inc.functions.php 2010-03-23 15:09:06.000000000 +0200
@@ -4,6 +4,7 @@
*
*/
function SimpleTags_Install() {
+ register_uninstall_hook (dirname(__FILE__) . '/simple-tags.php', 'SimpleTags_Uninstall' );
$options_from_table = get_option( STAGS_OPTIONS_NAME );
if ( $options_from_table == false ) {
$options = (array) include( dirname(__FILE__) . '/default.options.php' );
diff -uwdBrN simple-tags/simple-tags.php simple-tags.new/simple-tags.php
--- simple-tags/simple-tags.php 2010-03-23 14:01:55.000000000 +0200
+++ simple-tags.new/simple-tags.php 2010-03-23 15:07:42.000000000 +0200
@@ -3,7 +3,7 @@
Plugin Name: Simple Tags
Plugin URI: http://redmine.beapi.fr/projects/show/simple-tags
Description: Extended Tagging for WordPress 2.8 and 2.9 ! Suggested Tags, Mass edit tags, Autocompletion, Tag Cloud Widgets, Related Posts, Related Tags, etc!
-Version: 1.7.4.4
+Version: 1.7.4.4.1
Author: Amaury BALMER
Author URI: http://www.herewithme.fr
Text Domain: simpletags
@@ -23,6 +23,7 @@
Contributors:
- Kevin Drouvin (kevin.drouvin@gmail.com - http://inside-dev.net)
- Martin Modler (modler@webformatik.com - http://www.webformatik.com)
+- Vladimir Kolesnikov - http://blog.sjinks.pro/

Todo:
Both :
@@ -55,9 +56,8 @@
require( STAGS_DIR . '/inc/tpl.functions.php'); // Templates functions
require( STAGS_DIR . '/inc/widgets.php'); // Widgets

-// Activation, uninstall
+// Activation
register_activation_hook(__FILE__, 'SimpleTags_Install' );
-register_uninstall_hook (__FILE__, 'SimpleTags_Uninstall' );

// Init ST
function simple_tags_init() {

Для тех, кто патчи не любит, есть исправленная версия плагина (из исходного архива также удалены скриншоты): скачать Simple Tags 1.7.4.4.1

Связанные записи

Сбой OpenJDK при использовании Eclipse в Ubuntu Lucid Lynx

Vladimir — Tue, 09 Mar 2010 08:02:07 +0000

Симптом: Eclipse молча погибает при редактировании файла, в /var/log/kern.log появляется подобное сообщение об ошибке:

Mar 9 09:11:44 sjinks kernel: [350411.627132] java[19570] trap int3 ip:7ff3fbd74302 sp:7ff42741b030 error:0

Ключевые слова: java trap int3. Если они есть в логе, с большой вероятностью вы читаете про ту самую ошибку

Багтрекер Eclipse сообщает, что сбой возникает из-за ошибки в XULRunner 1.9.1.

Есть два решения проблемы:

Поставить XULRunner 1.9.2 из mozilla-daily ppa и добавить -Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner-1.9.2.1pre в eclipse.ini (после -vmargs). После данной операции eclipse.ini будет выглядеть примерно так:

-startup
plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.0.200.v20090519
-product
org.eclipse.epp.package.cpp.product
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
-vmargs
-Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner-1.9.2.1pre
-Dosgi.requiredJavaVersion=1.5
-XX:MaxPermSize=256m
-Xms40m
-Xmx256m
Второй вариант проще: перед запуском Eclipse установить переменную окружения GRE_PATH в абсолютно левый путь
Например, у меня Eclipse запускается так:

export GDK_NATIVE_WINDOWS=true
export GRE_PATH=/tmp/aaaaaaaaaaaa
/opt/eclipse/eclipse

После выполнения любой из двух операций всё работает просто замечательно.

Связанные записи

Ошибка в ORM Kohana 3 при использовании префиксов таблиц

Vladimir — Fri, 19 Feb 2010 11:00:51 +0000

Ситуация: имеем две таблицы: пользователи и подписки:

CREATE TABLE prefix_users (
id INTEGER NOT NULL PRIMARY KEY,
name VARCHAR(255) NOT NULL
);

CREATE TABLE prefix_subscriptions (
id INTEGER NOT NULL PRIMARY KEY,
user_id INTEGER UNSIGNED NOT NULL,
some_data TEXT NOT NULL
);

Один пользователь может иметь несколько подписок, одна подписка может принадлежать только одному пользователю.

Настройки соединения с базой данных (application/config/database.php) имеют следующий вид:

return array(
'default' => array(
'type' => 'mysql',
'connection' => array(
'hostname' => 'localhost',
'username' => 'user',
'password' => 'pass',
'persistent' => FALSE,
'database' => 'database',
),
'table_prefix' => 'prefix_',
'charset' => 'utf8',
'caching' => FALSE,
'profiling' => TRUE,
),
);

Модели в Kohana 3 будут иметь следующий вид:

// application/classes/model/user.php
class Model_User extends ORM
{
protected $_has_many = array(
'subscriptions' => array(
'foreign_key' => 'user_id',
'model' => 'Subscription',
),
);
}

// application/classes/model/subscription.php
class Model_Subscription extends ORM
{
protected $_belongs_to = array(
'user' => array(
'foreign_key' => 'user_id',
'model' => 'User',
),
);
}

Допустим, что в контроллере у нас есть вызов наподобие

ORM::factory('Subscription')->with('user')->find_all();

Что произойдёт? А ничего хорошего:

Database_Exception [ 1054 ]: Unknown column 'prefix_user.id' in 'field list' [ SELECT `prefix_user`.`id` AS `user:id`, `prefix_user`.`name` AS `user:name`, `prefix_subscriptions`.* FROM `prefix_subscriptions` LEFT JOIN `prefix_users` AS `user` ON (`prefix_user`.`id` = `prefix_subscriptions`.`user_id`) ORDER BY `prefix_subscriptions`.`id` ASC ] ~ MODPATH/database/classes/kohana/database/mysql.php [ 183 ]

Почему? Модуль ORM предполагал, что запрос будет выглядеть так:

SELECT `user`.`id` AS `user:id`, `user`.`name` AS `user:name`, `subscriptions`.*
FROM `subscriptions`
LEFT JOIN `users` AS `user` ON (`user`.`id` = `subscriptions`.`user_id`)
ORDER BY `subscriptions`.`id` ASC

Так бы и было, если бы таблицы не имели префикса. ORM передаёт Database поля в виде user.id, Database их экранирует в `user`.`id`. Проблема в том, что Database ничего не знает о псевдонимах таблиц (users AS user в JOIN), а ORM ничего не знает о префиксах таблиц. Поэтому Database с чистой совестью добавляет префикс ко всему, что находится в именах слева от точки. В результате вместо SELECT `user`.`id` AS `user:id` получаем SELECT `prefix_user`.`id` AS `user:id`.

Есть два решения:

Унаследовать свой класс ORM от Kohana_ORM и исправить в нём метод with();
Исправить метод Kohana_ORM::with().

Результат получится примерно одинаковым — код будет выглядеть так:

public function with($target_path)
{
if (isset($this->_with_applied[$target_path]))
{
// Don't join anything already joined
return $this;
}

// Split object parts
$aliases = explode(':', $target_path);
$target = $this;
foreach ($aliases as $alias)
{
// Go down the line of objects to find the given target
$parent = $target;
$target = $parent->_related($alias);

if ( ! $target)
{
// Can't find related object
return $this;
}
}

// Target alias is at the end
$target_alias = $alias;

// Pop-off top alias to get the parent path (user:photo:tag becomes user:photo - the parent table prefix)
array_pop($aliases);
$parent_path = implode(':', $aliases);

if (empty($parent_path))
{
// Use this table name itself for the parent path
$parent_path = $this->_table_name;
}
else
{
if( ! isset($this->_with_applied[$parent_path]))
{
// If the parent path hasn't been joined yet, do it first (otherwise LEFT JOINs fail)
$this->with($parent_path);
}
}

// Add to with_applied to prevent duplicate joins
$this->_with_applied[$target_path] = TRUE;

// Use the keys of the empty object to determine the columns
foreach (array_keys($target->_object) as $column)
{
$name = '"'.$target_path.'"."'.$column . '"';
$alias = $target_path.':'.$column;

// Add the prefix so that load_result can determine the relationship
$this->select(array($name, $alias));
}

if (isset($parent->_belongs_to[$target_alias]))
{
// Parent belongs_to target, use target's primary key and parent's foreign key
$join_col1 = '"'.$target_path.'"."'.$target->_primary_key.'"';
$join_col2 = $parent_path.'.'.$parent->_belongs_to[$target_alias]['foreign_key'];
}
else
{
// Parent has_one target, use parent's primary key as target's foreign key
$join_col1 = $parent_path.'.'.$parent->_primary_key;
$join_col2 = '"'.$target_path.'"."'.$parent->_has_one[$target_alias]['foreign_key'] .'"';
}

// Join the related object into the result
$this->join(array($target->_table_name, $target_path), 'LEFT')->on($join_col1, '=', $join_col2);

return $this;
}

Патч по объёму гораздо меньше:

--- kohana/modules/orm/classes/kohana/orm.php
+++ kohana/modules/orm/classes/kohana/orm.php
@@ -637,7 +637,7 @@
// Use the keys of the empty object to determine the columns
foreach (array_keys($target->_object) as $column)
{
- $name = $target_path.'.'.$column;
+ $name = '"'.$target_path.'"."'.$column . '"';
$alias = $target_path.':'.$column;

// Add the prefix so that load_result can determine the relationship
@@ -647,14 +647,14 @@
if (isset($parent->_belongs_to[$target_alias]))
{
// Parent belongs_to target, use target's primary key and parent's foreign key
- $join_col1 = $target_path.'.'.$target->_primary_key;
+ $join_col1 = '"'.$target_path.'"."'.$target->_primary_key.'"';
$join_col2 = $parent_path.'.'.$parent->_belongs_to[$target_alias]['foreign_key'];
}
else
{
// Parent has_one target, use parent's primary key as target's foreign key
$join_col1 = $parent_path.'.'.$parent->_primary_key;
- $join_col2 = $target_path.'.'.$parent->_has_one[$target_alias]['foreign_key'];
+ $join_col2 = '"'.$target_path.'"."'.$parent->_has_one[$target_alias]['foreign_key'] .'"';
}

// Join the related object into the result

Скачать патч (unified diff).

Идея в том, что имена псевдонимов заключаются в двойные кавычки — в этом случае Database не занимается «самодеятельностью» в виде добавления префиксов куда надо и не надо.

Проверялось на Kohana 3.0.3

Отчёт об ошибке в трекере Kohana