Сегодня для рождения сайта и жизни его в сети создана уютная обстановка. Множество CMS позволяет наполнить сайт необходимым функционалом и удобно управлять его содержимым. Даже бесплатные решения позволяют новичкам без проблем наполнять свой сайт информацией, не обладая при этом особыми знаниями (хотя это не всегда хорошо). Но в любом деле есть исключения, которые требуют особого подхода. Именно об особых случаях в веб-разработке я и хочу вам рассказать. Порой сайт должен обладать особым функционалом, или соответствовать определенным требованиям, которые ставит перед разработчиком (студией) заказчик. В таком случае приходиться разрабатывать дополнительные модули, и не всегда это удобно, а порой и не возможно сделать со «стандартной» CMS. В подобных случаях для сайта разрабатывается уникальный «движок», хотя это случается крайне редко. В большинстве случаев разработчики (студии) создают фирменные CMS по другим причинам, предлагая пользователю дополнительные удобства, функционал или (и) безопасность. О том, почему и зачем я пошел этим путем, и что из этого получилось речь пойдет дальше.
Предисловие
Сразу хочу сказать, что я отношусь к тем людям, которые жить не могут без переделывания, создания или усовершенствования (утилизации) разного рода устройств. Порой это качество заставляет «изобретать велосипеды» или делать что-то по-своему. Желание разобраться в том, как функционирует девайс, программа или даже вселенная, порой сводит на нет простое и спокойное пользование ими. Надеюсь на Хабре достаточно жителей, которые поймут о чем я, и им будет интересна история применения этого качества в веб-разработке.
Я обожаю, когда мои мысли и идеи воплощаются в электронном виде и доступны людям по всему миру. Эту возможность Интернет дал каждому пользователю, и это прекрасно. Интернет состоит из наших мыслей идей и желаний, и каждый из нас может сделать его лучше. По крайней мере, я стремлюсь к этому и хочу помогать пользоваться его возможностями другим. И вот наступило время подумать о будущем моих проектов и сайтов, которые я бережно верстал для других. Пора было решить вопрос функционала, масштабируемости и управления контентом. И это не должно было стать проблемой, но не для меня. Я устанавливал различные CMS, но вместо удовлетворения во мне усиливались сомнения, а вместе с ними пришло вдохновение…
Мне хотелось управлять не только контентом и модулями сайта, но и самой системой, — ее интерфейсом и функциями. Я стоял перед выбором: потратить n часов для освоения работы и структуры открытой CMS, или выделить (n x 10) часов для разработки своего «движка», который будет «подвластен» только мне. Первый вариант существенно экономил время и обладал некоторыми преимуществами, а вот реализация второго варианта требовала уйму времени и имела много недостатков. Но вышеуказанные качества и высокий уровень вдохновения не оставили мне выбора и я приступил к разработке.
Теория
Модульность, расширяемость и простота в управлении, — вот основные требования к проекту. Сама CMS должна обеспечивать лишь базовый функционал (управление страницами, структурой сайта и редактирование информации на нем) который по возможности расширялся бы. Основное требование это гибкая конфигурация сайта с помощью функциональных модулей. Они должны расширять функционал сайта в любых пределах, — от сайта-визитки, до интернет магазина. Очень важно было сделать администрирование сайта максимально простым и понятным. Я хотел, чтобы клиент уже через полчаса самостоятельно мог добавлять страницы, редактировать информацию, управлять разделами и меню на сайте. Поэтому надо было максимально упростить процесс администрирования, оставив лишь необходимые функции которые бы понадобились неискушенному владельцу сайта.
Вот список базовых функций (операций) админ-панели CMS:
- общие настройки сайта
- создание страниц (WYSIWYG редактор)
- управление страницами (редактирование свойств и содержания, удаление)
- управление разделами (добавление, редактирование свойств)
- управления меню (добавление, редактирование ссылок)
- редактор дизайна (визуальный редактор для шаблонов HTML)
- работа с модулями (управление настройками модулей)
Этот функционал должен удовлетворить большинство пользователей (администраторов), тем более как показывает практика, заказчик зачастую ленится заниматься даже этой элементарной работой. Поэтому я решил сфокусироваться на удобном интерфейсе и эргономике, не нагружая ее лишними элементами.
Разработка
Все началось с файла index.php, потом появлялись необходимые каталоги, которые постепенно наполнялись скриптами. Менялась их структура, — код перекочевывал из файла в файл и попутно оптимизировался. Функции объединялись в классы а в базе данных появлялись новые таблицы и колонки. Проверка, отладка и доработка, — бессонные ночи, и усталые глаза. Впрочем, это знакомо каждому разработчику.
Пожалуй, пора перейти от лирики до знакомства со структурой движка сайта и логикой его работы. Не буду утомлять вас ненужными деталями, и постараюсь сделать лаконичное и понятное описание.
Структура
Компоненты веб-сайта которые обеспечивают его структуру и наполнение, можно условно поделить на «логический» и «физический» уровень. Таблицы баз данных определяют структуру сайта, и его наполнение (7). Эти данные и являются «логическим» (информационным) уровнем. «Физический» (файловый) уровень(8) содержит файлы шаблонов и контент (4).
Шаблон это текстовый файл (.html) с куском кода HTML, который определяет дизайн определенной части страницы и находиться в специальном каталоге. Страницы сайта условно поделены на шесть зон (заголовок, левая колонка, центр, правая колонка, нижняя линия и подвал), которые составляют главный шаблон (каркас). Для каждой зоны своя группа шаблонов условно деление, которой обуславливает только дизайн и название файла. То есть страница может быть построена как минимум из одного шаблона (например заголовка), и как максимум из шести. Состав шаблонов сохраняется в пределах раздела, и обуславливает внешний вид в нем. Разные разделы соответственно могут включать разные шаблоны и модули, если конечно в этом есть необходимость.
Специальный каталог со скриптами php является модулем, и содержит основные включаемые файлы (скрипты) для сайта и админ–панели (свойства и настройки модуля).
Сложным вопросом стал механизм включения модулей в основной исполняемый файл. Рассматривались разные варианты реализации этого процесса, но пришлось остановиться на «полуавтоматическом». Для вставки модуля в том или ином месте страницы, необходимо прописывать специальные «метки» (в виде специального HTML комментария), которые в процессе обработки (2) заменялись на содержимое индексного файла модуля и встраивались в общий исполняемый код. А уже в админ-панели CMS администратор определяет, какой именно модуль, куда и в какой раздел необходимо установить.
Конечно это не идеальный способ, ведь для включения модуля необходимо править шаблоны, но так как CMS разрабатывается только для одной студии и является «закрытой», и все манипуляции будет осуществлять разработчик, а не заказчик, — этот механизм оказался вполне удобным.
Теперь рассмотрим состав таблиц, которые отвечают за разделы и страницы сайта.
Таблица разделав содержит такие основные колонки:
- ID раздела (уникальный ключ, и ключ привязки к страницам)
- префикс раздела (служебное имя)
- название раздела (название для удобной идентификации или вывода в заголовок)
- описание раздела (расширенная информация для администратора)
- колонки шаблонов (шесть колонок для привязки шаблонов на каркас сайта (5))
- колонки модулей (шесть колонок для привязки модулей к шаблонным меткам (5))
- флаги (служебные идентификаторы, тип раздела и прочего)
Таблица страниц состоит из колонок:
- ID страницы (уникальный системный ключ)
- раздел страницы (привязка страницы к разделу)
- URI (ключ страницы доступный через URL)
- имя (название страницы, используемое для заголовка)
- описание (дополнительное описание)
- обложка (путь к графическому файлу идентифицирующим страницу, например в ленте блога)
- текст (текстовая информация размещаемая на странице)
- флаги (системный идентификатор страницы)
- статус (является ли страница активной, скрытой или удаленной)
Кроме этих двух основных таблиц, существуют дополнительные таблицы для настроек, модулей, бэкапа и прочих нужд системы.
структура и логика CMS
На рисунке изображена упрощенная схема структуры сайта работающего на CMS. Очень коротко можно описать суть механизма вывода элементов веб-страниц буквально двумя предложениями.
При GET запросе (1), производится проверка его (URI) на отсутствие мусора, после чего извлекается идентификатор (3) страницы и раздела. После выдачи данных о разделе идет обработка и вставка шаблонов и модулей а так-же информации (текст и контент) из полей таблицы соответствующим запрашиваемой страницы. В противном случае — если страница или раздел не найдены, то осуществляется рэдирект на соответствующую страницу ошибки.
Практика
После долгого периода разработок наступил долгожданный период тестирования. Старый сайт-визитка был сделан для знакомого предпринимателя был выбран для практических испытаний. После разбития на шаблоны он зажил новой динамической жизнью, а я принялся за работу над первым модулем, — фотогалереи, которой не хватало этому сайту.
Прошло много дней и месяцев, писались модули и устранялись баги. CMS успешно справляется с возложенными на нее обязанностями, — помогая мне воплощать свои идеи в жизнь не отвлекаясь на технические нюансы. Мне понравилась моя работа и я не жалею о потраченном времени.
Но время не стоит на месте, ставя новые задачи и требования, поэтому готовлюсь к новым работам над CMS для улучшения ее удобства и безопасности.
Планируется обновление интерфейса и рефакторинг кода, но это уже совсем другая история… Желаю всем удачи!
