HostCMS best practices или как это делается у нас

HostCMS best practices или как это делается у нас.
Часть первая, теоретическая.

Предисловие

В перую очередь хотелось бы поблагодарить разработчиков HostCMS за качественный продукт, техподдержку - за терепение, адекватность и оперативность. Спасибо!

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

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

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

Поехали

Добавление нового сайта

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

При добавлении сайта используйте так называемый Индекс сайта. Возьмем к примеру sitename.ru. В папках images и js (при наличии такой) мы создаем папку sn (sitename, кому как удобней). Это позволяет не путаться в куче картинок для различных сайтов и скриптах. В самой системе стоит указывать в качестве директории для хранения загруженных файлов, к примеру, upload/sn (sitename). Это полезно тем, что при грамотной конфигурации ftp аккаунтов в сочетании с Пользователями сайта можно добиться очень гибкой структуры доступа к административной части и ftp сайта.

Создавайте 2 роли - это Администратор и Контент-менеджер. Администратор имеет доступ ко всем модулям сайта и всей папке с системой - это единственный аккаунт с такими правами, менеджер - только к Структуре, Страницам и документам, Инфосистемам и папке upload/sn. Сайты могут иметь различное количество пользователй с различными правами (зависит от редакции системы), например Контент-менеджер - доступ к документам, менеджеры по продажам - интернет магазин, верстальщик и дизайнер - к макетам сайта.

Да, кстати, E-mail при добавлении сайта мы оставляем ab-ercyl@fvgranzr.eh - так проще работать с почтовыми фильтрами в программах. На некоторых хостингах существует ограничение на использование почтовых ящиков - почту из ситемы можно будет отправить только если в поле От будет @sitename.ru (не @yandex.ru, @gmail.com, @mail.ru и т. п.).

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

В наших проектах мы сами оптимизируем изображения - при загрузке в систему, обработчик не уменьшает качество. Для этого отредактируйте константы JPG_QUALITY = 90 и PNG_QUALITY = 9

В дальнешем вам придется вернуться в раздел Сайты и добавить обработчик страницы 404.
Так же, по желанию, изменяется robots.txt.


Шаблоны в HostCMS

В HostCMS существует 3 уровня шаблонов:
1. Макеты
2. Шаблоны страниц
3. XSL-шаблоны

Макеты - сверстаный макет сайта, файлы HTML и CSS, а так же указанные в них блоки модулей системы (Меню, Новости, товары и т. п.).

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

Таким образом, макеты - служат для форматирования и настройки отображения или расположения блоков системы (Вид), xsl-шаблоны - для вывода модели блока (Модель).

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

Контроллер отдает XML документ, который в свою очередь разбирается XSL движком, а в макетах у нас сверстано визуальное представление блока (CSS).

В своей практике мы практически отказались от использования Шаблонов. Причинами этому чтали:
1. Оптимизация  производительности - на каждый макет свой набор CSS правил и JS скриптов, даже есть макеты шаблонные.
2. Оптимизация трудозатрат - мы не тратим время на разделение сверстанного макета на 3 части.

Наличие типовых динамических страниц в большинстве случаев ограничивает количество шаблонов до одного, с содержанием <?php $kernel->show_current_page(); ?>. В небольших проектах можно вставить эту строку прямо в макет и тогда шаблоны можно вообще не использовать. Но сделаем так как предполагали разработчики.


Итак, для следующей части нам понадобится:
1. Установленная HostCMS с рабочим доменом (мы будем работать с localhost).
2. Созданный в ней сайт.
3. Созданная структура папок.

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

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

Так же рекомендуем к прочтению статью Kotoff - http://www.hostcms.ru/forums/22/3181/page-2/

PS Dear developers, пожалуйста, поправьте где мы ошиблись.

Поправили теги на BB-коды. HostCMS

vkharkov писал(а):

В дальнешем вам придется вернуться в раздел Сайты и добавить обработчик страницы 404.

А также 403 и 503 - ну чтобы было кошерно (И учитывать в макетах и шаблонах 503й статус тоже имеет смысл.)


И вот на эту тему хочется развести небольшой холивар
vkharkov писал(а):

В своей практике мы практически отказались от использования Шаблонов. Причинами этому чтали:
1. Оптимизация производительности — на каждый макет свой набор CSS правил и JS скриптов, даже есть макеты шаблонные.
2. Оптимизация трудозатрат — мы не тратим время на разделение сверстанного макета на 3 части.

А вот это довольно спорный момент.

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

Во2х, ну про оптимизацию трудозатрат - это просто смешно! Грамотно сверстанный макет разделить на три части - дело одно минуты. (Неграмотно сверстанный макет проще отдать верстальщику на переделку - иначе себе дороже выйдет).
А опытные верстальщики, которые давно верстают под различные шаблонизаторы, изначально делают макеты разделенными на части - вынося шапку и подвал в отдельные файлы, подключаемые с помощью SSI или php include. Это очень удобно как для разарботчика (которому дают макет уже оптимизировавший его трудозатраты) так и для верстальщика (меньше копипастинга и однозначность в версиях общего для разных макетов кода). Так что путь для оптимизации трудозатрат лежит именно здесь. И не учите своих коллег плохому!


vkharkov писал(а):

При добавлении сайта используйте так называемый Индекс сайта. Возьмем к примеру sitename.ru.

Идея грамотная, я тоже ее использую, но немного иначе. Как и вы, в настройках сайта я создаю для каждого сайта свою папку для загрузки файлов, например upload/sn/
а внутри нее создаю папку skin и размещаю там все что относится к этому сайту - скрипты, дополнительные стили, изображения входящие в макет и т.д. Таким образом все относящиеся к сайту файлы лежат в одном месте.
Впрочем, это, конечно, дело вкуса и никак не повод для холивара, в отличие от предыдущего пункта

Kotoff писал(а):

А вот это довольно спорный момент.

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

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

Kotoff писал(а):

Во2х, ну про оптимизацию трудозатрат — это просто смешно!  Грамотно сверстанный макет разделить на три части — дело одно минуты. (Неграмотно сверстанный макет проще отдать верстальщику на переделку — иначе себе дороже выйдет).
А опытные верстальщики, которые давно верстают под различные шаблонизаторы, изначально делают макеты разделенными на части — вынося шапку и подвал в отдельные файлы, подключаемые с помощью SSI или php include. Это очень удобно как для разарботчика (которому дают макет уже оптимизировавший его трудозатраты) так и для верстальщика (меньше копипастинга и однозначность в версиях общего для разных макетов кода). Так что путь для оптимизации трудозатрат лежит именно здесь. И не учите своих коллег плохому!  

Опять же, если мы хотим что-то изменить? Лезть в CSS размером в 10кб, или размером в 3кб? Где проще поменять (быстрей найти)?

Евгений, это личное дело каждого, кто как верстает и интегрирует. Лично мне удобней так, и выше описанно почему так. Соглашусь что держать шапку и подвал удобнее один раз в Макетах а все остальное делать через Шаблоны. Однако невозможность использовать уникальные CSS и набор скриптов в зависимости от раздела структуры или шаблона не позволяет нам делать так.

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

Однако невозможность использовать уникальные CSS и набор скриптов в зависимости от раздела структуры или шаблона не позволяет нам делать так.

есть два соображения.
То что шаблоны не позволяют использовать собственные css - это правильно, т.к. css должны подключаться в head а шаблон выводится уже в body, подключение же таблицы стилей в body невалидно.
А вот в структуре можно создать доп.свойства типа файл и загружать для нужных разделов нужные css и/или js.
А потом в разделе head макета обрабатывать доп.свойства текущего раздела структуры и подключать нужные файлы, через Minify (что лучше) или в явном виде. Единственный недостаток такого способа заключается в неудобстве редактирования загруженные файлов.
Но для меня как разработчика это не составит проблемы, т.к. я вообще не редактирую ни стили ни шаблоны через интерфейс ЦА (об используемом мною инструментарии я рассказывал здесь), а у меня как у администратора сайта (или контент-менеджера) по идее не вообще не должно возникать потребности править что-то в стилях и скриптах, это дело разработчиков.

Kotoff писал(а):

А вот в структуре можно создать доп.свойства типа файл и загружать для нужных разделов нужные css и/или js.
А потом в разделе head макета обрабатывать доп.свойства текущего раздела структуры и подключать нужные файлы, через Minify (что лучше) или в явном виде. Единственный недостаток такого способа заключается в неудобстве редактирования загруженные файлов.

Долго...

Kotoff писал(а):

Но для меня как разработчика это не составит проблемы, т.к. я вообще не редактирую ни стили ни шаблоны через интерфейс ЦА

Мы тоже. Но мы храним там.

А теперь ситуация если сайтом занимаются несколько разработчиков?.. Это должен знать каждый. А если разработчик меняется?
Такой подход обусловлен организацией трудового процесса. Можно пользоваться разными IDE - но продакшен должен быть у всех одинаковый. А т.к. решения с subversion и аналогичными вещами будут только лишний раз отнимать время - складывать в системе намного удобнее.

Я предлагаю не холиварить, ваш подход тоже верный. Давайте просто поможем всем остальным...
PS Может нам что нибудь скажут разработчики?...

vkharkov писал(а):

Долго…

OMG!

vkharkov писал(а):

Я предлагаю не холиварить, ваш подход тоже верный. Давайте просто поможем всем остальным…

Так ведь у нас, по сути, и не холивар, а изложение двух различных подходов к разработке Это же лучше чем просто монолог - в нашем диалоге каждый может найти что-то более удобное именно для себя!

P.S. Если вы живете в Питере, то я бы, пожалуй, пообщался с вами за кружечкой пивка или рюмочкой чего покрепче.

К сожалению, не в Питере...
А пообщаться - всегда пожалуйста