Как сделать тему WordPress виджет совместимой за 3 шага

В комментариях к последней статье «Виджеты — это очень просто!» попросили рассказать, как же сделать тему виджет совместимой. Честно говоря, я думал, что на офф.сайте это описано, а как выяснилось написано то оно написано, да не совсем там.

В общем, отрыл я пошаговое описание того, как нужно «грамотно» виджетизировать свою тему, которое ниже предлагаю вам в своём переводе с небольшими корректировками и дополнениями.


Шаг 1. Редактируем functions.php

Сперва необходимо удостоверится в том, что в папке с вашей темой находится файл function.php, а если таковой отсутствует, то создайте его сами.
Следующим шагом нам необходимо определиться — как у нас формируется сайдбар. Откройте свой sidebar.php и попытайтесь вникнуть в код и понять, что используется для формирования сайдбара — списки (<ul>) или дивы (<div>).
Например, у Артема сайдбар стандартный, из списков и заголовков второго уровня, что видно по коду:

А вот у Максима напротив, сайдбар состоит из последовательных блоков div, обрамленных изображениями «скругленных углов», а уже внутри дива находится контент виджета. Кусок кода, чтобы было (возможно) проще понять, о чём я говорю:

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

Достаточно в functions.php добавить блок кода, чтобы в итоге получить сайдбар на основе списков с заголовками 2 уровня:

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

Если же, вы используете, какой-то более извращенный метод (ничего личного, Макс:-)), то код может принять устрашающий вид, аля:

Дам небольшие пояснения, строка, передаваемая в параметр ‘before_widget’ будет выводится как начало любого виджета, а ‘after_widget’ — конец. Т.е. тут мы задаём тэги обрамления виджета. ‘before_title’ и ‘after_title’ соответственно определяют обрамление заголовка виджета (это все те «Рубрики» и «Самое читаемое»). В итоге мы получим дивный сайдбар с заголовками 4 уровня.

Для особо замороченных существует возможность получить при выводе виджета его id (генерится из имени виджета) и класс (получается в процессе обработки виджета). Т.к. ‘before_widget’ пропускается через sprintf, то в любое место строки можно передать %1$s и %2$s, чтобы при выводе получить соответствующие параметры. Надеюсь «замороченные» поняли, о чём я.

Шаг 2. Проверяем сайдбар и добавляем на него виджеты

Чтобы понять работает наш сайдбар или нет, нужно добавить на него несколько виджетов.
Идём в админ панель, далее «Внешний вид > Виджеты» и лицезреем (или нет, если забыли сохранить и/или загрузить functions.php в свою тему) панель сайдбара, куда можно (и даже нужно) натаскать пару-тройку виджетов. И главное нажать «Сохранить», после чего перейти к третьему шагу.

Шаг 3. Добавление сайдбара в шаблон

Ну и наконец-то то, ради чего всё делалось — подключение сайдбара в шаблон.
Тут есть простой и очень простой способ. Оба заключаются в редактировании файла sidebar.php вашей темы.
Простой способ:
Вставить сразу после строки <div id=»sidebar»> следущий код

а перед последним </div> код — <?php endif; ?>
Очень простой способ заключается в том, чтобы понять для себя раз и навсегда, что никто уже не использует шаблоны без виджетов и, стерев предварительно ВЕСЬ код из sidebar.php, скопипастить туда:

Чем меньше кода в подключаемом файле, тем быстрее у нас всё работает (хотя на таком уровне это конечно «мёртвому припарки», но всё же).

Теперь заходим в свой блог и наблюдаем работающие виджеты.


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

И ещё, я думаю — писать пост про создание темы с несколькими виджетами или нет? Пригодится тебе такая статья, читатель, или нет?

Выпадающее меню “имени Suckerfish” в WordPress

За последнее время сразу несколько человек поинтересовались у меня, а не в курсе ли я, как делать выпадающие меню в WordPress? Я честно отвечал «Нет», потому что с содроганием вспоминал, как когда-то, на заре изучения web-кодинга, пытался сделать более-менее нормальное выпадающее меню. Триста раз проклял я тогда и java-script, и html, и, конечно же, все браузеры.

Но раз люди спрашивают, то появляется жгучее желание им помочь, вот и полез раскапывать, как дела обстоят сейчас и что новенького умные дядьки намутили, и даже, знаете ли, нашёл. Причём нашёл и очень сильно удивился тому, как это было сделано — вот что значит мало практиковать вёрстку и работать с CSS, потому что, по сути, для того, чтобы намудрить ОТЛИЧНОЕ выпадающее меню, достаточно знать:
а) как делать ненумерованные списки в html (<ul></ul>)
б) уметь копипастить файл-стилей

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

Шаг 1. Готовим список пунктов меню руками

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

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

Всё просто и, я думаю, дополнительные разъяснения не требуются, главное не забыть указать у внешнего меню class=»nav» и id=»nav-one».

Шаг 2. Стилизуем списки

Сам файл стилей не слишком большой, но между тем целиком код в блоге я приводить не хочу, поэтому советую для дальнейшей беседы скачать файл стилей, а я буду просто рассказывать про принцип работы, ссылаясь на него.
Берём файл sfstyle.css и открываем блокнотом или любым другим редактором (если кому интересно, то я использую Zend Development Environment или, проще говоря, ZDE).
Ну что же, приступим.

Первым делом уберём у всевозможных списков все отступы и прочие списочные атрибуты, это делается в .nav, .nav ul. После чего выводим их в строчку, а не как обычно, за это у нас отвечает float:left; в .nav li. Сразу обращу внимание на то, что мы везде применяем относительное (relative) позиционирование (position), чтобы элементы появлялись в строго заданных им местах, относительно родительских элементов.

Теперь нам необходимо спрятать внутренние списки с глаз долой и отображать их только при наведении. Тут мне попалось два способа:
1) Найденый на A List Apart — для вложенных ul элементов устанавливаем атрибут display:none;, а при наведении (li :hover ul) возвращаем в нормальное значение block.
2) Попавшийся на одном Ajax-ориентированном сайте — прятать список за экран (top:-999em;), а потом устанавливать позицию при наведении.

Так как я взял CSS из второго варианта (почему станет ясно позже), то с первым предлагаю поэкспериментировать самостоятельно.

В принципе на этом можно было бы и закончить, если бы не всеми любимый Internet Explorer (будь он неладен), который плохо обрабатывает псевдо-класс :hover, поэтому переходим к следующему шагу.

Шаг 3. Немного java-script и jQuery

Как это не прискорбно, но java-script придётся применять в любом случае, но я имею вам предложить целых два варианта (ну на самом деле их, наверное, больше), а вы уж сами решайте каким воспользоваться. Объяснять как именно ЭТО работает, не буду, скажу только, что всё сводится к прицеплению обработчкиков при наведении для всех li внешнего списка.
Способ 1 — Чистый java-script

Способ 2 — C применением jQuery

Кому как, а мне визуально больше нравится второй вариант, к сожалению, тут есть одно «НО» — необходимость подключения библиотеки jQuery. Не скажу, что это огромный минус, потому что: а) она идёт в комплекте с WordPress, так что ничего дополнительно скачивать не придётся; б) возможно какой-то из установленных у вас плагинов уже ею пользуется. Сама библиотека весит 20-30кб, поэтому особо не обременит пользователя, к тому же грузится она только первый раз, а потом подгружается из кэша. И не стоит забывать, что она позволяет делать многие интересные вещи, о чём ниже, в пункте 4.

Сейчас я объясню как её подключить:
1. Проверьте, не подключена ли она уже каким-нибудь плагином, для этого откройте любой пост в своём блоге и в html коде поищите слово «jQuery».
2. Если его нет, то лезем в файл темы header.php и где-нибудь перед </head> вставьте
<script type=»text/javascript» src=»http://ваш_домен/wp-includes/js/jquery/jquery.js»></script>

Кстати, если кто не знает, то приведенные выше java-script листинги нужно тоже вставить в хэдер до </head>, обрамив с обоих сторон <script type=»text/javascript»>…</script>

Шаг 4. jQuery-бонус — плавное меню

Раз уж мы вынудили пользователя скачать лишних целых 25кб, то надо его за это как-то наградить:)
Как вы смотрите на то, чтобы сделать появление меню плавным? Думаете сложно? А как вам вот такой код?

Помоему просто отлично, а главное понятно) Добавлю лишь, что вместо «fast» можно добавить «slow» или любое число в миллисекундах.

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

Теперь думаю при помощи этой методики не составит труда делать различные меню — при помощи всяких там wp_list_categories и иже с ним.

ПыЦ: Только не спрашивайте меня, почему SuckerFish. Как я понимаю — это означает рыбу прилипалу или я ошибаюсь? Есть среди читателей знатоки ангельского языка?

10 вещей, которые стоит сделать при смене темы в WordPress

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

Так же этот список может пригодиться тем из пользователей WordPress, которые любят менять тему в соответствии с сезоном или праздниками (а ведь Новый Год на носу), сам я этим не страдаю, но знаю, что существуют и такие индивиды.

1. Удостоверьтесь, что весь перевод (если вы его делали) сохранен в кодировке блога, а то печально наблюдать крякозябры в перемешку с нормальным текстом.

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

3. Заново разместить все свои виджеты в сайдбаре(-ах), указав необходимые настройки.
3 и 4 пункты — если вы используете тему с динамическим сайдбаром, если же нет, то правим прямо sidebar.php

4. Переносим функции, которые размещали для правильной работы плагинов. Например, тот же Wp-PageNavi, WP-RelatesPosts, ну и в том же духе.

5. Вставляем в хэдер или футер коды своих «счётчиков/анализаторов» (liveinternet/google-analystic), чтобы потом не удивляться резкому падению посещаемости до 0.
Для пользователей аналистика советую плагин Google Analyticator, который кроме автоматического внедрения нужного кода в хэдер, ещё и позволяет исключать определенных пользователей. Ведь вам же не нужно считать свои собственные клики?

6. Проверяем правильно ли прописан фид, если вы перешли на FeedBurner, т.к. ссылка по умолчанию будет на www.сайт.ру/feed.
Мой вам совет, чтобы не морочить себя пунктом 6, воспользуйтесь плагином Feedburner Feed Replacement, который автоматически редиректит все обращения к вашему фиду на фидбёрнер.

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

8. Протестируйте свою тему — пройдитесь по всем разделам, поищите через поиск, проверьте, чтобы текст был грамотно написан, коментарии оставлялись, а плагины не выдавали ошибок, а фид вёл туда куда нужно. Причём советую перед тестом разлогиниться, так как большинство фич (та же капча) видны только гостям.

9. Проверьте как ваш сайт отображается в разных браузерах. И если у вас на компьютере стоит, например, только IE (вздрогнул при мысли об этом), то воспользуйтесь сервисом http://www.browsershots.org/.

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


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

Как безопасно обновиться до WordPress 2.3 по шагам

Руководство для самых нетерпеливых)
Сразу скажу, что сам я буду обновляться только после выхода русского релиза от Максима. На днях собирался ещё и поставить кучу плагинов, но теперь придётся повременить и дождаться их обновления.


Какая же последовательность действий, чтобы безопасно обновиться с 1.5.x, 2.0.x, 2.1.x, или 2.2.x до 2.3?

0. Удостоверьтесь, что у вас стоит UTF версия WordPress или сперва обновитесь версией от Максима, потому что в противном случае возможны проблемы с кодировкой.
1. Сделайте бэкап БД.
Сделайте копию всех своих данных: пользователей, постов, страниц, категорий.
Можно воспользоваться плагином WP-DBManager или сделать всё руками:
а) зайдите в админ.панель phpmyadmin (где он расположен зависит от хостера) или поставьте плагин WP-Phpmyadmin, чтобы запускать его из WordPress.
б) в панели слева выберите пункт Databases.
Databases menu

в) в списке кликните на свою БД
Database Selection

г) на следующей странице показан список всех таблиц. Жмём на закладку Export вверху страницы.
Export Tab

д) теперь перед вами меню экспорта. Тут вам необходимо выбрать таблицы, относящиеся к WordPress. Если в данной БД установлен только блог, то смело жмём Select All, в противном случае отмечаем все строки начинающиеся на wp_ (если устанавливали по умолчанию) или другой префикс, который можно посмотреть в файле wp_config.php
wp-tables list

е) Проверьте, что выбран пункт SQL, проставьте галки Structure, ‘Add DROP TABLE’, ‘Add AUTO_INCREMENT’, ‘Enclose table and field names with backquotes’, DATA (но уберите галки внутри этого блока) и ‘Save as File’
wp-tables list

ж) Сперва выбираем пункт ‘None’ в разделе ‘Save as File’, жмём GO и сохраняем файл на диск.
После этого можно сохранить и архивированную версию, выбрав ‘zipped’.
Процесс бэкапа базы данных закончен.

2. Бэкап всех файлов WordPress.
Подключаемся по фтп своим любимым клиентом и сливаем все папки и файлы (включая .htaccess) к себе на локальную машину. Описывать этот процесс не буду, потому что подозреваю, что раз вы смогли когда-то залить блог на сервер, то сможете и скачать.

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

4. Отключите ВСЕ плагины.
Идём в Админ.панель и выключаем их по одному.

5. Скачиваем последнюю версию с оффсайта.
И распаковываем на своём компьютере.

6. Удаляем старые файлы WordPress на сервере.
Это стоит делать в том случае, если вы не уверены, что ваш FTP-клиент (или если вы работаете через админ.панель хостера) правильно перезапишет файлы.
НЕ УДАЛЯЙТЕ:
* wp-config.php
* папку wp-content
* папку wp-images
* папку wp-includes/languages/ если пользуетесь локализацией через MO файлы
* файл .htaccess

Обязательно удалите:
* все файлы начинающиеся на wp-* кроме перечисленых выше, а так же readme.html, wp.php, xmlrpc.php и license.txt. Обычно их можно найти в корне сайта. И ещё раз напоминаю — НЕ УДАЛЯЙТЕ wp-config.php
* папку wp-admin
* папку wp-includes. Помним о wp-includes/languages/
* папку wp-content/cache. У вас будет эта папка только в том случае, если вы обновляетесь с WordPress 2.0
* папку wp-content/plugins/widgets. У вас она будет, только если вы устанавливали дополнительные виджеты. Старые версии не совместимы с 2.3

7. Скопируйте новые файлы на сервер.
Возможно придётся перезаписать часть файлов, например темы, входящие в стандартную поставку WordPress (default и classic).

8. Запустите процесс обновления WordPress.
Перейдите по адресу http://ваш_сайт/wp-admin/upgrade.php, если блог находится в другой папке на сервере, то допишите к УРЛ wp-admin/upgrade.php.

9. Обновите пермалинки и .htaccess.
В панели управления блогом в Options->Permalinks (Настройки->Постоянные ссылки) обновите структуру ссылок и, если необходимо, добавьте нужные строки в .htaccess.

10. Проверяем плагины на работоспособность.
Для этого сверяемся со списком совместимых плагинов и проверяем обновления в разных источниках (офф.архив плагинов, WP-plugin database, WpZipper)
Не забываем после установки их активировать.

11. Изменяем текущую тему под WordPress 2.3.
Для этого читаем статью How To Add WordPress 2.3 Tags To Your Current Theme.

Вроде всё. Как говориться — piece a cake, baby.


А стоит ли вообще обновляться? Прочитай статью о нововведениях в WordPress 2.3 и реши для себя сам.
Кстати, если найдутся желающие прочесть статью How To Add WordPress 2.3 Tags To Your Current Theme в моём переводе, то отпишитесь в комментариях и постараюсь не разочаровать вас.