Вітаю вас у другій частині цієї серії. У першій статті ми розповіли про стандарти кодування WordPress, про те, як уникнути конфліктів імен функцій, про коментарів в коді, а також привели кілька загальних порад з безпеки.
Сьогодні ми підемо ще далі, напишемо ще більше кодів і дізнаємося про деякі методи підвищення продуктивності і безпеки наших плагінів. Сьогодні ми розглянемо наступні теми:
- Як і коли слід включати скрипти / стилі;
- Як правильно виконувати виклики Ajax;
- Фільтри та дії, які надають великі можливості для користувачів.
Відкривайте свій улюблений редактор коду і приготуйтеся пограти з WordPress!
Як і коли я повинен включати скрипти?
Перше, що ви повинні мати на увазі — WordPress має дві чудові функції (wp_enqueue_script і wp_enqueue_style), з допомогою яких ви можете включити скрипти і стилі. Тому, будь ласка, не додавайте їх вручну в заголовку або за допомогою звернення wp_head.
Якщо ви використовуєте методи WordPress, ви зможете включити власні скрипти в функції кешування і минификации плагінів, ви зможете розмістити їх за своїм вибором в заголовку або підвалі, ви зможете додати залежні сценарії, а також використовувати всі прийоми, про які піде мова в цій статті. Як і багато інші функції.
Неправильний код:
add_action( ‘wp_head’ , ‘my_custom_scripts’ );
function my_custom_scripts() {
echo «;
}
Правильний код:
add_action( ‘wp_enqueue_scripts’, ‘my_customs_scripts’ );
function my_customs_scripts(){
wp_enqueue_script( ‘script-handler’, get_template_directory_uri() . ‘/js/my.js’, array(‘jquery’), ‘1.0.0’, true );
}
Я не можу описати всі варіанти використання wp_enqueue_xxxx, тому що їх дуже багато (для цього у вас є таке відмінне підмога, як Кодекс). Я просто спробую показати, як ви повинні додати скрипти в свої теми або плагіни.
Що ви завжди повинні пам’ятати, так це те, що слід виходити з принципу розумної необхідності. Це означає, що ви не повинні включати файли там, де вони не повинні підключатися.
Ви можете подумати: «Це всього лише один файл, це не вплине на весь сайт«. З таким ставленням ви можете кинути папір в парку, заспокоюючи себе: це всього лише один листок, він не забруднить весь парк. Але так не повинно бути.
Якщо всі розробники будуть вставляти свої скрипти, коли їм заманеться, все закінчиться тим, що користувальницькі додатки розростуться до страхітливих розмірів. А ми не хочемо цього.
Тепер, коли ми з’ясували це, давайте розглянемо декілька порад щодо того, як включати скрипти, якщо це дійсно необхідно.
1. Ніколи не включайте файли інтерфейсу в серверної частини і навпаки:
// Тільки інтерфейс
add_action( ‘wp_enqueue_scripts’, ‘my_front_customs_scripts’ );
function my_customs_scripts(){
wp_enqueue_script( ‘script-handler’, get_template_directory_uri() . ‘/js/my.js’, array(‘jquery’), ‘1.0.0’, true );
}
// Тільки серверна частина
add_action( ‘admin_enqueue_scripts’, ‘my_back_customs_scripts’ );
function my_customs_scripts(){
wp_enqueue_script( ‘script-handler’, get_template_directory_uri() . ‘/js/my.js’, array(‘jquery’), ‘1.0.0’, true );
}
Але зачекайте! Давайте підемо ще трохи далі, і будемо включати скрипти тільки на тих сторінках, які в них дійсно потребують. Я раджу вам зареєструвати їх, а потім поставити в чергу завантаження тільки для певних сторінок.
2. Вмикайте файли, тільки на сторінках, на яких вони необхідні:
//Тільки інтерфейс
add_action( ‘wp_enqueue_scripts’, ‘my_front_customs_scripts’ );
function my_customs_scripts(){
wp_register_script( ‘script-handler’, get_template_directory_uri() . ‘/js/my.js’, array(‘jquery’), ‘1.0.0’, true );
if( is_page(‘my-page’) ) {
wp_enqueue_script( ‘script-handler’ );
}
// Буде корисно підключати, якщо це дійсно необхідно
// якщо( is_single() )
// якщо( is_home() )
// якщо( ‘cpt-name’ == get_post_type() )
}
//Тільки серверна частина
add_action( ‘admin_enqueue_scripts’, ‘my_back_customs_scripts’ );
function my_customs_scripts( $hook ){
wp_register_script( ‘script-handler’, get_template_directory_uri() . ‘/js/my.js’, array(‘jquery’), ‘1.0.0’, true );
//Це потрібно підключати, тільки коли редагується запис
if( ‘edit.php’ == $hook ) {
wp_enqueue_script( ‘script-handler’ );
}
// Якщо ви додали сторінку опцій на зразок цієї
// $plugin_screen_id = add_options_page(…)
// ви можете зробити наступне
$screen = get_current_screen();
if ( $plugin_screen_id == $screen->id ) {
wp_enqueue_script( ‘script-handler’ );
}
}
/* Інший спосіб використовувати id панелі */
add_action( ‘admin_print_styles-‘ . $plugin_screen_id, ‘my_back_customs_scripts’ );
3. Ваші скрипти призначені для використання з шорткодами?
// Тільки інтерфейс
add_action( ‘wp_enqueue_scripts’, ‘my_front_customs_scripts’ );
function my_customs_scripts(){
wp_register_script( ‘script-handler’, get_template_directory_uri() . ‘/js/my.js’, array(‘jquery’), ‘1.0.0’, true );
// якщо вам потрібно включити скрипт для шорткода
// не додавайте його всюди
// замість цього ви можете включити його тільки там, де він потрібен
global $post;
if( is_a( $post, ‘WP_Post’ ) && has_shortcode( $post->post_content, ‘custom-shortcode’) ) {
wp_enqueue_script( ‘script-handler’);
}
}
4. Вмикайте стилі з умовами
На відміну від інших фрагментів коду, які можуть ставитися і до скриптів і стилів, наступний код буде працювати тільки з wp_enqueue_style (принаймні, на даний момент):
// Тільки інтерфейс
add_action( ‘wp_enqueue_scripts’, ‘my_front_customs_styles’ );
function my_front_customs_styles(){
wp_register_style( ‘my-plugin-css’, plugins_url( ‘my-plugin/css/plugin.css’ ) );
// Давай внесемо цей css тільки для старих (і недосконалих) браузерів
wp_enqueue_style( ‘my-plugin-css’ );
global $wp_styles;
$wp_styles->add_data(‘my-plugin-css’, ‘conditional’, ‘lte IE 9’);
}
У Кодексі ви можете знайти ще декілька прикладів. Ще один чудовий приклад, який ви можете використовувати для запуску всіх своїх плагінів — WordPress Plugin Boilerplate.
Перегляньте його код, щоб розібратися, як включені скрипти і стилі. Плагін Wpfavs (розроблений на основі WordPress Plugin Boilerplate) також чудовий приклад того, як створювати плагіни для серверної частини WordPress.
Як правильно виконувати виклики Ajax
У цьому розділі я опишу деякі помилки реалізації Ajax в WordPress, з якими мені часто доводилося зустрічатися. Їх умовно можна розділити на наступні групи:
- Виклик Ajax не повинен виконуватися безпосередньо до файлу;
- Виклики Ajax повинні використовувати значення nonce;
- Перевіряйте права доступу користувача, якщо це необхідно;
- Змінні JavaScript повинні вмикатися з допомогою wp_localize_script.
Я знаю, Jquery елементарно виконує Ajax-виклики, і ми можемо просто створити файл з ім’ям ajax.php, включити в ньому wp-load.php і виконати Ajax в ньому ж.
Але це не «шлях WordPress» — це не ефективна практика. Тим більше що це не так безпечно, і тим самим ви втрачаєте багатьох корисних функцій WordPress.
Правильний спосіб полягає у використанні звернень wp_ajax_my_action і wp_ajax_nopriv_my_action. Основна відмінність між ними полягає в тому, що перше звернення використовується для зареєстрованих користувачів, а друге — для незареєстрованих.
Зверніть увагу, що «my_action» замінюється на ім’я конкретної дії. Ми розглянемо, як це працює трохи нижче.
Давайте розглянемо все це на простому прикладі з невеликою кількістю коду. Давайте уявимо, що ми хочемо вивести 5 записів, коли будь-який користувач (зареєстрований чи ні) натискає кнопку. Ми назвемо це дія cool_ajax_example, і приступимо до додаванню функції зворотного виклику Ajax, яка буде повертати дані.
Ви можете увімкнути цей код у файлі functions.php або всередині плагіна:
//Спочатку ми додаємо звернення дій
add_action(‘wp_ajax_cool_ajax_example’, ‘cool_ajax_example_callback’ );
add_action(‘wp_ajax_nopriv_cool_ajax_example’, ‘cool_ajax_example_callback’ );
function cool_ajax_example_callback() {
…
}
Як бачите, обидва звернення використовують ту ж саму функцію зворотного виклику, яка буде повертати дані. Також зверніть увагу, що ім’я нашого дії включається в кінці імені обігу wp_ajax_cool_ajax_example.
Дуже важливо скрізь вставляти ім’я дії, інакше це не буде працювати взагалі. Перш ніж ми продовжимо роботу з функцією зворотного виклику, давайте розглянемо JQuery, необхідний для виклику Ajax.
Скрипт JQuery буде спрацьовувати, коли ми натискаємо просту HTML-кнопку, цей запит ми повинні відправити до файлу admin-ajax.php, який є сценарієм, обробляють всі Ajax запити в WordPress.
Також нам потрібно додати nonce, і так як ми вже говорили про те, що хочемо дотримуватися безпеку, то тут задіється функція wp_localize_script.
Якщо ви включили скрипти коректно, так, як було описано на початку цієї статті, у вас має бути ім’я обробника скрипта (в нашому прикладі ‘script-handler’), тому давайте використовуємо його, щоб передати значення PHP нашому файлу javascript. Ви можете увімкнути цей фрагмент коду відразу після функції wp_enqueue_function, використовуваної для включення JavaScript:
wp_localize_script(
‘script-handler’,
‘MyVarName’,
array(
‘ajax_url’ => admin_url( ‘admin-ajax.php’ ),
‘nonce’ => wp_create_nonce( ‘return_posts’ )
)
);
Як бачите, wp_localize_script — досить простий спосіб передати будь-яку змінну PHP файли JavaScript, і завдяки тегу
