Для тех, кто не в курсе, по тем или иным причинам, коротко объясняю, что такое VDS/VPS сервер:

VPS (Virtual Private Server) или VDS (Virtual Dedicated Server) — услуга, в рамках которой пользователю предоставляется так называемый Виртуальный выделенный сервер. В плане управления операционной системой по большей части она соответствует физическому выделенному серверу. В частности: root-доступ, собственные IP-адреса, порты, правила фильтрования и таблицы маршрутизации.

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

В некоторых системах аппаратной виртуализации (к примеру — VMWare и Xen) также доступны для редактирования настройки ядра операционной системы и драйверов устройств.

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

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

Таким образом, Виртуальный Выделенный Сервер (VDS/VPS) обладает всеми преимуществами физического сервера, являясь практически полным его аналогом. Купив VDS, Вы получаете, пусть не очень большой, но собственный сервер, с полными административными правами, возможностью инсталлировать любое ПО и запускать любые сервисы.

Очень привлекательно! Не правда ли? Тем не менее, тестирование показало, что блог на VDS, при тех параметрах, которые я смог себе позволить, работает несколько медленнее блога на виртуальном хостинге. Несмотря на большое желание переехать, пусть на виртуальный, но всё-таки свой сервер, я уже было начал склоняться к виртуальному хостингу на TimeWeb. Как вдруг … Повторюсь, всё неприятное происходит “вдруг”. На второй неделе использования хостинга на TimeWeb в зашёл в раздел “Информация по нагрузке” своего аккаунта. То, что я там увидел, одновременно удивило и разочаровало меня:

Напомню: на этом хостинге был размещён лишь ОДИН сайт – этот блог. Блог, не являющийся сильно посещаемым, нагрузил процессор сервера по самое “не балуй”. Что же будет, если я перенесу на этот хостинг свой второй блог и два своих форума? Видимо, ничего хорошего – выгонят поганой метлой за нарушения, с формулировкой “зверское превышение нагрузки на сервер”. Шутки шутками, но если серьёзно, один блог расходовал, если не учитывать пиковую нагрузку 31 марта, половину допустимой нагрузки на процессор. Если учесть то, что при публикации обновлений моих плагинов, трафик на обоих моих блогах (на этом и международном) возрастает в 3..5 раз и остаётся таким 5..10 дней после публикации, то становится очевидным, что бан неизбежен . Долго я не думал. Решение проблемы очевидно и я переехал со всем своим скарбом на FirstVDS. Теперь у меня есть свой, пусть виртуальный, но свой сервер!

Тем, кто захочет пойти по моим стопам или уже хочет, но не решается, хочу сказать, что ничего сверхъестественного для управления виртуальным сервером знать не надо. Для управления VDS на уровне реализации хостинга блога или форума быть гуру вовсе не обязательно. Если Вы пользуетесь ISPManager на виртуальном хостинге, а это одна из самых распространённых систем управления, то Вы, возможно, даже не почувствуете разницу между виртуальным хостингом и VDS.

Впрочем, небольшая разница есть. Став арендатором VDS и получив root доступ, Вы сможете создать сайт (домен) только после создания аккаунта пользователя VDS, т.е. для себя любимого. Другими словами, Вы – арендатор и root-пользователь являетесь администратором сервера, а Вы – пользователь являетесь пользователем виртуального хостинга, созданного Вами – администратором. Кстати, Вы можете создать виртуальный хостинг не только для себя, но и для кого-либо ещё и это не является нарушением правил использования. Впрочем, если Вам вдруг захочется попробовать себя реселлером хостинга, лучше пойти официальным путём и заключить официальное соглашение с владельцем ресурсов.

Разумеется есть и другие отличия, но они лишь расширяют Ваши возможности относительно виртуального хостинга. Это возможность подключить уже установленные, но неиспользуемые по умолчанию, библиотеки PHP, возможность загрузить и установить нестандартные библиотеки PHP, а также возможность перезагрузить сервер, если что-то пошло не так. В целом же все то же самое, что и в ISPManager для виртуального хостинга.

Если Вам это интересно – решайтесь!

© 2012, minimus. Все права защищены. При копировании и републикации статьи, ссылка на первоисточник обязательна.

Похожие статьи:

1. Переезд с проблемами
2. Переезд без проблем
3. Файл-хостинг для блоггера

В самое ближайшее время я планирую опубликовать версию 1.5 этого плагина. Бета версия будет опубликована в ближайшие два дня на форуме поддержки SimpleLib. В дальнейшем, я планирую приступить к разработке версии 2.0. Дальше я пока не заглядывал, а потому, расскажу о нововведениях ожидающихся в этих двух версиях Simple Ads Manager.

Simple Ads Manager 1.5

Коротко о нововведениях:

1. Изменения в интерфейсе редактора рекламных объявлений
2. Изменения в запросах к базе данных для рубрик, авторов и т.д.
3. Поддержка флеш (SWF) баннеров
4. Журнал ошибок
5. Ограничения показа объявлений по пользователям
6. Прочие доработки

Изменения в интерфейсе редактора рекламных объявлений

Если честно, я устал принимать сообщения возмущённых пользователей о том, что ничего не работает. На поверку оказывается, что человек хочет видеть рекламное объявление в режиме “изображение”, а включен режим код. Начиная с версии 1.5, в редакторе рекламных объявлений будут видны параметры только включенных режимов и опций, для всех остальных режимов и опций их параметры будут скрыты. Для того, чтобы увидеть параметры режима или опции, необходимо будет этот режим или опцию включить.

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

Изменения в запросах к базе данных для рубрик, меток и т.д.

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

Поддержка флеш (SWF) баннеров

В версии 1.5 вводится поддержка флеш (SWF) баннеров. Это значит, что теперь Вы можете изготовить свои собственные флеш-баннеры и использовать их как рекламные объявления с помощью Simple Ads Manager. Необходимо только указать, что используемое изображение является флеш-баннером. Не забывайте о том, что URL перехода должен задавать сам флеш-ролик с помощью внутреннего скрипта. Ссылка задаваемая для изображения в данном случае работать не будет.

Журнал ошибок

Довольно часто я получаю сообщения на форуме поддержки о том, что плагин выдаёт сообщение об ошибке, связанной с обновлением базы данных. Честно говоря, сложно отвечать на такие сообщения не имея подробной информации, поэтому я решил добавить в плагин журнал сообщений. Все ошибки возникающие в ходе работы плагина, связанные с обращением к базе данных, будут фиксироваться в журнале ошибок. Фиксируются ошибки как при обновлении баз данных, так и при выводе объявлений в Face Side. Мне кажется, что это нововведение должно ускорить исправление ошибок, как автора (меня), так и пользователей, неизбежно возникающих при работе с таким сложным (?) плагином, как Simple Ads Manager.

Ограничения показа объявлений по пользователям

Уже поступило несколько просьб со всего мира о том, чтобы ввести ограничения показа рекламных объявлений по пользователям. Основное в просьбах – не показывать объявление рекламодателю, когда он заходит на сайт. Вполне логично, особенно, если объявление было заказано на фиксированное количество показов. Впрочем, иногда есть необходимость показа незарегистрированным пользователям одних объявлений, а зарегистрированным – других. Начиная с версии 1.5 это станет возможным.

Прочие доработки

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

Simple Ads Manager 2.0

Разумеется, эта версия существует только в планах, но некоторые намётки уже есть:

1. API дополнений (Addons API)
2. Новый трекер кликов
3. Новая роль пользователей – рекламодатель

API дополнений (Addons API)

У меня лежит довольно большой список интересных предложений от пользователей, который не имеет смысла реализовывать внутри плагина. Смысл реализации отсутствует по следующим причинам. Во-первых, эти предложения интересны не всем пользователям плагина. Во-вторых, их реализация серьёзно “утяжелит” плагин и сделает невозможным его использование на низкобюджетных блогах. Сами по себе предложения интересные. Например “расширенная статистика” показов объявлений или “система заказа” объявлений могли бы очень пригодиться некоторым блоггерам, но не всем. Поэтому появилась мысль расширить возможности плагина путём введения в него обработки actions и filters. Это стандартный способ расширения WordPress, почему бы не использовать его для расширения этого плагина. Введение API позволит писать расширения (дополнения) для плагина не только мне, но и всем остальным заинтересованным разработчикам.

Новый трекер кликов

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

Новая роль пользователей – рекламодатель

С некоторых пор, WordPress стал поддерживать расширенные роли пользователей, наряду со встроенными ролями. Введение роли “рекламодатель” и соответствующие изменения в плагине позволят рекламодателям регистрироваться на блоге в качестве “рекламодателя” и получить доступ к инструментам размещения своих объявлений на площадке и просмотра статистики размещённых объявлений. По мере развития Addons API, количество инструментов для рекламодателя будет увеличиваться.

P.S.

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

P.P.S.

Один человек не может “объять необъятное”. Несмотря на то, что я часто перевожу понравившиеся мне плагины на русский язык, я не могу перевести все плагины для WordPress, да, в общем то, и не стремлюсь. Если Вы не нашли на этом сайте нужный Вам плагин, Вы можете поискать русские плагины wordpress на сайте mojWP.ru.

© 2012, minimus. Все права защищены. При копировании и републикации статьи, ссылка на первоисточник обязательна.

Похожие статьи:

1. Simple Ads Manager. Как это работает.
2. WordPress плагин Simple Ads Manager
3. WordPress плагин Simple Counters

Пол года назад я уже писал о переезде от одного хостера к другому. Статья была о том, как избежать проблем при смене хостера. Но что делать когда проблемы уже возникли? Эта статья именно о том как можно решить проблемы возникшие ещё до решения о переезде и как минимизировать потери от возникших проблем. Я расскажу Вам как бороться с возникшими проблемами, используя свой опыт.

Предыстория

Пол года назад я переехал от хостера Komtet на сервер Infiumhost. Не то чтобы Komtet был плохим хостером, скорее наоборот, но у него небыло подходящего для меня тарифного плана, поэтому пришлось переехать. Я долго выбирал хостера и остановился на Infiumhost. По началу всё шло хорошо, первые два месяца нареканий не было. Всё супер: быстрый отклик сервера, богатый набор выделенных ресурсов и цена очень даже демократичная для уровня и объёма предоставляемых услуг. Но вдруг, всё плохое бывает “вдруг”, начались падения сервера. И чем дальше, тем чаще. Дошло до того, что по выходным сервер скорее “лежал”, чем “стоял”. Техподдержка, в лице Ануфриева Сергея Валерьевича, поначалу весьма вежливая, начала откровенно хамить. В довершение ко всему, меня вдруг заблокировали без объяснения причин. С трудом удалось выяснить, что это не очередное падение сервера, а банальная блокировка:

От: minimus – 2012-03-17 09:32:10
Сервер в дауне вторые сутки!!! У Вас хоть что-нибудь работает? Ваш сервер “колбасит” уже неделю!!!

——————————————————————————————
От: Ануфриев Сергей Валерьевич – 2012-03-17 09:34:15
я боюсь, что именно у вас уже ничего и не будет работать.

——————————————————————————————
От: minimus – 2012-03-17 09:36:05
Это ещё почему?

——————————————————————————————
От: minimus – 2012-03-17 10:50:05
Ну так что? Есть что ответить?

——————————————————————————————
От: Ануфриев Сергей Валерьевич – 2012-03-17 11:34:00
систематическое нарушение правил и превышение нагрузки

Вы считаете, что я слишком жестко начал разговор? Это следствие предыдущего:

От: minimus – 2012-02-08 09:50:45
www.simplelib.com, blogcoding.ru – последние 12 часов “504 Gateway Time-out”
Как долго это будет продолжаться? Я несу финансовые потери!

——————————————————————————————
От: Ануфриев Сергей Валерьевич – 2012-02-08 11:58:08
> Я несу финансовые потери!
нам это не очень интересно.

сайты функционируют нормально.
проверяйте через http://host-tracker.com/

—————————————————————————————–
От: minimus – 2012-02-08 14:16:34
Сейчас УЖЕ ДА …
08072012.jpg

—————————————————————————————–
От: minimus – 2012-02-08 18:34:26
>нам это не очень интересно.
Г-н Ануфриев, мне не интересно по каким причинам Вы и Ваши коллеги не могут обеспечить нормальное функционирование моих сайтов. Вы взяли на себя определённые обязательства, будьте любезны их исполнять! А хамство в отношении клиентов, это в любом случае моветон …
Удачи Вам в вашем нелёгком труде … ну или изучите инструкцию в конце концов …

—————————————————————————————–
От: Ануфриев Сергей Валерьевич – 2012-02-12 00:00:00
Перемещено в архив по причине отсутствия активности в течение 3 дней.

Ответа я тогда не дождался …

Позднее, анализируя сложившуюся ситуацию, я пришёл к выводу, что меня забанили незаконно. А суть вот в чём. Я заказал хостинг когда Infiumhost предлагал на тарифном плане “Оптимум” другие параметры нежели сейчас. Например 256Mb memory_limit тогда против 192Mb сейчас. Другие параметры тоже изменились в худшую сторону. Я думаю, что перенастроив параметры выделяемые для данного тарифного плана и настроив систему контроля, техники забыли или умышленно оставили без изменений (для перезаключения договоров на новых, худших условиях) ограничения для старых аккаунтов. Таким образом мой WordPress запрашивает 512Mb памяти (он всегда просит столько, но использует сколько дадут) и получает 256Mb, согласно настройкам аккаунта, а система контроля фиксирует нарушение по выделению памяти (перерасход). Я, конечно, не специалист в этой области, но думаю, что это происходит приблизительно так.

Но, вернёмся к нашим “баранам” … Доступ к сайтам, и, соответственно, к базам данных закрыт. Техподдержка отвечает “стиснув зубы”. Что же делать?

Исходные данные

Итак, что же мы имеем в качестве исходных данных для продолжения работы нашего сайта? Практически ничего, кроме желания всё восстановить.

1. Данные, накопленные за четыре года, недоступны
2. Хостинг отсутствует и перенос данных невозможен (см. пункт №1)

Тем не менее, как Вы уже заметили, сайт работает и это значит, что ещё не всё потеряно.

Восстанавливаем потерянные данные

Если не отчаиваться и включить мозг, всё не так уж и страшно. Первым делом, я запросил доступ к данным у тех. поддержки Infiumhost. Не смотря на то, что у нас случился нелицеприятный разговор и даже не один, мне дали ссылку на архивный файл backup‘а десятидневной давности. Не стесняйтесь просить, а если нужно и требовать, свои данные (базы данных, файлы) – это всё Ваша интеллектуальная собственность. И каким бы страшным не было Ваше прегрешение перед хостером, он не может и не в праве не вернуть Вам её, а тем более присвоить!

Итак, часть данных восстановлена. Почему часть? Потому, что backup не свежий и, следовательно, содержит не все данные. Кроме того, позднее выяснилось, что он немного “кривой” – часть файлов была записана с изменёнными расширениями. Но, как говорится, лучше что-то чем ничего. Тем более, что есть способ восстановить недостающие данные.

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

Другим источником утерянной информации может быть кэш поисковика Google. Суть та-же самая, найдите необходимую статью в поиске Google, но переходите на неё не по ссылке, а через ссылку “Сохраненная копия”, если Ваша статья была просмотрена роботом Google до потери сайта, Вы сможете её открыть в “первозданном виде”.

Подбор хостера

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

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

Я искал хостера предлагающего объём предоставляемых услуг на уровне или большем, чем изначально предлагал мне Infiumhost. Это должен был быть хостер работающий на рынке не менее 5..7 лет. И это должен был быть хостер с нормальной, вменяемой тех. поддержкой.

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

Второй хостинг, а точнее Виртуальный Выделенный Сервер (VDS), я приобрёл у firstVDS. По цене VDS обходится даже дешевле, чем Виртуальный хостинг от Timeweb – 249 руб/мес. за тариф VDS-Разгон от firstVDS против 265 руб/мес. за тариф Century от Timeweb. Кроме того, мне давно хотелось попробовать VDS в деле, хочется, знаете ли, самому назначать своим сайтам выделяемые ресурсы и не зависеть от прихотей хостера. К тому же, как оказалось, по управлению VDS ничуть не сложнее виртуального хостинга, если Вы не хотите установить что-то совсем экстраординарное. Та же панель (ISPManager), те же способы управления данными, просто больше возможностей (например подключить дополнительные библиотеки PHP). Более подробно о работе с VDS я расскажу в одной из следующих статей.

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

Установка данных

Первое с чем я столкнулся после переноса данных на новый хостинг, это отказ работы этого блога. Как я уже упоминал в начале этой статьи, часть файлов в backup’е была сохранена некорректно – расширения файлов при упаковке потеряли последнюю букву. Я обнаружил это уже после закачки данных на хостинг. Вам же советую проверять файлы ещё до закачки – это сохранит время и нервы. Мне повезло, что искорёжило только имена файлов, а не их содержимое.

Разумеется, я имел “частичную” резервную копию всех своих сайтов, но так случилось, что и она была устаревшей – файлы были на месте, а вот копия баз данных была трёхмесячной давности. Расслабился и поплатился за это.

 Заключение

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

1. Требовать резервную копию данных со своего аккаунта при любых обстоятельствах
2. При необходимости использовать Google Reader или кэш Google
3. Не торопиться при выборе следующего хостера – подбирать с особой тщательностью

Что нужно делать для того, чтобы проблем возникало как можно меньше:

1. Постоянно и как можно чаще производить резервное копирование
2. Периодически проверять статус и статистику превышений и предупреждений своего сайта
3. Подбирать хостера с особой тщательностью

По идее, если исполнять эти нехитрые правила, проблем возникнуть не должно. Однако, человек предполагает, а Бог располагает …

Удачи!

© 2012, minimus. Все права защищены. При копировании и републикации статьи, ссылка на первоисточник обязательна.

Похожие статьи:

1. Переезд без проблем
2. Переезд. VDS/VPS хостинг
3. Мягкий старт

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

Но, вот, плагин уже написан … Что же дальше? Как донести это совершенное творение до пользователей?

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

• Пользователь может найти Ваш плагин прямо из “админки” своего блога банальным поиском.
• Пользователь может загрузить и установить Ваш плагин из той-же “админки” своего блога
• Пользователь может автоматически обновлять Ваш плагин по мере его обновления
• Страница вашего плагина в репозитарии может содержать ссылку на Ваш блог, а это очень популярный ресурс …

Добавление плагина в репозитарий

Для того, чтобы добавить свой плагин в репозитарий WordPress, необходимо зарегистрироваться на сайте, а затем перейти на страницу “заявки на добавление плагина” и заполнить все поля заявки. Их всего три:

1. Plugin Name – имя плагина. Не торопитесь давать вычурное имя своему плагину. В данном случае, это не совсем имя, это название папки в которую впоследствии будут помещены файлы Вашего плагина. Естественно, что это имя должно подчиняться некоторым правилам написания. Во-первых, имя должно состоять из символов латиницы, дефисов и символов подчёркивания. Общепринято использовать латиницу и дефисы, например: multilungual-comments-number. Во-вторых, оно должно совпадать с именем главного файла плагина (без расширения).
2. Plugin Description – Описание плагина на английском языке. Желательно написать так же, как будет написано в коротком описании плагина в дальнейшем (readme.txt).
3. Plugin URL – это не URL плагина, это URL статьи описывающей плагин. Желательно, что бы статья была на английском языке, но если Вам негде разместить такую статью, сойдёт и на русском (украинском, белорусском, казахском и т.п.).

Заполнив все поля, нажмите на кнопку “Send Post” и ждите e-mail с подтверждением регистрации плагина.

Загрузка плагина в репозитарий

Получив от модератора WordPress подтверждение добавления Вашего плагина в репозитарий Вы можете начать подготовку к его загрузке в оный. Для этого Вам надо:

• Соответствующим образом оформить файлы плагина, включая файл readme.txt
• Установить на свой компьютер программное обеспечение SVN
• Произвести необходимые манипуляции с файлами и папками для загрузки файлов в репозитарий

Итак, начнём.

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

Главный (и, возможно единственный) файл плагина должен содержать следующие строки комментариев в самом начале файла:

• Plugin Name – здесь Вы можете написать красивое имя Вашего плагина. Именно так оно будет отображаться на странице Вашего плагина в репозитарии и на страницах “Плагины” пользователей Вашего плагина
• Plugin URI – URL статьи описывающий плагин, обычно статья в Вашем блоге
• Description – короткое описание плагина, показывается на админ-странице “Плагины” блога в списке плагинов
• Version – текущая версия плагина. Обычно состоит из трёх чисел, разделённых точками: основная версия.субверсия в пределах основной версии.количество изменений (сквозной номер редакции)
• Author – автор(ы) плагина. Ник в системе wordpress.org
• Author URI – ссылка на ресурс автора. Обычно на основной блог …

Второй блок комментария содержит copyright автора и заявление о распространении данного продукта на условиях лицензии GNU General Public License v2.

Ваш плагин ОБЯЗАТЕЛЬНО должен содержать файл readme.txt – это обязательное условие. Без этого файла страница плагина в репозитарии не будет отображаться, т.к. этот файл и есть страница Вашего плагина.

В файле readme.txt используется язык “Markup”. Полностью описывать правила оформления этого файла не буду – это долгая история, Вы можете найти их здесь. Проверить написанный файл можно здесь.

Программное обеспечение

Репозитарий плагинов WordPress является репозитарием SVN с урезанными функциями, поэтому для загрузки плагина в репозитарий и последующих его обновлений Вам потребуется программное обеспечение SVN. Скачать Subversion можно здесь – это базовый пакет, необходимый для работы с репозитарием. Поскольку с базовым пакетом необходимо работать из командной строки, я, для удобства, установил себе Tortoise SVN – это надстройка, позволяющая работать в интерфейсе проводника Windows. Не забудьте установить пакет русского языка для Tortoise SVN.

Процесс загрузки

Для работы с репозитарием, я, обычно использую Tortoise SVN, но для первоначальной активации лучше использовать базовый пакет SVN. Для этого нужно воспользоваться командной строкой или PowerShell (Windows). Сначало необходимо перейти в папку svn_repository, созданную пакетом Subversion и создать папку плагина (например: multilingual-comments-number). Затем скопировать структуру папок, созданную для Вашего плагина модератором репозитария:

После выполнения этих команд в папке Вашего плагина должны появиться папки trunk, tags и branches. Если это так, значит всё идёт “как надо”.

Теперь необходимо перейти в папку плагина, т.е. сделать её текущей для PowerShell.

Скопируйте подготовленные файлы плагина в папку trunk. Это можно сделать с помощью команд PowerShell, но я делаю это с помощью проводника Windows.

Теперь, когда файлы плагина скопированы в локальную копию репозитария, нужно дать знать центральному репозитарию о произведённых изменениях и загрузить файлы в центральный репозитарий:

Всё! Плагин в репозитарии WordPress. Поздравляю! В течении ближайших 15-ти минут он станет доступным для всех.

Все манипуляции с плагином производятся в папке trunk. Если Вы хотите версировать плагин (для пользователей будут доступны все версии плагина, а не только текущая), используйте папку tags. Для этого скопируйте папку trunk в подпапку папки tags (подпапка должна иметь название в виде версии плагина) и дайте знать об этих изменениях центральному репозитарию:

Как Вы уже заметили, копирование производится силами SVN, а не операционной системы. Таким образом мы избавляемся от необходимости использовать команду add после копирования.

Обновления плагина

Для обновлений плагина я использую Tortoise SVN. Это очень просто. Нужно скопировать изменённые файлы плагина (можно все, Tortise SVN сам разберётся “что к чему”) в папку trunk локальной копии репозитария.

Затем, с помощью меню Tortoise SVN произвести необходимые действия – добавить новые файлы, фиксировать файлы и т.д и т.п.

P.S.

Надеюсь Вы догадались, что я использую в командах multilingual-comments-number исключительно ради примера, Вы должны использовать имя своего плагина.

© 2012, minimus. Все права защищены. При копировании и републикации статьи, ссылка на первоисточник обязательна.

Похожие статьи:

1. Анатомия плагина WordPress. Введение.
2. Анатомия плагина WordPress. Часть 2.
3. Анатомия плагина WordPress. Часть 3

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

Концепция плагина состоит в том, что все субъекты рекламных кампаний описаны как объекты, имеющие набор собственных параметров и методов. Это четыре базовых объекта плагина:

• Объект “Рекламное объявление” (ad) – объект хранящий основные параметры рекламного объявления и логику вывода его на страницы блога
• Объект “Рекламное место” (Ads Place) – ротатор рекламных объявлений, так же являющийся контейнером для объектов “рекламное объявление”, связанных правилами ротации
• Объект “Рекламная зона” (Ads Zone) – селектор объектов “Рекламное место”. Расширяет логику ротации.
• Объект “Рекламный блок” (Ads Block) – бъект осуществляющий вывод на страницу блока объявлений.

Объект “Рекламное объявление”

Ad

Объект “Рекламное объявление” является очень важным, но несамостоятельным объектом. Он содержит основные параметры объявления (код объявления, ссылки), параметры ротации, параметры логики ограничения показа на страницах сайта, финансовые параметры. Теоретически, и это даже реализовано в плагине, объект “Рекламное объявление” может производить вывод своего содержимого на страницу, но это, по большому счёту, не имеет смысла, т.к. при этом логика показа становится не нужна. Тем не менее, если Вам понадобится произвести принудительный вывод какого-либо рекламного объявления на страницу, у Вас есть такая возможность.

Объект “Рекламное место”

Ads Place

Объект “Рекламное место” является ротатором рекламных объявлений. Концептуально объект “Рекламное место” должен воплощать собой физическое размещениние ротируемых рекламных объявлений на страницах сайта. Кроме того, каждый объект “Рекламное место” является контейнером объектов “Рекламное объявление”. Являясь ротатором, этот объект обеспечивает вывод на текущую страницу одного объявления в соответствии с заданными “весами” объявлений и логикой ограничения показа, заданной для каждого объявления соответствующим объектом “Рекламное объявление”. В том случае, когда логика ограничений не позволяет вывести на страницу ни одного объявления, ротатор выводит на страницу объявление-заглушку.

Для демонстрации логики ограничений показа приведу несколько примеров:
Например, у меня есть три категории в блоге – Новости, Новости спорта и Новости церкви. Я создал одно Рекламное место “Header”.

Пример 1:

Это “Рекламное место” содержит три объявления. Заглушка настроена.

Рекламное объявление (ID1) настроено как “Показать объявления только на страницах данного типа”: Страница статьи, Страницы архивов рубрик; “Показывать объявление только в одиночных статьях и архивах заданных рубрик”: Новости.
Рекламные объявления (ID2 и ID3) настроены как “Показать объявления только на страницах данного типа”: Страницы статьи, Страницы архивов рубрик; “Показывать объявление только в одиночных статьях и архивах заданных рубрик”: Новости спорта.

Результат:

Рекламное объявление (ID1) будет отображаться только на страницах статей и страницах архива рубрики Новости. Только это объявление будет показано на этих страницах.
Объявления (ID2 и ID3) будут ротироваться только на страницах статей и страницах архивов рубрики Новости спорта. Только эти объявления будут показываться на этих страницах.
Объявление-заглушка будет показываться на всех остальных страницах.

Пример 2:

Это “Рекламное место” содержит три объявления. Заглушка не настроена.

Рекламное объявление (ID1) настроено как “Показать объявления только на страницах данного типа”: Страницы статьи, Страницы архивов рубрик; “Показывать объявление только в одиночных статьях и архивах заданных рубрик”: Новости.
Рекламные объявления (ID2 и ID3) настроены как “Показать объявления только на страницах данного типа»: Страницы статьи, Страницы архивов рубрик; “Показывать объявление только в одиночных статьях и архивах заданных рубрик”: Новости спорта.

Результат:

Рекламное объявление (ID1) будет отображаться только на страницах статей и страницах архива рубрики Новости. Только это объявление будет показано на этих страницах.
Объявления (ID2 и ID3) будут ротироваться только на страницах статей и страницах архивов рубрики Новости спорта. Только эти объявления будут показываться на этих страницах.
На всех остальных страницах ничего не будет показываться.

Пример 3:

Это “Рекламное место” содержит пять объявлений. Заглушка настроена.

Объявление (ID1) настроено как “Показать объявления только на страницах данного типа”: Страницы статьи, Страницы архивов рубрик; “Показывать объявление только в одиночных статьях и архивах заданных рубрик”: Новости.
Объявления (ID2 и ID3) настроены как “Показать объявления только на страницах данного типа”: Страницы статьи, Страницы архивов рубрик; “Показывать объявление только в одиночных статьях и архивах заданных рубрик”: Новости спорта.
Объявления (ID4 и ID5) настроены как “Показывать объявление на всех страницах блога”.

Результат:

Рекламное объявление (ID1) будет отображаться только на страницах статей и страницах архива рубрики Новости. Не только это объявление будет показываться на этой странице (см. ниже).
Объявления (ID2 и ID3) будут ротироваться только на страницах статей и страницах архивов рубрики Новости спорта. Не только эти объявления будут показываться на этой странице (см. ниже).
Объявления (ID4 и ID5) будут ротироваться на всех остальных страницах, как объявления по-умолчанию. Кроме того, эти объявления будут участвовать в ротации на страницах категории Новости и Новости спорта вместе с соответствующими объявлениями.
Заглушка не будет показана никогда ни на каких страницах.

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

Объект “Рекламная зона”

Ads Zone

Объект “Рекламная зона” является селектором объектов “Рекламное место”. Этот объект разработан для улучшения реализации логики показа объявлений на сайтах показывающих большое количество рекламных объявлений. Согласитесь, сложно отследить логику показа для сотни, а то и нескольких сотен объявлений, содержащихся в одном рекламном месте. Значительно проще разбить эти объявления на группы по определённым критериям, например по рубрикам показа, разместить в соответствующих объектах “Рекламное место” и, в зависимости от рубрики страницы, запускать необходимое “Рекламное место” для вывода рекламных объявлений.

Объект “Рекламная зона” может пригодиться и при отсутствии большого количества рекламных объявлений.

Рассмотрим на примере:

У меня есть три категории в блоге – Новости, Новости спорта и Новости церкви. Я создал три объекта “Рекламное место” – “Header”, “Header (Church)” и “Header (Single Post)”. Так как я не хочу, чтобы читатели религиозных новостей видели рекламу вина, сигарет и т.д., я поместил все объявления, не предназначенные для религиозных пользователей, в объект “Рекламное место” “Header”, а рекламу с религиозным содержанием в объект “Рекламное место” “Header (Church) “. Я поместил все доступные рекламные объявления в объект “Рекламное место” “Header (Single Post)». Для объявлений религиозного содержания я установил параметр “Показывать объявление только в одиночных статьях и архивах заданных рубрик”: Новости церкви, для других – “Не показывать объявление в одиночных статьях и архивах заданных рубрик”: Новости церкви.

Затем я создал один объект “Рекламная зона” под названием “Header” и установил для этого объекта Рекламное место “Header” как Рекламное место по-умолчанию. Для рубрики “Новости церкви” я назначил рекламное место  “Header (Church)”. Для одиночных статей я назначил рекламное место “Header (Single Post)”.

Результат:

Религиозные пользователей (читатели рубрики Новости Церкви) увидят объявления только религиозного содержания, все остальные читатели – другие объявления.

Объект “Рекламный блок”

Честно говоря, ничего концептуально особенного в этом объекте нет. Просто выводит рекламу блоками, вот и всё. Админ блога может назначить размер блока рекламы (количество строк и столбцов в сетке блока). В качестве объекта сетки (любого) можно задавать как объекты “Рекламное место”, так и объекты “Рекламная зона”. Впрочем, объекты “Рекламное объявление” тоже могут учавствовать в этом процессе, но я не рекомендую. Если Вы имеете всего пару объявлений, есть множество других плагинов, более лёгких, как по пониманию процессов, так и по количеству кодов.

Вся логика показов объектов “Рекламное место” и “Рекламная зона” при использовании в объекте “Рекламный блок” сохраняется. Другими словами, объект “Рекламный блок” просто группирует объекты в одном физическом месте блога.

P.S.

Вот собственно всё, что я хотел сказать. Может что-то упустил. Если по-прежнему что-то не понятно, не стесняйтесь – спрашивайте в комментариях или на форуме поддержки.

© 2012, minimus. Все права защищены. При копировании и републикации статьи, ссылка на первоисточник обязательна.

Похожие статьи:

1. WordPress плагин Simple Ads Manager
2. Simple Ads Manager. Дорожная карта
3. Эффективное управление рекламой в WordPress-блогах

В качестве первого кандидата на переход в новую категорию кодов для Blogger я решил выбрать свой первый виджет, написанный для Blogger-платформы, b-cumulus. Поскольку популярность этого виджета по-прежнему высока, а сложнось установки всё так же пугает новичков, выбор кандидата становится очевидным.

Для тех кто не в курсе, что такое b-cumulus, напоминаю. b-cumulus – это анимированное облако тегов (меток) на базе флеш-облака, разработанного Роем Танком (Roy Tanck).

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

1. Быстрая установка в “два клика”
2. Удобная настройка гаджета непосредственно в интерфейсе Blogger с возможностью предварительного просмотра полученного результата.
3. Отсутствие возни с размещением необходимых для работы гаджета файлов на сторонних ресурсах – все необходимые файлы расположены на серверах Google, рекомендованных самим Google для подобных целей.
4. Локализация гаджета – гаджет может быть локализован для любого языка (панель настроек)

Установка

Заидите в панель управления Вашего блога, страница “Дизайн”. Выберите сайдбар, в котором Вы хотите разместить облако меток (тегов). Нажмите на линк “Добавить гаджет”:

В открывшемся окне “Добавить гаджет” перейдите на вкладку “Добавьте свой собственный”:

На вкладке “Добавьте свой собственный” введите URL гаджета и нажмите на кнпку “Добавить по URL”.

URL ГАДЖЕТА: http://b-cumulus.googlecode.com/svn/tags/3.0/b-cumulus.xml – скопируйте этот URL и вставьте в поле для URL гаджета:

Если всё пойдёт нормально, гаджет загрузится и появится окно настроек гаджета:

Настройки

• Название – заголовок гаджета.
• Высота – высота гаджета.
• Высота облака – высота облака в пикселях, не путайте с высотой гаджета – для некоторых шаблонов это могут быть разные вещи.
• Ширина облака – ширина облака меток в пикселях. Если Вы не знаете какова ширина сайдбара Вашего шаблона, настраивайте методом подбора.
• Минимальный размер шрифта – минимальный размер шрифта метки, т.е. размер шрифта метки с минимальным весом
• Максимальный размер шрифта – максимальный размер шрифта метки, т.е. размер шрифта метки с максимальным весом
• Цвет меток с минимальным весом – цвет метки с самым малым “весом”
• Цвет меток с максимальным весом – цвет метки с самым высоким “весом”. Для остальных меток будет выбран цвет на линейке между этими двумя цветами.
• Цвет подсвеченных меток – цвет метки под курсором мыши, при наведении курсора на метку
• Скорость вращения – скорость вращения облака
• Цвет фона – цвет фона облака меток.
• Прозрачный фон – устанавливает прозрачный фон облака меток.
• Показывать вес меток – показывать “вес” метки, при наведении на неё курсора мыши.

Как видите, ничего сложного, скорее наоборот … Пользуйтесь!

© 2012, minimus. Все права защищены. При копировании и републикации статьи, ссылка на первоисточник обязательна.

Похожие статьи:

1. b-cumulus – анимированное Облако тегов для Blogger
2. Blogumus – анимированный виджет Облако тегов для Blogger
3. WordPress плагин wp-cumulus

Плагин полностью настраиваемый. С помощью пользовательских параметров плагина можно настроить цвет шрифта, цвета и вектор направления градиента фона, цвета и/или темы подсказок, иконки для FeedBurner и Twitter, как для бейджика, так и для подсказок, позиционирование бейджика на экране браузера и т.д. и т.п.

Новое в версии 2.0

1. Подсказки используют jQuery плагин qTip2 (в первой версии использовался qTip1)
2. Настройка тем подсказок (в первой версии настройки отсутствовали)
3. Настройка темы бейджика (стандартная, win7)
4. Настройка цвета окантовки (только для стандартной темы)
5. Настройка цвета шрифта
6. Поддержка IE7 и IE8 (рисуется с помощью VML)
7. ВСЁ рисуется с помощью canvas (современные браузеры) или VML (старички IE7, IE8)

Установка

Код устанавливается одним куском, непосредственно перед закрывающим тегом секции head (см. ниже):

Код показанный ниже вставляйте в районе выделенной строки показанной в вышепреведённом коде.

Минимальные изменения в коде, которые необходимо сделать перед вставкой в шаблон:

1. Если Ваш шаблон или вставленные Вами коды используют jQuery, удалите первые две строки (выделены в коде). Если Вы не поняли предыдущую фразу, ничего менять не надо – оставьте как есть.
2. Обязательно измените ID Feedburner и Twitter на свои (строки 33 и 41, выделены в коде), в противном случае будут показываться мои данные!

Настройка параметров

Параметры, задаваемые пользователем (scOptions):

• position – right или left, вывод бейджика справа или слева в окне браузера.
• delta – цифровое значение в пикселах. Отрицательное значение – смещение бейджика вверх относительно средней линии экрана браузера, положительное – вниз на заданное количество пиксел.
• dgv – направление вектора градиента фона. horizontal – справа налево, vertical – сверху вниз.
• color – начальный цвет градиента фона. Шесть шестнадцатиричных цифр (‘#1c82d0′).
• colorTo – конечный цвет градиента фона. Шесть шестнадцатиричных цифр (‘#145181′).
• borderColor – Цвет полупрозрачной (40%) окантовки бейджика. Шесть шестнадцатиричных цифр (‘#676767′).
• borderStyle – Стиль окантовки бейджика. Строковая переменная: “default” или “win7″.
• fontColor – цвет шрифта бейджика (“#ffffff”).
• hints – не трогайте этот параметр – “уши” WordPress плагина (“themed”).
• plurals – Формула задающая правила обработки форм множественного числа. По-умолчанию задана формула для русского языка (“(n%10==1 && n%100!=11 ? 0 : n%10>=2 && n%10<=4 && (n%100<10 || n%100>=20) ? 1 : 2)”), для английского будет выглядеть так: “(n != 1)”. Все формулы для различных язаков можно найти на сайте sourceforge.net.
• hintStyle – стиль подсказки. По-умолчанию “ui-tooltip-custom”. Может быть: ui-tooltip-custom, ui-tooltip-plain, ui-tooltip-light, ui-tooltip-dark, ui-tooltip-red, ui-tooltip-green, ui-tooltip-blue.

FeedBurner:

• id – Ваш ID на FeedBurner
• imgUrl – URL изображения для области FeedBurner бейджика. 50х50 пиксел, прозрачный фон, PNG. Даже если изображение будет отличаться по размеру, оно будет трансформировано (50х50)
• hint – Текст или HTML-текст для подсказки FeedBurner
• hintImg – URL изображения для подсказки FeedBurner. 40х40 пиксел, прозрачный фон, PNG.
• str – массив строк для вывода в соответствии с требуемой формой множественного числа. Для русского языка состоит из трёх элементов (["читатель", "читателя", "читателей"]).

Twitter:

• id – Ваш ID на Twitter
• imgUrl – URL изображения для области Twitter бейджика. 50х50 пиксел, прозрачный фон, PNG. Даже если изображение будет отличаться по размеру, оно будет трансформировано (50х50)
• hint – Текст или HTML-текст для подсказки Twitter
• hintImg – URL изображения для подсказки Twitter. 40х40 пиксел, прозрачный фон, PNG.
• useAvatar – логическая переменная, если true – использовать в качестве изображения для подсказки аватар из аккаунта Twitter, в противном случае (false) – использовать изображение заданное в переменной hintImg.
• str – массив строк для вывода в соответствии с требуемой формой множественного числа. Для русского языка состоит из трёх элементов (["спутник", "спутника", "спутников"])

 Скачать

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

Вы так же можете скачать плагин с сайта Google Codes.

© 2012, minimus. Все права защищены. При копировании и републикации статьи, ссылка на первоисточник обязательна.

Похожие статьи:

1. Blogger-плагин Simple Counters
2. WordPress плагин Simple Counters
3. Simple Counters. ЧАВО!

Итак! Представляю довольно свежий плагин подсветки синтаксиса кода написанный Арамом Кочеряном (Aram Kocharyan) Crayon Syntax Highlighter.

Возможности

Плагин написан на PHP и, в отличии от других подобных плагинов, весьма “лёгок” и быстр.

На сегодняшний день плагин понимает 14 языков программирования и имеет возможности для увеличения числа оных как силами самого Арама, так и силами сторонних программистов. Для этого необходимо добавить соответствующий файл описания синтаксиса языка на базе прилагаемого шаблона и поместить его в папку langs – плагин сам его обнаружит и добавит в перечень распознаваемых языков. Очень радует то, что это единственный плагин, из известных мне плагинов, который правильно интерпретирует смешанные языки (например HTML в PHP или Javascript в HTML).

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

Подсветка кода задаётся тегами коротких кодов crayon, с указанием языка программирования или тегами коротких кодов соответствующего языка (например php). Кроме того!!! Текст кода может быть взят из файла расположенного на сервере. Меня уже достало то, что частенько при обновлении WordPress мои коды корёжатся или вовсе исчезают. Грузить коды из файлов – отличный выход из этой неприятной ситуации.

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

Локализация

Плагин русифицирован и это заслуга Вашего покорного слуги. К сожалению автор плагина изменил мои файлы локализации и кое-что пошло не так. Видимо Арам не в курсе количества plurals (форм множественного числа) в русском языке и тем более не в курсе правил определения этих самых plurals. Кроме того, оригинал плагина предполагает локализацию только административной части плагина, локализация кнопок блока подсвеченного кода не предусмотрена (пока). Для тех кого такое положение дел с локализацией этого замечательного плагина не устраивает, предлагаю скачать либо мои оригинальные файлы локализации плагина (положить в папку trans), либо модифицированный плагин с локализацией Face View (страницы пользовательского просмотра).

Модификация небольшая, нет нужды скачивать весь модифицированный плагин – Вы сами можете внести изменения в свою копию плагина. Достаточно внести несколько (5) изменений в файл crayon_formatter.class.php.

Модификация (модифицированные строки выделены):

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

Удачи!

© 2012, minimus. Все права защищены. При копировании и републикации статьи, ссылка на первоисточник обязательна.

Похожие статьи:

1. Подсветка кодов в блоге. Часть первая.
2. Подсветка кодов в блоге. Часть вторая.
3. Карусель в блоге. Часть 2.

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

Одна страница параметров

Поскольку в качестве материала для примеров написания кодов в этой статье я использую свой плагин Multilingual Comments Number, рассмотрим как админ-страница реализована именно в этом плагине.

Классический метод

Если Вы помните, функция onAdminPage была заявлена в конструкторе как action для вызова административной страницы:

Сама функция вывода страницы выглядит так:

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

Современный метод

Начиня с WordPress версии 2.9 появилась возможность использовать Settings API, что позволяет разработчику более гибко обращаться с параметрами плагина.

В последней версии Multilingual Comments Number я использовал именно этот метод.

Объявляем и регистрируеем параметры плагина:

В конструкторе класса плагина добавляем action регистрации параметров:

Пишем функцию для регистрации параметров плагина, в которой используются три функции из Settings API:

1. add_settings_section – объявляет секцию параметров для их компактного отображения. Все параметры объявленные в секции будут сгруппированы в пределах этой секции. Как именно будет прорисована секция можно определить в callback-функции.
2. add_settings_field – объявляет параметр, т.е. заявляет о его существовании и, с помощью callback-функции, определяет способ отображения.
3. register_setting – регистрирует ранее объявленный параметр, т.е. заявляет о необходимости сохранения значения параметра в таблицу параметров WordPress. Так же объявляет функцию проверки введённого параметра, если это необходимо.

Как видите, в данном случае, параметры плагина будут размещены не на отдельной странице, а на странице параметров WordPress “Обсуждение”, что для этого плагина вполне логично. Для этого я задал параметр page как “discussion“, если бы я захотел иметь отдельную страницу параметров, я задал бы что-нибудь вроде “mcn-settings” …

Теперь опишем callback-функции для секции и параметров:

На сегодняшний день, callback секции может выводить только описание секции …

Как видно из кодов приведённых выше, callback-функции параметров задают внешний вид вывода как самого параметра так и его описания.

Функция проверки параметра довольно проста – в качестве входящего значения передаётся введённый параметр, с ним можносделать всё, что душе угодно:

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

Регистрируется страница также как и в “классическом” способе:

Строится такая страница с использованием встроенных методов settings_fields и do_settings_sections:

settings_fields – выводит скрытые поля необходимые для обслуживания страниц параметров.

do_settings_sections – прорисовывает секции и поля параметров, объявленные в коде плагина. К сожалению, вывод данных с помощью этой функции довольно примитивен. Кроме того, не позволяет использовать универсальные call-back функции для однотипных параметров – приходится использовать для каждого параметра свою call-back функцию, что является растранжириванием ресурсов. Как улучшить ситуацию мы рассмотрим в одной из следующих статей, в самое ближайшее время.

Несколько страниц параметров

Серьёзные по объёму плагины часто требуют нескольких страниц параметров, например

• собственно параметры
• параметры элементов хранимых в базе данных
• редактор элементов хранимых в базе данных

Это, по большому счёту, классическая схема. Плагины имеющие огромное количество параметров, не умещающихся на одной странице, обычно используют разбиение параметров не по страницам, а по вкладкам. Разумеется, истина, как всегда, находится где-то посередине, поэтому комбинированный метод отображения параметров (страницы + вкладки) наиболее распространён. Пример: мой плагин Simple View.

Начальные действия идентичны как для классического так и для современного методов.

Так же как и при одностраничном варианте добавляется action в конструктор:

затем описываем добавляемые страницы (пример из плагина Simple View):

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

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

Продолжение следует …

© 2012, minimus. Все права защищены. При копировании и републикации статьи, ссылка на первоисточник обязательна.

Похожие статьи:

1. Анатомия плагина WordPress. Часть 2.
2. Анатомия плагина WordPress. Часть 1.
3. Анатомия плагина WordPress. Заключение

Обновление прошло в два этапа (версии 1.0.15 и 1.1.17). На первом этапе очистил код от мусора, т.е. систематизировал и оптимизировал его. Так же добавил локализацию слов “readers” и “followers” в бейджике. Однако, судя по проведённому опросу, не всем понравилось это нововведение. Поэтому, на втором этапе, я добавил возможность отключения локализации этих двух слов, а так же добавил возможность изменения локализации этих слов с помощью фильтров WordPress, поскольку опрос показал, что разные блоггеры переводят эти слова по разному.

Почему, всё же, фильтры, а не параметры? Дело в том, что в различных языках существует разное количество форм множественного числа и разные правила их использования. Например в английском языке есть только одна форма множественного числа (один и много), а в чешском – две, такие же как и в русском (один, 2..4, много), но в отличие от русского языка, форма 2..4 применяется только в первом десятке. Как видите, учесть всё это разнообразие очень сложно и если попытаться запихнуть всё это в параметры, код плагина необоснованно раздуется до невероятных размеров. А при использовании фильтров, программист сам запрограммирует количество форм множественного числа для своего языка и правила их использования.

Фильтры Simple Counters

Для собственной локализации слов “readers” и “followers” Вы можете использовать фильтры плагина “simple_counters_localization_feedburner” и “simple_counters_localization_twitter“. Для того чтобы их использовать, необходимо добавить в файл functions.php шаблона темы следующий код:

или такой:

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

Для программистов … Каждый фильтр получает две переменные. Первая (string) – нефильтрованное выражение передаваемое в параметры. Второе (integer) – количество подписчиков или фолловеров, в зависимости от фильтра.

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

© 2011, minimus. Все права защищены. При копировании и републикации статьи, ссылка на первоисточник обязательна.

Похожие статьи:

1. WordPress плагин Simple Counters
2. Simple Counters. ЧАВО!
3. Simple Counters. Опрос