Осторожно! Злая тема… для WordPress!

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

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

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

Для тех, кто не очень дружит с ангельским языком, расскажу вкратце о чём там речь:
Некий дизайнер Derek Punsalan сделал темку (а точнее даже несколько) для WordPress и решил их подарить всему миру. В итоге она разлетелась по куче разных тематических архивов, одним из которых был WpSphere. И что вы думаете?

После скачивания и установки с этого сайта, некоторые пользователи заметили, что в тексте страниц находится примерно такой код

Если вы не разбирается в PHP, поясню — такой метод применяется, чтобы скрыть реальный исполняемый код, потому что после декодирования (функция, base64_decode), текст будет выглядеть несколько более подозрительно

В результате выполнения этого скрипта, с одного из серверов (я указал лишь часть исходника) подгружался java-script. По словам одного из блоггеров, Пола Кэрола, который проводил исследования по поводу «вредоносности» данного кода, выходит, что ничего плохого не происходило, а Wp-Sphere просто мониторили количество установок тем.

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

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

И напоследок, к проверенным источникам с лёгкостью могу отнести сайт themes.wordpress.net, ибо официальный, а так же советую ознакомиться с «Кратким руководством по безопасности WordPress» от Максима, скоро постараюсь опубликовать не краткое, а большое и разностороннее.

Мира вам и безопасного интернета и WordPress.

Быстрее-легче-стабильнее или “немного” о Wp-Super-Cache.

Почему-то, как мне показалось, довольно тихо прошло появление очередного «всесильного всемогущего сокращающего время загрузки и нагрузку на сервер» плагина WP-Super-Cache, а ведь за бугром о нём только ленивый не писал и даже успели отDiggать страницу плагина почти тысячу раз. Поэтому, думаю, стоит всё же приглядеться и пощупать это чудо программерской мысли.

Итак, что же может этот плагин, для чего/кого он предназначен и чем лучше аналогичных стандартных и не очень средств кэширования?


Введение
Большинству пользователей WordPress’а известен прекрасный плагин WP-Cache 2. Он кэширует страницы блога и отдаёт их по запросу без обращения к базе данных. Несмотря на это, всё же приходится подгружать определенный php-код, чтобы обслуживать уже кэшированные страницы, чтобы там не говорили на странице о wp-cache (прародитель wp-cache2)

WP Super Cache действует по другому принципу. После установки, создаются html файлы, и они отдаются браузеру без единого вызова php. Насколько быстро ваш сервер отдаёт картинки? Почти так же быстро он будет выдавать и кэшированные страницы. Если вашему сайту ежедневно приходится справляться с массированным потоком посетителей или периодически испытывать Дигг-эффект, то этот плагин для вас.

Как оно работает то?
Как обычно действуют люди, подготавливая свой сайт к массовому паломничеству с дигга? Они в ручную сохраняют копию страницы, которая теоретически будет генерить основной траффик, и помещают её в папку соответствующую пермалинку. Этот метод помогает серверу выдерживать большие нагрузки и не «умирать», но эффективность его напрямую зависит от возможности предсказывать потоки пользовательского интереса к страницам. Сам по себе WP-Cache хоть и полезен, но в определенных ситуациях не совсем адекватен, тогда как WP Super Cache как раз и был создан, чтобы воссоздавать этот процесс автоматически.

Когда к странице обращается незалогиненый посетитель или он не оставляет комментариев, то сервер отдаёт ему статическую html-страницу из подпапки supercache, которая создаётся в cache папке WordPress. Если вы зайдёте в эту папку (например по фтп), то обнаружите точную копию своей пермалинк структуры в виде папок и отдельные html-файлы в каждой из них. Чтобы убедиться, что страница создана плагином, достаточно просмотреть её исходный код и вы обнаружите там следующую строку в самом конце <!— super cache —> или <!— super cache gz —> для сжатого варианта.

Залогиненым же пользователям или тем, кто оставит комментарий, будет показана кэшированная страница, созданная средствами стандартного WP Cache, где в конце будет значится <!— Cached page served by WP-Cache —>.

Фишки/Отличия от WP-Cache

  • Собственная система hook’ов, для более тонкой настройки кэширования (важно только разработчикам).
  • Прекрасно работает и с WordPress MU в VHOST и не-VHOST конфигурациях. Файлы каждого блога кэшируются независимо друг от друга.
  • Стандартные файлы WP-Cache разбиты на 2 части. Мета-файлы теперь располагаются в отдельной папке, что увеличивает скорость обращения к ним и определения необходимости обновления кэша.
  • Встроена заплатка для WP-Cache при работе с защищенными постами.
  • Автоматически отключает gzip-сжатие в WordPress вместо того, чтобы «умереть».
  • Улучшена работа с Akismet и иными плагинами борьбы со спамом — кэш будет обновлен, только если комментарий 100% не спам.
  • Кнопка «lock down» (защёлкнуть) — подготавливает сайт к мощному наплыву посетителей. После включения «защёлкивает» статичные кэш файлы и не удаляет их после добавления нового комментария.
  • Автоматическое внесение изменений в .htaccess (Не забудьте сохранить свой .htaccess перед установкой плагина).
  • Не кэшируются запросы с GET-параметрами.
  • Улучшенная проверка совместимости wp-cache-config.php и advanced-cache.php, если вы пользовались старой версией.
  • Улучшена поддержка Microsoft Windows.
  • Правильно работает с кэшированными страницами в ОС Red Hat/Cent или других, содержащих запись для gzip в /etc/mime.types.
  • Функция «Не кэшировать следующие адреса» теперь может использовать регулярные выражения.

Минусы

  • Если вы залогинен или оставили комментарий, вы никогда не увидите super-cache страницу. Вам всегда будет выдаваться старый-добрый WP-Cache. Это не так уж и плохо, так как большинство ваших посетителей никогда не оставляют комментарии.
  • Для работы со статическими страницами используется Mod Rewrite Апача, поэтому необходимо, чтобы он был активирован на сервере.
  • Особо динамичные части вашего сайта не будут обновляться так быстро, как хотелось бы. Например, виджет — последнии комментарии.
  • Некоторые хостинги испытывают проблемы при работе со сжатыми html-файлами, т.ч. может потребоваться дополнительная настройка.
  • Не рассчитывайте, что дешевый хостинг выдержит большой всплеск трафика, даже если страницы будут кэшированы.
  • Помните, что динамический контент, вроде того, который размещается в сайдбаре, будет обновлен только когда будет обновлена кэшированная страница. Время до обновления можно настроить, но кэшированные файлы будут удалены лишь в том случае, если у вас будет смесь из статических и динамических запросов.
  • Некоторые плагины, такие как SK2, Bad Behaviour и другие, работа которых зависит от «свежести» данных, могут работать не совсем корректно, во всяком случае, до тех пор, пока эти плагины не будут специально оптимизированны для очищения кэша в нужный момент.

(с) Автор Плагина


Это всё конечно интересно и красиво на словах, но работает ли оно в действительности? Сам я не мастер нагрузочного тестирования, поэтому приведу выкладки других людей.

Во-первых, автор плагина ставит в пример себя — после анонса Wp-Super-Cache на дигге, посещения скакнули до 4700 пользователей, что прямо скажем не мало. И вот какие графики получились — первый нагрузка на процессор, второй — посещения.
wp super cache plugin cpu graph
wp super cache plugin visits graph
Отчётливо виден момент активации кэширование (падение нагрузки на процессор), а так же приятно наблюдать, что рост посещений никак не сказывается на процессоре.

Во-вторых, некий Роберт провёл замеры производительности для 1000 запросов. Тестировал по локальной сети, на сервере (P4 — 3Ghz, 2GB RAM) поставил чистый ВордПресс и с другой машины делал запросы.

Результаты:
а) стандартный WordPress без кэша:
— время на тест — 161 сек;
— запросов в секунду — 6.21/сек
— время на 1 запрос — 161 мсек
— скорость передачи — 31.07 Kbytes/сек

б) WordPress + Super Cache:
— время на тест — 5.718750 сек;
— запросов в секунду — 174.86/сек
— время на 1 запрос — 5.719 мсек
— скорость передачи — 898.62 Kbytes/сек

в) WordPress + Super Cache + eAccelerator:
— время на тест — 2.531250 сек;
— запросов в секунду — 395.06/сек
— время на 1 запрос — 2.531 мсек
— скорость передачи — 2030.22 Kbytes/сек

Думаю, комментарии излишни.

Включил сейчас плагин на этом блоге, на пару минут для теста активировал gzip-сжатие и проверил, как реагируют браузеры. С Оперой и ФФ всё ок, а ИЕ6 как обычно отличился — предложил сохранить локально .html.gz страничку) Чтобы не пугать людей, сжатие отключил, но вообще нужно будет разобраться почему ИЕ так отреагировал.

Плагин в установке достаточно прост, особенно если следовать рекомендациям в readme :-), а вот настройка для тех, кто не видел до этого Wp-Cache2, возможно покажется непонятной. С другой стороны Wp-Super-Cache довольно специфическая вещь и не факт, что окажется востребованным.

Хотелось бы узнать — нужно ли отдельным постом расписывать установку и настройку?


Кстати, курсовая и 2 из 4 экзамены сданы на отл., что ещё немного приближает ко второму красному диплому :p
Заинтересовался я тут eAccelerator, интересно, удастся ли мне поставить его на виртуальную площадку у МастерХоста. Если да, то напишу как и что я делал.
Удачного дня и побольше Дигг-эффектов.

Извращения с темами WordPress для новичков и не только (Часть 3)

Последний и пока что заключительный этап в глумлении над темами многострадального WordPress.

Произвольные поля

Наверное? многие неискушенные пользователи WordPress частенько задавались вопросом: «А что же это такое «Произвольные поля«?» (или Custom Fields в англ.версии), когда их глаза попадали на соответствующий блок в панели написания поста. Постараюсь объяснить популярно и доходчиво — это потрясающая по своим возможностям фишка. Не понятно?
Хорошо, а если так — произвольные поля, позволяют добавлять к посту/странице «скрытую» информацию любого (текстового) вида, а потом обрабатывать её при выводе. Всё ещё не ясно? Ну тогда обратимся к примеру.

Добавляем «Настроение» и «Слушает»

Пишем пост и прокручиваем страницу до раздела «Произвольные поля», после чего вбиваем в название поля: «Настроение», а в текст поля «Хреновое» (ну или у кого-что, а у меня сегодня голова раскалывается), таким же манером добавляем «Музыка» и то, что у вас сейчас играет.
В нужном файле темы (думаю, вы уже усвоили, что файл index.php отвечает за внешний вид главной, single.php — посты, page.php — страницы, search.php — поиск и т.д.), в любом месте добавляем:

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

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

Вставка изображения со ссылкой на пост

Сперва, создадим произвольное поле article_image и укажем в нём полный путь до изображения.
custom_fields_img
В теме же вставим следующий код:

Тут требует пояснения только одна функция — get_post_meta();. В неё передаётся три параметра: первый — ID поста, данные о котором мы хотим получить, второй — название произвольного поля, третий — принимает значения true или false и определяет — получать в результате 1 значение или несколько. При помощи $post->ID мы передаём ID текущего поста и соответственно «вынимаем» данные из поля.
Пример тоже довольно поверхностный, потому что при использовании такого кода, мы обязаны указывать данные для произвольного поля, иначе получим кривой код без ссылки.

Случайное изображение

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

Ничего сложного тут нет, поэтому без пояснений — если что, почитайте про соответствующие php-функции.

WP List Pages

Возможно вы уже натыкались на функцию wp_list_pages(), когда модифицировали темы, теперь посмотрим на неё поближе.
По своим свойствам wp_list_pages() немного напоминает wp_list_categories(), который упоминался во второй части «Извращений», только работает не с рубриками, а со страницами (заметьте, не с постами). У него так же есть параметры include/exclude, управляющие выводом определенных страниц по ID, сортировка при помощи sort_column и многие другие. Отмечу только, пожалуй, параметр depth, который определяет глубину списка при выводе:
0 — все страницы и подстраницы в виде иерархического дерева;
-1 — все страницы и подстраницы в виде ненумерованного списка;
1 — только страницы верхнего уровня иерархии;
2 и больше — указанный уровень вложенности.

Sitemap или Карта сайта

Блогу как таковому, имхо, карта сайта без надобности, потому что это будет просто список постов, а вот если делать, например, сателит, с статичным набором страниц и несколькими уровнями вложений (Главная > Информация > Актёры > Актёр), то будет не плохо иметь страницу, с которой можно было бы попасть на любую другую. Да и поисковики будут довольны — любая страница в 3 клика.

Данный код выведет нам список всех страниц и подстраниц кроме 10, которая и является самой «Картой сайта».
«А куда поместить этот код? Нам же он не на каждой странице нужен!» — воскликните вы. Терпение-терпение, дочитайте до конца и узнаете, как назначать отдельным страницам отдельные шаблоны.
Хотелось бы подчеркнуть, что речь идёт не о google-sitemap, который полезен и блогам, для более качественной индексации.

Динамический вывод подстраниц

Если вы поместите следующий код в sidebar.php темы, то при заходе на страницу, будут выводиться все её подстраницы, если они конечно есть.

Параметр echo просто блокирует вывод, ведь нам надо проверить — есть что выводить или нет.

Шаблоны для страниц

Если вы дочитали до этого момента, то узнаете таинство создания различных шаблонов для страниц! Для тех, кто использует WordPress не как блог-платформу, а как CMS, это довольно полезное знание.
Сейчас вы будете приятно удивлены тем, как всё оказывается просто:
1. Заходим в папку своего шаблона и создаём php файл с любым именем (я сделал себе stats.php)
2. Открываем его в редакторе и вставляем следующий код

3. Открываем в админ.панели ту страницу, которой хотим назначить шаблон и выбираем его в правом меню.
template_sidebar
Всё, теперь у вас при вызове этой страницы будет применяться именно выбранный шаблон. Результат на странице статистики.
Главное аккуратно скопировать первый блок <?php … ?> и назначить имя.

Произвольная главная страница

Часто встречал людей, которые задавали один и тот же вопрос — и на форумах, и «в живую» — как сделать так, чтобы на главной показывалась какая-нибудь другая страница, а не список постов?
И, как всё гениальное, это просто сделать, если не сказать оооочень просто. Идём в Настройки > Чтение, а дальше всё видно на картинке.
main page


Ну вот и закончились наши «Извращения». Но учитывая то, что о WordPress ещё СТОЛЬКО всего рассказать, думаю, нас ждёт ещё много интересного и необычного. Например, о том, как постить в блог через e-mail.
Хотелось бы услышать, какие темы вам интересны и вы хотели бы, чтобы я их осветил. Это не обязательно должно быть связанно с WordPress, я ведь и многое другое умею)

Извращения с темами WordPress для новичков и не только (Часть 2) — query_posts

Ну что, продолжим извращаться с темами?

Query Posts

Хотелось ли вам самим определять какие сообщения и когда должны показываться на странице? Нет ничего проще, ведь существует чудо функция query_posts, определяющая какие записи попадут в выдачу. Функция работает как некий фильтр, отбирающий посты по указанным критериям. Сейчас всё станет более ясно на примерах, а затем я просто перечислю большинство существующих параметров, после чего всё ограничится вашим воображением.

Список последних записей

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

Как видно из кода мы передали в функцию query_posts параметр showposts равный 5. Даже не будучи особым знатоком английского языка, понятно что будут показаны 5 постов. Сортируются они по умолчанию по дате публикации — от последних к первым. the_permalink() — даёт нам ссылку на пост, а the_title() — заголовок.

N-постов из определенной рубрики

Совсем чуть-чуть усложним задачу — будем выводить 5 последних постов из категории с ID 2.

Всё проще простого — всего 6 знаков, а какой эффект, какой размах:-) Думаю тут пояснения не требуются, поэтому перейдём к

Исключаем записи из вывода

Допустим существует некая категория (для примера с ID = 3), посты которой не хочется выводить на главной, для этого мы мановением чудо символа «-» (минус) убираем её из выдачи.

Расширяем кругозор или список доступных параметров

Думаю вы оценили прелесть этой небольшой, но мощной функции query_posts, и хотя вы всегда можете более глубоко изучить её в кодексе, я позволю себе перечислить параметры, которые могут вам пригодиться:
cat и category_name — выбор рубрики по ID или по имени, как исключить какую-то рубрику — см. выше.
Хинт: если нужно передать несколько рубрик, то не нужно несколько раз писать cat=1&cat=2, достаточно перечислить рубрики через запятую cat=1,2. Кстати говоря, этот приём относится к любому параметру, который может принимать несколько значений.
author и author_name — посты определенного автора, по ID (author=3) и имени (author_name=Tapac).
p и name — выбирает посты по id (p=5) или по короткому имени (name=this_post_slug).
page_id и pagename — тоже самое, только применительно к страницам.
showposts — сколько из отфильтрованных постов/страниц показать при выдаче.
ВременнЫе (hour, minute, second, day, monthnum, year) — посты за указанный период.
paged — параметр позволяет показывать те посты, который в обычном случае доступны при переходе по ссылкам «Предыдущая страница», т.е. paged=2 покажет посты, как если бы мы отмотали на 2 страницы в прошлое (при выводе по 10 постов на странице, мы получили бы в выдаче записи с 21 по 30).
posts_per_page — сколько постов на страницу. Хорошо группируется с предыдущим параметром.
order — порядок сортировки по дате, принимает значения ASK — от старых к новым или DESC — от новых к старым (стоит по умолчанию).
offset — т.н. отступ. Пропускает (сдвигает) на определенное количество записей.

Выводим подкатегории

В завершение сегодняшнего поста хочу поделиться трюком, который может пригодиться при использовании WordPress как CMS.
Начну из далека, постучался ко мне в icq некто vzldd (в инфо — Дмитрий) с просьбой помочь с сайтом по фильмам (если автор против рекламы сайта, то я уберу ссылку), а точнее он хотел разместить в правом сайдбаре 2 колонки — в одной список категорий фильмов, а во второй — просто рубрики. Я посоветовал ему завести две большие рубрики и раскидать существующие в них как дочерние. После чего предложил вставить в шаблон следующий код:

, где 12345 — ID родительской рубрики (т.е. в нашем примере Download)
Но при выводе таким образом, перед списком выдавался заголовок c именем родительской рубрики, а её хотелось указать отдельно руками. Копаем кодекс дальше.

По идее мы должны получить список, но без заголовка, а на деле мы получаем пустой список с надписью «Нет рубрик». Странно? Да не то слово, но если почитать ещё немного в кодексе по поводу синтаксиса и параметров wp_list_categories, то находим такую строку

If the parameter (child_of) is used, the hide_empty parameter is set to false.

, т.е. параметр hide_empty (который разрешает или запрещает показывать рубрики, если в них нет постов) автоматически должен переключиться в режим — показывать всё, но увы и ах, это «переключение» по какой-то причине происходит только в случае, когда кроме child_of нет других параметров. И вот вам итоговый вариант скрипта, выводящего все дочерние категории для выбранной нами:


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

Извращения с темами WordPress для новичков и не только (Часть 1)

Интересно, есть ли ещё люди, сомневающиеся в том, что на WordPress можно сделать сайт практически любой сложности, сохранив при этом удобство управления контентом через стандартную админку?
Можете не отвечать, сам знаю, что хватает людей, которые делают кислую мину при упоминании, что сайт работает на WP: «Это же блоговый движок, все сайты на нём одинаковые-шаблонные…»
Ага, шаблонные, но попрошу рассматривать этот факт, не как минус, а как ОГРОМНЫЙ плюс, потому что это означает лишь то, что вы можете САМИ настроить всё именно так, как вам хочется — расположить элементы, определить условия вывода данных и многое-многое другое.
И не смотрите на мой блог с ухмылкой, как говорится «сапожник без сапог», зато с определенным опытом, которым сейчас буду делиться. Для понимания потребуются минимальные знания php, редактор (можно и в блокноте), сам вордпресс и желание творить.

Тэги условий

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

Подсвечиваем в меню текущую страницу

Предположим у нас есть 3 страницы «Обо мне», «О блоге», «Контакты» (короткие имена about/bloginfo/contacts), отображаемые в меню, и мы хотим, чтобы при нахождении на одной из этих страниц, соответствующий пункт меню был подсвечен или как-нибудь по другому выделен. Для этого дела в style.css мы создаём класс .current, которому задаём то, как хотим «подсветить» пункт меню.
То на какой странице мы находимся, определяется при помощи функции is_page(), в которую передаётся короткое имя страницы. Если короткое имя соответствует текущей странице, то возвращается true и выполняется условие идущее в фигурных скобках.
Не путайте страницы и записи/посты!
Для примера меню будет сделано в виде списка, если у вас другая реализация, то действуйте по аналогии.

Не сложно догадаться, что когда мы находимся на любой другой странице, то у нас подсвечен будет первый пункт — «Главная».

Динамические заголовки страниц

Можно конечно назвать это неким подобием SEO, хотя лучше всё же использовать специализированные плагины для оптимизации (например, All In One SEO Pack), но этот же метод можно применять и в других ситуациях. Итак, открываем файл header.php своей темы и вносим изменения в <title> .

В этом устрашающего вида коде мы последовательно проверяем? на какой же странице находимся «Главная > Несуществующая > Рубрика > Поиск > Архив > Страницы и посты». Функция bloginfo(‘name’) выдаст нам название блога, wp_title(») — заголовок по умолчанию (для постов — это «Заголовок», для рубрик — их название).

Выделение постов определенной рубрики

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

и модифицируем её до вот такого вида

Теперь всем постам из рубрики номер 5 (номера можно посмотреть в разделе «Управление > Рубрики») будет дополнительно присвоен класс «feature». Тут стоит отметить, что перед «feature» обязательно должен стоять пробел, чтобы классы не «склеились». Осталось только придумать и описать в стилях (style.css) соответствующий класс.

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

А почему бы не сделать для каждой рубрики разное оформление при отображении поста? Пусть в рубрике «авто» будет на фоне машина и сайдбар слева, а в рубрике «мото» разместим мотоцикл и сайдбар справа.
Получается нам потребуется 3 шаблона: мото, авто и по-умолчанию.
Копируем файл single.php из своей темы три раза и обзываем файлы single_auto.php, single_moto.php, single_other.php.
Каждый из них будет отвечать за соответствующий шаблон, поэтому настраиваем их, так как хочется, а в основном single.php убираем всё, заменив на:

Номера категорий соответственно ваши.

Отдельные шаблоны для разных рубрик

С шаблонами рубрик (т.е. оформлением страницы при просмотре всех постов в определенной рубрике) всё намного проще. Если хочется, чтобы при переходе в рубрику все посты выводили как-то «особо», то создаём в папке темы файл category-2.php, в котором и делаем это «особое оформление». Теперь если кто-то зайдёт в рубрику под номером 2, то подгрузится данный шаблон и будет сплошная красота. Формат имени файла «category-НомерРубрики.php».

Вешаем баннер после первого поста

Частенько возникает желание расположить баннер или блок контекстной рекламы сразу после первого поста. Как это сделать? Открываем файл index.php шаблона и добавляем переменную, которая будет отсчитывать номер поста. Выглядит это так:

Находим блок окончания цикла (<?php endwhile;?>) и вставляем перед ним:

В файл ad.php сохраняем код баннера или той же сапы.


На этом закончу первую часть руководства. Надеюсь, вы почерпнули что-то новое и полезное.
Хотелось бы понять насколько доступно то, что изложено в посте, какие коррективы стоит внести и что более полно разъяснить. Поэтому не стесняйтесь — комментируйте.

В следующей части я расскажу о query_posts, что это и как, используя эту функцию, можно управлять последовательностью вывода постов, так же расскажу о «Произвольных полях», покажу как очень просто сделать карту сайта и возможно что-то ещё. Подписывайтесь на rss, чтобы ничего не пропустить.