Вот дайджесты и блоги разработчиков, которые есть у меня в фидах:

• Clagnut
• Molly Holzschlag
• Microformatique
• QuirksBlog
• 456 Berea Street
• Andy Budd
• Eric Meyer
• A List Apart
• Digital Web
• HTML Editor Reviews
• Snook
• Ed Eliot
• DOMScripting
• All in the HEAD
• How To Create
• Microformats
• CSS3 Info
• Vitamin
• Smashing Magazine

Может быть, у вас тоже что-нибудь есть? Кидайте в комменты.

За этот список выражаю благодарность Вадиму pepelsbey Макееву, в незапамятные времена поделившемуся со мной своим opml-листом :)

Итак:

1. Если вы работаете не в Яндексе, не в Гугле, и вообще не в любом подобного размаха проекте, забейте на IE < 6, Opera < 8, Safari < 3, Firefox < 2. Исключив поддержку данных браузеров, вы упростите свою работу и сократите её время. Тем самым вы будете успевать больше, а код ваш будет лучше. Короче, вашему работодателю понравится. И, да — старые браузеры должны умереть.
2. Если дизайнер что-то не доделал или не предусмотрел в макете, а вы не чувствуете себя с Фотошопом на ты, не стесняйтесь послать дизайнеру макет на переделку/доделку, и самого дизайнера послать не стесняйтесь тоже, если он вдруг заартачится. Лучше потратьте время на улучшение верстки, чем на попытку кособоко нарисовать недостающую кнопочку, которую заказчик, скорее всего, все равно завернёт.
3. Если вы евангелист семантической верстки или собираетесь им стать, подумайте хорошенько и выведите логичную концепцию, почему именно вы применяете данную доктрину, и в каких случаях вы готовы от неё отступаться. Четко аргументируйте свою точку зрения. Если у вас нет аргументов, и вы не готовы со спокойной душой отступать от своей идеи, вы фанатик, и в Яндекс вас не возьмут. Зато, возможно, возьмут в W3C.
4. Учитесь всегда, учитесь везде. Пробуйте все новое в отрасли, читайте блоги по веб-разработке, дискутируйте, спрашивайте, убеждайте. Истина рождается в споре. Взаимодействуйте с сообществом, это поможет вам не отстать от жизни.
5. Храните все сделанные вами проекты в статическом варианте. Периодически просматривайте свои работы, думайте, что можно было бы сделать лучше, где можно было бы применить новые технологии, ищите ошибки. Если в какой-то момент вы понимаете, что в последних 10 проектах вам нечего улучшить, вы либо Виталий Харисов, либо остали от отрасли. Не дайте себе деградировать!

Возможно, мои советы покажутся вам фашисткими, но что же делать, да, я фашист.

Роли исполняли:

1. Никита Селицкий
2. Александр Исаков
3. Юрий Дроздов
4. Юрий Артюх
5. Вадим Макеев
6. Владимир Агафонкин
7. Денис
8. Максим Покровский
9. Павел Корнилов
10. Виталий Харисов
11. Марат Таналин
12. Волотко Дмитрий
13. webmolot
14. Александр Макаров
15. alexilin.ru
16. Волотко Дмитрий
17. Павел Ловцевич
18. Павел Коноплицкий
19. Владимир
20. Влад Мержевич
21. Игорь Морозов

Что касается третьей встречи русского крыла Web Standards Group, она превзошла все наши ожидания. Пришло около 70 человек из собиравшихся 120 — огромная явка, мы считаем. На встрече прошли четыре доклада от наших бессменных хедлайнеров Вадима Макеева и Алексея Рыбакова, а также доклад гуру javascript’а Андрея Сумина и рассказ Алексея Николаенкова и его коллеги о Kandy — среде разработки для вебтехнологов. Снимал всё это дело веб-разработчик и гениальный фотограф Вадим Пацев. Причём, благодаря Павлу Ловцевичу и ещё одному молодому человеку, имя которого мне, к сожалению, неизвестно, съёмка была не только фото, но и видео! Как всегда, итогом встречи стала вербовка новых людей в нашу тихую песочницу, ну и, как мне кажется, нам удалось заинтересовать людей веб-стандартами и деятельностью нашей группы в частности. За официальной частью последовали две афтепати для наиболее выносливых. Наши афтепати — это вообще что-то с чем-то. Я считаю, стоит вступать в нашу группу уже хотя бы затем, чтобы посмотреть, как отжигают напару Марат Мамяшев и Алексей Рыбаков. Лично я была в полном восторге.

В общем, встречи WSG Russia ещё обязательно будут, скорее всего, в начале 2008 года в Москве пройдёт следующее собрание. А что касается конференций, то План Бунина на 2008 год действительно велик. Присоединятесь к оффлайновому сообществу веб-разработчиков! Это полезно и весело ;)

Ну и пара фотографий с мероприятий, пока вы совсем не забыли, как я выгляжу:

Это на конфе, фото Серёжи Мезенцева.

А это на встрече WSG. Фото by basic, а лицо у меня такое, потому что накануне мы с Анди изрядно приняли в «Заводных яйцах».

В общем, будьте с нами, будьте как мы, будьте лучше нас! :)

1. «Языки HTML и CSS — официальный учебный курс» Молли Хольцшлаг
2. «Пуленепробиваемый Web-дизайн» Дэн Седерхольм
3. «Мастерская CSS. Профессиональное применение Web-стандартов» Энди Бадд, Камерон Молл, Саймон Коллизон
4. «CSS-каскадные таблицы стилей. Подробное руководство» Эрик А. Мейер (это, по сути, расшифровка спецификации, и поэтому самая сложная книга, но если её осилить, можно стать мега-монстром).

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

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

Можно довольно долго рассуждать о том, почему дизайнеры в огромном количестве гонят некачественный продукт. Мне кажется, основная проблема в том, что на веб-дизайнера нигде не учат. Более того, сейчас в Рунете каждый второй считает себя веб-дизайнером. «Умеешь рисовать в фотошопе скруглённые уголки, градиенты и отражения? Отлично, значит, и разработать интерфейс огромного информационного портала тоже сможешь», — такое чувство, что так рассуждает большинство нанимателей этих самых дизайнеров. И очень жаль. Поскольку для комфортной работы с дизайнером он должен иметь представление об информационной архитектуре, юзабилити, веб-технологиях — программировании и вёрстке, чтобы не рисовать заведомо то, что невозможно или очень сложно реализовать. Однако на деле получается, что скруглённые уголки круче всех.

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

Правило №1. Рисуйте макет сайта только в Photoshop.

Некоторые дизайнеры почему-то очень любят использовать для создания макетов Adobe Illustrator. Это очень крутая программа, но предназначение у неё совершенно иное. В результате, всё равно приходится экспортировать макет в Photoshop, что зачастую вызывает массу ошибок. Ещё одна модная нынче фишка — Fireworks. Да, это уже гораздо лучше, чем Иллюстратор, но всё равно плохо, потому что традиционно верстальщики учатся работать с Photoshop, и когда дизайнер присылает им файл в формате .png, они просто-таки не знают, что с ним делать. Про макеты в .jpg и прочих подобных форматах я вообще молчу. Да, такое тоже бывает!

Правило №2. Аккуратные слои.

В Photoshop существует очень удобный механизм группировки слоёв. Это очень полезное свойство: гораздо легче разобраться в макете, если слои сгруппированы по элементам (например, шапка-контент-подвал). Также следует уделить внимание осмысленному именованию слоёв и групп, причём, желательно использовать английский язык — верстальщик всё равно именует элементы по-английски. Слои, которые не используются в макете, необходимо удалять, а не оставлять отключёнными — верстальщик в процессе работы отключает разные слои, а потом включает всё сразу и может сильно испугаться. Иногда в одном макете помещают группы или слои для всех разновидностей данного типа страницы: например, форма регистрации и страница о том, что регистрация прошла успешно. В таком случае, отключённую группу или слой нужно помечать цветом, чтобы верстальщик её не пропустил.

Правило №3. Модульная сетка.

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

Правило №4. «Липкие листочки».

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

Правило №5. Помните о динамике.

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

Правило №6. «Рыба» и типографика.

Совершенно естественно, что при разработке сайта почти никогда не используется тот контент, который там будет — зачастую, это контента ещё просто не существует. Поэтому дизайнеры, да и верстальщики используют «рыбу» — произвольный текст, который вписывается в контентные блоки. Но, к сожалению, делается это зачастую без проблеска мысли — например, на русскоязычном сайте везде используется популярная рыба на английском — «Lorem Ipsum…», которая не даёт представления, как будет выглядеть этот текст, набранный кириллическим шрифтом. Используйте подходящие к случаю рыбы!

Что касается типографики, то тут я убеждена: дизайнер просто обязан знать основы типографского искусства: осмысленно задавать интерлиньяж, размеры и семейства шрифтов, отступы и поля. А то как-то был у меня случай: прислали макет, в котором достаточно значимые подписи были исполнены шестым кеглем. А когда же я изменила размер шрифта на более читабельный, дизайнер капризно заныл, что у него на макете всё по-другому!

Правило №7. Шрифты.

О шрифтах нужно сказать отдельно. Почему-то каждый дизайнер, купивший на Горбушке диск с двумя тысячами бесплатных шрифтов, считает своим долгом тут же эти шрифты засунуть куда только можно. Я даже не знаю, может быть, это последствия непросвещённости? Что ж, просвещаю: на компьютере пользователя, который зайдёт на ваш сайт, в 99% случаев есть только системные шрифты, и в 99.9% — это стандартные шрифты Windows. Поэтому, как не старайся, милый сердцу маковода Lucida Grande увидит, дай бог, 1% пользователей, а все остальные всё равно увидят Arial. Конечно, в небольших объёмах оригинальные шрифты более чем уместны: это касается логотипов, статичных заголовков и прочих подобных вещей. Но фигачить напропалую весь текст на сайте каким-нибудь Neo Sans Pro, а потом ругаться, что всё не так, как на макете — подвергать себя опасности быть укушенным взбесившимся верстальщиком.
Если вы всё же используете в своём макете нестандартные шрифты, присылайте их верстальщику вместе с макетом, иначе он не сможет нормально измерить кегль и начертание. За растрированные же текстовые блоки вам вообще могут оторвать голову! Так что будьте осторожны и внимательны.

Правило №8. Техническое задание.

Перед тем, как приступить к созданию макета, обязательно прочтите техническое задание: что будет на этом сайте, как он должен работать, какую именно интерактивность иметь… Если же в вашей компании экономят на техническом писателе, попытайтесь хотя бы в устной форме ознакомиться с требованиями к сайту. А то очень часто случается ситуация, когда дизайнер нарисовал красивый макет, верстальщик его заверстал, а потом оказывается, что, к примеру, настоящая флэшка, которая должна быть центральным элементом сайта, шире нарисованной на 10 пикселов. Сколько времени и сил впустую! А ещё кошмарнее, когда дизайнер не понимает, что возможно реализовать при помощи веб-технологий, а что нельзя. И в результате на свет появляются блоки с аудио-плеером, в которых по ходу прослушивания радиопередачи должен плавно пролистываться текст этой самой передачи! Нет, это, конечно, реализуемо, но такие задачи должны осмысленно закладываться в планируемое время разработки, чего обычно не происходит.

Правило №9. Цветовая гамма.

Милый дизайнер! Я очень рада, что на твоём столе стоит тридцатидюймовый дорогущий монитор с отличной матрицей. Но ты должен понять, что ты пока — в меньшинстве подобных счастливчиков, а большинство пользователей сайта, который ты рисуешь, пользуются обычным ноутбуком или монитором с разрешением 1280 на сколько-нибудь там и не супер-качественной матрицей. Поэтому не нужно рисовать макет в 3000 пикселов шириной. Всё равно обычный пользователь не оценит всей красоты огромной подложки, но может очень рассердиться, когда поймет, что ему пришлось загрузить лишние полмегабайта картинки. Также, воздержись, пожалуйста, от использования очень светлых тонов вроде #F1F1F1. Доказано, что подобные оттенки не воспринимаются на сознательном уровне, однако, создают «шум» в глазах пользователя, который мешает ему сосредоточиться на полезных частях сайта. И ещё: постарайся не пользоваться цветовыми профилями. Обычно это заканчивается тем, что после вёрстки кто-нибудь обязательно начнёт вопить, что в макете-то цвета другие! Побереги нервы: свои и верстальщика.

Правило №10. Системные контролы.

Это немного спорная тема, но я всё же её коснусь. Ни для кого не секрет, что дизайнеры очень любят рисовать кастомные элементы форм. В чём-то они правы: в Windows, особенно в стандартной теме, далеко не самые красивые контролы, и они действительно могут испортить внешний вид сайта. Однако, во-первых, все эти красивые скруглённые штучки с градиентами довольно слабо реализуемы на кроссбраузерном уровне, а во-вторых, среднестатистический пользователь потратит куда больше мозговых усилий на то, чтобы понять, куда ему ввести своё имя, если перед ним что-то очень красивое, но абсолютно непохожее на стандартные контролы его операционной системы, к которым он привык. А заставлять пользователей задумываться над интерфейсом — значит, потерять какую-то особо нетерпеливую часть аудитории.

Правило №11. Продумайте всё.

Когда я пришла на работу в компанию, которая занималась разработкой сайтов для T-Mobile, первое, что мне пришлось сделать — это прочитать Style Guide. Style Guide представлял собой папку А4, толщиной примерно сантиметров в двадцать, в которой были описаны все цвета, шрифты, размеры и тому подобные вещи, которые можно применять в оформлении каких-либо материалов для T-Mobile. При помощи этого стайлгайда наши дизайнеры рисовали макеты, уделяя внимание всем деталям. Кажется, это были лучшие макеты, с которыми мне доводилось работать. Я веду свою мысль к следующему: не ленитесь отрисовывать все элементы, которые могут встретиться на странице. Все заголовки, абзацы, подписи к картинкам, цитаты, врезки и так далее и тому подобное. Потому что чаще всего, если верстальщик сам берётся додумать недостающие элементы, это заканчивается истерикой у дизайнера. Позаботьтесь обо всём сразу.

В общем, резюмируя всё вышесказанное — дизайнер должен уметь не только обосновать, что эти три колонки цветов «вырви глаз» символизируют собой российский флаг, но и тщательно продумать, спроектировать свою работу, аккуратно и дотошно её выполнить, не забывая при том, что с макетом в дальнейшем будут работать ещё несколько человек. Работайте профессионально. Это приятно и полезно.

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

Чтобы получить представление о моих навыках вёрстки, статических прототипов более чем достаточно, а пугать потенциальных заказчиков очередным кошмаром, в который другие разработчики превратили мой макет, совершенно не хочется.

И, да - я по-прежнему открыта для фриланса.
U r welcome -)

Скачать песню: Rammstein «Engel» (6 Mb)

Так как это мой первый опыт перевода больших технических текстов, ляпы имеются. Любые исправления будут приняты с радостью ;)

Перевод под катом.

Написание плагина

Введение

Вплоть до версии Wordpress 1.2, если вы хотели изменить его поведение, вам нужно было редактировать (или «хакать») исходный код Wordpress. Однако, в большинстве текущих версий Wordpress вы можете с легкостью модифицировать функциональность ядра Wordpress или добавлять новую с помощью «плагинов». Основная идея использования расширяемой архитектуры состоит в том, чтобы при сохранении ядра относительно простым, но достаточно гибким, каждый аспект его ввода и вывода мог быть изменен с помощью плагинов. Вот определение:

Плагин Wordpress

Плагин Wordpress - это программа или набор функций, написанных на PHP, которые добавляют определенный набор возможностей или сервисов к блогу на Wordpress, которые легко объединяются с системой управления и методами Wordpress при помощи Plugin Application Program Interface (API).

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

Эта статья подразумевает, что вы уже знакомы с основами функциональности Wordpress, а также с языком программирования PHP.

Ресурсы

Plugin Resources — всеобъемлющий список статей и средств для разработчиков плагинов, включающий в себя развернутые статьи по написанию плагинов, и статьи на специфические «узкие» темы.

Другой хороший путь изучить устройство плагинов - это смотреть в исходные PHP-коды хорошо написанных плагинов, таких как Hello Dolly, плагин, входящий в базовую поставку Wordpress.

Если вы написали плагин к Wordpress, прочитайте Plugin Submission and Promotion, чтобы узнать, как распространить ваш плагин.

Создание плагина

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

Имена, файлы, и местоположения файлов

Имя плагина

Первая задача при создании плагина - подумать, что плагин будет делать, и придумать для него имя (желательно уникальное). Проверьте Plugins и другие хранилища, чтобы убедиться в том, что придуманное вами имя - уникальное; вы можете также погуглить по выбранному вами имени. Большинство разработчиков плагинов выбирают имена, которые отражают функциональность их плагина; например, плагин для отображения погоды может иметь в названии слово “погода”. Название может состоять из нескольких слов. (Естественно, ваш плагин должен иметь название на английском языке. - прим. переводчика)

Файлы плагина

Следующий шаг - создание файла PHP с именем, производным от названия плагина. Например, если ваш плагин будет называться «Fabulous Functionality», вы можете назвать ваш файл fabfunc.php. Опять же, попробуйте создать уникальное имя. Люди, которые установят ваш плагин, положат этот файл в свою директорию для плагинов wp-content/plugins/, и два плагина, которые человек использует, могут иметь одинаковое имя файла.

Другой вариант - разбить ваш плагин на несколько файлов. Ваш плагин должен иметь как минимум один файл PHP; он также может содержать файлы Javascript, CSS, изображения, языковые файлы и т.п. Если ваш плагин состоит из нескольких файлов, задайте уникальное имя для директории, в которой они лежат, и для главного файла PHP, такие как fabfunc и fabfunc.php в нашем примере, положите ваши файлы в эту директорию, и дайте пользователям возможность устанавливать целую директорию в свою папку для плагинов.

В этой статье «PHP файл плагина» означает главный PHP-файл, который находится в директории для плагинов или в ее поддиректории.

Файл «Прочитай меня» (Read me)

Если вы хотите разместить ваш плагин на http://Wordpress-plugins.org, вам необходимо создать файл readme.txt в стандартном формате, и включить его в свой плагин. Смотрите http://wordpress.org/extend/plugins/about/readme.txt для получения разъяснений по формату.

Домашняя страница

Также, очень удобно создать веб-страницу, играющую роль «домашней страницы» вашего плагина. Эта страница должна объяснять, как установить плагин, что он делает, с какими версиями Wordpress совместим, что менялось от версии к версии вашего плагина, и как использовать плагин.

Заголовки файлов

Самое время дать некоторую информацию по поводу вашего главного файла PHP.

Стандартная информация о плагине

Начало вашего файла должно содержать стандартный информационный заголовок. Этот заголовок позволяет Wordpress понять, что ваш плагин существует, добавить его в панель управления плагинами, где он может быть активирован, загрузить его и запустить его функции; без заголовка ваш плагин никогда не будет активирован и запущен. Это формат заголовка:

<?php
/*
Plugin Name: Название вашего плагина
Plugin URI: http://URI_страницы_которая_описывает_ваш_плагин
Description: небольшое описание плагина.
Version: номер версии
Author: имя автора
Author URI: http://URI_автора
*/
?>

(естественно, все должно быть по-английски - прим. переводчика)

Минимальная информация, которая нужна Wordpress, чтобы обнаружить ваш плагин - его название (Plugin Name). Остальная информация (если она есть) используется для создания таблицы плагинов на странице управления плагинами. Порядок строк неважен.

Лицензия

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

<?php
/* Copyright YEAR PLUGIN_AUTHOR_NAME (email : PLUGIN AUTHOR EMAIL)
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
?>


Программирование плагина

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

«Ловушки» (Hooks) плагина

Множество плагинов выполняют свои задачи с помощью соединения с одной или более «ловушками». «Ловушки» работают в то время, пока Wordpress запущен. Wordpress проверяет, имеют ли несколько плагинов одинаковые зарегистрированные функции, и если это так, функции запускаются. Эти функции меняют стандартное поведение Wordpress.

Например, перед тем как Wordpress добавляет заголовок поста в вывод браузера, сначала он проверяет, имеет ли какой-либо плагин зарегистрированную функцию для «фильтра-ловушки» под названием «the_title». Если имеет, текст заголовка пропускается через каждую зарегистрированную функцию, и конечный результат выводится. Таким образом, если ваш плагин должен добавлять некую информацию к заголовку поста, он может зарегистрировать функцию-фильтр «the_title».

Другой пример - «действующая ловушка» под названием «wp_footer». Перед концом HTML-страницы, которую генерирует Wordpress, он проверяет, имеют ли какие-нибудь плагины зарегистрированную функцию «wp_footer», и запускает ее.

Вы можете узнать больше о том, как регистрировать функции для фильтров и «ловушек», и какие «ловушки» доступны в Wordpress, в Plugin API. Если вы нашли место в коде Wordpress, где вы хотели бы иметь действие или фильтр, но в Wordpress его нет, вы можете предложить новые «ловушки» (предложения в основном принимаются); как это сделать, вы можете узнать в Reporting Bugs.

Теги шаблонов

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

Чтобы объявить тег шаблона, просто напишите функцию php, и задокументируйте ее для пользователей плагина на вашей странице, посвященной плагину и/или в главном файле плагина. Хорошая идея, документируя функцию, приводить пример выполнения содержащий <?php и ?>, который нужно добавить в тему для получения результата.

Сохранение данных плагина в базу

Большинство плагинов получают некую информацию от владельца блога или от его пользователейдля использования ее в фильтрах, рабочих функциях, и функциях шаблонов, которую нужно хранить между сессиями. Эта информация требует сохранения в базе Wordpress на длительное время между сессиями. Вот два основных метода сохранения данных в базу:

1. Используйте механизм Wordpress Options (о нем рассказывается ниже). Этот метод предназначен для хранения относительно небольшого количества статической информации, называемой «массивом данных» - тип данных, которые владелец блога вводит при первом запуске плагина, и затем редко изменяет.
2. Создайте новую отдельную таблицу в базе данных. Этот метод предназначен для данных, связанных с определенными постингами, страницами, прикрепленными файлами или комментариями - тип данных, которые растет с течением времени, и которые не имеют индивидуальных имен. Смотрите Creating Tables with Plugins для получения информации, как создать таблицу плагина.

Механизм настроек (Options) Wordpress

Wordpress имеет механизм для сохранения, обновления и извлечения индивидуально поименованных массивов данных (настроек), хранящихся в базе Wordpress. Значения настроек могут быть строками, массивами или объектами PHP (они будут сериализованы или сконвертированы в строку перед записью, и разсериализованы перед извлечением). Названия настроек - строки, и они должны быть уникальными, чтобы не конфликтовать с Wordpress или другими плагинами.

Вот главные функции, которые ваш плагин может использовать, чтобы получить доступ к настройкам Wordpress:

add_option($name, $value, $description, $autoload);

Создает новую настройку; не делает ничего, если опция уже существует.

• $name - обязательный (строка). Имя настройки.
• $value - необязательный (строка), по умолчанию пустая строка. Значение настройки.
• $description - необязательный (строка), по умолчанию пустая строка. Описание настройки, которое находится в базе, чтобы кто-либо, просматривающий базу, понимал, что это за настройка.
• $autoload - необязательный, по умолчанию - «да» («да» или «нет»). Если установлено «да», настройки автоматически извлекаются функцией get_alloptions.

get_option($option);

Извлекает значение настройки из базы.

• $option - обязательный (строка). Имя настройки, значение которой нужно получить.

update_option($option_name, $newvalue);

Обновляет или создает значение настройки в базе (примечание: add_option не может быть вызвана без использования $description или $autoload параметров).

• $option_name - обязательный (строка). Имя настройки для обновления.
• $newvalue - обязательный. Новое значение настройки.

Панели администрирования

При условии, что ваш плагин имеет некие опции, хранящиеся в базе Wordpress (см. раздел выше), вы, вероятно, захотите иметь административную панель, которая позволит пользователям смотреть и редактировать настройки вашего плагина. Методы создания панелей описаны в Adding Administration Menus.

Интернационализация плагина

После того, как вы закончили писать ваш плагин, его необходимо интернационализовать (при условии, что вы планируете распространять ваш плагин). Интернационализация - это процесс настройки программного обеспечения под локализацию; локализация - это процесс перевода на различные языки отображаемого программой текста. Wordpress используется по всему миру, и интернационализация и локализация встроены в его структуру, в том числе, и локализация плагинов. Wordpress использует “GNU gettext” для локализации (см. Translating WordPress).

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

• Выберите имя для пространства перевода вашего плагина. Обычно оно такое же, как имя главного файла вашего плагина (только без .php). Имя должно быть уникальным.
• Везде, где ваш плагин использует строки текста, которые будут показаны пользователю (известны как «сообщения»), заключите их в одну из двух gettext-функция Wordpress. Заметьте, что в вашем плагине вы должны использовать второй аргумент - имя пространства перевода, которое вы выбрали (в ядре Wordpress этот аргумент остается пустым).

__($message, $domain)

Переводит $message, используя текущую локаль для $domain. Поместите строки, которые собираетесь использовать в расчетах, в эту функцию.

_e($message, $domain)

Переводит $message, используя текущую локаль для $domain. Поместите в эту функцию строки, которые собираетесь показывать пользователю.

• Создайте для вашего плагина файл POT (каталог переводов для всех переводных сообщений), и распространяйте его вместе с плагином. Пользователям необходимо будет положить MO-файл перевода в директорию вашего плагина. и назвать его domain-ll_CC.mo, где ll_CC - имя нужной локали. Для получении информации о файлах POT, MO и локалях см. Translating WordPress.
• Загружайте перевод для текущей локали и ваше текстовое пространство с помощью функции load_plugin_textdomain до того, как вызываются функции gettext, но настолько поздно, насколько возможно в сессии (потому что некоторые многоязычные плагины меняют локаль при загрузке). Одна из возможностей имплементации - объявление функции инициализации, которая вызывается выше всех функций вашего плагина. Например, ваше пространство текста называется «fabfunc»:

$fabfunc_domain = 'fabfunc';
$fabfunc_is_setup = 0;
function fabfunc_setup()
{
global $fabfunc_domain, $fabfunc_is_setup;
if($fabfunc_is_setup) {
return;
}
load_plugin_textdomain($fabfunc_domain, ‘wp-content/plugins’);
}


Если ваш плагин находится в собственной поддиректории, присоедините ее имя ко второму аргументу функции load_plugin_textdomain.

Советы по разработке плагина

Это последняя часть статьи, включающая в себя различные советы по разработке плагина.

1. Код плагина должен соответствовать стандартам разработки Wordpress (WordPress Coding Standards). Пожалуйста, примите во внимание стандарты Inline Documentation.
2. Все функции вашего плагина должны иметь уникальные имена, отличные от имен функций ядра Wordpress, других плагинов или тем. По этой причине, хорошая идея - использовать уникальный префикс для имен функций вашего плагина. Другая возможность - объявлять ваши функции внутри класса (который тоже должен иметь уникальное имя).
3. Не используйте явно префикс базы Wordpress (обычно wp_) в вашем плагине. Вместо этого используйте переменную $wpdb->prefix
4. Чтение базы - легкий процесс, а вот запись в базу - сложный. Базы исключительно хороши при сборке данных и их выдаче, эти операции обычно выполняются быстро. Внесение изменений в базу - более комплексный процесс, следовательно более ресурсоемкий. В результате, постарайтесь уменьшить количество записей в базу. Держите все готовым в коде, тогда вы сможете делать только те записи в базу, которые действительно нужны.
5. Выбирайте из базы при помощи SELECT только то, что вам нужно. Даже несмотря на то, что базы извлекают данные достаточно быстро, вы можете уменьшить нагрузку на базу, выбирая только те данные, которые вам нужны. Если вам нужно подсчитать количество строк в таблице, не используйте SELECT * FROM, потому что все данные всех строк будут занимать память. Подобно этому, если вам нужны только post_id и post_author в вашем плагине, выбирайте SELECT’ом только конкретные поля, чтобы уменьшить нагрузку. Помните: сотни других процессов могут обращаться к базе одновременно с вами. База и сервер могут только распределять ресурсы между процессами. Изучите, как минимизировать обращения вашего плагина к базе, чтобы гарантировать, что ваш плагин не злоупотребляет ресурсами.

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

Конечно, не обошлось и без ляпов, но это была наша первая попытка организации конференции, и она прошла на ура.
Еще бы, на РИТ пришло более полутысячи разработчиков всех мастей! Причем, во второй день, вопреки ожиданиям, было вовсе не хуже.

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

Что касается секции “Клиентское программирование”, то в ней мне было интересно все, так как я специалист именно в данной области. Все доклады были очень интересны, особенно понравились доклады Леши Рыбакова, Вадима Макеева и Макса Россомахина (так как они относились непосредственно к верстке). Леша Рыбаков вообще отжог не по-детски, огромный респект :)

В общем, я считаю, конференция удалась на все сто, несмотря на весь скепсис в самом начале этого проекта.
Большое спасибо всем участникам, докладчикам и организаторам!

Ссылок же по теме в этот раз очень много, дам только ссылку на статьи на Вебпланете:

• РИТ-2007: день первый
• РИТ-2007: день второй, заключительный

Фотографии:

• Фото от Олорина
• Отчет на tagirov.org

Остальное ищите в поиске по блогам от Яндекса.

P.S. Вчера после окончания пили пиво с яндексоидами, вебстандартистами и другими разработчиками - милейшие люди работают в Яндексе :) Ну и вообще невероятно рада появившимся новым знакомствам.

Со временем этот вопрос решился на 99% - все, что касается моей работы в интернете, у меня одинаковое на любой машине, на которой будет нужно.
Получаю я такое безоблачное существование следующим образом:

1. я использую Firefox в качестве основного браузера, а к нему использую дополнение Google Browser Sync, которое хранит все мои данные на сервере и синхронизирует их (пароли, закладки, сессии, историю и т.п.)
2. я пользуюсь сервисом букмарков Del.icio.us, где храню свои закладки, в том числе, и ссылки на те расширения для Firefox, которые необходимы мне для работы.
3. фиды я читаю при помощи сервиса Netvibes. Раньше это была Яндекс.Лента, но Netvibes категорически круче всех.
4. работа с фтп происходит с помощью FTPRush. Он не синхронизируется через веб, но умеет экспортировать настройки, в том числе и учетные записи серверов.
5. жизненно важные программы я таскаю с собой на iPod

Таким образом, где бы я ни была, на какой бы системе мне не приходилось работать - все мое всегда со мной, стоит только поставить Firefox (проверено на Linux, win2k и многочисленных компах друзей, не считая домашнего и рабочего).
Собственно, не хватает только синхронизации локальных файлов. Существуют и такие программки (Handy Backup, к примеру), но у меня пока нет необходимости ими пользоваться - большинство времени я работаю непосредственно в интернете.

А как вы облегчаете себе жизнь?