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

wordpress создание плагина

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

Тогда как темы меняют внешний облик вашего вебсайта, плагины меняют его функционирование. С помощью плагинов вы можете создать пользовательские типы почты, добавить в базу данных новые таблицы для отслеживания популярных статей, автоматически соединять папку с содержимым с сервером "CDN", таким, как Amazon S3… в общем, вы понимаете.

wordpress создание плагина

Тема или плагин WordPress?

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

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

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

Основы создания плагина на WordPress

Все, что понадобится при создании плагина WordPress – это папка и отдельный файл с одной строкой контента. Перейдите в wp-content/plugins и создайте новую папку с названием awesomeplugin. Внутри нее сделайте файл с названием awesomeplugin.php. Откройте его в текстовом редакторе и вставьте внутрь следующую информацию:

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

Проделав это, можно перейти на серверную сторону для активации своего плагина. Вот, собственно, и все! Конечно, он ничего не делает; но, строго говоря, это активный, функционирующий плагин.

Структурируем плагины

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

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

В основном, стремитесь к балансу между структурой разметки, простотой использования и минимализмом. Разделите свой плагин на необходимое количество файлов, но не переборщите. Я обнаружил, что полезно ориентироваться на структуру популярных плагинов, таких как WP-PageNavi и Akismet.

Название плагина и его функции

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

Самое простое решение – применять уникальные префиксы. Например, можно использовать "acme_excerpt,", или что-то другое с низкими шансами совпадения с чьей-то чужой схемой именования.

Безопасность плагина

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

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

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

Убираем за собой

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

WordPress предлагает три отличных ловушки, чтобы помочь вам справиться с этим:

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

register_deactivation_hook()
Название говорит за себя. Эта функция работает, как и ее вышеприведенный коллега, но запускается всякий раз, когда ваш плагин деактивируется. Я предлагаю применять следующую функцию при удалении данных; используйте эту только для общего поддержания порядка в хозяйстве.

register_uninstall_hook()
Эта функция запускается, когда администратор вебсайта удаляет ваш плагин на серверной стороне WordPress’а. Это отличный способ удалять валяющиеся вокруг данные, такие, как таблицы базы данных, установки и тому подобное. A недостаток метода заключается в том, что плагину нужна возможность запускать ее для работы; так, если ваш плагин не может таким способом делать деинсталляцию, то можно создать файл uninstall.php. Для получения дополнительной информации прочтите документацию к этой функции.

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

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

Документация и стандарты кодирования

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

Я, помимо прочего, документирую код для самого себя, потому что едва помню то, что делал вчера, и еще меньше – назначение функций, которые писал несколько месяцев назад. Документируя код, вы вырабатываете у себя хорошие привычки. А если начинаете работать в команда или если ваш код становится популярным, то документация станет неизбежной частью вашей жизни, так что можете начинать уже сейчас.
Хотя и не настолько важные, как документация, следующие стандарты кодирования – отличная идея, если вы хотите, чтобы ваш код соблюдал инструкции к WordPress.

Применяем на практике

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

Планирование наперед

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

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

Функцию, которая дает нам возможность возвращать примерное количество просмотров,

Функцию, которая дает нам возможность показывать количество просмотров пользователю,

Функцию, которая возвращает список постов, основанный на подсчете их просмотров.

Подготовка нашей функции

Первым шагом будет создание папки и файловой структуры. Хорошо бы сложить их все в один файл, так что давайте перейдем к папке plugins и создадим новую папку с названием awesomely_popular. В ней сделайте файл с названием awesomely_popular.php. Откройте его и вставьте вверху немного метаданных, вроде этого:

Запись просмотров поста

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

Как видно, я добавил в начало функции документацию в стиле phpDocumentor, и так довольно хорошо видно, чего можно ожидать от этого правила. Сначала, применяя условный тэг (conditional tag), мы определяем, смотрит ли пользователь пост на специально выделенной странице.

Если пользователь находится на выделенной странице, мы привлекаем объект $post, который содержит данные о показываемом посте (ID, название, дату поста, количество комментариев и т.д.). Затем возвращаем уже полученное количество просмотров. Добавим к нему 1, а затем перепишем исходное значение на новое. В случае, если что-то пойдет не так, сначала проверяем, таково ли текущее количество просмотров в действительности.

Нужно установить текущее количество просмотров; оно не может быть пустым. И оно должно быть цифровым для того, чтобы можно было добавить к нему 1. Если оно не соответствует этому критерию, то спокойно можно биться об заклад, что текущее количество просмотров равно 0. Далее мы добавляем к нему 1 и сохраняем в базе данных. Наконец возвращаем количество просмотров, полученных постом, вместе с этим последним числом.

Пока все идет хорошо. Но эта функция никогда не вызывается, так что в действительности не будет использоваться. Вот где в дело вступают ловушки. Вы могли бы зайти в свои файлы с темами и вызвать оттуда функцию вручную. Но затем потеряли бы эту функциональность, если бы сменили тему, проиграв таким образом весь замысел. Ловушка с названием wp_head, которая запускается прямо перед тэгом </head>, присутствует в большинстве тем, так что можно просто установить свою функцию на запуск каждый раз, когда запускается wp_head, как тут:

Вот и все, что касается "мистики" ловушек. Мы, в общем, когда запускается wp_head, также выполняем функцию awepop_add_view. Код можно разместить как впереди, так и позади самой функции.

Возврат и показ просмотров

В вышеприведенном я уже применяю функцию WordPress для возврата просмотров get_post_meta(), так что написание отдельной функции может показаться немного чрезмерным. В этом случае оно могло бы быть излишним, но так развивается объектно-ориентированное мышление, что дает нам бОльшую гибкость при дальнейшей разработке плагина. Давайте взглянем:

Это тот же отрывок кода, который мы применяли в функции awepop_add_view(), так что вы могли бы также просто использовать его для возврата подсчета просмотров. Это удобно, потому что если вы решите по-другому применить случай с 0, вам нужно будет тут только чуть-чуть изменить. Вы также сможете легко распространить его и обеспечить поддержку в случаях, когда мы не в цикле (т.е. когда объект $post недоступен).

Пока что мы только вернули количество просмотров. Теперь давайте их покажем. Вы, может быть, думаете, что это глупо — все, что нам нужно – это echo awepop_get_view_count() . "views", не так ли? Это, несомненно, сработает, но что, если там всего 1 просмотр. В таком случае нам понадобится применить единичный просмотр. Также вам могла бы понадобиться свобода при добавлении какого-нибудь ведущего текста или яркой детали, что иным способом было бы трудно сделать. Так что для учета этих сценариев давайте напишем другую простую функцию:

Показ списка постов на основе просмотров

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

Начинаем с передачи группы параметров классу WP_Query для того, чтобы создать новый объект, содержащий несколько постов. Этот класс будет проделывать для нас ответственную работу: он находит 10 опубликованных постов, в метатаблице которых содержится awepop_views, и выстраивает их в соответствии с этим свойством в порядке убывания.

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

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

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

Так гарантируется, что если плагин деактивируется (и, таким образом, функция становится неопределенной), PHP не будет показывать большую ошибку ol’ error. Он просто не станет показывать список наиболее популярных постов.

Заключение урока по созданию плагинов WordPress

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

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

На этом, урок по созданию плагинов для WordPress окончен, надеюсь вам понравилось!

Автор: Daniel Pataki

Источник: //wp.smashingmagazine.com/

Редакция: Рог Виктор и Андрей Бернацкий. Команда webformyself, обучение созданию сайтов с нуля.

Метки:

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

Комментарии Вконтакте:

Комментарии (22)