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

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

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

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

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

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

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

С другой стороны, есть ошибка — летать на экране плагина (70 «активных установок). Он случайным образом имитирует муху на экране. Это на самом деле не решить проблему, так что он не будет иметь огромную аудиторию. Это был забавный плагин для разработки, однако.

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

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

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

2. Поддержка вашего продукта

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

— Никки Егер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 scaffold-test, которая устанавливает всю необходимую конфигурацию.

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

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

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

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

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

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

Заключение

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

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