Выбор системы управления контентом сайта

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

1. Введение

Сегодня часто говорят о системах управления контентом сайта (в английском оригинале Content Management System - CMS). Мы постараемся дать наиболее общее определение этого понятия, чтобы рассматривать все доступные подходы к вопросу с единой точки зрения.

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

Инструкции по использованию включены в определение неслучайно. Дело в том, что некоторые программные пакеты являются многофункциональными и способ их использования заранее не фиксирован. В качестве примера можно привести широко используемый для веб-программирования язык PHP. Первоначально его название расшифровывалось как Personal Home Page (персональная домашняя страница). То есть он позиционировался как система управления контентом небольшого персонального сайта. Сейчас язык PHP предоставляет большое количество возможностей и создать сайт с его помощью можно множеством способов. Как только вы определите набор инструкций — как будете создавать страницы, как будете управлять структурой сайта, где и в каком виде будете хранить содержимое страниц — вы получите систему управления контентом сайта, построенную на базе языка PHP.

2. По-старинке

В 90-е годы наиболее распространенной системой управления контента была следующая: в качестве программного обеспечения использовался веб-сервер, предоставляемый в составе услуги хостинга, редактор HTML-документов(от Notepad до Macromedia DreamWeaver) и FTP-клиент (например CuteFTP, gFTP, FAR или TotalCommander). Страницы создаются с помощью редактора и размещаются на сервере с помощью FTP-клиента. Структура сайта обеспечивается ссылками с одних страниц на другие и, возможно, присутствием меню на некоторых страницах. Сейчас такую систему называют статической. Название связано с тем, что содержимое (контент) страниц находится в статических (постоянно расположенных на диске) файлах, в противоположность динамически создаваемым страницам (генерируемым на лету с помощью программы, находящейся на сервере). С нашей точки зрения, принятая терминология, разделяющая сайты на статические и динамические, не вполне отражает смысл изменений, произошедших в технологиях управления контентом сайта. Суть не в том как хранится содержимое сайта, в «статических» файлах, в виде динамических программ или в базе данных, а в том, каким образом происходит обновление и структурирование информации. Поэтому вместо термина «статические», более правильно говорить «системы управления сайтом на базе языка HTML».

Преимущества систем на базе языка HTML:

1. Легко изменить внешний вид любой конкретной страницы, не повлияв на вид других страниц.
2. Несложно добавить на сайт новую страницу, скопировав и исправив файл с существующей страницей.
3. Человеку, занимающемуся поддержкой сайта, достаточно знать только язык HTML.
4. Сайт будет работать на любом сервере хостинга, даже с самыми ограниченными возможностями.
5. Сайт можно просматривать локально, не устанавливая дополнительное программное обеспечение.
6. Малое число используемых программных компонентов делает затруднительным взлом такой системы.

Однако, при всех своих преимуществах такие системы обладают значительными недостатками:

1. Сложно внести изменения в структуру и внешний вид сайта, так как для этого необходимо изменить содержимое всех страниц (поскольку меню сайта, логотип и средства навигации дублируются на каждой странице)
2. Система не гарантирует единый стиль страниц сайта - любая ошибка при обработке файлов, содержащих страницы приводит к тому, что разные страницы сайта выглядят по-разному.
3. Невозможно использовать «динамические» компоненты, такие как голосования, форум, и т.д.
4. Отсутствует разделение прав доступа к сайту, так как человек, имеющий FTP-доступ, может изменить любую страницу.

За годы использования таких систем были разработаны решения, частично компенсирующие указанные недостатки. Первый недостаток может быть частично устранен путем вынесения меню и общих элементов навигации в отдельные файлы, что может быть сделано с помощью технологии серверных включений SSI - Server Side Includes или путем использования фреймов. Альтернативно, можно использовать специальные средства, позволяющие заменять куски HTML-текста во многих файлах одновременно. Третий недостаток может быть исключен с помощью добавления необходимых программ, написанных на языке PHP. Четвертый недостаток может быть частично компенсирован путем размещения страниц в различные папки и назначением различных прав доступа к этим папкам.

Системы на базе HTML с использованием дополнительных решений до сих пор широко используются. Однако поскольку в эти системы добавляются в том или ином виде элементы программирования, возникает вопрос: «Стоит ли основывать систему на отдельных HTML-страницах или лучше взять за основу некоторый общий программный код и единую структуру данных?». Здесь мы перейдем к современным «динамическим» системам управления сайтом.

3. Современные системы управления сайтом

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

4. Критерии выбора системы управления

4.1 Информационная модель

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

Пример 1: Информационная модель сайта сообщества

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

Пример 2: Информационная модель промо-сайта

Сайт состоит из одной главной страницы, содержащий flash-ролик, демонстрирующий преимущества продукта. Внизу страницы размещена контактная информация и ссылка на основной сайт производителя.

Пример 3: Информационная модель сайта группы разработчиков (wiki)

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

Пример 4: Информационная модель корпоративного сайта

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

Указанные различия информационных моделей совсем не исключают непрофильного использования систем управления контентом. Для примера возьмем систему управления, содержащую информационную модель сайта сообщества из примера 1. Переименуем сообщения в страницы и статьи, назовем одного члена сообщества редактором, остальным запретим размещать сообщения (страницы). Скроем все характерные для сообщества элементы навигации и управления. Получим внешне в точности корпоративный сайт из примера 4. Однако внутренняя структура сайта будет отличаться, что приведет к усложнению добавления других необходимых для корпоративного сайта элементов и, как следствие, к повышению стоимости поддержки. Таким же образом из самолета можно сделать автомобиль, если оставить шасси, кабину и двигатель, а остальное скрыть.

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

4.1.1 Структура и навигация

Информационная модель во многом определяет структуру сайта. Навигация на сайте должна максимально соответствовать структуре. Пользователь должен иметь возможность легко найти необходимую ему страницу, причем не единственным способом, а несколькими. В качестве основного элемента навигации обычно используется меню. На корпоративных сайтах оно имеет несколько уровней вложенности. В качестве дополнительных средств навигации обычно используются карта сайта и средства поиска по сайту. Кроме того, чтобы дать пользователю понять, где он находится, часто используются, так называемые «хлебные крошки», указывающие положение страницы в иерархии сайта (например: Главная > Продукты > Программные продукты > Sun Java System).

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

4.2 Требования поисковой оптимизации

Современные поисковые системы предъявляют повышенные требования к формату страниц сайта. Поисковые системы гораздо более чувствительны к отклонениям от стандарта HTML, чем современные браузеры. Если страница содержит непонятные элементы, браузер все равно попытается ее отобразить, тогда как поисковая система может просто проигнорировать. Для того, чтобы увидеть какие страницы создает система управления контентом, следует взглянуть на готовые сайты, сделанные на базе данной системы (например, собственный сайт системы). Проверить совместимость страницы со стандартом HTML можно с помощью HTML-валидатора. Предпочтение нужно отдавать системам, создающим наиболее совместимый со стандартом код наименьшего объема. Адреса основных страниц должны быть, по возможности, простыми и не содержать в себе знаков вопроса с числовыми атрибутами. Кроме того, система должна предоставлять возможность редактировать заголовок каждой HTML-страницы и META-теги, а также задавать альтернативный текст для размещаемых рисунков.

4.3 Расширяемость и масштабируемость

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

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

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

4.4 Функциональность

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

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

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

4.4.1 Наличие необходимых элементов

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

4.4.2 Наличие перевода на русский язык

Важно, чтобы система была переведена на русский язык или содержала в себе возможности ее перевода. Однако при этом крайне редко учитываются особенности языка. Например, в результатах поиска можно часто увидеть «найдено документов: 4», вместо привычного «найдено 4 документа». В последнем случае, разработчикам пришлось бы беспокоиться о склонении слова «документ». Для того, чтобы сделать по-настоящему качественный сайт, неточности перевода вам придется устранять при внедрении системы.

4.4.3 Система прав доступа

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

4.4.4 Система версий документов

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

4.4.5 Система статистики

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

4.4.6 Система обновлений

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

4.4.7 Система резервного копирования

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

4.5 Системные требования

Системные требования определяются языком программирования и сервером баз данных, используемыми в системе. Наиболее часто в качестве языка программирования используется PHP или Perl, а в качестве сервера баз данных - MySQL или PostgreSQL. Такие системы могут быть размещены практически на любом коммерческом веб-хостинге, который стоит относительно недорого, но могут иметь ограничения по масштабируемости.

Если посещаемость сайта больше 100 тысяч хитов в день, или число страниц превышает 100 тысяч, рекомендуется использовать системы на базе языка Python или Java-сервлетов. В качестве базы данных могут использоваться как открытые (Mysql, PostgreSQL), так и коммерческие решения (Oracle, DB2, MSSQL). Такие системы управления контентом обычно требуют выделенный (или виртуальный выделенный) сервер хостинга. Кроме того, зарплата программистов на языках Java и Python заметно превышает зарплату программистов на PHP.

Cуществуют системы управления контентом, использующие xml для хранения данных, например Apache Forrest.

4.6 Лицензия: коммерческая или система с открытым исходным кодом

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

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

4.6.1 Преимущества систем с открытым исходным кодом

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

4.6.2 Недостатки систем с открытым исходным кодом

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

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

4.7 Развитие системы

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

5. Система собственной разработки или готовое решение?

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

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

6. Выводы

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

P.S.: Автор старался сделать статью понятной для читателей, незнакомых с терминологией, поэтому примеры и определения специалисту могут показаться грубыми. Если же какие-то аспекты были при этом забыты или изложены превратно, пожалуйста напишите об этом автору.

Автор: Григорий Рубцов

Статья написана по материалам онлайн-курса «Практический интернет-маркетинг»

Версия для печати
Вернуться к разделу "Статьи по IT"
Обсудить статью на форуме (cообщений: 5)