CMS в реальном использовании выглядит следующим образом:
[icon name=»code» prefix=»fas»] ядро, с заранее заданным функционалом;
[icon name=»code» prefix=»fas»] дополнения к ядру, обеспечивающие дополнительный, отсутствующий в ядре функционал (например, в Drupal – модули, в WordPress – плагины), как платные, так и бесплатные;
[icon name=»code» prefix=»fas»] тема оформления – отвечает за то, каким увидит ваш сайт пользователь, в эту часть так же может быть заложен отсутствующий в ядре функционал либо дополняющий его, как платные, так и бесплатные.
Публикации в CMS предусмотрены двух типов:
[icon name=»info» prefix=»fas»] единичная страница («page»), как правило, без необходимости связи с другими публикации (типичный пример использования – контакты);
[icon name=»list» prefix=»fas»] страницы («post»), связанные друг с другом по хронологии (на их основе – разнообразные «ленты» публикаций).
Для организации структуры «лент», их выбора то тем или иным признакам используют т.н. «семантики»:
[icon name=»sort» prefix=»fas»] многоуровневые (иерархические), пример – рубрики, категории (вышестоящая по иерархии рубрика включает прикрепленные публикации к нижестоящим по иерархии рубрикам),
[icon name=»sort» prefix=»fas»] одноуровневые, пример, теги, метки и т.п.
В чем «вкусность» Drupal по сравнению с WordPress, о которой уже упоминал – в ядре Drupal изначально предусмотрена возможность создания в админке сайта (без использования дополнительного функционала):
[icon name=»plus» prefix=»fas»] разнообразных «типов публикаций» на основе предзаданных (раge или post), например, можно сразу разделить публикации по типу – новости, мнение экспертов, редакционная колонка, интервью и т.д. и т.п.
[icon name=»plus» prefix=»fas»] разнообразных «семантик», для связи публикаций по тем или иным признакам, например, персона, тема, место действия и тд. и т.п.
В WordPress изначально присутствует только одна иерархическая «семантика» (category) и одна одноуровневая «семантика» (tag). Разумеется, и в WordPress предусмотрена возможность использования дополнительных «типов публикаций» и дополнительных «семантик», правда, для этого необходимо будет кодить либо использовать тот или иной дополнительный плагин с соответствующим функционалом.
Почему важно продумать структуру организации «типов публикаций» и «семантик» на начальном этапе?
Теоретически, дополнять то что есть можно на любом этапе. Другой вопрос – какой ценой?
Одно дело, если вы решили создать дополнительную «семантику», когда у вас всего 10 публикаций, другое – 1, 10 или 100 тысяч публикаций.
Например, у вас региональный сайт, с течением времени вы решили, что вам нужна дополнительная «семантика» по муниципальным образованиям или населенным пунктам. Автоматически «привязать» ранее созданные публикации к той или иной позиции новой «семантики» не возможно, придется делать «вручную».
Другой пример, вы решили, выделить из существующего новый «тип публикации», чтобы, например, у нового была иная структура оформления. Хорошо, если выделяемые публикации были хоть как-то структурно выделены, и есть в базе данных принадлежащий только им признак, например, только им была присвоена определенная позиция в «семантике» «категории». Не просто, но эту процедуру выделения можно автоматизировать. Если такого признака нет – снова только «вручную».
Таким образом, чем более продумана на начальном этапе структура организации контента на вашем сайте, тем больше времени, сил и средств вы сэкономите в будущем.
И еще рекомендация на будущее.
Если ваш контентный сайт предполагает публикацию такого формата, как «новости», обязательно отделите именно эти публикации от остального. Без подключения ваших новостей к Яндекс.Новости и Гугл.Новости (о чем подробнее будет в следующем разделе «Контент и Технологии») донести их до широкой аудитории, которой новости интересны по определению, более чем проблематично. И если Гугл.Новости менее требовательны к содержанию передаваемых им публикаций, то Яндекс.Новости предпочитают в передаваемом им потоке именно новости, а не что то иное.
Еще один момент, связанный с особенностями CMS, который необходимо учитывать при проектировании уже собственно содержания публикации.
В любой CMS предустановлены и их можно сразу использовать такие элементы публикации:
[icon name=»arrow-right» prefix=»fas»] Заголовок,
[icon name=»arrow-right» prefix=»fas»] Описание (выдержка, отрывок)
[icon name=»arrow-right» prefix=»fas»] Текст,
[icon name=»arrow-right» prefix=»fas»] Изображение,
[icon name=»arrow-right» prefix=»fas»] Дата/время,
[icon name=»arrow-right» prefix=»fas»] Автор.
Что следует знать и над чем нужно подумать в этой части.
С заголовком понятно – он должен быть. А каким именно — подробнее будет в следующем разделе «Контент и Технологии».
Описание (выдержка, отрывок) – с точки зрения внешнего вида, элемент не обязательный. Его можно использовать в ленте публикаций, как дополнительный элемент, можно не использовать. Аналогично и на самой странице публикации. Роботу Google все равно – есть такой элемент или нет. Совсем иначе для робота Yandex. Об отсутствии этого элемента в публикациях Yandex будет напоминать в Вебмастере как о возможной проблеме сайта: Отсутствуют метатеги Description.
Нужно или нет – решать вам. В практической плоскости – этот элемент необходим, если вы захотите, что бы при репосте в соцсети публикации с вашего сайта соцсеть «подхватывала» не только заголовок и изображение записи, но и законченный осмысленный текстовый отрывок. Подробнее о метатегах публикации будет в следующем разделе «Контент и Технологии».
Текст публикации – благодаря разнообразным редакторам текст публикации уже давно не просто текст. Разнообразные вставки изображений и их галерей, видео, аудио, коды вставок видео и аудио со сторонних ресурсов, отображения публикаций из соцсетей и т.д.и т.п. – можно будет сделать здесь при создании публикации.
И в этом смысле скорее всего внешним видом одна публикация будет совсем не похожа на другую. Иногда – это хорошо.
Если же вам что-то, например, галереи изображений, видео, аудио, коды вставок видео и аудио со сторонних ресурсов, нужны как запоминающиеся и отличающие именно публикации вашего сайта элементы оформления, т.е. если они есть, то всегда на одном и том же месте, следует их определить заранее и для их ввода и сохранения можно использовать т.н. «дополнительные» поля, которые, впоследствии использовать на макете публикации для отображения того, что необходимо именно в том месте, где необходимо.
Можно и не заранее. Можно потом. Но в этом случае, чем позже, тем больше ручного труда для корректировки отображения ранее созданных публикаций. Хорошо, если на этапе, когда публикаций 10, не сложно. А если их 1, 10 или 100 тысяч? «Дополнительное поле» к каждой публикации появится в момент его создания. Только содержание его, до заполнения и сохранения публикации останется пустым.
Варианты автоматизации этого процесса есть, но они все равно потребуют значительного ручного труда на предварительном этапе.
Изображение публикации – лучше если оно есть. Совсем хорошо, когда оно полностью соотносится с содержанием публикации. Его используют и как элемент оформления на лентах публикаций, и как элемент оформления собственно публикации. Единственно, не забываем о том, что любое изображение – объект авторских прав. И если нет специального разрешения, использование чужого изображения – нарушение этих самых прав с риском получить штраф по итогам судебного разбирательства.
Дата/время – и необходимый элемент оформления, и элемент, по которому CMS формирует ленты в хронологическом порядке.
Автор – по умолчанию СМS определяет Автором публикации, того пользователя, кто создал публикацию. Если у вас публикации будут публиковать только сами авторы – вопросов нет. Очень часто на контентных сайтах организовано несколько иначе. Для простоты: создают контент одни, размещают – другие. Кого посчитает CMS Автором в таком случае? Того, кто разместил. По отношению к настоящему Автору – совсем некрасиво. А если создавал не один, а несколько?
И тут еще вопрос, как вы захотите реализовать подборку публикаций действительного Автора: просто указание ФИО в виде текста, еще может быть лента его публикаций, либо сначала переход на отдельную страницу действительного Автора, где, например, будет прикреплена лента его публикаций.
Для первого случая, можно использовать дополнительную «семантику» авторов. Для второго – «дополнительное поле» с указанием URL заранее созданной страницы Автора.
Как именно сделать – дело ваше, но факт такой необходимости лучше определить заранее. Переделать впоследствии будет сложнее. Для этих целей и служит «техническое задание». И при его наличии – намного проще проверить что из запланированного сделано и как именно сделано.