Управление контентом в 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 ндфл за обучение для получения социального вычета в кратчайшие сроки

  • Петров Николай

    WP все больше становится похож на Drupal

  • MAX

    Таксономия в WordPress была введена в погоне за модой Друпала. И хотя основы были заложены достаточно давно (с версии 2.3), реального использования нет и не будет прежде всего из-за крайне бестолковой реализации и совершенно дико предложенного способа использования, о чём вы сейчас превосходно показали. WordPress до сих пор не может предложить управлять данными легко и просто. Главная пробелма — фиксированные типы данных и записей.

    Просто сравните как выполняется создание типа записи в моей MaxSite CMS — Настройки — Основные — Типы страниц — Вбиваем название и произвольный тип. Дальше в редакторе выбирает любой тип. Использование — если в виджетах (а чаще всего именно такая задача), то просто в виджете указываем тип страниц для вывода. Если в шаблоне, то несколько вариантов, суть которых сводится к одной строчке «'type'=>тип».

    Данным примером я всего лишь хочу призвать к объективной реальности: стоит признать, что в WordPress плохо реализована поддержка таксономии при использовании вне «внутренних» рубрик и меток. Делать свои аля «Custom Post Types» довольно проблематично.

    • Alex Wpstarter

      даже если это и «погоня за модой Друпала», то очень полезная погоня

    • Я бы не сказал, что это погоня за Друпалом — это попытка добавления инструмента для создания и управления информационной архитектурой сайта/блога.

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

      Совершенно согласен с тем, что в Вордпресс это реализовано убого. Я никак не могу понять, откуда такая мания — добавлять новые функциональные возможности в шаблоны оформления, а не в ядро…

  • Pingback: Tweets that mention Управление контентом в WordPress CMS: ситуация на сегодня и ближайшая перспектива -- Topsy.com()

  • Alex

    Custom Post Type лучше переводить полностью как «пользовательский тип записи», чтобы не вносить путаницу с уже существующими в движке типами

    • По смыслу подходит, но не совсем. Custom Post Type создается разработчиком, а не пользователем движка.

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

      • Хоть и разработчиками создан, но если вспомнить то и CCK небыл встроен в Drupal изначально.

  • Да, к сожалению, поддержка таксономий в WP довольно ограничена. Фактически они сделали возможность создавать группы тегов и категорий.

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

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

  • Забавно… Именно сегодня взялся за новый проект на WP(уже пол года на нем ничего не делал) в котором понадобилось Custom Post Types, Custom Taxonomies и не упомянутый в статье Custom Fields. Вечером решил почитать google reader, а тут на тебе =)
    з.ы. а почему про Custom Fields в статье ни слова? ведь они существенно расширяют возможности по форматированию информации

    • Custom Fields позволяют добавить дополнительную информацию к посту. А типы записей, таксономии, форматы постов позволяют структурировать контент (разбивать посты на группы).

      Конечно, можно в Цикле проверять значение Custom Fields и использовать его для разделения записей по какому-то признаку, но это не стандартная возможность. Для этих целей Custom Fields использовались когда не было Custom Post Types.

      Поэтому я не включал их.

      Еще один пример, Custom Post Types позволяют использовать различные Custom Fields для различных постов.

  • А чем Друпал лучше Вордпресса? По-моему для новичка Вордпресс — просто находка, он прост и понятен.

    • Понятия лучше/хуже в данном случае не подходят. Drupal удобнее использовать для решения одних задач, WP — для других.
      В целом, Drupal более гибкий, т.к. изначально создавался как многоцелевая CMS, а не блоговый движок. Отсюда же вытекает и простота работы с WP.

  • ооо, большое спасибо, давно интересовала такая информация

  • Prolab

    Создал свой Custom Post Type назвал film, привязал шаблоны — в основном всё работает, но не срабатывает постраничная навигация для моего нового типа, т.е. всегда отображается только первая страница перечня фильмов, строка навигации внизу страницы формируется правильно, постоянные ссылки по умолчанию, как будто параметр paged игнорируется, со стандартными post всё работает, тема twentyten, если в index.php добавить query_posts(array('post_type'=>'film')); постраничная навигация так же не работает. Любая подсказка сильно мне поможет.

    • Я давно планировал написать статью на эту тему. Постараюсь на этой неделе ее опубликовать.

      Вкратце так:
      1) проверяете $wp_query, установлено ли значение paged;
      2) если значение установлено, проверяете запрос к базе (в нем должен быть LIMIT);
      3) если значение paged не установлено, то, скорее всего, проблема в правилах перезаписи url, т.е. проверяете правила в WP_Rewrite.

      • Nikslashman

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

        На данный момент я определил, что проблема не в ЧПУ, но ни одно из найденных в интернете решений не помогло. Буду очень благодарен.

        • Я использую paginate_links. Настроить параметры для этой функции — история отдельная, настраивать приходится под конкретную ситуацию, но все проблемы решаемые 🙂

        • Nikslashman

          К слову, наткнулся на такое решение http://wordpress.org/extend/plugins/custom-post-type-category-pagination-fix/. В полной мере еще не протестировал, но при первом знакомстве мою проблему решило.

        • Прочитал описания этого плагина и вспомнил, что я практически никогда не использовал структуру ссылок %category%/%postname%. Поэтому, наверное, с таким багом не сталкивался.

  • Test

     чамчвм

  • chance

    Здравствуйте, нужен профессиональный дельный совет. Есть сайт игровой тематики, ничего общего с блогом)
    Вообщим на сайте есть два типа таксономий игровые жанры и платформы, сейчас же я хочу сделать более осмысленную конструкцию и создать таксономию игры (или тип), чтобы при написании статьи можно было выбирать к какой игре она относится, а сами игры при этом вы водились отдельно. Ну, например, захожу в статью гайд по тетрису, а там ссылка на страницу с игрой или другие материалы по этой игре, сама же игра в виде страницы со статьей.
    Также прикрутил к теме профиль пользователей, если при всем при этом можно было бы добавить у него список с играми, мол, в какие игры я сейчас играю, вообще было бы замечательно.
    У кого какие советы, код писать не надо, просто посоветуйте, как лучше реализовать (без плагинов)

    • > сама же игра в виде страницы со статьей

      Как это выглядит? Игра на JS или flash и интегрирована в страницу?

      > список с играми

      WP поддерживает метаданные пользователей (таблица wp_usermeta, получить можно с помощью get_user_meta).
      Заполнять этих данные может либо сам пользователь (нужно будет добавить поля на страницу профиля), либо, если игры интегрированы в сайт и есть возможность узнать какие игры пользователь запускал, то можно заполнять метаданные автоматически.

      • chance

        Вы меня не так немножко поняли, про мета я знаю они здесь не к чему. Профили и соц элементы я организовал несколько иначе. Но ближе к делу сейчас у меня есть категория игры, статьи, гайд и т. п. Я хочу сделать пользовательский тип статьи (ну или если посоветуют что-то другое) под названием «игры». Такой пост будет содержать всю инфу по игре (системные требования, движок, разробы и т.д.) и при этом хочу, чтобы все статьи, которые будут, добавляется позже и связанные с той или иной игрой можно было подключить к этому типу. Например, Игра Ассасинс, потом добавляю статью обзор, и при этом вставляю галочку, что статья будет привязана к этой игре. Человек заходит на сайт видит материал и внизу (к примеру) все материалы по этой игре. Функции и плагины типо похожие статьи не катят!

        • Если я правильно понимаю, вам нужно «привязать» один пост к другому? Т.е. если такая «привязка» установлена, то на странице основного поста будет выводиться «привязанный»?

          В этом случае, удобнее всего будет использовать кастомные типы страниц (custom posts types) для «привязанных» постов.
          Готовый плагинов для решения этой задачи я не знаю, поэтому плагин придется написать самостоятельно. Но тут никакого сверхсложного кода не будет.

          1) Создаем новый тип постов для игр — «Игры».

          2) Добавляем metabox на страницы редактирования для всех остальных типов постов.

          3) В этом метабоксе показываем выпадающий список со всеми постами типа «Игры». Значением (value) каждого элемента списка лучше всего сделать ID поста. В результате, после нажатия на кнопку «Сохранить» у поста появится метаполе, в котором будет сохранен ID «привязанного» поста.

          4) Добавить вывод «привязанного» поста в шаблоне темы.

          5) Если постов типа «Игры» будет много, то выпадающий список лучше заменить полем с автодополнением.

        • chance

          Спасибо, буду пробовать

  • Ну как по мне то все больше и больше похож. Вот статью написал о плагинах Views, Types и Access для WordPress. Пользуюсь ними, очень даже неплохо облегчают работу, разработка быстрее чем на Drupal получается, особенно хорошо нелать небольшие проекты с нестандартным выводом. Очень советую преобрести если занимаетесь WordPress. Плагины платные но они стоят своей цены, окупились не раз.

    http://wp-admin.com.ua/views-types-cred-aaccess/