Адаптивный контент средствами WordPress.

Перевод статьи:  Adaptive content with WordPress.
Автор:  Анна Ладошкина.

Отзывчивый дизайн не просто проверяет возможности используемых нами в веб-дизайне и разработке средств и подходов, более того, он вынуждает нас пересмотреть уже устоявшиеся способы формирования контента и управления им. Как известно, любые новые технологии подразумевают введение надлежащих инструментариев. Это наводит на мысль о том, что сейчас открываются возможности для появления совершенно новых систем управления контентом (CMS) и публикационных платформ (надеюсь, что в скором будущем у нас будет из чего выбирать). Но каждый, кто когда-нибудь переходил с одной CMS платформы на другую, прекрасно знает, что это совсем не безболезненный процесс. Вопрос в том, сможем ли мы приспособить уже давно и успешно используемую нами популярную платформу WordPress для решения задач, связанных с созданием и управлением адаптивным контентом?

Прежде всего, мы должны четко определиться с целью и взглянуть на вещи со стороны. Что, собственно подразумевается под понятием «адаптивный контент» и почему он так необходим в эпоху развития отзывчивого дизайна? Далее нужно рассмотреть все имеющиеся у нас функциональные возможности WordPress, чтобы выделить из них те, которые можно использовать с целью создания публикационной платформы, отвечающей всем предъявляемым временем требованиям. Перед нами стоит непростая задача — контент, созданный нами однажды, благодаря своей гибкой сущности должен быть свободно доступен с различных устройств и с учетом различных условий просмотра. Ну что ж, давайте посмотрим, насколько близко мы можем приблизиться к намеченной цели.

Адаптивный контент и зачем он нужен.

В своей недавней книге «Content Strategy for Mobile» («Контентная стратегия для Мобильных устройств»), специалист по UX и контентной стратегии Карен МакГрейн дает исчерпывающее и хорошо аргументированное объяснение тому, почему мы нуждаемся в новом подходе к управлению контентом. Мы не просто разрабатываем сайты с отзывчивым дизайном, мы идем дальше — мы создаем контент, который впоследствии может быть опубликован на разных платформах и быть доступен с различных устройств. Что, если завтра для кого-нибудь холодильник станет основным средством получения информации? Будет ли ваш сайт готов к такому сценарию использования?

По большому счёту отзывчивый дизайн благодарен своим появлением возникшей необходимости предоставления адекватных пользовательских возможностей владельцам мобильных устройств. Если честно, то мобильность — это еще не все, данное свойство является лишь частью рассматриваемого здесь вопроса. Если заглянуть в будущее, то в качестве новых платформ и устройств, на которых появится наш контент вполне могут быть: часы; холодильники; обычные очки; говорящие роботы, в конце концов, в общем все, что можно только вообразить. Означает ли это, что нам необходимо позаботиться о создании отдельной версии своего сайта и для говорящих роботов? Нет, таким образом мы лишь усугубим ситуацию. Где же выход? Спасательным кругом в данном случае является адаптивный контент — контент, который создается один раз и может быть многократно использован в различных ситуациях и сценариях. Звучит превосходно, не правда ли? Но как нам этого достичь?

1. Структурированный контент.

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

2. Презентационная независимость контента.

Наш следующий шаг будет направлен на разделение контента от презентации. Фактически, этот вопрос отражает одно из важнейших требований редизайна, а также является краеугольным камнем веб-стандартов. Но мы пойдем еще дальше — нам необходимо освободиться от WYSIWYG способа мышления. Теперь этот принцип больше не работает и «то, что видишь ты» совсем не обязательно «видят пользователи» твоего ресурса. Эта иллюзия очень опасна. Нам не следует средствами разметки выделять определенные фрагменты текста курсивом или вставлять изображение, используя соответствующий HTML элемент в поле контента, куда мы помещаем содержимое страницы. Нам нужно лишь указать ссылку на соответствующий контентный объект, а система проектирования уже сама обязана определить, как именно этот объект должен быть представлен пользователю.

3. Метаданные.

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

4. Контент многократного использования.

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

Могут ли все вышеперечисленные аспекты быть реализованы средствами WordPress? Мак Грейн обвиняет WordPress и другие платформы блоггинга в том, что они не предоставляют поддержки издателям в плане использования адаптивного контента. Действительно, в WordPress все еще используется WYSIWYG редактор, предусматривающий единственное текстовое поле для ввода вашего поста. К сожалению, это именно та ситуация, с которой зачастую сталкивается разработчик, использующий обычную «коробочную» версию WordPress. Но не все так плохо, как кажется на первый взгляд, ведь WordPress, к счастью, это нечто большее, чем просто программное обеспечение для блоггинга. Со временем этот продукт эволюционировал в мощную инструментальную платформу, фреймворк, с помощью которого разработчик в состоянии предоставить своим клиентам действительно новые, отвечающие требованиям времени возможности.

Преобразование WordPress в адаптивную платформу для публикаций.

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

WordPress был представлен и начал свое развитие уже будучи полноценной CMS, предусматривающей пользовательские типы постов и пользовательские таксономии. Другой мощной возможностью, которую необходимо использовать в комбинации с предыдущими, являются так называемые пользовательские поля. Этот простой термин имеет отношение к GUI. Кстатьи, эти самые пользовательские поля представляют собой набор метаданных, которые могут быть ассоциированы с любым объектом в WordPress. Данная платформа обладает возможностью создания UI для ввода метаданных с высокой степенью конфигурации, а также гибким API для хранения и доступа к ним.

Что это нам дает? Имея в своем распоряжении такой инструмент как пользовательские типы постов, мы больше не привязаны к «страничной» концепции представления контента. Мы можем создать тип поста для любого требуемого объекта (такой как news, events, partners, т.е любой необходимый нам тип), имея при этом возможность посредством набора метаданных, добавляемых с помощью пользовательских полей, определять структуру объекта. Более того, мы можем создать отдельный пользовательский интерфейс для управления метаданными. Все это делает наш контент более структурированным. И еще, поскольку WordPress позволяет нам создавать метаданные любого типа, мы могли бы использовать эту возможность для хранения альтернативных вариантов данных, ассоциируемых со встроенными блоками контента, таких как названия и описания. (И в этом случае, мы могли бы увидеть SEO плагины, которые позволяют использовать уникальные SEO-оптимизированные названия и описания для каждого имеющегося в нашем распоряжении объекта контента.)

Каковы ограничения? WordPress немало критикуют за непоследовательность в предоставлении API для хранения метаданных. Имеется в виду то, что если данная платформа предусматривает метаданные для постов (а также пользовательских типов постов) и для пользователей, то они не доступны в случае с таксономиями (для этого требуется отдельный плагин). Создание собственного UI редактора записей (постов) является не такой уж тривиальной задачей как кажется. Большинство трудностей в этом вопросе связано с отсутствием предопределенных функций и стандартных методов (именно поэтому, в разных плагинах данный функционал реализуется различными способами, что вместо систематизации процесса, создает лишь путаницу). Но последние нововведения, способствующие унификации и оптимизации инструментальной панели WordPress вселяют в нас надежду.

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

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

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

Применяя данный подход, мы сможем добиться того, что знакомое нам окно редактирования записей будет трансформировано до неузнаваемости:

Панель управления WordPress

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

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

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

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

add_filter('user_can_richedit', '__return_false');

Что касается второго правила, то здесь все намного сложнее. Мы, конечно же, не собираемся преследовать каждый HTML тег в вашем тексте, поскольку те из них, которые представляют действительно семантические элементы, вполне допустимы. Но если мы начинаем вставлять используемые для компоновки дивы (<div>), то у нас начинаются неприятности. Ведь ни для кого уже не секрет, что определенный компонент шаблона ресурса, представляемый в виде колонки в одном сценарии, может быть чем-то совершенно иным в другом.

Еще одна серьезная проблема связана с тем, каким образом WordPress вставляет мультимедийные файлы, в частности изображения, в поля ввода контента. На данный момент система просто вписывает в поле обычный HTML код, в который внедряется ссылка на соответствующее изображение, данные о его размерах и все это при необходимости обертывается дополнительной разметкой. Такое поведение представляет собой наихудший из возможных вариантов для адаптивного подхода. А что, если нам понадобится применить другой вариант изображения для определенного сценария использования ресурса? Или как быть, если мы будем вынуждены переместить нашу мультимедийную библиотеку на другой домен; сменим дизайн самого объекта, что повлечет за собой необходимость изменения размеров изображения; или же будем использовать технологию создания отзывчивого шаблона, которая требует указания нескольких источников изображения? В нашем случае все эти прецеденты абсолютно тупиковые и будут ими до тех пор, пока мы не изменим действия, выполняемые системой по умолчанию.

И все-таки у WordPress есть практически все необходимое для того, чтобы реализовать концепцию адаптивного подхода:

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

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

add_shortcode('frl_image', 'frl_image_screen');
function frl_image_screen($atts, $content = ''){

extract(shortcode_atts(array('id' => 0, 'link' => 'file', 'size' =>
'medium'), $atts ));

$out = '';
$id = intval($id);
if($id == 0)
return ''; // no attachment

$out = "<figure class='image {$size}'>";
$args = array(
'class' => 'frl-image',
'title' => ''
);

$img = wp_get_attachment_image($id, $size, false, $args);

/* linked image */
if($link == 'none'){ //no link
$out .= $img;

} elseif($link == 'file') { //link to file
$url = wp_get_attachment_url($id);
$out .= "<a href='{$url}'>{$img}</a>";

} else { //custom url
$url = esc_attr($link);
$out .= "<a href='{$url}'>{$img}</a>";
}

if(!empty($content))
$out .= "<figcaption>{$content}</figcaption>";

$out .= "</figure>";

return $out;
}

Заключение.

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

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

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

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

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *