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

1. Загрузка своей собственной копии jQuery.

Отлично, поехали грузить… Вы серьезно желаете сделать это?! Загрузка своей собственной копии jQuery – идеальный способ начисто все разрушить.

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

<?php
 if( !is_admin()){
wp_deregister_script('jquery');
wp_register_script('jquery', ("http://cdn.jquerytools.org/1.1.2/jquery.tools.min.js"), false, '1.3.2');
//wp_register_script('jquery', ("http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"), false, '1.7.2');
wp_enqueue_script('jquery');
}
?>

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

Решение: не делайте так! Просто используйте копию jQuery, поставляемую с WP.

2. Некорректная загрузка JS/CSS-файлов.

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

Решение: используйте wp_register_script/wp_enqueue_script.

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

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

Решение: загружайте ваши скрипты только тогда, когда это необходимо.

Ниже представлен довольно простой пример того, как сделать это:

add_action( 'wp_print_scripts', 'deregister_cf7_javascript', 15 );
function deregister_cf7_javascript() {
    if ( !is_page(15) ) {
        wp_deregister_script( 'contact-form-7' );
    }
}
add_action( 'wp_print_styles', 'deregister_cf7_styles', 15 );
function deregister_cf7_styles() {
    if ( !is_page(15) ) {
        wp_deregister_style( 'contact-form-7' );
    }
}

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

3. Отсутствие экранирования пользовательского ввода в SQL, а также кодирования пользовательского ввода на выходе.

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

Решение: Убедитесь в том, что вы санитизировали пользовательский ввод, чтобы защититься от SQL-инъекций, и закодировали его при выводе на экран, чтобы предотвратить XSS-уязвимости. В кодексе есть неплохая статья, посвященная валидации данных.

4. Обращение к многочисленным сторонним сервисам.

Использовать стороннюю регистрацию или плагины для входа на сайт полезно лишь в том случае, если вы имеете значительное количество пользователей, активных в определенной социальной сети. Вход через социальные сети или сервисы заключает в себе определенное удобство для пользователей, помогает привлечь более количество людей. Однако если вы предлагаете возможность регистрации и входа на сайт через Twitter, FB, G+ и другие социальные сервисы только для того, чтобы расширить базу пользователей, то в таком случае вы поступаете неправильно. Это не является необходимым шагом и может привести к медленному съезжанию вниз в поисковой выдаче, поскольку ваш сайт будет долгое время подгружать все эти сторонние сервисы.

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

5. Ожидание слишком многого от виртуального хостинга.

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

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

6. Использование «admin» в качестве имени пользователя и небезопасного пароля.

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

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

7. Безмерное добавление разной функциональности в functions.php.

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

Помимо всего прочего, изучение различных конфликтов и проблем, возникших после обновлений, станет настоящим кошмаром для разработчиков. Допустим, к примеру, что вы добавили массу разной функциональности в файл functions.php  вашей темы. В таком случае вы попросту не можете постепенно один за другим отключать лишний функционал, чтобы выявить «виновника» возникших проблем. Если бы вся функциональность была бы разбита по плагинам, то в таком случае вы бы легко определили ошибку и нашли бы ту часть кода, которую нужно обновить или удалить.

Решение: создавайте функциональный плагин каждый раз, когда вы хотите вставить что-либо в файл functions.php. Это займет чуть больше времени, однако поможет оградить вас от потенциальных проблем в будущем.

Источник: wpmu.org