Что из себя представляет простейший сайт? Всякий, кто сделал в своей жизни хотя бы одну страничку, уверенно скажет: "это несколько html-файлов и картинок, лежащих на сервере и связанных между собой гиперссылками". И каждый, кому приходилось производить на таком сайте какие-нибудь изменения, согласится с тем, что такой сайт очень неудобен для обновления и поддержки.

Допустим, что в связи с наступлением нового года вы хотите поменять на сайте шапку. Для этого вам нужно вручную произвести изменения на всех страницах сайта, не сделав нигде ни одной ошибки. А если вы захотели полностью сменить дизайн? Это равносильно тому, чтобы создать весь сайт заново, с нуля. Хорошо еще, если это небольшая домашняя страничка, состоящая из десятка небольших документов. А порой приходитсяь работать с корпоративным сайтом, объем которого порядка полутора тысяч страниц, представляющих собой самостоятельные html-документы.

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

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

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

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

Хотя, вообще говоря, определение движка сайта весьма и весьма размыто. Этими двумя словами можно помимо всего прочего называть и простой механизм, благодаря которому осуществляется разделение контента и оформления. Этот механизм может вообще не использовать никаких скриптов на стороне сервера, а быть реализованным с помощью простых технологий, например SSI, по умолчанию поддержаемую веб-сервером Apache. Однако, все таки, чаще под словами "движок сайта" понимают нечто большее - систему, предоставляющую мощные и гибкие средства для публикации и управления содержимым (CMS), легко расширяемую, использующую базу данных и т.д.

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

Начало выбора движка

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

В целом, движок - это набор скриптов, написанных на каком-нибудь скриптовом языке программирования, например php. Либо на "серьезном" языке, например С# или java, как opencms. Различия состоят в конкретных реализациях того или иного механизма, да в наборе функциональности доступной для движка.

Процессор шаблонов.

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

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

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

Структура данных и данные.

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

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

Хранилищем информации служит база данных. Обычно, это какая-либо распространенная sql-база, но существуют и полноценные портальные движки использующие в качестве хранилища текстовые файлы (GuppY , Siteman, wap-motor). Главное преимущество "нормальной" базы - это высокая производительность, а также гарантии целостности данных. Из плюсов текстовой базы можно отметить разве что лишь дешевизну хостинга (тарифные планы без базы обходятся дешевле стандартных), да еще, в некоторых вариантах, - возможность непосредственного доступа к информации путем простого редактирования файлов.

Другие функции.

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

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

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

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

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

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