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

Не мудрствуя лукаво, давайте посмотрим, что они материал.

1 - неполная документация

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

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

2 - несогласованность

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

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

3 - Неправильное использование префиксов

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

Попробуй вместо seo_enhancer для SEO плагин или multisite_manager для вашего плагина управления многоступенчатой ​​установкой. Лучший вариант не беспокоиться об этом - инкапсулировать ваши объекты (переменные, функции и т. Д.) В классы, просто добавив к последним префикс и вуаля.

4 - Написание твердых ценностей

Программное обеспечение создано динамическим, так зачем идти против естественного и вставлять статику. Чтобы избежать проблем с SEO de Ressources не кодируйте все жестко путь к чему-то. Вместо этого, когда вам нужно обратиться в WordPress, ищите одну из его специализированных функций. За беду вот одна залог. Также не используйте префикс базы данных напрямую, вместо этого сделайте $ wp-> table_name.

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

5 - Легион файлов CSS и javascript

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

Я согласен, но вы можете использовать препроцессоры CSS, такие как Sass / Less, а также автоматизаторы задач, такие как Grunt или Gulp. Да, вы можете сохранить исходные файлы Sass / Less и javascript в каталоге темы (для разработчиков), скомпилировать их вместе как один или два файла с помощью Grunt или Gulp и, наконец, задокументировать процесс сборки. Пользователи вашей темы будут в восторге, а разработчики с удовольствием сделают ее одним или несколькими детьми.

6 - случайные родительские темы

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

Например, в файле functions.php если вы пишете функцию, которая действует как шаблон, инкапсулируйте ее в function_exist () чтобы позволить дочерним темам переопределить это должным образом.

7 - Неадекватное включение ресурсов CSS и javascript

WordPress ясен, вы хотите включить файл .css или .js, вы должны поместить его в соответствующую очередь. Теперь вам решать, как это сделать при правильных условиях. Вы не хотите загружать css и js слайдера на страницу, на которой их нет. Также по возможности используйте HTTPS.

8 - Кустовые продукты

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

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

9 - Темы, не подготовленные к переводу

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

Подготовить тему для перевода очень просто. Используйте обе функции __ () et _e () инкапсулируя текст в нем.

10 - Плохое определение веб-разработки

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

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

Бонус: ограниченность

С самого начала я рассказал вам о десяти вещах. Извините, похоже, есть еще один. Но я также говорил о встречах с людьми.

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

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

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

Вот и все, я представил вам материал 10 (возможно, 11), который раздражает разработчика WordPress. У тебя есть? Насколько они вас раздражают? Поделитесь ими с нами в разделе комментариев.