• 7 минут чтения

• WordPress, Плагины, Обслуживание

• Поделись ТвиттерЛинкедин

Обновления, которые я выпустил, преследовали несколько целей: от исправления ошибок до новых функций и исправлений в документации. Хотя обо всем этом приятно говорить, исправления ошибок — это те, из которых вы узнаете больше всего, поэтому давайте начнем с них.

Конфигурация веб-сайта и учетной записи

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

Возможность войти в несколько хостов людей, которые дали мне доступ к их серверной части а также FTP, чтобы я мог проверить свое исправление, оказался неоценимым. Это позволило мне выпустить 4.0.1 в течение часа после выпуска 4.0.

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

Большой вид

Хорошая практика №1: Не думай что-нибудь о сайтах людей и внешних аккаунтах.

Массивы опций управления версиями

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

Хорошая практика № 2: Добавьте номер версии в свои массивы опций.

Я до сих пор не использую API опций WordPress (ознакомьтесь с этим постом Ozh, чтобы узнать все об этом), что мне, вероятно, следует делать, но пока мне проще самому сохранять и проверять опции.

Не выпускайте слишком рано

Если у вас есть ошибка, которая беспокоит многих пользователей вашего плагина, вы, вероятно, захотите выпустить исправление ошибки как можно скорее. Я знаю, что. Однако это вызвало проблему с моим выпуском 4.0.3, потому что я не протестировал должным образом часть кода, который я представил, из-за чего мне пришлось выпустить 4.0.4 всего через два часа, чтобы исправить глупую ошибку, которую я сделал с булевы значения. Нет ничего более болезненного, чем 500 человек, загружающих версию вашего плагина, которая на самом деле не работает.

Хорошая практика №3: Тестируйте, тестируйте, тестируйте перед выпуском, даже если вы спешите.

Знайте, на какой версии работают люди

За последние две недели я помог нескольким людям, которые сказал они были в последней версии моего плагина, но на самом деле их не было. Чтобы исправить это, я начал выводить номер версии в комментарии, который плагин выводит перед кодом отслеживания. Проблема в том, что если люди запустят плагин, такой как W3 Total Cache (который, кстати, должен использовать каждый) или что-то еще, что минимизирует их вывод, этот комментарий будет потерян.

Для этого тоже есть решение: я уже завернул скрипт в <CDATA> теги, чтобы помочь с проверкой Strict XHTML. Минификация не будет происходить внутри этих тегов CDATA, поэтому я переместил свой «фирменный» комментарий в раздел CDATA, и теперь я всегда могу видеть, во-первых, что мой плагин активен, а во-вторых, какую версию плагина они используют.

Хорошая практика № 4: Убедитесь, что вы видите, какую версию вашего плагина используют люди.

URL-адреса в WordPress

Одна из таких вещей, которая может генерировать довольно ужасные ошибки, — это URL-адрес блога. Будь то из-за того, что люди ведут весь свой блог на https или «просто» запустить свой блог в подкаталоге, это может вызвать головную боль. У меня так было в версии 4.0.2, когда я добавил очистку URL-адресов: все относительные URL-адреса в сообщениях и текстовых виджетах, начинающиеся с / были сделаны абсолютными, чтобы правильно отслеживать эти URL-адреса. Небольшая проблема: я забыл о блогах в подкаталогах, поэтому крошечная часть людей попадала со ссылками, которые раньше вели на /home но это теперь пошло к https://example.com/blog/home. Я знаю, это было глупо; но именно поэтому я говорю вам: чтобы вы не сделали ту же ошибку.

Хорошая практика № 5: Убедитесь, что все URL-адреса, которые вы используете, будут работать в все обстоятельствах, независимо от того, находится ли WordPress в подкаталоге, на поддомене или просто в корне.

Запись в корневой каталог

Отчасти связан с последней проблемой, хотя я столкнулся с этим при разработке своего плагина SEO для WordPress, а не плагина Google Analytics: если вы записываете файл — скажем, файл карты сайта XML — в корень веб-сайта, а веб-сайт на самом деле при многосайтовой установке WordPress все может пойти совсем не так.

Проверьте следующий сценарий:

1. Пользователь 1 пишет и публикует сообщение на example.com/blog-1/.
2. Обновленная XML-карта сайта для example.com/blog-1/ генерируется, и example.com/sitemap.xml обновляется.
3. Пользователь 2 пишет и публикует пост на example.com/blog-2/.
4. Обновленная XML-карта сайта для example.com/blog-2/ генерируется и example.com/sitemap.xml перезаписывается.

Видишь, что только что произошло? XML-карта сайта теперь содержит только записи из blog-2… Именно поэтому wp-контент директория создана. Вряд ли когда-либо потребуется помещать файл в корень установки, и, не делая этого, вы значительно упрощаете запуск своего плагина в среде с несколькими сайтами/WordPress MU.

Хорошая практика № 6: Если вы создаете файлы, создавайте их в wp-контент каталог вашего блога. Делать нет записывать файлы в корневой каталог, если вам это абсолютно необходимо. И если вам нужно это сделать, убедитесь, что ваш плагин активен в нескольких блогах на одном и том же экземпляре с несколькими сайтами.

Переосмыслите свои фильтры

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

Большой вид

Хорошая практика № 7: Если вы фильтруете контент, постарайтесь фильтровать его в как можно большем количестве мест, чтобы пользователи получали согласованные результаты во всем WordPress.

Никогда не предполагай

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

Дальнейшее чтение на SmashingMag:

• Основы WordPress: как создать плагин WordPress
• Как развернуть плагины WordPress с помощью GitHub с помощью Transients
• Как использовать автозагрузку и контейнер плагинов в плагинах WordPress
• Как разработчики коммерческих плагинов используют репозиторий WordPress

(аль)