10 советов, как упростить обслуживание WordPress

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

Почему правильное обслуживание WordPress имеет значение

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

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

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

1. Сделайте резервную копию!

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

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

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

2. Установите свой сайт WordPress локально

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

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

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

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

3. Иди на хуй

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

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

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

И не говоря уже о том, что вы на самом деле не «гитите», если не используете ветки! Создайте по крайней мере две ветки для разработки и производства, чтобы разработчики могли выполнять всю работу в ветке разработки, тестировать сайт, а затем, если все в порядке, отправлять в рабочую ветку, чтобы убедиться, что на рабочем сайте все в порядке.

4. Удалите ненужные файлы, код и плагины

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

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

Помимо файлов PHP и плагинов, неиспользуемые медиафайлы также могут со временем заполнить вашу папку wp-content , что может вызвать проблемы у ваших разработчиков при работе с любыми функциями, связанными с мультимедиа. Вы можете найти различные плагины, чтобы упростить эту задачу. Одним из примеров является Media Cleaner.

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

5. Комментирование

Вы, вероятно, знакомы с мемом программирования, который выглядит примерно так: когда код был написан, его понимал автор, который его написал, коллеги и Бог. Через какое-то время только автор и Бог знали, что он делает, и теперь только Бог знает, что он делает — если только автор не добавил надлежащих комментариев!

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

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

 function stripWhiteSapaces(str) { … Return str; }

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

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

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

6. Линтинг

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

Например, при использовании Visual Studio Code в качестве IDE VS Code использует официальный линтер PHP ( php -l ) для диагностики языка PHP. Вы можете настроить правила/ограничения для каждого языка отдельно (т.е. PHP, JavaScript, CSS и т.д.). Вы можете ознакомиться со стандартами кодирования WordPress для более подробной информации.

• https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/
• https://make.wordpress.org/core/handbook/best-practices/coding-standards/javascript/

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

7. Именование переменных и файлов

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

Рассмотрим некоторые важные моменты:

1. Избегайте однозначных имен
2. По возможности пишите кратко
3. Иногда очень полезно добавить «тип» к имени файла. Например, если это значок, у вас может быть что-то вроде BlackArrowIcon.png или, если это большое фоновое изображение, это может быть что-то вроде FrontYellowBG.jpg. Или, если это файл кода, иногда очень легко узнать, что означает этот файл, при работе с несколькими файлами, открытыми на разных вкладках в среде IDE. Например, если есть класс со вспомогательными функциями, будет полезно, если он будет называться HelperClass.php вместо Helper.php.

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

8. Отладка WordPress

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

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

• Кинт отладчик
• Панель отладки
• Монитор запросов

9. Используйте лучший CSS

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

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

Вот несколько быстрых советов с моей стороны без подробностей:

• Применяйте хорошую практику именования. Используйте методологию именования, например BEM (модификатор блочного элемента).
• Избегайте встроенных стилей. Вместо этого используйте внешние таблицы стилей.
• Старайтесь придумывать общие повторно используемые шаблоны, когда это возможно, а не просто нагромождать стили, когда это необходимо.
• Разбейте стили на несколько файлов в зависимости от функций или областей веб-сайта. Если вы обеспокоены тем, что большее количество файлов стилей может повлиять на производительность загрузки, вы можете решить эту проблему, используя хороший плагин кэширования, который объединит несколько файлов в один файл.
• Используйте препроцессор CSS, такой как SASS, LESS и т. д.

10. Получите обратную связь от текущих разработчиков

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