На этом сайте мы много говорим о советах и хитростях для получения того, что вы хотите от WordPress … но сегодня мы собираемся сделать шаг назад от технических вещей, чтобы взглянуть на некоторые практики, вредные привычки и ложные навыки кодирования, которые было бы лучше оставить в нашем прошлом. Итак, простите за жесткое название поста (ха-ха!), Мы поговорим о 5 удивительно распространенных практиках, которые являются недостатками на платформе.
Две из самых приятных вещей в работе над темами WordPress — это тот факт, что мы нацеливаемся в невероятно гибкой среде (то есть в Интернете), и у нас есть солидная документация, которая поможет нам пройти через этот процесс (то есть Кодекс WordPress) ,
В конце концов, если тема работает, имеет ли значение чистый, поддерживаемый код?
Но есть и опасность, связанная с разработкой тем: мы можем полностью отказаться от лучших практик работы с Интернетом и полностью игнорировать документацию. В частности, нет ничего, что заставляет нас писать чистый, поддерживаемый код. В конце концов, если тема работает, имеет ли значение чистый, поддерживаемый код? Кроме того, зачем пытаться следовать рекомендациям WordPress, если тема работает нормально?
Слабые аргументы, верно? Я не знаю — чем больше я работал в пространстве WordPress, тем больше я удивлялся тому, сколько на самом деле существует плохого кода. Таким образом, я подумал, что было бы забавно описать пять основных грехов разработки тем WordPress.
Игнорирование Кодекса WordPress
Как и большинство языков программирования, фреймворков или библиотек, WordPress включает в себя огромное количество документации. Кодекс WordPress, пожалуй, лучший ресурс, который есть у разработчиков для работы с WordPress. В конце концов, он предоставляет документацию для большинства приложений.
Но Кодекс WordPress часто выходит за рамки стандартной документации — помимо предоставления имен функций и параметров, Кодекс предоставляет богатые примеры того, как использовать многие функции API. После прочтения любой статьи вам будет трудно не найти четкого примера того, как работает данная функция.
Помимо API, в Кодексе также есть множество других статей, связанных с разработкой:
Всякий раз, когда я работаю над темой или плагином и сталкиваюсь с тем, что думаю, что мне нужно написать собственную функцию, чтобы достичь чего-то, я сначала буду искать в Кодексе. В большинстве случаев уже доступна функция, которая помогает с тем, что мне нужно.
Каждый серьезный разработчик WordPress должен регулярно использовать Кодекс при работе над любым проектом, связанным с WordPress. Игнорирование этого может часто приводить к творческим, но непроверенным и нестабильным решениям, которые могут принести больше вреда в будущем, чем пользы.
Не локализуйте вашу тему
Несколько лет назад, если бы вы спросили меня о моих мыслях о локализации WordPress Theme, я бы сказал, что это будет зависеть от маркетинга, на который вы ориентируетесь. То есть, если вы думаете, что аудитория собирается использовать язык, отличный от вашего, определенно сделайте это; в противном случае нет ничего плохого в том, чтобы оставить тему переведенной на ваш родной язык.
Перенесемся на несколько лет вперед, и WordPress ‘запитывает миллионы сайтов в Интернете. Сайты по всему миру используют приложение для управления контентом своего сайта. Вдобавок ко всему, для разработчиков становится все более привычным дополнять свой доход или даже зарабатывать на жизнь работой с WordPress.
Поскольку WordPress получил широкое распространение и Интернет сделал мир таким плоским, рынок для любой конкретной темы не ограничивается одним языком. Кроме того, WordPress позволяет невероятно легко локализовать вашу тему, и для этого требуется так мало дополнительных усилий, что теперь я утверждаю, что локализация вашей темы больше не является обязательной.
По большей части вам нужно понять три вещи:
Кроме этого, очень мало дополнительных затрат на локализацию темы; Тем не менее, я рекомендую вам взглянуть на статью « Перевод WordPress» в Кодексе. Он обрисовывает в общих чертах три вещи выше и углубляется в каждую.
Дислокация файла темы
Разработчики много говорят об организации и поддержке кода. Лично я считаю, что эти принципы гораздо проще воспринимать на словах, чем на самом деле следовать им, но они важны.
Дело в том, что они выглядят по-разному для каждого типа проекта. Некоторые приложения написаны на одном языке и работают на настольном компьютере, некоторые приложения используют два языка и работают на мобильном устройстве, другие проекты, такие как WordPress Themes, могут использовать от трех (HTML, CSS и PHP) до четырех ( через JavaScript) языки. Кроме того, некоторые компоненты темы выполняются на стороне клиента, некоторые — на стороне сервера, некоторые — напрямую с WordPress, а другие — напрямую с базой данных.
Сказать, что есть возможность пожертвовать ремонтопригодностью, — преуменьшение.
Но это не должно быть проблематично, так как есть определенные стандарты, которые WordPress предлагает для организации ваших файлов тем. В частности, Кодекс подробно описывает, как организовать файлы шаблонов PHP, таблицы стилей, источники JavaScript и изображения.
- Контрольный список файлов шаблонов содержит список файлов, составляющих базовую тему, и подробную информацию о том, что каждый из них должен включать.
- Иерархия шаблонов дает объяснение того, как все файлы темы сочетаются друг с другом и как WordPress отображает каждый файл в течение жизненного цикла страницы.
- Вступление в шаблоны также предоставляет подробную разбивку шаблонов и структуру страницы WordPress для каждого.
- Theme Development — это массивная статья, которая охватывает все, что связано с развитием темы.
Конечно, для организации ваших файлов требуется немного больше усилий, чем просто для того, чтобы «заставить это работать», но выплата дивидендов со временем, когда вы начинаете работать над следующей версией вашей темы или когда несколько разработчиков начинают работать над одной и той же кодовая.
Игнорирование стандартов кодирования
Конечно, организация файлов — это только часть процесса разработки, которая влияет на организацию и удобство обслуживания. Далее мы должны сосредоточиться на том, как мы на самом деле пишем код, который находится в наших файлах.
В конце концов, мы должны предоставлять не только хорошо организованные файлы, но и простой в использовании код, соответствующий стандартам. Опять же, Кодекс WordPress предоставляет стандартный набор для основных языков, которые вносят вклад в кодовую базу темы:
Многое для обработки, а? Дело в том, что, проводя время, знакомясь со всем вышеперечисленным, вы получаете со временем дивиденды. Применение этих стандартов в начале разработки экспоненциально дешевле, чем рефакторинг существующей темы или плагина.
Кроме того, это приводит к внесению лучшего кода обратно в сообщество
Не проверяю свою работу
После того, как тема была разработана и готова к выпуску, вы должны — по крайней мере — провести одно тестирование. То есть вы должны проверить, правильно ли отформатированы различные стили данных постов, что ваша тема не использует устаревшие функции или использует какие-либо функции неправильно.
К счастью, Кодекс предоставляет ряд предложений и инструментов, которые помогут значительно упростить этот процесс.
- Режим отладки помогает сгладить любые предупреждения PHP и / или ошибки
- Theme Unit Test — файл данных, включающий предварительно отформатированные данные постов, которые вы можете запускать в локальной среде разработки.
- Theme Check — это плагин, который изучит эту кодовую базу вашей темы и предоставит заметки о том, что необходимо решить, а также рекомендации по улучшению кодовой базы.
Конечно, есть и дополнительное тестирование, которое вы можете выполнить, например, кросс-браузерное тестирование, соответствие стандартам HTML / CSS и так далее. Кодекс описывает еще больше предложений по тестированию в статье Theme Testing Process .
Каковы ваши собственные любимые мозоли?
Говорят, что вы часто учитесь на своих ошибках, и я буду первым, кто признает, что за время работы с WordPress я сломал каждую из них. Но, как и все остальное сообщество разработчиков, вы учитесь и начинаете создавать лучшие проекты с опытом.
Это первая статья такого типа, посвященная культуре WordPress, которую мы будем публиковать на сайте … так что поделитесь собственным опытом ниже — или еще лучше, напишите о них подробно, и мы опубликуем его, если это здорово !
Тем не менее, это, конечно, не окончательный список, и я уверен, что есть еще что добавить (мы даже не касались взлома ядра, преследования базы данных или жестких элементов кода, которые должны иметь опции). Оставьте свои собственные любимые мозоли в комментариях!
Каковы некоторые из наиболее раздражающих, вредных или неустойчивых методов, с которыми вы сталкивались?