WordPress as CMS

В этой рубрике я буду выкладывать те заметки, которые могут быть интересны тем, кто хочет разобраться во внутренней «кухне» WordPress'а. Но всё, что будет публиковатья в «Лаборатории» предназначено только для исследований.

И хотя WordPress в общем-то и так CMS, разве что адаптированная под блоги, но все равно имеющая одну проблему, которая заключается в том, что WordPress вроде как «вещь в себе». Поэтому использовать WordPress не по назначению не так-то и просто.

Поскольку термин «WordPress as CMS» уже устоявшийся, то я буду подразмевать под этим такое использование (или переделку) WordPress'а, которое позволит использовать его в нестандартном варианте (как угодно).

Предположим, нам нужно реализовать на базе WordPress'а вывод обычных страниц. То есть нас не интересует блоговая система. В WordPress'е для этого можно использовать постоянные страницы (мы говорим в терминах WordPress!). То есть, даже если мы перепишем функции вывода страниц под конкретные наши запросы (вместо стандартных), то все равно столкнемся с несколькими сложностями.

1. Шаблон

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

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

Но главное ограничение - это то, что в таком шаблоне (и вообще во всех аналогичных) существует большая проблема по созданию нестандартных страниц и записей. По большому счету в WordPress'е нет никаких проблем сделать кастомизацию вывода для различных страниц (записей), рубрик, архива и т.д., включая их типы, и их номер (id). Например для одной рубрики задать один шаблон, для другой другой и т.д. И все эти вещи уже есть в WordPress'е! Например использование метаполей делает настройки любой записи практически безграничными. Но всё упирается именно шаблон.

Не могу утверждать, что у меня уже есть абсолютно идеальный шаблон. Но как минимум у него нет тех ограничений, которые присутствуют в Кубрике. Большинство идей я привел в учебном шаблоне RIONI (см. архив рассылки). И если вы хотите делать действительно нормальные шаблоны, то вам следует ориентироваться именно на него.

2. Внутренняя структура данных

При запуске WordPress выполняет инициализацию, где считывает настройки, данные и т.д. Казалось бы, если мы хотим получить свой вывод данных (например 7, 3 и 6 записи), то можно было бы как-то заставить WordPress не выполнять default SQL-запрос, а выполнить наш. И вот тут-то мы сталкиваемся с другой проблемой.

Дело в том, что структура данных, которую нужно получить, формируется не из SQL-запроса, а из query_vars - переменных на основе которых уже и стоится SQL-запрос.

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

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

Если вы думаете, что каждая итерация цикла TheLoop генерирует новое обращение к БД, то ошибаетесь. Все данные уже хранятся в массиве (точнее объекте), а сам вывод это обычный обход его в цикле.

Для того, чтобы это продемонстрировать сделаем очень простой шаблон.

Создайте каталог для нового шаблона (я его назвал NULL). В каталог поместите обычный style.css, где укажите название шаблона. Поместите в каталог index.php с таким содержимым.

<?php
function pr($var) {
	echo '
';
	print_r ($var);
	echo '
';
}
pr($wp_query);
?>

Функция pr() выполняет вывод массива или объекта и мы её создали только для того, чтобы вывести в браузере в виде преформатированного текста. В общем обычная отладочная php-функция.

То есть у нас получился абсолютно пустой шаблон, без единой WordPress'овской функции. Теперь переключитесь на него в админ-панели и убедитесь, что $wp_query оказалась полностью заполненной (если у вас в тексте html-тэги, то тогда просмотрите исходный код страницы). В ней содержатся и тексты, и заголовки, указан типы данных и т.д., и т.п.

Переменная $wp_query - "сердце" WordPress'а. Внимательно посмотрите на его поля и вы поймете откуда и что берется. Например SQL-запрос ([request]) автоматически формируется из массива [query_vars]. То есть, чтобы изменить сам запрос нужно изменить значение этих полей.

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