Отличия MaxSite CMS от WordPress с точки зрения верстки шаблона

В своих учебных статьях о MaxSite CMS я подразумеваю, что их читатель хоть немного, но программист. И поэтому привожу куски кода чтобы те, кому это интересно, мог использовать в своих проектах. Если читатель не имеет представлений о PHP, то мои рассказы ему мало интересны. Однако есть группа тех, кто непосредственно связан с вебстроительством, и при этом имеет посредственные знания PHP. Речь идет о верстальщиках-дизайнерах. Большинство из них могут разобраться в базовом синтаксисе PHP, выучить несколько функций CMS и всё это использовать при верстке шаблона. Как правило, верстальщики (будем дальше по тексту их так именовать) имеют некий отлаженный и готовый «программистский шаблон», где уже выставлены нужные функции в нужных местах.

Речь в статье пойдет именно для этой категории, и я постараюсь максимально исключить сложный код, сосредоточившись на теории и конкретных описаниях с практическим уклоном. Чтобы привнести некоторый накал страстей, я решил усложнить себе задачу, но упростить её тем, кто умеет делать шаблоны для WordPress: я буду приводить сравнение и рассказывать об отличиях в MaxSite CMS. Таким образом верстальщику будет проще понять что к чему.

Для затравки давайте остановимся на принципиальных отличия шаблонов WordPress от MaxSite CMS.

WordPress-шаблоны имеют предопределенную структуру. В каталоге шаблона обязательно должен быть файл style.css, в котором должны быть строчки с названием, описанием, автором и т.п. В MaxSite CMS для таких целей используется необязательный файл info.php. Если в WordPress-шаблоне удалить или неверно указать данные в style.css, то это приведет к ошибке. В MaxSite CMS info.php является вспомогательным файлом, а сам шаблон определяется по имени каталога.

Таким образом в WordPress-шаблоне style.css является обязательным и это мешает в случаях, если мы хотим разместить стили в отдельном подкаталоге. Ну или придётся идти на хитрость: размещать пустой style.css. MaxSite CMS вообще никак не привязывается к файлам (кроме index.php - об этом ниже), поэтому структуру шаблона можно задавать любую.

Теперь рассмотрим вопрос о типах данных. Когда система получает адрес, то она его анализирует и определяет какие именно данные нужно вывести на странице. Например есть тип данных «home» - это главная страница сайта. Есть тип «category» - рубрики, «tags» - метки и т.п. Устройство WordPress таково, что в нём жестко заданы типы данных. Таким образом, если нам нужно для разных типов данных выполнить разный код, в WordPress нужно использовать предопределённые функции «is_тип», например is_home(), is_category(), is_author(), is_year(), is_single(), is_page() и т.п.

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

Таким образом шаблон в WordPress состоит из набора файлов, в которых для каждого конкретного случая задаётся свой формат вывода.

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

Многие верстальщики знают особенность WordPress: если в шаблоне нет файлов типов, подключается общий index.php. То есть верстальщик, по сути только делает один файл для всех типов, а для кастомизации использует условия внутри него с помощью функций «is_тип».

В MaxSite CMS для определения типа данных используется одна функция - «is_type('тип')». При этом файл index.php используется как диспетчер типов - в нем содержится код, который сам определит какой type-файл необходимо подключить. И здесь главное отличие от WordPress в том, что верстальщику в MaxSite CMS не нужно редактировать type-файлы. Более того, их может вообще не быть в шаблоне. Диспетчер типов сам определит их существование и при необходимости подключит типы из default-шаблона.

Строго говоря, index.php в качестве диспетчера типов не является обязательным условием. Самое главное - это наличие файла. Больше MaxSite CMS никаких требований не предъявляет и ей всё равно что в нём содержится.

Итак мы определили, что в WordPress нужно редактировать type-файлы, в MaxSite CMS - нет. Однако давайте разберём вопрос с тем, каким образом и где размещать HTML-код.

В WordPress каждый файл типа предполагает существование трех частей: шапка, сайдбары, подвал. Поэтому, если открыть файл шаблона, то мы увидим присутствие таких функций, как get_header() - для вывода шапки, get_sidebar() - для вывода сайдбара и get_footer() - для вывода подвала. Что же делают эти функции?

Функция get_header() подключает файл шаблона header.php. Соответственно, в этом файле нужно располагать начальную часть HTML-кода.

Функция get_footer() подключает файл footer.php. В нём размещают конечную часть шаблона.

Функция get_sidebar(), как вы уже поняли, подключает файл sidebar.php.

В MaxSite CMS нет таких функций, потому что подключение любого файла выполняется обычной PHP-функцией require().

<?php require('header.php') ?>
<?php require('footer.php') ?>
<?php require('sidebar-top.php') ?>
<?php require('sidebar-1.php') ?>
<?php require('sidebar-2.php') ?>

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

Предположим вы хотите выводить разную шапку для разных типов данных. В WordPress перед get_header() мы, для примера, введем некую переменную, пусть $my_var. Если переменная равна 1, то выводим один вариант кода, если 2, то другой. Результирующий код будет примерно таким (файл типа, например index.php):

if (is_home()) $my_var = 1;
else $my_var = 2;
 
get_header();
...

В данном случае, мы меняем переменную для главной страницы. Соответсвенно, как многие предположат, всё что нужно сделать, так это проверить $my_var в файле header.php, который подключит функция get_header(). Вот примерно так (файл header.php):

<title><?php 
 
if ($my_var == 1) echo 'Титул для главной';
else 'Ой, это не главная...';
 
?></title>

И данный пример будет нерабочим, потому что переменная $my_var задана вне функции get_header(), то есть для неё $my_var просто не существует! Однако, если мы перепишем код на:

if (is_home()) $my_var = 1;
else $my_var = 2;
 
require('header.php');
...

- то он прекрасно выполнится.

Таким образом использование get_header(), get_sidebar() и get_footer() уже ограничивает возможности шаблона. Особенно, если стоит задача менять какие-то части сразу в шапке, подвале и сайдбаре.

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

Основные трудности с шаблонами в WordPress как раз и заключаются в этой части. Главная проблема в том, что для разных типов требуется выводить данные по-разному. Например для рубрик это может быть ul-список, а для одиночных страниц - какой-то div.class. Если верстальщик использует единый index.php, то в этом цикле приходится изголяться с кучей условий «is_тип» - по другому в WordPress не получится.

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

<?php if (have_posts()) : ?>
    <?php while (have_posts()) : the_post(); ?>
 
    Тут собственно и выводим данные        
 
    <?php endwhile; ?>
<?php else : ?>
 
    Если не найдено
 
<?php endif; ?>

То есть верстальщик вынужден прописывать HTML-код внутри этого цикла, что вносит изрядную путаницу. И именно поэтому многие предпочитают вместо единого index.php с кучей условий «is_тип», создавать отдельные файлы типов, что упрощает задачу с точки зрения программирования, но заставляет дублировать HTML-код между файлами.

Рассмотрим теперь как дело обстоит в MaxSite CMS.

После того, как система передала управление диспетчеру типов (index.php - который копируется из default-шаблона), подключается type-файл. Как я уже отметил раньше, в шаблоне может вообще не быть type-файлов. В этом случае используются дефолтные. Type-файл устроен так, что вначале он получает необходимые данные для вывода (например для главной страницы это массив последних записей), после этого подключает шаблонный main-start.php, после сам выводит данные в цикле (некий аналог TheLoop) и в конце подключает шаблонный main-end.php.

То есть в шаблоне в файле main-start.php мы размещаем HTML-код, который выводится до цикла вывода, а в main-end.php - после.

Отметим первое отличие: в WordPress в файлах шаблонов нужно размещать сложный цикл вывода, начальную и конечную часть HTML-структуры, а в MaxSite CMS сразу всё разделено. Исключение цикла вывода упрощает и практически полностью исключает «программистский» код.

Кроме этого, в MaxSite CMS принято (просто так исторически сложилось и не является обязательным) выделять в отдельный файл header.php HTML-код до начала body и подвал в footer.php. Первый файл подключается в main-start.php, второй - в main-end.php.

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

Таким образом, в MaxSite CMS верстальщику нет надобности заботиться о сложном цикле вывода данных, а разбиение HTML-структуры на отдельные файлы позволяет упростить создание шаблона: по сути верстальщик лишь разбивает готовый HTML на две части: до цикла и после. Если вы откроете для примера файлы шаблона mini, то увидите практически голый HTML-код с небольшими вставками require(). Такой шаблон проще для понимания, чем любой WordPress-шаблон.

Осталось рассмотреть последний вопрос: каким образом нужно поступать, если требуется изменить данные в цикле вывода.

В WordPress, как мы уже поняли, всё действо происходит в типовых файлах. Нужно что-то поменять, меняем в цикле вывода. Если нужно менять HTML-структуру, то придется править все файлы типов.

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

Первая - type-файл довольно сложный (для верстальщиков) с точки зрения программирования. И хотя в нем со временем совсем не сложно будет разобраться (во всяком случае проще, чем с TheLoop), на начальном этапе могут быть какие-то трудности.

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

Так вот, вместо изменения type-файла лучше всего использовать type_foreach-файлы. Эти файлы автоматически подключаются в разных частях type-файлов и тем самым, позволяют изменить практически любой вывод. Например, если нужно изменить вывод на главной странице, то мы копируем type_foreach-файл home.php. В нём находится только та часть кода, которая отвечает непосредственно за вывод данных. Здесь нет сложных циклов, в которых можно запутаться, а только интуитивно понятный код. Например mso_page_title() - вывод заголовка, mso_page_date() - даты записи, mso_page_cat_link() - рубрики, mso_page_content() - текст записи и т.п.

С помощью type_foreach-файлов можно менять практически любую часть type-файла. В версию MaxSite CMS 0.41 входит 64 файла. Разобраться с ними будет несложно, ну а открывающиеся возможности порадуют любого WordPress-верстальщика. Например, нам нужно добавить произвольный текст перед выводом рубрик. Копируем маленький category-do.php в свой шаблон, где и размещаем нужный текст. Система автоматом его подхватит. Никакого программирования, никаких сложностей.

В следующих статьях я продолжу рассказ о шаблонах MaxSite CMS с практическими примерами.