Как подойти к современной разработке WordPress (часть 1)

Опубликовано: 2022-03-11

Ни для кого не секрет, что кодовая база WordPress представляет собой беспорядок. Лично я каждый раз, когда прохожу через это, хочу только свернуться калачиком и заплакать. С другой стороны, WordPress намного опережает своих конкурентов. Простая в использовании и мощная CMS — это огромная задача, и WordPress остается популярным, потому что обеспечивает это.

Так зачем нам заботиться о качестве кода в ядре WordPress? Это работает, верно?

Да, это работает, и кодовая база 15-летней давности вряд ли будет полностью переработана добровольцами. К сожалению, это означает, что он также служит примером кодирования «в стиле WordPress», оправдывая многих разработчиков за несоблюдение передового опыта и современных методов разработки. Так много плагинов и тем WordPress имеют печально известный плохой код, и слепое следование устаревшим практикам только продолжает тенденцию.

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

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

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

Очевидно, это не относится к действительно простым задачам, таким как добавление нескольких строк CSS или пары пользовательских сообщений и переписываний. Но собрать вместе несколько плагинов (или, чаще, несколько десятков плагинов) или создать сайт на основе Visual Composer — это в любом случае не разработка программного обеспечения.

Само по себе это неплохо — тот факт, что некоторые решения настолько просты, является причиной такой популярности WordPress. Но в этой серии я буду говорить о реальной разработке WordPress: написании значительного кода PHP, HTML, CSS и JavaScript. В этой статье я начну с общего рабочего процесса, а затем сосредоточусь на фронтенд-разработке WordPress.

Современный рабочий процесс разработки WordPress

В общем, код качества:

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

Основные результаты — более низкая стоимость разработки и владения — имеют множество дополнительных преимуществ, которые я не буду здесь описывать.

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

Используйте контроль версий

Это означает использование Git. К сожалению, «ковбойское кодирование» при производстве по FTP почти все еще актуально. Совсем недавно я работал в британском агентстве, и у них были файлы с такими именами по всей их кодовой базе:

  • functions copy.php
  • functions copy 2.php
  • functions test.php
  • functions2.php
  • functions test2.php

Самое первое, что вы должны сделать, приступая к работе с сайтом WordPress, — поставить его под контроль версий. Tanking Servers — забавная ретроспектива ошибок разработки WordPress. Было бы очень легко исправить эти — и подобные неудачи, которые, вероятно, случались со всеми — с помощью Git.

Сделали ошибку в коде и весь сайт упал? git reset возвращает все как было. Обновление новой версии все сломало? git reset работает как машина времени. Какой-то вредоносный код появился из ниоткуда? git status показывает любые новые файлы, удаленные файлы или изменения в любых отслеживаемых файлах. Затем вы просто git checkout восстанавливаете оригиналы.

Остерегайтесь раскрытия папки .git

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

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

Поэтому публичный доступ к папке .git должен быть заблокирован. Если вы используете Apache, добавление приведенного ниже фрагмента в начало файла .htaccess заблокирует доступ к папке .git , а также к файлам журнала. Файлы журналов часто содержат конфиденциальную информацию, поэтому разумно также сделать их недоступными. Для различных настроек веб-сервера обратитесь за помощью к своему эксперту DevOps.

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

Используйте отдельные среды

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

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

Например, конфигурация сервера может храниться в отдельном файле. Вы можете создать wp-config-local.php для каждой локальной и промежуточной среды. (Не забудьте добавить его в файл .gitignore !) Затем добавьте следующий фрагмент в wp-config.php :

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

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

Используйте WP-CLI

Интерфейс командной строки WordPress (WP-CLI) — чрезвычайно полезный инструмент для администрирования установок WordPress. Наличие доступа к WP-CLI означает возможность запуска практически любой функции WordPress API. Например, вы можете добавлять, удалять и редактировать пользователей и их пароли с помощью WP-CLI. Полезно, если вы только что унаследовали сайт, а владелец заблокировал себя.

Другой пример: начальное развертывание с помощью WP-CLI не составляет труда. Это можно сделать с помощью нескольких команд:

  • Загрузка ядра, тем и плагинов
  • Поиск и замена в базе
  • Добавление пользователя-администратора

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

Используйте дополнительные параметры развертывания

Говоря об автоматизации, стоит изучить некоторые технологии и процессы развертывания, такие как:

  • Непрерывная интеграция/непрерывное развертывание/доставка (CI/CD)
  • Докер
  • Автоматизированное тестирование (включая внешние регрессионные тесты)

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

Используйте линтинг

Однако для проектов любого размера линтинг является благом для большинства разработчиков. Линтинг означает автоматическую проверку вашего кода на наличие ошибок. Полнофункциональная IDE, такая как PHPStorm, уже делает это из коробки; однако для более простых редакторов, таких как VSCode или Sublime Text, требуется специальная программа, называемая линтером. Один из способов настроить это — настроить редактор так, чтобы он запускал линтер всякий раз, когда вы сохраняете файл.

PHP_CodeSniffer де-факто является линтером для PHP. Помимо проверки синтаксических ошибок, он также может проверять, соответствует ли ваш код рекомендациям по стилю, таким как PSR-2. Это значительно упрощает соблюдение стандартов кодирования.

Для JavaScript ESLint является популярным линтером. Он имеет обширный набор правил и поддерживает пользовательские конфигурации для всех разновидностей и фреймворков JavaScript.

Эффективным вариантом использования здесь является включение линтинга в конвейер сборки CI/CD, чтобы весь код автоматически проверялся перед развертыванием.

Современные методы фронтенд-разработки WordPress

Теперь, когда для всего проекта WordPress настроен правильный рабочий процесс, давайте углубимся в лучшие практики для внешнего интерфейса.

Используйте современные инструменты: Sass и ES6+

Мир фронтенд-разработки постоянно меняется и всегда в движении. Когда-то мы думали, что Sass был лучшим инструментом для написания CSS — и для разработки WordPress до Gutenberg — так оно и есть, — но потом все начали говорить о CSS-in-JS и стилизованных компонентах.

Даже WordPress не смог устоять и перенял некоторые из этих новых технологий. Gutenberg, новый редактор блоков, построен на React и REST API.

Вы обязательно должны освоить эти основные интерфейсные технологии:

  • ЭС6+. Документация WordPress называет его ESNext и даже поощряет его использование.
  • Сасс. Используется WooCommerce и является лучшим способом написания CSS, если вы еще не увлекаетесь CSS-in-JS.
  • Вебпак. Даже ядро ​​WordPress теперь использует Webpack и Babel.

ES6 и Sass — это современные JavaScript и CSS соответственно, а Webpack — это инструмент, который позволяет использовать все эти современные функции, не беспокоясь об обратной совместимости. Webpack можно назвать компилятором внешнего интерфейса, который генерирует файлы для использования в браузере.

Переход с jQuery на Vue.js или React

Ядро WordPress и почти все плагины WordPress зависят от jQuery, поэтому вы не можете просто перестать его использовать. На самом деле нет смысла прекращать использовать его для простых задач, таких как скрытие пары <div> или выполнение одноразового запроса AJAX, когда вы привыкли делать это таким образом. jQuery в любом случае будет загружен, и он прост и удобен в использовании.

Сложные приложения — это то, где jQuery борется: трудная для понимания логика, ад обратных вызовов, глобальные переменные и отсутствие HTML-шаблонов. Это явно требует другого способа организации внешнего интерфейса.

Современные интерфейсные библиотеки, такие как React, используют принципы объектно-ориентированного программирования (ООП) и организуют интерфейсную архитектуру приложений в виде модульных повторно используемых компонентов. Компонент содержит весь код, разметку и «состояние компонента» (переменные) для конкретного элемента. Элемент может быть практически любым: кнопкой, полем ввода, пользовательской формой или виджетом, который отображает последние сообщения из серверной части WordPress REST API. Компоненты могут содержать другие компоненты, образуя иерархическую связь.

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

На данный момент в тренде две библиотеки на основе компонентов: Vue.js и React. React был бы очевидным выбором, потому что он уже используется Гутенбергом. Однако для тех, кто плохо знаком с современным JavaScript, лучше начать с Vue.js.

React сразу бросает вас в глубь, используя функции ES6, классы, проприетарный синтаксис JSX и конвейер сборки Webpack. Кривая обучения довольно крутая.

Vue.js, с другой стороны, гораздо более удобен для начинающих, и его можно использовать, просто добавив тег <script> . Vue.js использует простой JavaScript (ES5), HTML и CSS. Знакомство с новыми понятиями происходит гораздо более постепенно.

Поработав над несколькими проектами Vue.js, вы будете лучше подготовлены к глубокому погружению в React. Не то, чтобы это всегда было необходимо, но, например, разработка Гутенберга требует этого.

Используйте API REST WordPress

REST API WordPress — это просто стандартизированный интерфейс для удаленного запроса и изменения данных из WordPress. Это больше связано с архитектурой программного обеспечения, чем с совершенно другим способом кодирования. Те же старые фрагменты jQuery AJAX можно использовать с немного другими параметрами.

Самое главное преимущество? Поскольку WordPress REST API стандартизирует взаимодействие между серверной частью и интерфейсом, это важный шаг к модульности, возможности повторного использования и удобочитаемости вашего кода. Эти ужасные шаблоны с HTML и PHP, смешанные вместе, и немного SQL, добавленного в смесь, должны уйти. Поскольку шаблоны представляют собой просто HTML с заполнителями для данных, передаваемых в качестве параметров, нет большой разницы между передачей этих данных в PHP или через REST API во внешнее приложение.

Вы также можете изучить WPGraphQL. Он может или не может в конечном итоге заменить WordPress REST API, но он быстро набирает обороты.

Изучите Гутенберг (клиенты скоро потребуют его)

Конечной целью Гутенберга, помимо прочего, является полная настройка сайта.

Это закладывает основу для новой модели WordPress Core, которая в конечном итоге повлияет на весь процесс публикации на платформе.

Страница проекта WordPress Gutenberg на GitHub

Gutenberg действительно получил серьезный отказ от разработчиков WordPress. Вот некоторые из аргументов против слияния с ядром WordPress:

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

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

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

Время идти в ногу со временем: даже «WordPress Way» развивается

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

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

В течение некоторого времени WordPress и WooCommerce следовали практике разработки «функциональных плагинов», реализующих и использующих новые технологии. Когда придет время, эти плагины объединятся в ядро, как это сделал Гутенберг. У WooCommerce также есть собственный проект React. WordPress REST API также начинался как отдельный плагин и теперь является частью ядра WordPress.

Вопрос не в том, должны ли мы изучать новые вещи и использовать их в своей повседневной работе, а в том, как . Ответ — «постепенно», шаг за шагом. Либо изучите что-то новое, либо сделайте что-то, что вы хорошо знаете, новым и другим способом.

Например, узнайте, как использовать Webpack со всеми вашими старыми скриптами. Webpack может преобразовать ваш новый код ES6+ в «простой» JavaScript, совместимый со старыми браузерами. Он также может минимизировать сценарии и объединять их вместе. Это одна новая вещь. Сделанный? Затем перепишите свой JavaScript, используя возможности ES6. Это новый способ делать то, что вы хорошо знаете.

Результат: вы изучите Webpack и ES6. Как профессионалы, мы должны идти вперед и не отступать. Всегда продолжайте учиться. И поделитесь, когда вы это сделаете: Toptal ведет список лучших практик разработки WordPress и приветствует вклад сообщества в него.

Во второй части нашей серии мы углубимся в PHP-часть современной серверной разработки WordPress.