С недавних пор этот блог опять стали одолевать спамеры. Не знаю с чем это связано, больше года всё было относительно спокойно. Проскакивало по несколько спамерских комментариев в неделю, явно написанных людьми, а не ботами, и всё. А тут по 10-20 требкеков в день. Удалить их, конечно, не сложно, но надоедает и раздражает, к тому же трекбеки явно ставились автоматически, т.е. спамер своё время на них не тратил.

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

Поэтому я решил закрыть трекбеки для всех постов старше 2-х месяцев. Ставить специальный плагин для решения этой задачи нет никакой необходимости, всё можно сделать с помощью несложного SQL запроса и cron'а.

Теория

В WordPress все посты хранятся в таблице wp_posts (префикс wp_ может быть другим). В этой таблице есть поле ping_status, которому можно присвоить одно из двух значений: «open» или «closed». Как несложно догадаться по названию, значение «closed» отключает трекбеки к данном посту.

Теперь нужно определиться с датами. MySQL поддерживает довольно много функций для работы со временем и датами. Нам потребуются:
1) CURDATE – возвращает текущую дату;
2) DATE_SUB – вычитает даты;
и выражение INTERVAL ... DAY – позволяет указать интервал с заданным количеством дней.

Дата последнего изменения поста хранится в поле post_modified (таблицы wp_posts).

Формируем запрос

UPDATE wp_posts SET ping_status="closed" WHERE post_modified < DATE_SUB(CURDATE(), INTERVAL 60 DAY)

Как видите, это обычный UPDATE запрос, который установит полю ping_status значение «closed» для всех записей у которые последний раз обновлялись более 60-ти дней назад.

Кстати, аналогичным способом можно закрыть и комментарии. Для этого нужно установить значение «closed» для поля «comment_status».

Остаётся настроить периодический запуск этого запроса

Удобнее всего для этого использовать cron. Тут потребуются хотя бы базовые навыки работы с панелью управления хостингом. В большинстве панелей в меню находится ссылка на страницу cron, а для создания задачи нужно заполнить небольшую форму. При этом необходимо указать два обязательных параметра – команду, которую будет выполнять cron, и периодичность её выполнения.

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

mysql --default-character-set=utf8 --user=user_name --password=user_password db_name < path_to/block_trackbacks.sql

Здесь block_trackbacks.sql – имя файла в котором записан наш запрос.

Периодичность выполнения можно указать – 1 раз в день. Принципиальной роли, в данном случае, она не играет.

Результаты

Как и следовало ожидать, работает данный метод очень неплохо. Количество спама в трекбеках снизилось практически до нуля И, обратите внимание, данный способ подходит для любой CMS, главное, найти какое поле отвечает за отключение трекбеков.

Успехов!

На днях доделал очередную версию моего плагина для WordPress – Terms Descriptions. Скачать вы её можете на отсюда. Либо, если вы уже используете этот плагин, через систему обновлений WP.

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

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

Примечание. Посмотреть описание предыдущих версий плагина можно в статье: Плагин WordPress: Terms Descriptions.

Рассмотрим по порядку все основные изменения.

Интерфейс

Переделан практически полностью. Надеюсь, будет удобнее

В предыдущих версиях плагин создавал всего одну страницу в админке WP. На которой были расположены форма создания новых терминов, таблица с терминами и форма с настройками. Для первых версий плагина этого было достаточно. Но добавлять новые формы было сложно, т.к. страница получалась очень загроможденной.

Сейчас плагин создаёт три административных страницы, которые находятся в меню «Термины».

На первой странице (рис.1) размещена форма добавления новых терминов и таблица с уже существующими терминами.

Рис.1.

Принцип создания термина остался тем же, но форма изменилась. Во-первых, сейчас добавлена нормальная поддержка произвольных типов записей WP (custom post types). Во-вторых, для выбора записи (поста) используется поле с автокомплитом, а не выпадающий список с заголовками постов (рис. 2). Как оказалось, выпадающий список практически бесполезен, если блог содержит несколько сотен записей.

Рис. 2.

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

На второй странице находится форма со всеми основными настройками блога (рис. 3).

Рис. 3.

На третьей странице (рис. 4) – инструменты для экспорта/импорта данных плагина и для пакетной загрузки терминов.

Рис. 4.

Хранение терминов

Способ хранения и работы с терминами также был существенно переработан. Поэтому после обновления плагина в админке появится сообщение с кнопкой «Обновить БД». Я настоятельно рекомендую сделать резервную копию базы перед выполнением этой операции.

Причин для внесения этих изменений было две.

1) Оказалось, что часть пользователей создаёт большие списки терминов. И для работы с ними целесообразно создать отдельную таблицу.

2) Функция get_permalink, которая используется в WP для формирования ЧПУ, при определённых структурах ссылок оказывается довольно ресурсоемкой. Чтобы исключить её использование при формировании страниц блога, формирование ссылки теперь осуществляется один раз при создании термина. А для того, чтобы плагин правильно работал после изменения структуры URL, добавлена возможность пакетного обновления ссылок из админки. Кнопка «Обновить ссылки» находится справа над таблицей терминов (рис. 1). Т.е. если меняете структуру ЧПУ не забудьте обновить ссылки терминов.

Парсеры

Одними из самых неприятных проблем, с которыми я столкнулся при поддержке плагина, были конфликты с другими плагинами.

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

Например, количество багрепортов увеличилось в несколько раз после того как я добавил поддержку кавычек.

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

Сейчас в дистрибутиве плагина есть два парсера.

1) Простой. Ставит ссылку на текст, который полностью совпадает с одним из терминов.

2) Простой с поддержкой кавычек. Работает также как и простой, но дополнительно проверяет символы вокруг найденного термина, и, если они являются кавычками, преобразует термин в ссылку.

Переключение между парсерами осуществляется на странице Термины->Настройки (рис. 3).

Пакетная загрузка терминов

Позволяет загрузить сразу несколько терминов. Удобно, если у вас есть список терминов, сформированный с помощью какой-нибудь программы.

Форма пакетной загрузки находится на странице Термины -> Инструменты.

Формат добавления терминов следующий. Каждый термин должен быть записан в отдельной строке. Можно указать несколько словоформ для терминов. Разделитель словоформ – символ |. Т.е. точно так же, как и при добавлении нового термина. Но есть важное отличие, в качестве последней словоформы нужно указать ссылку. Ссылкой может быть обычный URL (наличие http:// обязательно) или id поста (пост нужно создать до добавления терминов).

Например,

яблоко|яблоки|яблок|яблочный|http://apples.com
груша|груш|груши|24
и т.д.
здесь, 24 – id поста на который нужно поставить ссылку.

Хочу предупредить. Добавление терминов занимает некоторое время. И, при попытке загрузить большой список, время выполнения скрипта может превысить лимит, установленный хостером. В таких случаях единственный вариант решения (если не считать вариант переезда на выделенный сервер) – загружать список по частям.

Заключение

В общем, надеюсь, новая версия вам понравится и позволит сделать работу более комфортной И, конечно, жду ваших предложений, пожеланий и баг репортов

Успехов!

Полезные ссылки.

Закажите VPS Start и выше и получите 30$ + панель ISP в подарок! Отзывы – zapili.net

WordPress на сегодняшний день является одой из самых популярных CMS и последнее время активно развивается. Но, к сожалению, это развитие не всегда получается гармоничным.

Одной из возможностей, которая почему-то по возможностям постоянно отстаёт от остальной части движка, является XML-RPC. На сегодняшний день этот протокол является основным средством удалённой публикации постов. И, при этом, он фактически бесполезен если вы используете произвольные типы записей (custom post types) и таксономии (custom taxonomies). Ни один XML-RPC метод публикации постов в WP 3.2.1 их не поддерживает.

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

Рассмотрим небольшой пример.

Допустим, нам нужно публиковать посты произвольного типа через XML-RPC и связывать их с таксономиями. При этом, таксономии могут быть как иерархическими, так и плоскими.

Примечание. Подробнее о типах постов и таксономиях рассказано в статьях: WordPress: вывод записей произвольных типов (Custom Post Types) и Управление контентом в WordPress CMS: ситуация на сегодня и ближайшая перспектива.

Немного теории

В WordPress предусмотрен фильтр (xmlrpc_methods), позволяющий добавлять новые методы во встроенный XML-RPC сервер. Делается это следующим образом:

add_filter('xmlrpc_methods', 'add_xml_rpc_methods');

Во втором параметре фильтра указываем имя функции, которая создаст запись в глобальном массиве XML-RPC методов.

function add_xml_rpc_methods($methods) {
	$methods['my.my_method_name'] = 'my_method_name';
	return $methods;
}

function my_method_name($args) {
//обработка XML-RPC запроса и отправка ответа
}

Чтобы создать XML-RPC метод нужно добавить новый элемент в массив $methods. Ключ этого элемента является именем метода, а значение – именем функции, которая выполняет обработку XML-RPC запроса и формирует ответ.

Реализация: XML-RPC клиент

Начнём с кода, который отправляет XML-RPC запрос. В данном случае будем использовать библиотеку The Incutio XML-RPC Library (она же используется и в WordPress).

require_once ('IXR_Library.php');

$client = new IXR_Client('http://my_blog.com/xmlrpc.php');
$client->timeout = 60000;

$requestData[0] = 0; //id блога
$requestData[1] = 'admin'; //имя пользователя
$requestData[2] = 'pass'; //пароль

$post = array();

$post['post_title'] = 'New Post';
$post['post_excerpt'] = 'Short description';
$post['post_content'] = 'This story about ...';
$post['post_status'] = 'draft';
$post['post_type'] = 'my_custom_post_type'; //тип поста
$post['post_date'] = date('Y-m-d H:i:s');
$post['post_modified'] = date('Y-m-d H:i:s');

//формируем массив с терминами таксономий
$terms = array();
$terms['taxonomy_1'][] = (int)$term['term_id_1'];
$terms['taxonomy_1'][] = (int)$term['term_id_2'];
$terms['taxonomy_2'][] = (int)$term['term_id_3'];
$terms['taxonomy_3'][] = (int)$term['term_id_4'];

$post['tax_input'] = $terms;

$requestData[3] = $post;

if (!$client->query('my.publish_post', $requestData)) {
	echo 'Publish Post error: '.$client->getErrorMessage();
	return;
}

$publishedPost = $client->getResponse();

Прежде всего, создаём объект IXR_Client, конструктору которого передаём адрес скрипт, который выполняет обработку XML-RPC запросов (xmlrpc.php).

Затем формируем массив с данными для публикации поста. В первых трёх элементах указываем: id блога (на данный момент не используется), логин и пароль. В четвертом элементе – массив с данными нового поста.

Чтобы сократить количество кода на стороне XML-RPC сервера, названия полей этого массива должны совпадать с полями массива, который передаётся функции wp_insert_post. Кстати, большинство ключей элементов этого массива совпадает с именами полей таблицы posts базы данных.

Обратите внимание на параметр

$post['post_type'] = 'my_custom_post_type'; //тип поста

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

Отдельно остановимся на таксономиях.

WordPress поддерживает таксономии 2-х типов: иерархические и плоские. Чтобы связать пост с терминами таксономий нужно перечислить их в элементе tax_input массива, который передаётся функции wp_insert_post. Например, так:

'tax_input' => array('taxonomy_1' => array('term', 'term2', 'term3'), 'taxonomy_2' => array('term1', 'term2'))

Здесь taxonomy_1, taxonomy_2 – имена таксономий, а term, term1 и т.д. – имена терминов.

Но здесь есть нюансы. Если публикуется «плоская» таксономия, то можно указать, либо имя термина, либо его id. При этом, id должен иметь тип int, если id сохранён в виде строки, то WordPress просто создаст новый термин. Для иерархических таксономий можно использовать только id термина (при этом нет ограничения на тип значения, оно будет автоматически приведено к типу int).

Т.е. универсальный вариант установки таксономий выглядит так:

$terms['taxonomy_1'][] = (int)$term['term_id_1'];
$terms['taxonomy_1'][] = (int)$term['term_id_2'];
$terms['taxonomy_2'][] = (int)$term['term_id_3'];
$terms['taxonomy_3'][] = (int)$term['term_id_4'];

Отправка запроса выполняется с помощью метода query, а прочитать результат можно используя getResponse.

XML-RPC сервер

На серверной стороне нужно зарегистрировать новый XML-RPC метод и написать функцию, которая будет обрабатывать запрос, и возвращать результат.

Примечание. Следующий код можно добавить в плагин или в файл functions.php темы.

add_filter('xmlrpc_methods', 'add_xml_rpc_methods' );

function add_xml_rpc_methods($methods) {
	$methods['my.publish_post'] = 'my_publish_post';
	return $methods;
}

function my_publish_post($args) {
	$blog_id = (int) $args[0];
	$username = $args[1];
	$password = $args[2];
	$post_data  = $args[3];

	if ( !get_option( 'enable_xmlrpc' ) ) {
		return new IXR_Error( 405, sprintf( __( 'XML-RPC services are disabled on this site.  An admin user can enable them at %s'),  admin_url('options-writing.php') ) );
	}

	$user = wp_authenticate($username, $password);

	if (is_wp_error($user)) {
		return new IXR_Error(403, __('Bad login/pass combination.'));
	}

	wp_set_current_user( $user->ID );

	if ( !current_user_can( 'edit_private_posts' ) ) {
		return new IXR_Error( 401, __( 'Sorry, you cannot edit private posts.' ) );
	}

	if (!is_array($post_data)) {
		return new IXR_Error( 401, __( 'Sorry, no post data not found.' ) );
	}

	$id = wp_insert_post( $post_data );

	if ($id === 0) {
		return new IXR_Error( 401, __( 'Post save error.' ) );
	}

	$post = array();
	$post['id'] = $id;
	$post['permalink'] = get_permalink($id);

	return $post;
}

Здесь мы регистрируем XML-RPC метод my.publish_post и указываем, что при обращении к нему WordPress должен вызвать функцию my_publish_post.

Большая часть кода в этой функции совпадает с большинством обработчиков стандартных XML-RPC методов WP. Собственно он оттуда и скопирован . Этот код проверяет, разрешен ли XML-RPC для данного блога (строки 14-16, кстати, не забудьте его включить в админке на странице Settings -> Writing), аутентифицирует пользователя и проверяет, достаточно ли у него прав для публикации поста.

Сама публикация выполняется с помощью всего одной функции wp_insert_post (строка 34).

Клиенту возвращаем id созданного поста и постоянную ссылку на него (формируем с помощью функции get_permalink).

Заключение

Как видите, принцип достаточно простой. Любую встроенную функцию WP можно вызвать через XML-RPC протокол и использовать все возможности движка при удалённой публикации постов.

Если есть вопросы или замечания, пишите, постараюсь ответить.

Успехов!

Интересные ссылки

Закажите печать фотокниг тремя способами: онлайн, в офисе или вип

На сегодняшний день движок WordPress довольно интенсивно развивается. Во всяком случае изменения в версиях с 2.8 по 3.1 добавляют WP возможности полноценных CMS. Большинство из этих возможностей должны быть активированы на уровне темы (или плагина), поэтому сразу после установки WP вы работаете с ним как с обычным блоговым движком.

Вроде бы все правильно. Если какие-то возможности вам не нужны, вы их не используете. Но при этом возникает серьёзная проблема с документацией. Дело в том, большинство примеров и в Кодексе, и в других источниках, ориентированы на самый простой случай – дефолтную инсталляцию WP. Как только вы активируете дополнительные возможности ко многим рекомендациям нужно относится очень аккуратно.

Об одном из таких примеров я хочу рассказать в этой статье.

Предположим, вы решили использовать произвольные типы записей (custom post types). Создать их достаточно просто и на эту тему есть масса статей, поэтому подробно останавливаться на этом моменте не будем.

В большинстве случаев достаточно добавить следующий код в файл functions.php вашей темы.

register_post_type('gadgets',
	array(
		'labels' => array(
			'name' => __('Gadgets'),
			'singular_name' => __('Gadget'),
			//остальные переводы
		),
		'public' => true,
		'publicly_queryable' => true,
		'query_var' => true,
		'taxonomies' => array('category','post_tag'),
		'supports' => array('title','editor','author','thumbnail','excerpt','comments'),
		'rewrite' => array('slug' => 'gadgets'),
		//другие настройки
	)
);

После этого вы сможете создавать записи данного типа в админке и WordPress автоматически сформирует страницу с лентой из этих записей. Адрес у этой страницы будет следующим.

http://blog.url/gadgets

Теперь обратите внимание, что для этого типа записей мы используем такие же категории, как и для типа Post (строка 11).

Очевидно, что на странице категории мы захотим увидеть записи всех типов, но WordPress покажет только тип Post.

Происходит это потому что WP при формировании запроса к базе данных явно указывает тип поста. И по-умолчанию этот тип – post.

К сожалению, в подобных случаях не все авторы тем хотят вникать в нюансы работы движка и просто используют функцию query_posts. Я понимаю, что примеры её использования приведены в статье The Loop, но там предполагается, что вам нужно создать дополнительный цикл на странице. Т.е., например, вывести основной список записей и ещё какой-нибудь дополнительный список, с фильтрацией по определённым условиям.

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

Решается задача достаточно просто.

function prefix_pre_get_posts($query) {
     if ($query->is_category) {
          $query->set('post_type', 'any');
     }
     return $query;
}

add_action('pre_get_posts', 'prefix_pre_get_posts');

Здесь мы назначаем собственный обработчик события (action) pre_get_posts. Как следует из названия, это событие возникает непосредственно перед отправкой запроса к БД. В первом параметре обработчик получает объект типа WP_Query, который формирует запрос к базе.

Прежде всего, мы проверяем, что в данный момент создаётся страница категории (строка 2). А затем изменяем атрибут post_type. По-умолчанию он равен post. Не забывайте, что обработчик обязательно должен вернуть изменённый (или неизменённый) объект WP_Query.

Вообще, если вы планируете работать с новыми возможностями WP (произвольными типами записей, таксономиями, форматами записей), то научиться работать с WP_Query нужно обязательно. Встроенными функциями движка здесь вы не обойдетесь.

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

Успехов!

Интересно почитать

Если самостоятельно учиться тяжело, то курсы программирования Киев помогут приобрести необходимые знания.

Приветствую всех! В этот раз поговорим о нынешних и будущих возможностях одного из самых популярных блоговых движков – WordPress. И заодно обсудим, корректно ли вообще называть его «блоговым».

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

И ещё одно замечание. Под «работой с контентом» я имею в виду не работу редактора, который форматирует текст с помощью TinyMCE, а работу web мастера, т.е. группировку записей по определённым признакам, их индивидуальное оформление, создание страниц архивов, навигацию и т.п.

Начнем с возможностей, которые предоставляет последний стабильный релиз WordPress (на данный момент это версия 3.0.5).

Таксономии (Custom Taxonomies)

Если верить википедии, таксономия – это учение о принципах и практике классификации и систематизации. В системах управления контентом (CMS), таксономиями называют различные инструменты для группировки информации.

И обычно их используют для группировки записей по каким-нибудь признакам. Если проводить аналогию с русским языком, то таксономии в WP можно считать прилагательными (отвечают на вопрос «какой? какая?»), т.е. они так или иначе характеризуют запись.

По-умолчанию, WordPress предоставляет три таксономии – категории, теги и ссылки. Но, начиная с версии 2.3 появилась возможность создавать собственные таксономии, правда на все 100% она не используется до сих пор (об этом чуть ниже).

Создать новую таксономию можно с помощью функции register_taxonomy. Для её вызова обычно используется событие (action) init.

Например, если вы создаёте группу записей о каких-то товарах и хотите группировать их по цвету, то можно использовать следующий код.

function color_init() {
	register_taxonomy(
		'color',
		'post',
		array(
			'label' => __('Color'),
			'labels'=>array(
				'name'=>__('Colors'),
				'singular_name'=>__('Color'),
				...
			),
			'sort' => true,
			'args' => array('orderby' => 'term_order'),
			'public'=>true,
			'show_in_nav_menus'=>true,
			'show_ui'=>true,
			'show_tagcloud'=>true,
			'hierarchical'=>true,
			'rewrite' => array('slug' => 'color'),
		)
	);
}
add_action( 'init', 'color_init' );

Добавить этот код можно в файл functions.php темы или вызвать из плагина.

Как видите, большинство параметров у функции register_taxonomy – это различные настройки. Если хотите, можете почитать их подробное описание.

Как только вы зарегистрируете таксономию, справа на страницах создания и редактирования записей появится блок новой таксономии.

Если таксономия иерархическая, то выглядеть он будет так:

а если таксономия обычная, то так:

Кроме того, в левом меню в группе Post появится ссылка на страницу редактирования таксономии.

Как видите, возможности у ваших таксономий будут точно такие же как и у стандартных тегов и категорий.

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

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

Поддержка такой иерархии шаблонов движком позволяет избавиться от длинных оператов switch в теме.

Также существует API для работы с таксономиями. Например, вы можете создать облако тегов с помощью функции wp_tag_cloud, вывести список терминов с помощью the_terms или использовать таксономии для фильтрации записей (функция query_posts).

Я не буду подробно на них останавливаться, т.к. эти же функции используются для работы со стандартными категориями и тегами.

Лучше рассмотрим ограничения, которые имеет система таксономий в WordPress.

Предположим, что вы создали таксономию, которая содержит взаимоисключающие значения. Например, название операционной системы для мобильных устройств. Если вы пишите пост о каком-нибудь телефоне, то будет неправильно если вы выберете одновременно термины Android и Simbian. Но WordPress никак не страхует вас от этой ошибки.

Т.е. в этом случае придется отказаться от использования стандартного интерфейса, создать свой meta-box (функция add_meta_box) и выводить в нём группу радиокнопок с терминами.

Ещё одна проблема связана с тем, что таксономии не всегда являются очевидным способом группировки контента.

Допустим, вы хотите чтобы оформление записей, содержащих видеоролики, отличалось от всех остальных. Можно просто создать категорию «Видео» и в инструкции пользователю написать, что все записи, содержащие видео, нужно включить в эту категорию.

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

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

Типы записей (Custom Post Types)

Эта возможность появилась в версии 3.0. По большому счёту её можно тоже считать таксономией, но и с точки зрения пользователя, и с точки зрения разработчика реализация этой возможности отличается от таксономий, поэтому не будем их путать.

Создать новый тип записи не сложнее чем таксономию. Используется функция register_post_type.

add_action('init', 'create_post_type');

function create_post_type() {
	register_post_type('video',
		array(
			'labels' => array(
				'name' => __('Videos'),
				'singular_name' => __('Videos'),
				...
			),
			'public' => true,
			'publicly_queryable' => true,
			'show_ui' => true,
			'query_var' => true,
			'capability_type' => 'post',
			'hierarchical' => false,
			'menu_position' => null,
			'taxonomies' => array('category','post_tag'),
			'supports' => array('title','editor','author','thumbnail','excerpt','comments'),
		)
	);
}

Как видите, используется событие (action) init, а в параметрах задаются основные настройки нового типа записей. Например, перечень полей в форме создания записи (supports), список таксономий (taxonomies) и т.д.

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

Обратите внимание, вы можете «привязывать» любые таксономии к любым типам записей.

Точно также как и в случае с таксономиями, WordPress имеет поддержку типов записей как на уровне темы, так и на уровне API.

Порядок использования шаблонов темы выглядит следующим образом.

А примеры работы с типов записей и перечень соответствующих функций вы найдете на этой странице.

В каких случаях лучше использовать типы записей, а не таксономии?

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

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

Тем не менее, появление и широкое использование этих возможностей создало дополнительную проблему.

Давайте вспомним, почему WordPress пользуется такой популярностью?

Правильно, из-за большого количества практически бесплатных тем и плагинов.

Вы можете скачать новую тему и изменить дизайн блога с помощью пары кликов мышкой… по крайне мере теоретически. Но что новая тема знает о ваших таксономиях и типах постов? Разработчик темы, конечно, может получить их список, но что дальше? Откуда он знает какую смысловую нагрузку они несут и как их нужно выводить?

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

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

Речь, конечно, о форматах записей (Post Formats).

Форматы записей (Post Formats)

Эта возможность появится в версии 3.1. На данный момент чтобы её потестировать вам нужно скачать development версию WordPress. Я использовал 3.1-RC4-17441.

Рассмотрим, что они из себя представляют.

Одно из их отличий от таксономий постов и типов записей заключается в том, что форматы не нужно создавать. Нужно просто включить их поддержку (используется функция add_theme_support).

add_action('after_setup_theme', 'add_post_formats');
function add_post_formats() {
	add_theme_support( 'post-formats', array( 'aside', 'gallery', 'quote' ) );
}

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

В результате справа на страницах редактирования и создания записей вы увидите новый блок.

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

Для этого нужно будет зарегистрировать таксономию с названием post_format и добавить в неё термины вида post-format-название_формата (например, post-format-aside). Для добавления термина используется функция wp_insert_term.

Естественно, в теме вы сможете определить формат текущей записи и соответствующим образом изменить её вид.

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

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

С другой стороны, это логично. Если тема создавалась для корпоративного ресурса, то вряд ли она подойдет для портфолио. Исключить эту проблему можно было оставив WP чисто блоговым движком.

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

В заключение хочу сказать, что я не знаю точно насколько популярными окажутся форматы постов. Кстати, взгляды авторов англоязычных блогов по этому вопросу тоже не однозначные. Но, в любом случае, приятно видеть, что движок развивается!

Поэтому, хочу пожелать его авторам удачи!

Интересно почитать

Хотите научиться делать красивые сайты? Курсы flash дадут знания для начала работы.

Подготовка 3 ндфл за обучение для получения социального вычета в кратчайшие сроки

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

Сегодня я хочу показать прием, который позволяет назначить виджетам (которые находятся внутри одного сайдбара) индивидуальные CSS стили.

Прежде всего, разберемся, о каких именно стилях идет речь.

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

Эти параметры задаются разработчиком темы при создании сайдбара. Например, так:

register_sidebar(array(
	...,
	 'before_widget' => '<li id="%1$s" class="widget %2$s">',
	 'after_widget'  => '</li>',
	 'before_title'  => '<h2 class="widgettitle">',
	 'after_title'   => '</h2>'
));

Разработчики виджетов обычно используют их внутри метода widget. Взгляните на фрагмент примера из кодекса.

class My_Widget extends WP_Widget {
...
	function widget($args, $instance) {
		extract( $args );
		$title = apply_filters('widget_title', $instance['title']);
		?>
		<?php echo $before_widget; ?>
			  <?php if ( $title )
				echo $before_title . $title . $after_title; ?>
			  Hello, World!
		  <?php echo $after_widget; ?>
		<?php
	}
}

Как видите, в параметре before_widget использованы две переменные: %1$s и %2$s (их значения подставляются с помощью функции sprintf). В результате для текстового виджета получим что-то вроде.

<li id="text-3" class="widget widget_text">

Т.е. мы можем задать стили отдельно для каждого типа виджетов. Но представьте, что нам нужно вывести заголовки каждого четного виджета в сайдбаре темно-синим, а каждого нечетного – серым цветом. И при этом цвет не зависит от типа виджета, а определяется исключительно порядком размещения виджетов и если пользователь переставит виджеты местами, то и цвета должны измениться.

Использовать параметр id для этих целей вряд ли получится. Он создается при вставке виджета в сайдбар и не изменяется при перемещении виджета.

Решение довольно простое.

Добавьте в файл functions.php следующий код.

function custom_widget_counter($params) {
	global $widget_counter;

	if ($params[0]['id'] == 'my_sidebar') {
		$widget_counter++;
		If ($widget_counter % 2 == 0) {
			$params[0]['before_title'] = '<h2 class="even">';
		}
		else {
			$params[0]['before_title'] = '<h2 class="odd">';
		}
	}
	return $params;
}

add_filter('dynamic_sidebar_params','custom_widget_counter');

«Фокус» заключается в использовании фильтра dynamic_sidebar_params, который позволяет изменять параметры, указанные при создании сайдбара (функция register_sidebar).

Установка атрибута class выполняется функцией custom_widget_counter (её имя мы указываем при добавлении фильтра). В первом параметре эта функция получает массив с текущими настройками.

Затем мы объявляем глобальную переменную $widget_counter, которая используется в качестве счетчика виджетов в сайдбаре.

Учитывая, что сайдбаров может быть несколько, проверяем id сайдбара и если он равен my_sidebar, устанавливаем параметр before_title. Для этого достаточно просто присвоить соответствующему элементу массива новое значение.

Если текущий виджет четный, устанавливаем <h2 class="even">, в противном случае – <h2 class="odd">.

И, самое главное, нужно обязательно вернуть (return) изменённый массив, иначе наши изменения применены не будут.

После этого остаётся только добавить соответствующие CSS правила в таблицу стилей.

И ещё раз хочу обратить ваше внимание. Этот метод будет работать для виджетов, которые разработаны в соответствии с рекомендациями кодекса (используются переменные before_widget, before_title и т.д. в разметке виджета).

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

До встречи!

Интересно почитать

Нужно продвижение ресторана? Попробуйте муляжи блюд от японских дизайнеров

Качественные и удобные промо сумки на заказ от швейного цеха

Приветствую!

Сегодня выложил очередное обновление WordPress плагина Terms Descriptions.

Для тех, кто слышит о нём впервые, кратко объясню его назначение. Он позволяет создавать списки терминов, назначать им ссылки, автоматически искать термины и преобразовывать их в ссылки в ваших записях. Подробнее можно почитать здесь.

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

Последнее усовершенствование предложил Андрей Х.

Идея заключается в добавлении атрибута class ссылкам, которые создаёт плагин.

Что это даёт?

1) Возможность выделить ссылки с помощью CSS стилей.

2) Возможность обеспечить единый внешний вид ссылок, если для остальных ссылок уже установлен атрибут class.

Добавить атрибут несложно.

Обновите плагин, в админке появится дополнительное поле.

Значение атрибута нужно указать в поле "Атрибут Class для ссылок".

После этого, ссылки будут выглядеть так.

<a href="http://site.domain" class="ext_link">Текст ссылки</a>

Не хотите пользоваться этой возможность, просто оставьте поле пустым.

Ещё одно изменение касается русской локализации. За это отдельное спасибо Андрей Х, который не поленился и исправил мои ошибки.

Кстати, если есть желание и возможность, вы можете перевести этот плагин на свой язык. Много времени это не займет. Плагин содержит менее 40 текстовых фраз. Для перевода удобнее всего использовать программу Poedit. Затем просто пришлите файл переводов мне.

Надеюсь, нововведения будут вам полезны.

Удачи!

Приветствую всех!

Я всё-таки собрался и доделал плагин Terms Descriptions

Изменений в новой версии не много, но об одном из них меня просили уже несколько раз.

Речь о поддержке словоформ, т.е. нескольких вариантов написания одного и того же термина.

Например, так яблоко|яблоки|яблок и т.д.

Разделять словоформы нужно с помощью символа |. При этом, каждый из вариантов написания может состоять из одного или нескольких слов. Например, жесткий диск|винчестер|HDD.

В общем, эта возможность должна понравиться SEO'шникам Хотя я не советую черезмерно увлекаться перелинковкой. Страница с большим количеством ссылок выглядит не естественно. Особенно, если ссылки одни и те же.

Поэтому не лишним будет использовать настройку "Преобразовывать первые … терминов".

Обратите внимание, что все словоформы считаются одним термином. Т.е. жесткий диск|винчестер|HDD – один термин. И если в настройках указать "Преобразовывать первые 2 термина", то плагин поставит только две ссылки (на те словоформы, которые встретятся первыми в тексте поста).

Важно!

Большие списки терминов (100+) могут отрицательно сказаться на скорости формирования страницы. В таких случаях решить проблему можно с помощью кеширования, благо для WordPress недостатка в соответствующих плагинах нет.

Ещё одна новость касается размещения плагина.

Я перенёс его на официальный сайт WordPress. Так что теперь будут работать автоматические обновления.

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

Кстати, на странице плагина есть виджет Compatibility. С его помощью можно указать с какими версиями плагин работает, а с какими – нет. Мне будет приятно, если вы поучаствуете в наполнении этой статистики.

Удачного обновления!

Интересно почитать

Шьем сумки из хлопка и ПВХ, цены – фантастика

Приветствую всех!

Сегодня, просматривая Google Reader, я наткнулся на две статьи о системе комментирования Disqus с диаметрально противоположными мнениями – For Idiotisqus и Системы комментирования для блогов – плюс и минусы. Что же делать?

В принципе, все это смахивает на типичный холивар, в которых я учавствовать не люблю. Но для многих блоггеров вопрос стоит конкретно: «Устанавливать стороннюю систему комментирования или нет?» И ориентироваться они будут именно на такие статьи. К тому же, потестировать такую систему локально не получится, вы просто не получите достаточно объективных данных. А ставить эксперименты на «живом» блоге никто не любит.

В этой статье я хочу рассказать о своем опыте использования Disqus и, возможно, помочь принять правильное решение

Прежде всего, разберемся, зачем вообще оно надо.

Стандартная система комментирования WordPress (и других движков) предлагает пользователю заполнить форму минимум из трех полей (имя, email и текст комментария). Обычно есть ещё и четвертое поле – ссылка.

Заполнять эти поля нужно каждый раз при отправке комментария. Некоторые блоггеры, правда, предлагают посетителям зарегистрироваться, тогда форму заполнять не нужно. Но, думаю, вы понимаете, что регистрироваться будут только постоянные читатели, которые комментируют часто, да и то, не все.

Очевидно, что если посетитель комментирует часто и не только на вашем блоге, то он захочет ускорить процесс и избежать ошибок при вводе своих данных.

Решать проблему можно по-разному.

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

Или заняться этой проблемой самому. Т.е. дать возможность использовать для аутентификации какие-нибудь социальные сервисы. При этом процедура аутентификации заключается в том, что посетитель подтверждает, что он является владельцем аккаунта на выбранном сервисе. И самое главное преимущество – она выполняется двумя кликами (если, конечно, вы залогинены на выбранном сервисе).

Второй вариант, естественно, выглядит привлекательнее. Но, к сожалению, красиво все получается только в теории.

Есть глюки в работе сторонних систем комментирования, есть проблемы с переводом на русский. Так, например, в Disqus не всегда правильно отображается время отправки комментария, хотя в английской версии этих проблем нет. Кроме того, Disqus в какой-то момент может оказаться недоступен (правда, я такого не замечал).

Но давайте посмотрим, какие есть альтернативы.

1) Написать систему аутентификации самостоятельно.

Я серьезно рассматривал этот вариант. В теории все просто. Есть два протокола – OpenId и OAuth, которые поддерживают большинство сервисов, и есть готовые библиотеки для работы с ними (писать всё с нуля долго и нудно). Но когда я начал тестировать OpenId библиотеки получилось, что протокол они вроде бы поддерживают, но работают не со всеми сервисами. Например, многие не работают с Google, а он – один из самых популярных OpenId провайдеров.

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

Примечание. Тут я могу ошибаться. Все библиотеки я не тестировал. Возможно, через какое-то время ситуация изменится.

От этого варианта я отказался.

2) Использовать сервис Loginza или аналогичный (правда, аналогов я не знаю ).

Здесь ситуация гораздо лучше. Поддерживаются все основные сервисы и работает он стабильно. К тому же есть готовый плагин для WP.

Тем не менее, вопросы остаются. Loginza не гарантирует, что вы получите все необходимые данные. Например, email. Некоторые сервисы аутентификации его просто не передают. Тут же возникает вопрос: «Каким образом тогда реализовать подписку на комментарии?»

Кстати, если интересно, у меня есть несколько статей об использовании Loginza – первая, вторая.

3) Использовать стороннюю систему комментирования, например, Disqus.

Тут от вас ничего особенного не потребуется. Подключить ее к своему блогу достаточно просто. Но, как я уже говорил, проблемы есть. Правда, всё не так плохо, как рассказывает Тормоз

Прежде всего, нужно четко понимать, что при использовании Disqus все комментарии автоматически синхронизируются между сервисом и вашей базой данных. Т.е. вы в любой момент может отключить эту систему, и не потеряете ни одного комментария (проверить очень легко, просто посмотрите таблицу wp_comments).

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

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

Но ориентироваться тут нужно на собственный блог, а не на усреднённую статистику. Например, для этого блога ситуация такая.

Имеет ли мне смысл ориентироваться, например, на эту статистику?

Переходим к поддержке JavaScript, точнее его отсутствию.

Без JS система вроде Disqus работать не будет. Тут без вариантов. Но фокус в том, что без поддержки JS нормально работает только стандартный метод отправки. Можно, конечно, аутентифицировать посетителя и через OpenId, но что будет представлять собой такая аутентификация?

Пользователя будет несколько раз редиректить между вашим сайтом и OpenId провайдером. Такой вариант прекрасно работает на ресурсах вроде Stackoverflow.com, но, думаю, 99% аудитории там четко понимают, что происходит и что нужно делать. Т.е. опять же, все зависит от ресурса и особенностей его аудитории.

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

Спам

Тут Disqus на высоте. Это одно из самых эффективных решений в борьбе со спамом. Подобные результаты я получал только при одновременном использовании Akismet и довольно сложной капчи.

Сейчас автоматитического спама вообще нет, а ручного стало гораздо меньше (меньше 10 комментариев в неделю). Это при том, что раньше я их десятками в день удалял.

Кстати, было бы совсем неплохо, если бы у спамеров браузеры зависали

Заключение.

В общем, не хочу я никому ничего навязывать. Мне лично удобно проходить аутентификацию с помощью сторонних сервисов, это экономит моё время. При этом, я пользуюсь последними версиями хороших браузеров

Но это не означает, что я советую всем блоггерам использовать Disqus или подобную систему. Попробуйте, посоветуйтесь с читателями (для этого достаточно написать пост и попросить оставить свои впечатления). Не понравится – вернёте всё назад.

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

Интересно почитать.

Работающая раскрутка кафе от японских рестораторов

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

Один из таких примеров – подключение JavaScript кода в WordPress.

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

Кстати, аналогичные возможности есть и в различных фреймворках, например, Yii.

Но разница между фреймворком и WordPress в том, что с помощью последнего можно создать сайт, не читая документацию, во всяком случае, ту часть, которая касается API. В этом нет ничего плохого, но можно столкнуться с некоторыми нюансами. О них речь пойдет ниже.

Основные проблемы и причины их появления

Возьмем самую распространённую ситуацию. Есть сайт на WP, и есть готовый JS скрипт, который нужно к этому сайту подключить.

Что написано в инструкции по установке скрипта?

«Вставьте тег <script…> в заголовок страницы (между <head> и </head>)».

Тут все правильно. Разработчик пишет инструкцию на общий случай, а не конкретно под WP.

Следующий вопрос. Где находятся теги <head> и </head> в WP?

Обычно в файле header.php текущей темы.

Т.е. если делать строго по инструкции, то нужно добавить теги <script…> в header.php.

Именно здесь и возникают проблемы.

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

Проблема 1. Многократная загрузка JS файлов.

Возникает если подключить JS скрипт в файле темы, а затем использовать плагин, которому нужен этот же скрипт. Чаще всего такое происходит с JavaScript библиотеками.

Разработчики плагинов доступа к файлам вашей темы не имеют, но должны гарантировать подключение необходимых скриптов. Поэтому для них единственным вариантом будет использование wp_enqueue_script.

В результате один раз JavaScript файл подключается вашим тегом, второй – тегом, который добавит плагин. Это приводит к увеличению веса страницы, времени её загрузки, росту трафика сервера.

Проблема 2. «Неработающие» плагины.

Вытекает из первой.

Рассмотрим небольшой пример. Допустим скрипты подключены в header.php следующим образом.

<head>
	...
	<script src="...jquery.js" ...></script>
	<script src="...jquery.my-plugin.js" ...></script>
	<?php wp_head(); ?>
</head>

Что произойдет если какой-то из плагинов WP подключит jQuery?

Функция wp_enqueue_script добавит теги script там, где находится вызов wp_head(). А это, помимо повторной загрузки jquery, означает, что и объект jQuery будет создан заново. И он будет использоваться вместо первого объекта, к которому подключили плагин.

В принципе, проблему можно решить так.

<head>
	...
	<?php wp_head(); ?>
	<script src="...jquery.my-plugin.js" ...></script>
</head>

Но если вы в админке WP отключите плагин, который использует jQuery, то my-plugin.js также перестанет работать. Т.к. jQuery будет не подключена.

Как избежать этих проблем?

Просто не трогайте header.php. В папке с темой есть файл functions.php в который нужно добавить следующий код.

<?php
if ( !is_admin() ) {
	function register_my_js() {
		wp_enqueue_script( 'my-script', get_bloginfo( 'template_directory' ).'/my-script.js', array( 'jquery' ), '1.0', true );
	}
	add_action('init', 'register_my_js');
}
?>

Этот код подключит скрипт на всех страницах сайта, кроме админки. Если нужно подключать скрипт только на части страниц, можно в условие проверки добавить is_single(), is_home() и т.д.

Кроме того, библиотеку jQuery явно подключать не нужно, т.к. она указана в массиве зависимостей (третий параметр wp_enqueue_script). WordPress подключит её сам до вашего плагина.

Для справки

Функция wp_enqueue_script подключает JS файл если он не был подключен ранее. Т.е. можно вызвать её несколько раз для одного и того же скрипта и, при этом, скрипт будет вставлен только один раз.

Параметры.

wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );

$handle – название скрипта, должно быть уникальным.

$src – URL скрипта. Если скрипт был предварительно зарегистрирован с помощью wp_register_script, то его указывать не обязательно.

$deps – массив зависимостей (нужно перечислить названия JS скриптов, которые должны быть загружены перед данным).

$ver – версия скрипта (необязательный).

$in_footer – если равен true, скрипт будет подключен в конце страницы, там где находится wp_footer(). Обычно в файле footer.php перед </body>.

Заключение

Очень советую почитать статью Function Reference/wp enqueue script. Она небольшая, но в ней вы найдёте несколько интересных примеров. Например, объясняющих как заменить версию библиотеки jQuery, которая идёт в дистрибутиве WP.

Интересное в сети.

Возможно, самый оригинальный подарок:фруктовые корзины с доставкой по Москве.

Технология кейс-стади: отлично работает при продаже услуг.