Создание шаблонов вне предлагаемого в MaxSite CMS варианта D2

После перехода в MaxSite CMS 0.84 только на shared-каталог у некоторых вебмастеров почему-то сложилось впечатление, что это усложняет верстку шаблонов и вариант D2 является единственным вариантом, от которого нельзя отступать. Мнение совершенно дикое и в корне неверное — уж чего-чего, а в MaxSite CMS шаблон может быть вообще произвольной структуры. Единственным условием любого шаблона — наличие файла index.php.

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

Но, вебмастеру, который пока с трудом разбирается в вёрстке или новичку в системе, мой помысел неясен — ему с головой хватает одного расположение сайдбара на весь сайт и простеньких css-стилей. Бывает ещё случай, когда вебмастер «закостенел» до такой степени, что уже не может мыслить вне своих css-стилей и именования своих же css-классов и вариант с div.all вгоняет его в полнейший ступор.

Попробую разъяснить почему я предлагаю именно такой вариант D2 (напомню, что этот шаблон — каркас для новых шаблонов) и как сделать свой вариант.

Структура каталогов

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

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

Аналогично можно поступить и с другими каталогами. Нужно ли это? Вряд ли. Это глупо и не имеет большого смысла. Поэтому будем исходить из того, что каталоги менять не будем.

Свои type-файлы

С этим всё достаточно просто. Если по какой-то причине не устраивают type-файлы, то создаем свои. Можно просто скопировать type-каталог из shared и внести нужные правки. Если нужно заменить отдельный type-файл (или его unit), то размещаем его так же как и в shared-каталоге, только в шаблоне. Система умная, сама разберется, что подключить.

Type_foreach-файлы

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

Опции

Если не нужны дефолтные опции, то в options/options.php указываем:

mso_set_val('get_options_default', false);

— и теперь шаблон будет использовать только свои опции. Размещаются они тут же — в каталоге options.

Перевод

Если шаблон не содержит фраз для перевода, то каталог language можно просто удалить.

Stock-файлы

Файлы, которые не должны путаться под ногами. Если их нет — удаляем и каталог.

Информация о шаблоне

Это только для информации, поэтому info.php и screenshot.webp можно просто удалить.

Функции

С файлом functions.php несколько сложней. Это специальный файл, который автоматически подключается не только при работе шаблона, но и в админ-панели. Здесь регистрируется сайдбар, подключаем какие-то базовые функции, шаблонизатор Page_out, Thumb-библиотеку, а также файл custom/my_functions.php. Что-то здесь удалять и менять смысла нет, поскольку тот же Page_out используется в type-файлах и его всё равно придется подключать.

Функции из shared/functions/template.php можно не подключать, хотя там расположена функция mso_default_head_section(), которая выводит HEAD-секцию шаблона. Если есть мазохисты, которые до сих пор формируют эту секцию вручную, то они могут удалить подключение этого файла.

Custom-файлы

В custom разные предопределенные файлы, которыми можно менять шаблон. В my_functions.php как правило регистрируют другие сайдбары, но в принципе это можно сделать и в основном functions.php, а все custom-файлы удалить.

Картинки и js-скрипты

Не знаю насколько это принципиально, но пути к картинкам указываются в css-стилях, то есть фактически произвольно. JS-скрипты удобней хранить в отдельном каталоге, но, опять же, подключение — по явно указанному пути. То есть произвольно. Если js-скриптов нет, можно их удалить.

В js/autoload автоматически подключаемые js-файлы. Хотя, если удалить файл с mso_default_head_section(), то никакого автоподключения не будет.

LESS-файлы

Нормальные верстальщики уже давно перешли на LESS или другой css-препроцессор. Но если вы ещё ковыряетесь в голом css, то... просто удаляем каталог css-less.

Модульная сетка

За модульную сетку отвечает файл main/main.php. Поскольку она будет только одна, то оставляем только этот файл. Остальное удаляем. (Содержимое рассмотрим чуть ниже.)

CSS-стили

Каталог css хранит стили шаблона. Файл var_style.php подключает less-компилятор, который вы не используете. Удаляем файл. В корзину уходит и print.css (при желании), и каталог profiles, в котором хранятся дополнительные css-профили.

Таким образом остаётся только var_style.css. К нему вернемся чуть позже.

Компоненты

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

Но, поскольку они кому-то лишние, каталог components отправляем в корзину.

Первая остановка

Похоже мы добрались до той черты, когда получили минимально возможный шаблон, основанный на shared-каталоге. Это всего 5 файлов:

index.php
functions.php
options/options.php
css/var_style.css
main/main.php

Строго говоря и css/var_style.css можно удалить. Будет подключен дефолтный из shared-каталога. Но в любом шаблоне будут css-стили, так что будем считать css-файл обязательным.

Рассмотрим Main-файл

Добрались до модульной сетки. Сразу привожу готовый вариант.

<?php if (!defined('BASEPATH')) exit('No direct script access allowed'); ?>
 
секция HEAD
 
<body>
 
Любая html структура
 
<?php
	# Вывод контента
	global $CONTENT_OUT; 
	echo $CONTENT_OUT; 
?>
 
Опять любая структура
 
<?php
	# Вывод сайдбара/ов
	mso_show_sidebar('1');
?>
 
Опять любая структура
 
</body></html>

Схематичная структура, где две php-вставки: одна выводит контент (он формируется в type-файлах), вторая — вывод сайдбара. Нужен другой сайдбар — делаем еще одну вставку с mso_show_sidebar().

Все css-классы — произвольны. Точно также как и HTML-теги и их структура.

Использовать ли css-фреймворк MaxSite CMS?

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

Здравомыслящему вебмастеру, конечно же такой вариант не сахар, поэтому логичней было бы использовать mso_default_head_section(), где уже выполняется весь нужный код. Меняем:

<?php if (!defined('BASEPATH')) exit('No direct script access allowed');

# секция HEAD
mso_default_head_section();
?>
 
<body>
...

Дальше интересней.

Предполагается, что вебмастер будет использовать css-фреймворк style-all-mini.css, который расположен в shared-каталоге, а свои стили в шаблонном var_style.css. Именно такой вариант сейчас и получился.

Если же нужно использовать только свои стили, не подключая из shared, то размещаем их в my_style.css и var_style.css.

Если же есть желание использовать только один файл или с другими именами, то делаем style.php и лепим в нём всё что угодно. Хоть подключение css-файлов, хоть php-код. Например:

<?php if (!defined('BASEPATH')) exit('No direct script access allowed');
 
echo mso_load_style(getinfo('template_url') . 'css/my-super-style.css');

Возвращаясь к type-файлам

Копировать type в свой каталог — безумство — поддерживать такое количество кода не каждому под силу. Поэтому правильным было бы использовать стандартные возможности для кастомизации — type_foreach-файлы.

Наиболее часто требуется поменять инфоблок записи (заголовок, рубрику, дату и т.д.). Делается это с помощью info-top.php. Таких type_foreach-файлов сейчас набирается примерно 100 штук — все для разных задач и в разных частях кода. Имена некоторых type_foreach-файлов формируются динамически. Например info-top-page.php будет подключен только в одиночной записи. Для главной потребуется создать info-top-home.php.

Таким образом, если возникла потребность изменить вывод части type-файла, в первую очередь откройте type-файл и проверьте: скорее всего там уже предусмотрен нужный type_foreach-файл.

В заключении

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

Если вы не владеете LESS. Создавайте var_style.css вручную.

Если вам не нужны компоненты. Лишние компоненты можно удалить, оставшиеся подключить через custom-файлы. Если и это не нужно, то выполняйте верстку в main.php, вместо кода подключения компонентов (get_component_fn) или, не меняя main.php, в custom/header_components.php и custom/footer_components.php.

Изучите подключение custom-файлов в main.php. Они используются для того, чтобы без переделки этого файла повлиять на его поведение.

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

Научитесь находить нужные type_foreach-файлы. Именно с их помощью можно настраивать вывод контента.