Ars Longa, Vita Brevis

svn: could not connect to server

2009-07-07T11:32:50Z

Сегодня столкнулся с интересной ошибкой при попытке экспорта проекта из репозитория Subversion:

$ svn export -q -r8913 https://my.repository.com/svn/trunk /var/www/some/path
svn: OPTIONS of 'https://my.repository.com/svn/trunk': could not connect to server (https://my.repository.com)

Произошло это после обновления системы (на машине стоит Debian).

Первое подозрение — что-то не то с DNS, ибо извне к репозиторию есть доступ. Проверил:

$ wget https://my.repository.com
--2009-07-07 13:10:21-- https://my.repository.com
Resolving my.repository.com... 12.34.56.78
Connecting to my.repository.com|12.34.56.78|:443... connected.
HTTP request sent, awaiting response... 200 OK

Получается, что проблема где-то в subversion, а не в невозможности соединения с сервером или криво настроенном DNS.

Как оказалось, это известная ошибка. Проблема была в том, что в библиотеке libneon27 версии 0.28.4-1 разработчики что-то сломали. При этом сломанный libneon27 лежит в testing, исправленный — в unstable.

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

Откатить libneon27 и libneon27-gnutls до версии 0.28.2
Поставить libneon27 и libneon27-gnutls из unstable
Выполнить команду echo http-library=serf >> ~/.subversion/servers

Мне по душе пришелся второй вариант. После обновления всё работает, что, собственно, и требовалось.

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

Linux: экстренная перезагрузка сервера

2009-07-06T20:08:37Z

Иногда случаются ситуации (поменьше бы их таких), когда из-за какой-нибудь ошибки оборудования или повреждения файловой системы операционная система входит в ступор и не может прочитать ничего с диска. Систему нужно перезагружать, но система не может прочитать /sbin/reboot, а техническая поддержка тупит (не могу не передать привет техперсоналу HiVelocity.net).

В этом случае систему можно перезагрузить двумя командами echo (нужны права администратора).

echo 1 > /proc/sys/kernel/sysrq
echo b > /proc/sysrq-trigger

Данная последовательность команд перезагрузит систему, не производя размонтирование файловых систем и сброс буферов на диск. Способ весьма экстремальный, но действенный.

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

echo 1 > /proc/sys/kernel/sysrq
echo e > /proc/sysrq-trigger
echo i > /proc/sysrq-trigger
echo s > /proc/sysrq-trigger
echo u > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger

Построчно:

Включение SysRq
Отправление SIGTERM всем процессам, кроме init
Отправление SIGKILL всем процессам, кроме init
Сброс всех данных на диск (sync)
Перемонтирование всех файловых систем в режим “только для чтения”
Перезагрузка системы

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

Показ отрывка вместо статьи на страницах комментариев

2009-06-22T16:28:15Z

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

Кроме того, в WordPress 2.7 добавлена поддержка многостраничных комментариев; следуя логике статьи, было бы неплохо показывать отрывок (excerpt) вместо полного текста и для страниц комментариев.

Я вижу два способа решения поставленной задачи:

Изменение шаблона single.php.
Добавление функции в functions.php темы.

Я начну рассмотрение со второго способа — после него реализация первого способа будет тривиальной.

Начнём со скучной теории (skip it).

При использовании разбиения комментариев на страницы, WordPress добавляет переменную cpage в массив $wp_query->query_vars. Но здесь есть парочка нюансов:

На первой странице комментариев (она же может быть последней — всё зависит от настроек WordPress) — той, которая отображается при просмотре статьи — WordPress не устанавливает переменную cpage в номер страницы.
При отправлении комментария (и использовании многостраничных комментариев) WordPress перенаправляет пользователя на страницу с изменившейся постоянной ссылкой: к постоянной ссылке страницы добавляется comment-page-PAGE/#comment-ID. PAGE — это номер страницы комментариев, ID — ID комментария.
Если в постоянной ссылке присутствует параметр comment-page-XXX (он же cpage при отключённом ЧПУ), то WordPress устанавливает переменную $wp_query->query_vars['cpage'] (сюрприз!)

Какие из этого можно сделать выводы? Если посетитель просматривает не первую страницу комментариев, либо только что оставил свой комментарий, $wp_query->get('cpage') вернёт ненулевое значение. В противном случае переменная $wp_query->query_vars['cpage'] не будет установлена. Что и требовалось по условию.

Теперь переходим к отрывку (который excerpt). Плохая новость заключается в том, что многие люди (в том числе и я) его просто не заполняют. Хорошая новость — WordPress (по крайней мере, 2.8; хотя в комментариях к коду написано, что работает, начиная с версии 1.5) умеет его заполнять самостоятельно — это делает функция wp_trim_excerpt(), которая устанавливается фильтром на событие get_the_excerpt. У этой функции (по сравнению с методом Сергея) есть два недостатка:

Она убирает напрочь всю HTML-разметку (anybody cares?)
У WordPress своё представление о том, как выглядит знак типографского пропуска (лечится установкой своего фильтра на событие wp_trim_excerpt).

Есть одна особенность: вызов функций the_excerpt()/get_the_excerpt() из фильтра the_content может привести к рекурсивному вызову этого же фильтра из функции wp_trim_excerpt().

В functions.php темы добавляем такой код (в WordPress младше 2.8 вместо esc_atrr() нужно использовать attribute_escape()):

Для тех, кто ждёт первый вариант: в шаблоне single.php заменяем вызов the_content() следующим кодом:

<?php
if ((int)$wp_query->get('cpage') > 0) {
echo get_the_excerpt() . '← Вернуться к полной версии записи «' . sprintf('<a href="%s">%s</a>', esc_attr(get_permalink()), get_the_title()) . '»…';
}
else {
the_content("Далее…");
}
?>

В принципе, вариант №2 (тот, который был рассмотрен первым) при желании можно реализовать в виде плагина.

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

Защищено: oDesk Time Tracker Vulnerabilities

2009-06-16T14:48:28Z

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

Глобальный nofollow для страниц комментариев

2009-06-19T15:46:34Z

Идеально для SEOшников, использующих разбиение комментариев на страницы: глобальный запрет следования по ссылкам для всех страниц комментариев, кроме первой (или последней, в зависимости от настроек WordPress).

В шаблон header.php добавляем такой вот код:

<?php if ($wp_query->get('cpage')) : ?>
<meta name="robots" content="index,nofollow"/>
<?php endif; ?>

Работает для WordPress 2.7 и старше.

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

WordPress 2.8 и $_REQUEST

2009-06-14T14:34:54Z

Тем, у кого возникли проблемы с интеграцией в WordPress сторонних приложений, использующих аутентификацию по cookie: разработчики в релизе 2.8 переплюнули сами себя и добавили одну фичу: выбросили из суперглобальной переменной $_REQUEST данные из $_COOKIE.

Я не знаю, какая реальная польза от этого — на мой взгляд, использовать $_REQUEST вместо $_GET и $_POST не совсем разумно и чревато CSRF-атаками, если не принимать специальных мер — зато есть проблемы: приложения, которые используют $_REQUEST, для того, чтобы вытянуть cookie (в частности, это phpBB), перестают работать.

Эта misfeature находится в файле wp-settings.php в районе 50-й строки:

// Force REQUEST to be GET + POST. If SERVER, COOKIE, or ENV are needed, use those superglobals directly.
$_REQUEST = array_merge($_GET, $_POST);

Я не знаю, что разработчики имели в виду, упоминая $_SERVER и $_ENV в комментарии, так как их значения в $_REQUEST не попадают: в общем случае,

$_REQUEST = array_merge($_GET, $_POST, $_COOKIE);

с поправкой на значение параметра variables_order и, начиная с PHP 5.3.0, параметра request_order.

Тем, кому новое поведение WordPress очень мешает, могу предложить два выхода:

Закомментировать строку $_REQUEST = array_merge($_GET, $_POST);
Написать плагин, который по событию plugins_loaded восстанавливает $_REQUEST из $_GET, $_POST и $_COOKIE. Простейшая реализация будет выглядеть так:

function restore_request_superglobal()
{
$_REQUEST = array_merge($_GET, $_POST, $_COOKIE);
}

add_action('plugins_loaded', 'restore_request_superglobal');

Пока я копался в коде WordPress, у меня возникло еще одно возражение против $_REQUEST: плагин, использующий $_REQUEST, не должен полагаться на то, что WordPress экранирует значения, делая их безопасными для использования в запросах. Строго говоря, плагин должен быть готов к тому, что данные могут быть как экранированы, так и не экранированы — все зависит от magic_quotes:

если magic_quotes_gpc = On, то $_GET, $_POST, $_COOKIE, $_SERVER и $_REQUEST будут экранированы;
если magic_quotes_gpc = Off, то $_GET, $_POST, $_COOKIE и $_SERVER будут экранированы, а $_REQUEST — нет.

// If already slashed, strip.
if ( get_magic_quotes_gpc() ) {
$_GET = stripslashes_deep($_GET );
$_POST = stripslashes_deep($_POST );
$_COOKIE = stripslashes_deep($_COOKIE);
}
// Escape with wpdb.
$_GET = add_magic_quotes($_GET );
$_POST = add_magic_quotes($_POST );
$_COOKIE = add_magic_quotes($_COOKIE);
$_SERVER = add_magic_quotes($_SERVER);

Такие вот пироги.

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

Ужасы таксономии в WordPress

2009-06-09T01:12:31Z

Внутренняя реализация управления таксономиями в WordPress — это просто кошмар какой-то. Мало того, что код написан в процедурном стиле (использование ООП помогло бы решить некоторые проблемы с производительностью, которые иначе можно решить только глобальными переменными), он к тому же очень плохо масштабируется.

Я взял свежую дефолтную инсталляцию WordPress 2.8-bleeding, сгенерировал тестовый контент и пошел искать недоработки и проблемы с производительностью. Одну из них я нашел очень быстро: при попытке удалить категорию, в которой была 1,001 ~~ночь~~ запись.

На неслабом сервере это заняло около 20 секунд и… более 12,000 запросов (да-да, двенадцати тысяч, я количеством ноликов, увы, не ошибся).

Лог запросов (application/x-gzip, 75.1 КиБ)
Лог запросов (text/html, 2.5 МиБ)

А всё почему? Из-за одного магического foreach в wp_delete_term():

foreach ( (array) $objects as $object ) {
$terms = wp_get_object_terms($object, $taxonomy, 'fields=ids');
if ( 1 == count($terms) && isset($default) )
$terms = array($default);
else
$terms = array_diff($terms, array($term));
$terms = array_map('intval', $terms);
wp_set_object_terms($object, $terms, $taxonomy);
}

Куда уж проще: выбрать ID всех объектов, связанных с данной таксономией:

SELECT DISTINCT tr.object_id
FROM wp_term_taxonomy AS tt INNER JOIN wp_term_relationships AS tr USING(term_taxonomy_id)
WHERE tr.term_id = 'TERM ID HERE' AND tr.taxonomy = 'TAXONOMY NAME HERE'

Затем удалить терм к едрене фене и жукам майским:

DELETE
FROM wp_term_taxonomy AS tt LEFT JOIN wp_term_relationships AS tr USING(term_taxonomy_id)
WHERE tr.term_id = 'TERM ID HERE' AND tr.taxonomy = 'TAXONOMY NAME HERE'

Затем вставить дефолтное значение терма для тех объектов, которые выпали из таксономии: вычитаем из результата, полученного в первом запросе, результат запроса SELECT object_id FROM wp_term_relationship WHERE object_id IN ("список из первого запроса"). Для полученного результата выполнить один большой INSERT:

INSERT INTO wp_term_relationships VALUES
('OBJECT_ID_1', 'DEFAULT_TERM_TAXONOMY_ID', 0), /* ... */ ('OBJECT_ID_N', 'DEFAULT_TERM_TAXONOMY_ID', 0)

После чего сделать UPDATE wp_term_taxonomy SET `count` = `count` + 'количество строк, затронутых INSERT' WHERE term_taxonomy_id = 'DEFAULT_TERM_TAXONOMY_ID'.

Причём если дефолтное значение терма не задано, то достаточно просто одного DELETE.

В результате получаем пять запросов вместо 12,000, улучшенную производительность и меньше мусора. За кадром осталась очистка ~~инсулинового~~ кэша WordPress, но идея понятна. Вот только жаль, что оно увидит свет очень нескоро.

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

Особенности магического метода __call в PHP

2009-06-30T04:34:22Z

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

Один из методов, __call(), согласно документации используется при попытке вызова недоступного метода в контексте объекта.

Иными словами, в следующем фрагменте кода

<?php
class A {
public function call($method, $params)
{
print "Attempt to call {$method}\n";
}
}

$a = new A();
$a->someMethod();
?>

будет вызван магический метод A::__call("someMethod", array()), который напечатает

Attempt to call someMethod

С несуществующими методами всё ясно, но в документации упоминается слово «недоступные» (inaccessible).

А с недоступными методами, к сожалению, не всё так гладко. Рассмотрим пример:

<?php
class A {
public function get()
{
return array(&$this, 'test');
}

public function __call($method, $params)
{
if (true == method_exists($this, $method)) {
call_user_func_array(array(&$this, $method), $params);
}
}

protected function test()
{
echo "It makes me money and that's all right\n";
}
}

$a = new A();
$callback = $a->get();
call_user_func($callback);
?>

Метод A::test() является доступным в контексте класса A, но недоступным в контексте объекта $a. Следуя документации, ожидаемым результатом был бы вызов A::test() из A::__call(). Но в действительности всё не так, как на самом деле:

Warning: call_user_func(A::test): First argument is expected to be a valid callback in test-visibility.php on line 23

А метод __call() даже не вызывается.

В принципе, я не обратил бы на это внимание, если бы магические методы __get()/__set()/__isset()/__unset() работали точно так же. Но я знаю, что это не так:

<?php
class A
{
private $x;

public function __get($name)
{
print $name . "\n";
return null;
}
}

$a = new A();
$a->x;
?>

В этом случае, хотя $a->x и недоступен в контексте объекта $a, метод A::__get() будет вызван.

Я не знаю, считать ли политику (не)вызова __call() в PHP ошибкой или нет, ясно одно: подобное поведение не согласуется с политикой вызовов других магических методов.

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

Увеличение производительности плагина NextGen Gallery

2009-06-06T10:27:11Z

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

Проявляется это в том, что при отображении любой галереи MySQL приходится полностью сканировать таблицу wp_ngg_pictures.

Например:

EXPLAIN
SELECT SQL_CALC_FOUND_ROWS tt.*, t.*
FROM wp_ngg_gallery AS t INNER JOIN wp_ngg_pictures AS tt ON t.gid = tt.galleryid
WHERE t.gid = 3 AND tt.exclude<>1
ORDER BY tt.sortorder ASC

+----+-------------+-------+-------+---------------+---------+---------+-------+--------+----------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+--------+----------------+
| 1 | SIMPLE | t | const | PRIMARY | PRIMARY | 8 | const | 1 | Using filesort |
| 1 | SIMPLE | tt | ALL | NULL | NULL | NULL | NULL | 11700 | Using where |
+----+-------------+-------+-------+---------------+---------+---------+-------+--------+----------------+

Исправляется ситуация путём добавления ключа по столбцам galleryid и sortorder в таблицу wp_ngg_pictures:

ALTER TABLE `wp_ngg_pictures` ADD KEY (`galleryid`, `sortorder`)

После этого EXPLAIN покажет значительно лучшую картину:

+----+-------------+-------+-------+---------------+-----------+---------+-------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------+-------+---------------+-----------+---------+-------+------+-------------+
| 1 | SIMPLE | t | const | PRIMARY | PRIMARY | 8 | const | 1 | |
| 1 | SIMPLE | tt | ref | galleryid | galleryid | 8 | const | 59 | Using where |
+----+-------------+-------+-------+---------------+-----------+---------+-------+------+-------------+

Как видим, использование правильного индекса позволяет избежать файловой сортировки; к тому же, из таблицы wp_ngg_pictures сразу выбираются только нужные данные (59 строк против 11,700 строк).

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

Симеиз

2009-06-05T01:26:08Z

[Show as slideshow]