Структура каталогов шаблона. Файлы шаблона

Помню, когда я делал свой первый шаблона на WordPress, то взял какой-то понравившийся несложный вариант и на его основе уже пытался экспериментировать. Меня очень сильно напрягали некоторые вещи, вроде использования ul-li-списка для вывода блоков сайдбара (тогда они ещё не были динамическими и жестко задавались в файле). Ведь любой здравомыслящий человек иначе как в виде div.widget оформлять не станет. Список-то тут при чём?

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

Но, когда разработка шаблонов поставлена «на поток», возникает острое желание как-то упростить исходный каркас будущего шаблона до такого варианта, чтобы содержал и базовые стили, и удобную HTML-разметку, и понятный (и приличный) PHP-код, который сделает из сайта более-менее функциональный вариант. «Хуже» всего ещё и то, что от клиента к клиенту появляются однотипные задачи, которые нужно решать оперативно. Да и не хочется делать двойную работу, потому что через какое-то время на горизонте может появиться еще один клиент, который скажется «сделай как у того-то» - а ты это уже делал и знаешь сколько возни и времени на это ушло.

Где-то ко второй сотне сайтов сделанных на WordPress'е у меня уже сформировался основной каркас будущих шаблонов, который меня устраивал в разумных пределах. И если с HTML-разметкой я определился достаточно быстро, то с программной частью была большая беда - WordPress имеет слишком много ограничений, поэтому приходилось создавать массу своих функций. Например даже стандартно убогое формирование «общего» TITLE, приходится делать своим вариантом. Не говоря уже про такие вещи как description, keywords и title для произвольной страницы, которые требовали не только изменения шаблона, но и написания отдельного плагина.

Абсоютно точно могу сказать, что грамотный и одновременно простой шаблон сделать в WordPress не реально. Просто из-за того, что система не позволяет. Нужно выкручиваться: делать свои функции, через одно место подключать опции (админка в шаблоне - круто, да?), и практически всегда переписывать даже стандартные вещи, вроде виджетов, цикла вывода и т.п. Оно и понятно, разработчики WordPress сильно увлеклись админ-панелью и напрочь забыли о вебмастерах, верстальщиках и программистах. Даже в последних версиях сменили дефолтный шаблон, который на поверку оказался сложней и запутаней старого, далеко не идеального Кубрика.

При создании MaxSite CMS, я, естественно, учитывал весь свой опыт работы с WordPress и всеми силами стараюсь не повторять его ошибок. Мне, например, не понятно, зачем верстальщику вообще ковыряться в сложном цикле вывода, если его задача сверстать HTML? Или зачем переносить HTML-структуру между множеством файлов разных типов данных? Или что делать, если клиент вдруг решил придумать свой вариант какой-то страницы? И насколько сложно добавить в уже готовый шаблон произвольный код (текст, html или php) и при этом сделать так, чтобы клиент мог после сдачи сайта сам поменять этот код, не обращаясь к FTP?..

В общем, поговорим о шаблонах MaxSite CMS в этом разрезе.

Структура каталогов шаблона

Для верстальщика нужен свой каркас шаблона, который он копирует и сразу получает рабочий вариант. Очень важно, чтобы каркас имел максимально понятную структуру.

Например css-классы можно хранить в отдельном каталоге. Это же самое касается и js-скриптов и картинок. Такие файлы, как

• index.php
• header.php
• footer.php
• options.php
• options.ini
• meta.ini
• functions.php
• screenshot.jpg

по идее вообще должны копироваться один в один с последующей минимальной правкой под новый шаблон.

Каталог css, обычно содержит файлы:

• reset.css - файл сброса стилей
• style.css (возможно с struct.css) - основные файлы стилей
• print.css - стили для печати
• main-menu.css - если шаблон использует выпадающее меню

Для подключения css-файлов в header.php используется такой код:

<link rel="stylesheet" href="<?= getinfo('stylesheet_url') ?>css/style.css" type="text/css" media="screen">

Каталог js обычно у меня содержит только один файл:

• my_ef.js

в котором я задаю свой js-код. Сюда же я копирую сторонние js-скрипты, например плагины jQuery. При этом отмечу, что сам jQuery не требуется копировать, поскольку библиотека идет в комплекте MaxSite CMS.

Для подключения js-скриптов в header.php я обычно указываю так:

<?= mso_load_jquery() ?>
<?= mso_load_jquery('cornerz.js') ?>
<?= mso_load_jquery('ui/effects.core.packed.js') ?>
<?= mso_load_jquery('ui/effects.highlight.packed.js') ?>
<script type="text/javascript" src="<?= getinfo('stylesheet_url') ?>js/my_ef.js"></script>

Вначале загрузится библиотека jQuery. Потом плагин cornerz (скруглённые углы), после UI-эффекты (они тоже в комплекте MaxSite CMS) и в конце свой js-файл.

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

Для изображений я использую каталог images. Обычно здесь у меня хранятся заготовки «булечек» для ul-списков: выбрав нужный, остальные, как правило, удаляю.

Для подключения изображений в css-файлах (они получаются в разных каталогах) указываетя путь с «../»:

#header {background: url("../images/header.jpg") no-repeat;}

CSS-стили обычно подключаются так: вначале reset.css, потом в style.css описывается структура, базовые элементы (a, p, hX, pre и т.п.), после идут блоки системы, вроде div.widget, div.page_content, div.page_other_pages, то есть те элементы, которые формируются в теле вывода type-файла. Далее следуют списки ul.is_link - они формируются в виджетах. После - стили для некоторых плагинов, специфичных блоков, страниц: календарь, комментарии, страница комюзеров и т.п.

Завершает style.css небольшие предопределённые стили-хелперы (помощники): img.left, img.right, img.center, div.break и т.п.

Файл print.css подключается для использования печати. Делается так:

<link rel="stylesheet" href="<?= getinfo('stylesheet_url') ?>css/print.css" type="text/css" media="print">

В 99% случаев в нем нужно просто отключить вывод «мишуры» вроде меню, шапки, сайдбаров и т.п. Мой базовый вариант таков:

#header1 {display: none;}
#MainMenu {display: none;}
#header2 {display: none;}
#header3 {display: none;}
#sidebars {display: none;}
#sidebar1 {display: none;}
#sidebar2 {display: none;}
#bottom {display: none;}
div.pagination {display: none;}
#rater {display: none;}
div.addzakl {display: none;}
div.comment-form {display: none;}
h3.comments {display: none;}

Особо хочется отметить, что MaxSite CMS прекрасно уживается с css-фреймворками (css-framework). И если верстальщик привык использовать, скажем 960 Grid System, то он спокойно дальше им пользуется. Можно разместить файлы хоть отдельно, хоть в общем css-каталоге.

Многократно используемые компонеты

Очень часто в практике верстальщика возникают задачи, которые могут повторяться от клиента к клиенту. Скажем нужно вывести в подвале список последних записей из твиттера или своего форума. Как обычно поступают вебмастера? Правильно, добавляют необходимый код в тело шаблона. Вместо этого, я предпочитаю вынести его в отдельный файл и подключать обычным require(). Такие файлы я условно называю компонентами шаблона и храню их в каталоге component.

Вот пример, где меню вынесено в отдельный файл:

<div id="header-menu"><?php 
	if ( file_exists(getinfo('template_dir') . 'component/main-menu.php') ) 
		require(getinfo('template_dir') . 'component/main-menu.php'); 
?></div>

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

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

Подключение произвольных типов данных

Бывают задачи, когда требуется подключить к шаблону произвольный тип данных. Предположим это будет своя форма заказа. В MaxSite CMS задача решается несколькими способами, самый простой из которых - расположить свой type-файл. Пусть (условно) нам нужна форма заказа по адресу http://сайт/order. Всё, что нужно сделать, так это разместить файл order.php в каталоге type своего шаблона.

<?php if (!defined('BASEPATH')) exit('No direct script access allowed');
	require(getinfo('template_dir') . 'main-start.php');
?>
 
тут форма, текст и т.д.
 
<?php require(getinfo('template_dir') . 'main-end.php'); ?>

Грубо говоря всё, что нужно сделать, так это разместить в файле подключение main-start.php и main-end.php, а между ними текст, форма и т.п.

Что делать, если шаблон использует разную структуру для разных типов данных?

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

Если «нетипичная» страница не требует получения и вывода данных (страницы, рубрики, виджеты), то проще всего в каталог type своего шаблона разместить свой файл типа, например для главной - home.php:

<?php if (!defined('BASEPATH')) exit('No direct script access allowed');
	require(getinfo('template_dir') . 'header.php');
?>
 
это главная!
 
</body>
</html>

То есть мы просто подключаем header.php, а дальше свой код. Если секция HEAD, отличается, то не подключаем header.php, а пишем свой вариант.

Если же стоит задача менять лишь некоторые части шаблона, то нужно использовать условие is_type() в main-start.php и/или main-end.php.

if (is_type('home')){
	echo 'Это главная!';
}

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

if (is_type('home')) require(getinfo('template_dir') . main-start-home.php');
elseif (is_type('page')) require(getinfo('template_dir') . main-start-page.php');
elseif (is_type('category')) require(getinfo('template_dir') . main-start-category.php');
else require(getinfo('template_dir') . main-start-default.php');

Понятно, что это довольно сложный вариант, или скорее более запутанный на уровне файлов. Но и задача непростая.