Недавно я решил более плотно посмотреть, как пишутся плагины для WordPress, и реализовать пару интересных, с моей точки зрения, идей, при чем не только для себя, но и для широкой публики. Раньше я преимущественно обходился правками functions.php в папке с моим шаблоном. А бывало, и кстати нередко, правками непосредственно в шаблоне. Поставив для себя задачу — сделать плагин максимально совместимым, я столкнулся с одной проблемой, о которой и хочу рассказать ниже.
Тему всей записи, на самом деле, можно сформулировать в двух вопросах. Обрабатывать существующие, стандартные для WP функции, либо создавать свои? И, если выбрана обработка существующих функций, то как быть с совместимостью с иными плагинами? Далее я предлагаю на эти, в общем-то, важные вопросы свои ответы. Если у вас есть свои — буду рад прочитать их в комментариях.
Если на первый вопрос я ответил очевидным образом, то со вторым — не всё так просто. И именно поэтому я до сих пор не выложил плагин, который уже работает на моём блоге (речьпро Твиттер-ники в комментариях, да), и который, благодаря моим фолловерам и нескольким читателям, уже имеет версию 1.02, пройдя путь в 12 серьёзных правок.
Но давайте по порядку. Сначала мне хотелось бы пояснить, отчего я решил обрабатывать существующую в WP функцию, а не использовать свою. Всё оттого, что подавляющему большинству пользователей WP, из числа обычных блоггеров, задача поменять одну строчку в шаблоне может показаться невыполнимой. И в этом нет ничего зазорного или обидного, это совершено нормально, тем более что разработчики WP делают многое, чтобы это не было камнем преткновения. Однако, на данный момент, ситуация такова, что плагины с простым функционалом пользуются большей популярностью, если их установка понятна и не требует особых усилий. Потому моё решение делать плагин максимально простым в установке (из административной панели закинул архив, нажал кнопку «активировать» и всё) — вполне логично.
А вот на второй вопрос ответить сложнее. Дело в том, что многие плагины, ровно как и мой шедевр, написаны на коленке, и потому они довольно часто конфликтуют друг с другом, тем более, если идёт обработка одной и той же функции. WP пока не научился, как следует разбираться с подобными конфликтами интересов двух плагинов. В итоге, как минимум, один из плагинов попросту перестаёт работать. Он не выключается, но перестаёт делать то, что должен. Как максимум — может поехать вёрстка, что пугает пользователей, для которых код шаблона — тёмный лес. Об ошибках на странице и о выводе ошибок вообще, всё-таки умолчу, так как подразумевается, что все ошибки, так или иначе, обрабатываются авторами, в своих плагинах. В том числе, и с помощью самого WP.
В итоге, потратив около полутора недель на расспросы своих друзей, читателей блога и фолловеров в Твиттере, я пришёл к мнению, что решение проблемы, сформулированной во втором вопросе, стоит переложить на плечи пользователя. При этом всё-таки сделав плагин максимально дружественным по отношению к другим плагинам, которые пользователь установил себе — даже если его блог обвешан ими как новогодняя ёлка. Самый яркий пример: это наличие двух антивирусов в системе. Это два серьёзных программных продукта, которые делают ровно одно и то же дело и, в конечном счёте, начинают конфликтовать между собой. С плагинами дело, конечно же, обстоит не так радикально и остро, но общий смысл примерно такой же.
К каждому своему плагину я буду прикладывать русскоязычный readme.txt (англоязычный всё равно надо будет вкладывать, таковы требования сообщества WP, если вы решитесь, рано или поздно, выложить плагин на wordpress.org), в котором буду сообщать о том, что как только пользователь включил плагин — необходимо в ту же минуту посмотреть, как он работает. Это помимо всей необходимой информации, например, о том, как установить, историю изменений и прочее. Вы удивитесь, какое количество людей включает по дюжине плагинов за раз, а потом, естественно, не знает, что с чем конфликтует.
Это я сейчас говорю про рядовых блоггеров, а не про профессионалов, которые ставят блоги по несколько раз на дню, и отлично знают пакет плагинов, которые уже притёрты друг к другу максимально плотно, и потому не мешают работе друг друга. Я, кстати, даже некоторые версии плагинов обновлять перестал, только потому, что обновлённая версия плагина начинает с чем-нибудь конфликтовать. Но не об этом речь.
К слову сказать, авторы многих плагинов, которые не правят существующий вывод стандартных функций WP, стараются сделать установку своего функционала максимально простой. Для этих целей используются, и довольно часто, shortcut’ы. Лишь редко, когда возможности использовать шоткаты нет (старые темы, нестандартные места вывода контента на странице и т.п.), приходится просить пользователя править код его шаблона. Если есть возможность, но автор не упростил установку плагина, то я считаю его недальновидным.
Ещё стоит отметить то, что эта запись касается тех плагинов, которые модифицируют, так или иначе, стандартный вывод WP. Если ваш плагин несёт в себе функционал, который в WP не заложен вовсе, то необходимо просто соблюдать осторожность в назывании функций (читайте документацию на wordpress.org). А если ваш плагин дополняет вывод стандартной функции (например вывод сразу после content();) — потрудитесь основательно проверить, как это выглядит на обвешанном плагинами блоге.