Виджеты WordPress: рефакторинг, часть 1

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

Но, как я упоминал в начале этого поста, создание инструментов качества кода сначала дает нам основу, которую мы можем использовать при рефакторинге шаблона (что нам явно необходимо сделать, учитывая количество красного, показанного GrumPHP).

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

Несмотря на это, предыдущий пост показывает, сколько работы мы для себя вырезали, верно?

Теперь мы начнем с рефакторинга WordPress Widget Boilerplate.

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

Шаблон виджета WordPress: рефакторинг, часть 1

Пожалуй, самое интересное для меня — привести этот репозиторий в соответствие с современными стандартами. Если вы посмотрите на ветку master в GitHub на момент написания этого поста (или на историю репозитория позже), вы увидите, что ей уже шесть лет.

Этой штуке шесть лет (на момент публикации).

Это долгий срок по меркам Интернета, не так ли?

В любом случае, в наших усилиях по рефакторингу мы собираемся сделать некоторые вещи:

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

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

1 Создание ветки разработки

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

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

Для этого введите в терминале следующую команду:

$ git checkout -b develop

Это создаст новую локальную ветку. Он еще не загружен на GitHub или в ваш удаленный репозиторий (где бы вы его ни хранили).

Далее введите следующую команду:

$ git push --set-upstream origin develop

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

Если вы используете GitHub, это должно выглядеть примерно так:

Если вы используете другой сервис, он все равно должен выглядеть аналогично. То есть структура каталогов должна быть одинаковой, но то, как она будет выглядеть в браузере, будет отличаться.

Примечание о ветке

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

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

2 Реорганизация файлов

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

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

Обновление каталогов

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

• создать каталог ресурсов для JavaScript и таблиц стилей,
• создайте каталог src для всех файлов PHP,
• создать языковой каталог для файлов интернационализации,
• храните все остальные файлы в корне репозитория, чтобы другим было легко следовать предоставленному файлу README.

Для этого я собираюсь сначала удалить и переместить несколько вещей. Я попытался организовать это в определенном порядке:

1. Я собираюсь удалить файл README.txt. Этот файл используется в качестве стандартного шаблона README, если вы собираетесь отправлять код в репозиторий плагинов WordPress, но это не обязательно для того, что я хочу для Boilerplate.
2. Я переименую plugin.php в Plugin .php, чтобы следовать соглашениям PSR.
3. Я также переименую lang в languages.
4. Я собираюсь создать каталог ресурсов и переместить, а затем переместить каталоги css и js в этот каталог. Я создам подкаталог dev в каждом из этих каталогов, где мы сможем работать с Sass и неминифицированными файлами JavaScript (оба из них появятся позже в этой серии).
5. После этого я создам каталог src и перемещу в него таблицу стилей представлений.
6. Я также переименую представления в Представления, а также заглавные буквы содержащихся в нем файлов.
7. Наконец, я перенесу все в корень каталога. Это означает, что виджет-шаблон исчезнет, ​​а все файлы будут находиться в корневом каталоге репозитория.

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

Удалите README

Для этого просто введите следующую команду в своем терминале из корня каталога widget-boilerplate :

$ rm readme.txt

Это удалит файл. Если вы введете следующую команду в своем терминале:

$ git status

Вы должны увидеть что-то вроде этого:

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

Введите следующее:

$ git rm README.txt
$ git add. $ git commit -n -m "Removing the original README.txt template."
$ git push

Это укажет Git удалить файл, добавить единственное изменение в набор изменений, зафиксировать его без запуска каких-либо инструментов качества кода (потому что нам не нужно делать это прямо сейчас, иначе произойдет сбой) и отправит его в ветку разработки удаленного репозитория .

Теперь, когда мы это сделали, давайте продолжим и переименуем некоторые файлы.

Переименование файлов

Пока мы этим занимаемся, мы собираемся переименовать не только файл plugin .php, но и другие файлы PHP. Это файлы, которые можно логически сгруппировать в одном наборе изменений, поэтому имеет смысл пойти дальше и сделать это.

Итак, из вашего терминала введите следующие команды:

$ mv plugin.php Plugin.php
$ mv views/admin.php views/Admin.php
$ mv views/widget.php views/Widget.php

При этом мы еще не вносили никаких изменений в файлы, поэтому коммитить нечего. Перейдем к переименованию каталогов.

создавать каталоги; Переименовать каталоги

Так же, как мы сделали с файлами, давайте продолжим и создадим новый каталог ресурсов . В терминале введите следующую команду:

$ mkdir assets

Затем мы хотим переместить каталоги css и js в этот каталог, поэтому также введите в терминал следующее:

$ mv css assets
$ mv js assets

И давайте переименуем каталог lang в Languages, введя следующую команду:

$ mv lang Languages

Наконец, давайте переименуем view в Views:

$ mv views Views

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

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

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

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

$ git add. $ git commit -n -m "Creating new directories; Renaming files."
$ git push

Теперь перейдем к подкаталогам для наших предварительно обработанных файлов.

Создать подкаталоги

В каталоге CSS создайте подкаталог с именем dev и пустой файл с именами admin.scss и widget.scss, так как мы будем работать с этими файлами позже в этой серии.

Затем добавьте каталог dev в каталог JavaScript и добавьте к этим файлам пустой файл admin.js и файлы widget.js. Если вы чувствуете себя так склонным, вы можете переместить уже существующие файлы в каталоги dev, поскольку это файлы, которые мы будем использовать в качестве основы для наших файлов разработки.

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

Из каталога css …

$ mkdir dev
$ mv admin.css admin.scss && mv widget.css widget.scss
$ mv *.scss dev

Выше я создал каталог dev для своих таблиц стилей, переименовал их в файлы Sass и переместил в каталог dev.

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

$ git add. $ git commit -n -m "Renaming and moving stylesheets into a dev directory."
$ git push

Теперь из каталога js …

$ mkdir dev
$ mv *.js dev

Поскольку нам не нужно менять тип связанных файлов, мы можем просто переместить их в новый каталог.

Наконец, давайте сделаем то же самое и посмотрим, есть ли какие-либо изменения, которые мы можем отправить с помощью быстрой проверки статуса git (что должно быть). Вот список команд, которые я запускал для фиксации и отправки изменений:

$ git add. $ git commit -n -m "Adding a JavaScript dev directory and moving the development files."
$ git push

Мы почти закончили. Все, что осталось сделать, это переместить определенные каталоги в корень репозитория и переименовать основной каталог в src. Итак, давайте сделаем это сейчас.

Переместить каталоги в корень

По сути, нам нужно переместить все, кроме файла плагина и каталога Views, из каталога widget-boilerplate, и нам нужно переименовать widget-boilerplate в src.

Звучит просто, правда? Это довольно просто. Из каталога widget-boilerplate :

$ mv assets .. && mv languages ..
$ cd ..
$ mv widget-boilerplate src

Затем я зафиксирую изменение на GitHub, используя следующее:

$ git add. $ git commit -n -m "Reorganizing the directory structure."
$ git push

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

Несколько слов об ООП

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

Что мы сделали в этом посте, так это, по сути, применили объектно-ориентированный архитектурный дизайн, основанный на анализе того, как плагин сочетается друг с другом.

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

В следующем посте

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

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

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