28 января 2007

Выпуск 22. WordPress-шаблон

Читали 4249 раз
Рубрика: E-mail рассылка
Навигация: Главная » WordPress » E-mail рассылка

Вышел WordPress 2.0.6 и 2.0.7

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

Кроме этого, версия 2.0.7 будет предпоследней в линейке WordPress 2.0.*, поскольку выход 2.1 ставит уже другие технические требования. Можете не сомневаться, что 2.0.7 на сегодняшний день самая стабильная версия. Все недочеты и ошибки, если найдутся, будут выпущены в виде последней версии этой линейки - 2.0.8.

Вышел WordPress 2.1

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

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

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

Проблема этой версии еще в том, что в пылу увлечением AJAX, разработчики напрочь забыли, что существуют не-английские пользователи с национальными кодировками. Поэтому, для всех не-UTF8 пользователей переходить на 2.1 просто опасно, поскольку в WordPress не реализован механизм перекодирования "в/из AJAX" (который работает только в UTF8). Поэтому, те возможности, о которых взахлеб рассказывают некоторые авторы, например автосохранение, может сыграть злую шутку - данные будут безвозвратно потеряны. Ситуация плачевна не только для WINDOWS-1251, но и всех остальных 8-битных кодировок.

Поэтому, первое условие перехода на 2.1 - блог должен работать в UTF-8.

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

Кстати сразу же скажу, что версия 2.1 больше не поддерживает MySQL версии 3.*. WordPress 2.1 требует наличия как минимум 4.0, а вот будущая 2.2, как планируется, будет требовать уже MySQL 4.1.

Так что уже сейчас, если ваш хостер предоставляет MySQL ниже 4.1 есть смысл уточнить вопрос апгрейда (ну или менять хостера).

Сам переход на MySQL 4 очень важен, поскольку позволил значительно оптимизировать работу с базой данных. Сейчас я провожу различные тесты и могу сказать, что теперь WordPress будет работать с MySQL в несколько раз быстрее. В некоторых случаях прирост скорости двадцатикратный (!!!). Впрочем, на эту тему у меня будет отдельная публикация.

Когда выйдет русский WordPress 2.1?

Поскольку я не особо силен (мягко говоря) в ангийском, то процесс остановился непосредственно на самом переводе. Если среди двух с половиной тысяч подписчиков найдется хотя бы один-два, которые помогут сделать перевод, то русское сообщество увидит версию WordPress 2.1, как минимум на несколько дней раньше. Для всех, кто может и готов помочь, предлагаю скачать файл (8 Кб), в который нужно внести перевод. Все инструкции внутри. [upd: уже вышел]

История WordPress

Эту статью я написал перед новым годом, поэтому просто анонсирую её в рассылке. Кому интересно откуда растут ноги WordPress, милости прошу.

Литературный конкурс

Это уже более свежий анонс, не имеющий отношения к WordPress. На сайте "Пять страниц о..." объявлен литературный конкурс. Нужно написать небольшой рассказ или эссе на тему "...и я впервые увидел небо". Предусмотрено жюри и призы: довольно неплохие. От меня победитель получит блог-клиент для WordPress WP-CLIENT.

WordPress-шаблон

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

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

нужно часто создавать разные шаблоны (дизайны);
нужно оптимизировать шаблон до удобоваримой структуры.

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

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

Вместо разделения по файлам можно использовать функции, которые определяют тип страницы и, соответственно, обрабатывают нужный код, например (index.php):

<?php
if (is_single()) : ?>
Обычная запись (single)
<?php
endif;
?>

<?php
if (is_page()) : ?>
Код для постоянных страниц (page)
<?php
endif;
?>

То есть такой небольшой код позволяет полностью исключить дублирование и при этом сохранить функциональность.

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

Файл index.php

Это основной файл. Именно в нем и происходит "переключение" типов страниц, а также содержится единый дизайн для всего блога.

Подключение header.php

В начале файла index.php я подключаю файл header.php:

<?php
require('./wp-blog-header.php');
require('header.php');
?>

Такая форма обеспечивает подключение необходимых функций WordPress. Делается это для того, чтобы обеспечить единую область видимости всех используемых переменных. Если же сделать это через функцию get_header() (как это обычно и бывает), то переменные, которые вы определите в файле header.php,окажутся утеряны после отработки этой функции.

Или нужно их переопределять как глобальные, что неудобно.

В самом же файле header.php я располагаю html-код, который заканчивается тэгом <body>. Таким образом у меня никогда не путаются пересекающиеся html-блоки. В конце файла (непосредственно перед </head>) я подключаю фильтр для head:

<?php wp_head(); ?>

Естественно, в этом файле можно добавить и php-код, например для работы с тэгами <title> или "meta keywords" или "meta description" (см. 20-й выпуск рассылки)

Структура дизайна

Все необходимые дизайнерские блоки я располагаю в файле index.php. То есть размечается div'ами или таблицами области, в которых будет выводиться например, сайдбар (меню), логотип, блок текста, "подвал" и т.д.

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

Файл style.css

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

div.logo {background: yellow;} /* для лого */
div.sidebar {background: red;} /* для сайдбара */
div.main {background: blue;} /* для текста */
div.footer {background: green;} /* для подвала */

То есть зрительно добиваюсь правильного расположения элементов. При этом я не обращаю внимания на их внутреннее содержание (это уже последующая отладка).

Использование именно фона, а не скажем границ, обусловленно тем, что фон не влияет на расположение элемента.

После отладки фон этих блоков просто убирается.

Подключение прочих блоков

Для вывода текстов используется довольно объемный код (если использовать еще и для разных типов страниц, то он будет еще больше). Поэтому вывод текста я осуществляю через отдельный файл, который подключается в основном index.php. Вот пример:

<div class="sidebar">
<?php require('sidebar.php'); ?>
</div>

<div class="main">
<?php require('main.php'); ?>
</div>

<div class="footer">
<?php require('footer.php'); ?>
</div>

То есть в файле index.php мы получаем только структуру сайта, разбитой на функциональные блоки. Таким образом код этого файла получается очень легким и занимает буквально одну страницу. Для отладки дизайна это очень удобно.

Условия для разных типов страниц

Иногда нужно вывести совсем разный контент. Например для обычных страниц нужно выводить как обычно (анонсы текстов), а для рубрик только список записей (заголовки). В этом случае можно оформить функциональность в разных файлах и подключать их по условию, например:

<div class="main">
<?php
if ( is_category() ) require('maxsite-cat.php');
   else require('main.php');
?>
</div>

То есть вывод рубрик будет осуществляться через файл maxsite-cat.php, а все остальное через main.php.

Безусловно, можно усложнить условия для номера рубрики или номера записи и т.п.

Файл main.php

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

<?php if (have_posts()) : while (have_posts()) : the_post(); ?>
...
...
<?php
endwhile;
else: echo '<h1>Извините, ничего не найдено...</h1>';
endif; ?>

В самом цикле вы по своему усмотрению формируете нужные блоки: заголовок, дата, рубрики, ссылку для редактирования, комментарии и т.д., и т.п. Дополнительные условия-функции is_, позволят управлять отображением разных типов контента. Например, нет смысла отображать рубрику для постоянных страниц.

Подключаем свои функции

Возможно, в процессе работы с WordPress у вас возникнет желание заменить или упростить некоторые функции. Делать это с помощью плагина не очень удобно, проще написать функцию и подключить её прямо к шаблону. Например, вывод title у меня выполнен в виде отдельной функции. Поэтому мне достаточно подключить свой файл функций к шаблону (в самом начале index.php или header.php):

<?php require_once('maxsite-function.php'); ?>

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

Когда верстался номер...

Перед отправкой рассылки, Google-reader на своих крыльях принес интересную новость. Денис Перехрест, он же numberoneblogger.com предложил организовать Дизайн-шоу. Денис берется подробно рассказать (и показать!) как создается дизайн для WordPress. Не пропустите!