Управление контентом в WordPress CMS: ситуация на сегодня и ближайшая перспектива

Владимир | | PHP, Web разработка, WordPress.

wp cms

Приветствую всех! В этот раз поговорим о нынешних и будущих возможностях одного из самых популярных блоговых движков – 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 – это различные настройки. Если хотите, можете почитать их подробное описание.

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

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

taxonomy hierarchical

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

taxonomy simple

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

taxonomy menu

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

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

taxonomy templates

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

Поддержка такой иерархии шаблонов движком позволяет избавиться от длинных оператов 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) и т.д.

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

custom post types

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

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

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

custom post types templates

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

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

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

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

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

Давайте вспомним, почему 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' ) );
}

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

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

post formats

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

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

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

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

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

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

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

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

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

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

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

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