Мои пять худших ошибок разработки WordPress

Или «Всем серверам, на которых я работал раньше: ужасный взгляд на пять худших ошибок WordPress, которые я совершил»

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

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

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

Когда я обновил взломанную версию ядра WordPress

Я только что перешел от малоизвестных программных проектов CraigsList к работе в реальном живом агентстве. Я приехал! Я нервничал из-за того, что работаю не на диване, а в чем-то другом, кроме пижамы. Но даже тогда я, как правило, знал WordPress Right от WordPress Doing It Wrong, и я находил приятным самовосхвалением хвастаться лучшими практиками WordPress, например, никогда не «взламывать ядро».

Моей первой задачей разработки WordPress в этом агентстве было возобновление застопорившегося проекта — довольно сложного для моих навыков в то время. Это потребовало множества настроек процесса регистрации и входа в WordPress. Считалось, что предыдущий разработчик добился значительного прогресса, просто отредактировав основные файлы wp-login .

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

Какими бы способностями к программированию я ни обладал, а мог и не обладать на тот момент, они быстро стали неактуальными, так как мой новый работодатель был в бешенстве. Она не понимала значения «взлома ядра», а я не был достаточно зрелым, чтобы объяснить это в понятной форме. Единственное, что временно охладило ее бровь, было то, что я заверил ее, что могу вернуться с помощью плагина резервного копирования / восстановления, который я установил.

Можете ли вы догадаться, куда это идет?

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

Ребят, не могу сделать бэкап.

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

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

Я научился по-настоящему ценить управляемые среды, такие как WP-Engine, с надежной системой резервного копирования/восстановления. Многие специализированные хосты имеют различные инструменты командной строки и другие функции, ориентированные на разработчиков, для выполнения резервного копирования, но WP-Engine — мой любимый. Это довольно быстро, если у вас не очень большая сеть. Пользовательский интерфейс прост. У него есть пользовательский интерфейс, и точка: с ним может работать любой, кто знает, как использовать WordPress. То есть, в отличие от какого-то CLI-подхода, который, вероятно, намного быстрее, или какой-то непонятной вещи, скрытой в Plesk, мои клиенты могут использовать это, понимать его, отслеживать его и проверять, что я его использую. Я большой фанат.

Когда я перетащил всю нашу платформу в ее родственный каталог

Я все еще был новичком в профессиональной сфере и всегда был сторонником Windows. Однако моя новая работа заключалась в магазине Mac, и я очень быстро научился любить все, что связано с ним. Ну, почти все. Похоже, у меня были большие проблемы с «волшебной мышью». У меня была тенденция терять соединение Bluetooth, что приводило к случайным и часто пугающим действиям перетаскивания после повторного подключения. Более того, я был просто неуклюжим с новой мелкой моторикой.

В те дни наш процесс разработки WordPress по-прежнему включал развертывание в рабочей среде через FTP. Для меня было обычным делом тратить целые рабочие дни на написание кода, болтать в чате, отвечать на электронные письма, в основном крутиться туда-сюда с помощью моей новой волшебной мыши, а Cyberduck был открыт для производства на моем рабочем столе. Боже, это звучит плохо! Но так оно и было.

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

Шли часы. День пришел и ушел. Все еще вниз.

К утру следующего дня все было восстановлено, и наш технический директор мягко попросил меня присоединиться к ней в конференц-зале. Наш системный администратор определил проблему. Он извлек журналы FTP и заметил, что мой пользователь переместил всю нашу платформу в родственный каталог. То есть wp-content стал вложенным в wp-includes .

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

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

Во-вторых, я проявлял большой интерес к развертыванию через Git. В конце концов, я написал плагин для WordPress, чтобы вплести наше управление версиями Bitbucket в обычный поток обновлений wp-admin . С тех пор у нас почти не было причин даже иметь FTP-доступ к производству. Этот плагин является одним из моих любимых профессиональных достижений. Конечно, близость к Git является необходимым условием для современных разработчиков.

Когда я удалил весь интерфейсный контент с помощью add_filter()

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

 add_filter( 'the_content', 'myprefix_add_a_badge' ); function myprefix_add_a_badge( $content ) { global $post; if( ! has_category( 'sponsored', $post ) ) { return false; } $out = $content . myprefix_get_badge(); return $out; }

Видите в этом что-то не так? Я быстро протестировал его на стадии подготовки, чтобы убедиться, что необходимые сообщения получили свои значки. Затем я развернул его и оставил работу на день. Как вы могли догадаться, Вселенная взорвалась.

В частности, в результате сообщения без значка отображались во внешнем интерфейсе вообще без содержания! Вы видите, почему? Проблема заключалась в том, что вместо того, чтобы возвращать $content в моем сторожевом условии, я возвращал false . Но на самом деле здесь много пластов ошибок.

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

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

Время, которое я разделил на ноль внутри бесконечного цикла

Запрос клиента заключался в том, чтобы переформатировать запись в блоге WordPress таким образом, чтобы дата читалась как «XYZ назад», а не как «10 ноября 2011 года». Я не был точно уверен, как этого добиться, но я знал, что это был формат даты, популярность которого, похоже, росла, и действительно, доктор Google очень быстро предоставил мне фрагмент. Это сработало на моем локальном! В нем было много математики, в частности, много деления . Я не был точно уверен, почему это сработало — было много вложенных циклов, остатков, округлений и тому подобного. Но это было в Google, и, похоже, оно работало, и я был достаточно счастлив развернуть его в рабочей среде.

Примерно через 30 минут я получил недружественный скайп от нашего системного администратора. Производство упало. Мертвые в воде. Он спросил меня, делил ли я в последнее время на ноль, и я понятия не имел, что он может иметь в виду. Вот что произошло.

Хотите верьте, хотите нет, но найденный мной нечитаемый фрагмент «работает на моем локальном компьютере» при достаточно большом размере выборки был способен к некоторому аномальному поведению. С некоторыми неудачными комбинациями дней, часов и минут циклы Руба Голдберга время от времени пытались разделить число на ноль. Вспомните школьную математику:

В обычной арифметике это выражение не имеет смысла, поскольку не существует числа, которое при умножении на 0 дает a (при условии, что a ≠ 0), и поэтому деление на ноль не определено. - Википедия

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

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

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

О, и что действительно смешного в этой ошибке? Ядро WordPress имеет для этого однострочное решение.

Время, когда я позволил проекту выйти из-под контроля, пока всем не надоело

Мне попался действительно увлекательный проект. Я должен был быть техническим руководителем и инженером-разработчиком WordPress, и мне должны были подчиняться разработчик Amazon AWS Lambda и глубокий эксперт по JavaScript. Это был первый раз, когда передо мной отчитывались несколько человек, и это был самый сложный проект, над которым я когда-либо работал. Даже называть его проектом WordPress было бы очень преуменьшением, но WordPress был связующим звеном, которое скрепляло все это вместе, поэтому для меня имело смысл выступать в роли технического руководителя.

Поскольку моя основная роль, как правило, заключалась в том, чтобы быть строго техническим специалистом, а также потому, что я склонен к минимализму, мне никогда не приходило в голову реализовать что-то вроде Jira или Basecamp или любой другой реальной платформы для управления задачами. Дела шли довольно хорошо для первой итерации проекта. Мы могли работать над нашими собственными отдельными компонентами, ссылаться на документ спецификации клиента как на нашу дорожную карту продукта и просто пинговать друг друга через Slack, когда нам нужно было соединить вещи вместе.

Проблемы начались, когда мы стали демонстрировать прогресс клиенту и реализовывать его отзывы. То, что начиналось как команда из трех человек, сразу же почувствовало, что оно поднялось на новый уровень: было неясно, кто за какую часть обратной связи отвечал, каков статус реализации этой обратной связи или даже кто с кем разговаривал. . Мы несколько раз превышали ограничение Gmail в 100 ответов на тему!

Вещи начали становиться неудобными. Я думаю, что клиент чувствовал, что он потерял контроль над направлением проекта, и, что не менее важно, он почувствовал, что он потерял видимость статуса проекта. Мой разработчик Amazon однажды упомянул: «Интересно, стоит ли нам использовать Trello».

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

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

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

Я рад сообщить, что этот проект был завершен к полному удовлетворению клиента. В настоящее время я считаю Trello или Jira де-факто обязательным требованием для команд из двух и более человек.

Иди вперед и учись на чужих ошибках

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

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

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