Ars Longa, Vita Brevis » советы

Особенности работы функции checkdnsrr()

Wandering Soul — Fri, 24 Sep 2010 12:49:56 +0000

Иногда «Да» означает «Нет»

Функция checkdnsrr() используется для проверки существования записей DNS. Например, фреймворк Kohana использует эту функцию для проверки наличия MX-записи домена, указанного в адресе электронной почты.

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

В Linux есть магический файл — /etc/resolv.conf; он отвечает за конфигурацию резолвера (набор функций в библиотеке C, предоставляющих доступ к Internet DNS).

В этом файле может быть задан параметр search, в котором задаётся список дополнительных доменов для поиска (обычно локальное имя домена).

Этот параметр может оказывать очень сильное влияние на результат, возвращаемый checkdnsrr(). Например, при поиске записи типа A для несуществующего домена checkdnsrr() вернёт 0:

$ php -r 'echo (int)checkdnsrr("x.y", "A"), "\n";'
0

Но если вдруг в /etc/resolv.conf задан параметр search, то результат уже не так однозначен. Например, если имеется запись

search example.com

то алгоритм поиска будет таким:

Сначала система будет пытаться найти запись A для несуществующего домена x.y;
Так как домен с таким именем не существует, система будет пробовать суффиксы, перечисленные в параметре search. В нашем случае система будет искать домен x.y.example.com

Если у домена example.com есть wildcard-запись типа A (*.example.com. IN A 1.2.3.4), то checkdnsrr() вернёт true — хотя это и не тот результат, который ожидается.

С проверкой MX-записей может возникнуть такая же ситуация: например, если имеются такие записи DNS:

*.example.com. IN CNAME example.com.
example.com. IN MX 10 mail.example.com.

В этом случае при наличии search example.com в /etc/resolv.conf checkdnsrr() будет возвращать true для любых доменов.

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

$result = checkdnsrr("x.y.", "A");

В этом случае над именем не будет проводиться никаких манипуляций, и результат будет не таким неопределённым

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

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

Vladimir — Mon, 06 Jul 2009 20:08:37 +0000

Перезагрузка системы двумя командами echo

Иногда случаются ситуации (поменьше бы их таких), когда из-за какой-нибудь ошибки оборудования или повреждения файловой системы операционная система входит в ступор и не может прочитать ничего с диска. Систему нужно перезагружать, но система не может прочитать /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)
Перемонтирование всех файловых систем в режим «только для чтения»
Перезагрузка системы

Вывод списка страниц с описанием

Vladimir — Mon, 27 Apr 2009 20:40:46 +0000

Простая альтернатива wp_list_pages()

Для вывода подстраниц (иными словами, дочерних страниц текущей страницы) авторы тем очень часто используют такой код (пример взят из OneTheme):

$children = wp_list_pages('title_li=&child_of='.$post->ID.'&echo=0');
if ($children) { ?>
<ul>
echo $children; ?>
ul>
} ?>

У wp_list_pages(), на мой взгляд, есть два серьёзных недостатка:

Хотя для вывода информации нужны всего два поля (ID и post_title), wp_list_pages() выбирает всю информацию, что ведёт к увеличению трафика между PHP и MySQL (и, в конечном итоге, сказывается на производительности);
При использовании wp_list_pages() не получается вывести дополнительную информацию о странице (например, её описание, рейтинг и т.п.).

С первым недостатком разбираются разработчики (если я не ошибаюсь, уже готов патч), а со вторым не всё так просто: функциональность «зашита» в класс Walker_Page, не предоставляющий фильтров, с помощью которых можно «повлиять» на результат (the_title не в счёт, в нашем случае с ним будет больше проблем, чем пользы). Так что если нужна дополнительная функциональность, придётся писать свою функцию (или класс).

Пример функции, выводящей список страниц с описаниями (как здесь; своеобразная интеграция с All in One SEO Pack):

function render_items_recursive(&$pages)
{
print '

;

foreach

(

$pages

)

{

";
print '. get_page_link($x->ID) . '" title="' . attribute_escape(apply_filters('the_title', $x->post_title)) . '">' . apply_filters('the_title', $x->post_title) . ' ';
print '' . get_post_meta($x->ID, 'description', true) . '';
if (false == empty($x->children)) {
render_items_recursive($x->children);
}
print '

;

}

';
}

function list_pages_with_description($parent)
{
$p = &get_pages('sort_column=menu_order,post_title&child_of=' . $parent);
if (true == empty($p)) {
return;
}

$pages = array();
$map = array();
$item = null;

foreach ($p as $x) {
unset($x->post_content);
if ($parent == $x->post_parent) {
$pages[$x->ID] = $x;
$map[$x->ID] = &$pages[$x->ID];
}
else {
$item = &$map[$x->post_parent];
$item->children[] = $x;
$map[$x->ID] = &$item->children[count($item->children)-1];
}
}

unset($map, $item);
ob_start();
render_items_recursive($pages);
$s = ob_get_contents();
ob_end_clean();
return $s;
}

Вызывается так:

$children = list_pages_with_description($post->ID); ?>
if ($children) : ?>
print $children; ?>
endif; ?>

А выглядеть всё будет так, как по ссылке выше. Поддерживается неограниченный уровень вложенности. В PHP4 из-за проблем с организацией ссылок работать, скорее всего, не будет.

Простой способ генерирования паролей в Bash

Vladimir — Sun, 15 Mar 2009 03:20:50 +0000

Генерация пароля без использования Perl

CHARS="0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz!@#$%^&*()-_=+\\|/"
LENGTH="8"
while [ "${n:=1}" -le "$LENGTH" ] ; do
PASSWORD="$PASSWORD${CHARS:$(($RANDOM%${#CHARS})):1}"
let n+=1
done

И на закуску немного экзотики:

LENGTH=10
base64 -w $LENGTH /dev/urandom | head -n 1

Мысли на тему массового UPDATE в MySQL

Vladimir — Sun, 18 Jan 2009 08:24:16 +0000

Оказывается, это возможно!

INSERT INTO `table` (`a`, `b`, `c`) VALUES
(1, 2, 3), (4, 5, 6), (7, 8, 9)
ON DUPLICATE KEY UPDATE `b`=VALUES(`b`), `c`=VALUES(`c`);

Например, для WordPress (при условии, что пара (user_id, meta_key) является уникальным ключом):

INSERT INTO `wp_usermeta` (`user_id`, `meta_key`, `meta_value`) VALUES
(1, 'key1', 'value1'),
(1, 'key2', 'value2'),
(1, 'key3', 'value3'),
(1, 'key4', 'value4'),
(1, 'key5', 'value5')
ON DUPLICATE KEY UPDATE `meta_value`=VALUES(`meta_value`);

Должно работать.

WordPress: одновременный логин для HTTP и HTTPS

Vladimir — Sat, 17 Jan 2009 19:09:55 +0000

Простое решение для POST на SSL URL

В WordPress, начиная с версии 2.6, встроена поддержка HTTPS: можно сделать либо HTTPS-логин, либо поместить панель администратора за SSL. Однако, из-за особенностей реализации, когда пользователь входит в систему, он получает cookie либо для HTTP, либо для HTTPS. Иными словами, если пользователь попал на http://example.com/wp-admin/, то при переходе на https://example.com/wp-admin/ ему придётся входить в систему еще раз.

Всё бы ничего, но если плагин делает POST на HTTPS, то пользователь попадает на wp-login.php, который после успешного входа сделает перенаправление (GET) на URL, который ожидает принять POST. При этом если POST шёл на https://example.com/wp-admin/admin.php?page=somepage&noheader=1, то пользователь увидит безобразную страницу.

К счастью, есть простое решение. Как известно, аутентификационные cookies устанавливает процедура wp_set_auth_cookie. Перед их установкой она генерирует событие set_auth_cookie, которому передаются следующие параметры:

$auth_cookie — значение для cookie, сгенерированное процедурой wp_generate_auth_cookie();
$expire — 0, если пользователь не выбрал "Запомнить меня", не 0 в противном случае;
$expiration — срок жизни cookie;
$user_id — ID пользователя (из таблицы wp_users);
$scheme — схема аутентификации: secure_auth для SSL, auth для HTTP.

Использовать эти данные можно следующим образом:

/**
* set_auth_cookie action hook
*
* @param string $auth_cookie Value generated by wp_generate_auth_cookie()
* @param int $expire 0, if Remember Me is not checked
* @param int $expiration Cookie expiration date
* @param int $user_id ID of the logged in usger
* @param string $scheme Authentication scheme (secure_auth or auth)
*/
function sj_set_auth_cookie($auth_cookie, $expire, $expiration, $user_id, $scheme)
{
static $was_here = false;

if (false === $was_here) {
$was_here = true;
if ('secure_auth' == $scheme) {
wp_set_auth_cookie($user_id, 0 != $expire, false);
}
elseif ('auth' == $scheme) {
wp_set_auth_cookie($user_id, 0 != $expire, true);
}
else {
$was_here = false;
}
}
}

add_action('set_auth_cookie', 'sj_set_auth_cookie', -100, 5);

Секреты update_postmeta_cache()

Vladimir — Wed, 01 Oct 2008 10:27:14 +0000

Способ увеличения производительности при чтении метаданных записей

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

Например, такой код

$all_posts = $wpdb->get_col("SELECT `ID` FROM `{$wpdb->posts}` WHERE `post_type` = 'post' ORDER BY `post_title`");
if (false == empty($all_posts)) :
foreach ($all_posts as $id) :
$caps = get_post_meta($id, '_disclosesecret_cap');
//...
endforeach;
endif;

потребует выполнения n дополнительных запросов, где n — число выбраннных записей.

Код можно сделать гораздо эффективнее, добавив всего одну строку:

$all_posts = $wpdb->get_col("SELECT `ID` FROM `{$wpdb->posts}` WHERE `post_type` = 'post' ORDER BY `post_title`");
if (false == empty($all_posts)) :
update_postmeta_cache($all_posts);
foreach ($all_posts as $id) :
$caps = get_post_meta($id, '_disclosesecret_cap');
//...
endforeach;
endif;

В этом случае понадобится один дополнительный запрос.

Техническая информация: get_post_meta() вызывает update_postmeta_cache(), если метаинформация не найдена во внутреннем кэше (группа post_meta, ключ $id — уникальный идентификатор записи). Так как update_postmeta_cache() читает все метаданные для указанных записей, получаем пенальти в одно обращение к базе данных на уникальную запись.

update_postmeta_cache() в качестве параметра принимает либо строку (список идентификаторов записей, разделённых запятой), либо массив. "Стоимость" вызова данной функции составляет один запрос к базе данных на весь набор параметров.

Побочные эффекты: если длина SQL-запроса превысит значение переменной max_allowed_packet (для MySQL), запрос к базе данных завершится ошибкой.

Пять советов верстальщику

Vladimir — Tue, 27 May 2008 22:17:43 +0000

Мои пять копеек

Принимая эстафету, организованную Никитой Селецким, от Максима Покровского, добавляю свои пять копеек в копилку советов по вёрстке.

Изучайте стандарты W3C. Как это ни банально звучит, хороший верстальщик (да и web-разработчик) просто обязан (пусть не наизусть) знать и понимать спецификации. Недавно в книжном магазине видел книжку по верстке. Лучше бы я её не видел: вложенные таблицы, архаичные тэги и всё в том же духе. Так вот: такие книги — зло. Всё, что надо знать, есть в спецификациях Следствия из данной рекомендации: да здравствует семантическая вёрстка; Vaild XHTML/CSS forever (тем не менее, это не должно быть самоцелью).
Дизайн должен быть кросс-браузерным. Internet Explorer уже давно не единственный браузер, которым пользуются люди, но, тем не менее, существует большое количество сайтов, которые написаны исключительно под IE. Так вот, это неправильно. Дизайн (равно как и код) нужно тщательно тестировать в как можно большем количестве браузеров. Для тех, кто под Windows, вообще райская жизнь: на одной машине без проблем уживаются IE6/7, FireFox, Opera, Safari и даже Konqueror из виндового порта KDE4. Затраты времени на тест в различных браузерах окупаются: заказчики имеют тенденцию смотреть на дизайн в экзотических браузерах, и когда всё отлично смотрится с первого раза, их приятно удивляет. А приятное удивление заказчика оборачивается бонусами для исполнителя
Помните про usability и accessibility. Тестируйте сайт с выключенными картинками, JavaScript и CSS (в различных комбинациях). Страница без CSS позволяет получить представление о том, как поисковик воспринимает страницу. Контент в самом низу? Что же удивляться, что Гугол недооценивает сайт? Или поставьте себя на место человека с ограниченными способностями, использующего скринридер. Хватит ли у Вас терпения, чтобы прослушать главную страницу Вашего сайта? Или Вам это надоест, когда скринридер пойдет читать меню навигации? Отключили JavaScript и развалился дизайн/не отправляется форма? Далеко не все пользователи включают JavaScript. И если для правильного отображения сайта требуется то, что может не быть доступно всем пользователям — это минус.
Изучайте работу мастеров. Это полезно. Только ключевое слово — изучайте. Если слепо передрать код/макет/нужное подставить без понимания того, что там происходит — это нехорошо. А если разобраться с кодом, то приобретаются знания и опыт. Как говорится, знание — сила.
Упрощайте. Если код можно упростить, его нужно упростить. Во-первых, так понятнее, во-вторых — чище, в-третьих — размер страницы уменьшается. Суп из div'ов ничуть не лучше вложенных таблиц, поверьте.

Вроде всё… Эстафету передавать мне особо некому (разве что Вам, Всеволод), поэтому подхватывайте все желающие