Уроки, извлеченные при разработке плагинов WordPress

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

В этой статье я поделюсь своим пятилетним опытом разработки плагинов для WordPress. Первый плагин, который я написал, был простым маркетинговым плагином. Он отображал кнопку призыва к действию (CTA) с поисковой фразой Google. С тех пор я написал еще 11 бесплатных плагинов и поддерживаю почти все из них. Я написал около 40 плагинов для своих клиентов, от очень маленьких до тех, которые поддерживаются уже более года.

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

1. Решить проблему

Если ваш плагин не решает проблему, он не будет загружен. Это так просто.

Возьмите плагин Advanced Cron Manager (более 8000 активных установок). Это помогает пользователям WordPress, которым трудно отлаживать свой cron. Плагин был написан из нужды — мне нужно было чем-то себе помочь. Мне не нужно было продвигать этот продукт, потому что он уже был нужен людям. Это почесало их зуд.

С другой стороны, есть Баг — плагин fly on the screen (70+ активных установок). Он случайным образом имитирует муху на экране. На самом деле это не решает проблему, поэтому у него не будет огромной аудитории. Тем не менее, это был забавный плагин для разработки.

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

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

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

2. Поддержите свой продукт

«3 из 5 американцев попробовали бы новый бренд или компанию, чтобы получить лучший сервис. 7 из 10 сказали, что готовы тратить больше на компании, которые, по их мнению, предоставляют отличный сервис».

— Никки Йегер

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

Качественная поддержка имеет решающее значение для роста вашего плагина. Даже плагин с лучшим кодом получит несколько билетов в службу поддержки. Чем больше людей воспользуется вашим плагином, тем больше билетов вы получите. Лучшее взаимодействие с пользователем даст вам меньше билетов, но вы никогда не достигнете папки «Входящие 0».

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

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

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

Вот список некоторых действий, которые вы можете предпринять:

• Создайте раздел часто задаваемых вопросов в своем репозитории.
• Закрепите ветку «Прежде чем спросить» в верхней части форума поддержки, выделив советы по устранению неполадок и ответы на часто задаваемые вопросы.
• Убедитесь, что ваш плагин прост в использовании и что пользователи знают, что им следует делать после его установки. UX важен.
• Проанализируйте вопросы поддержки и устраните болевые точки. Создайте доску, где люди могут голосовать за функции, которые они хотят.
• Создайте видео, показывающее, как работает плагин, и добавьте его на главную страницу вашего плагина в репозиторий WordPress.org.

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

3. Не используйте композитор

Composer — это программа для управления пакетами. Репозиторий пакетов размещен на packagist.org, и вы можете легко загрузить их в свой проект. Это как NPM или Bower для PHP. Управление сторонними пакетами так, как это делает Composer, является хорошей практикой, но не используйте ее в своем проекте WordPress.

Я знаю, я сбросил бомбу. Позволь мне объяснить.

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

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

Проблема Composer с плагинами WordPress до сих пор не решена, и в ближайшем будущем не будет никакого жизнеспособного решения этой проблемы. Проблема была поднята много лет назад, и, как вы можете прочитать в статье WP Tavern, многие разработчики безуспешно пытаются ее решить.

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

4. Разумная поддержка старых версий PHP

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

Перейдите с PHP 5.6 в качестве минимального требования, хотя официальная поддержка будет прекращена к концу 2018 года. Сам WordPress требует PHP 7.2.

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

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

5. Сосредоточьтесь на качественном коде

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

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

Почему было так тяжело? Потому что вы начинаете писать код, который на первый взгляд кажется излишним и не очень интуитивным. Я постоянно спрашивал себя: «Это действительно нужно?» Например, вам нужно разделить логику на разные классы и убедиться, что каждый отвечает за одну вещь. Вы также должны разделить классы для перевода, регистрации пользовательских типов сообщений, управления активами, обработчиков форм и т. д. Затем вы составляете более крупные структуры из простых небольших объектов. Это называется внедрением зависимостей. Это очень отличается от классов «внешнего интерфейса» и «администрирования», где вы втискиваете весь свой код.

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

Выше приведены лишь несколько примеров, но вам следует ознакомиться с принципами SOLID. Они действительны для любой системы и любого языка кодирования.

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

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

6. Протестируйте свой плагин заранее

Я усвоил этот урок трудным путем. Отсутствие тестирования привело меня к выпуску новой версии плагина с фатальной ошибкой. Дважды. Оба раза я получил 1 звезду, которую не смог превратить в положительный отзыв.

Вы можете тестировать вручную или автоматически. Travis CI — это продукт для непрерывного тестирования, который интегрируется с GitHub. Я создал очень простой набор тестов для моего плагина уведомлений, который просто проверяет, может ли плагин правильно загружаться в каждой версии PHP. Таким образом, я могу быть уверен, что плагин не содержит ошибок, и мне не нужно уделять много внимания его тестированию в каждой среде.

Каждый автоматизированный тест занимает доли секунды. 100 автоматизированных тестов займут около 10 минут, тогда как ручное тестирование требует около 2 минут для каждого случая.

Чем больше времени вы потратите на предварительное тестирование своего плагина, тем больше он сэкономит вам в долгосрочной перспективе.

Чтобы начать автоматическое тестирование, вы можете использовать команду WP-CLI \\`wp scaffold plugin-test\\`, которая устанавливает всю необходимую вам конфигурацию.

7. Документируйте свою работу

Это клише, что разработчики не любят писать документацию. Это самая скучная часть процесса разработки, но немногого можно добиться.

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

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

Использование обоих методов сэкономит вам время на написание документации, но документацию по коду будут читать не все.

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

Заключение

Эти семь правил помогли мне разработать качественные продукты, которые становятся основным направлением деятельности BracketSpace. Я надеюсь, что они также помогут вам в вашем путешествии с плагинами WordPress.

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