Зі зростанням популярності WordPress все більше коду створюється користувачами, розробниками та агентствами. У ході тривалої роботи з WordPress нерідко дивуєшся, як багато розробників наступають на ті самі граблі знову і знову. всі типові помилки у розробці під даний двигун я вирішив зібрати в одному пості та обговорити їх з вами, щоб покращити якість коду для цієї платформи.
Що не так із вашим кодом?
Вбийте в пошук Google запит WordPress - і отримайте 1,9 млрд результатів. Це — мільйони сайтів з прикладами коду, настільними посібниками та сніпетами, які стануть у нагоді будь-якому WordPress-розробнику. Але є 2 проблеми:
- Люди не дотримуються стандартів написання коду для WordPress
- Люди займаються бездумним "копіпейстом".
І з цих 2 причин новачок у розробці під WordPress, що проводить пошук відповідей на питання, що цікавлять його / її в Google, знаходить статтю, копіює з неї код, вставляє в свою тему або сайт - і все працює! На радощах можна зробити закладку на даний сайт. Але проблема в тому, що наведений текст може бути далеким від досконалості, але ви новачок, і проблем у цьому коді ви не помітите. Він просто працює, і ви його можете вічність використовувати у незмінному вигляді.
Давайте розберемо, як уникнути такої помилки.
Стандарти написання коду під WordPress
WordPress передбачає, що деякі частини коду в структурі WordPress і розмітки для PHP залишаються незмінними, інші ж треба змінювати і вдосконалити задля досягнення стабільності і стандартизації всім типів коду під даний движок. Тому не має значення, чи ви створюєте тему або плагін, для них використовуються єдині стандарти написання коду.
Якщо ви досі не читали статтю за посиланням вище, то обов'язково прочитайте її! З цієї статті має в принципі розпочинатися робота будь-якого новачка у створенні коду для WordPress. Витратьте трохи часу на її прочитання.
Самому доводиться практично деякі правила порушувати, але в основному треба зберігати принципи, які там описані. Допускається використання альтернативного синтаксису для структур управління кодом. Тож його легше читати.
І пам'ятайте: єдність стилю та збереження стандартів створення коду - один із тривалих, але ефективних шляхів до створення "чистого" та зручного у використанні коду для даної платформи!
Codex, Codex та ще раз Codex
Усі стандарти та вимоги до коду зібрані у зручному вигляді у форматі єдиного ресурсу для розробників під назвою Кодекс WordPress. Він доступний більш ніж на 50 мовах, і його можна назвати свого роду "біблією розробника" для даної платформи. Тут задокументовані можливості, опис та вимоги практично до кожної функції, класу, змінної WordPress, шляхи їх використання та практичні приклади коду. Працюючи з новими темами, постами, сайтами радимо тримати відкритими хоча б кілька вкладок зі статтями з "Кодексу".
Чудовий бік Кодекс полягає в тому, що це — живе ком'юніті і документація з будь-яких питань, що постійно оновлюється, найбільш динамічно оновлювана база знань з розробки під WordPress, в яку і ви можете робити свій внесок, ділитися знаннями і зберігати стандарти створення коду.
Радимо для ефективної роботи з Кодексом користуватися пошуком. Як на будь-якому Wiki-подібному сайті, навігація тут дещо ускладнена і на перший погляд здається позбавленою будь-якої стандартної логіки. Якщо ви не змогли знайти те, що вам потрібно, скористайтесь каналом #WordPress IRC і попросіть допомоги у спільноти там.
Виберіть відповідні інструменти для роботи
Тепер коли ми трохи розібралися зі стандартами та їх дотриманням, давайте перейдемо до самого коду.
<head> <link rel='stylesheet' href='style.css' type='text/css' media='screen' /> <script type='text/javascript' src='js/mysite.js'></script> <title>Hello</title> </head>
Наведений вище сніпет - типовий приклад перших рядків коду в більшості тем для WordPress. Але скрипти та стилі можна організувати куди ефективніше, і для цієї мети у WordPress є ціла низка функцій та можливостей для роботи з ними. І кожен плагін, який вимагає скриптів чи стилів, також можна організувати аналогічно. Використовуйте функції wp_enqueue_style() и wp_enqueue_script ()! Якщо ви не знаєте, для чого ці функції, саме час з'ясувати, навіщо вони нам потрібні.
Оголошення змінних та даних у явному вигляді для WordPress
Незалежно від того, чи йдеться про скрипт або про стиль оформлення, WordPress повинен знати про них у явному вигляді. Зробити це можна за допомогою wp_register_script() або wp_register_style(). Це – безпечні та надійні способи реєстрації нових скриптів та стилів у WordPress. Ці функції нічого не вводять і не виводять на сайті, а просто готують ваш двигун до правильної роботи з основними функціями та стилями, що використовуються.
<?php wp_register_script( $handle, $src, $deps, $ver, $in_footer ); wp_register_style( $handle, $src, $deps, $ver, $media ); ?>
$handle (Обов'язковий параметр). Тут задається ваше ім'я для таблиці стилів або скрипт. Довжина та вигляд його може бути будь-яким. Також можна додавати префікси, щоб уникнути конфлікту коду у майбутньому.
$src (Обов'язковий параметр). Тут вказується адреса таблиці стилів чи скрипта. Адреса може бути як зовнішньою, так і внутрішньою залежно від ваших завдань та операцій. Зовнішня адреса потрібна, якщо ви використовуєте сторонні рішення на кшталт Type Kit, Google шрифти або соцмедіа-коди на основі Javascript. Вкрай не рекомендуємо вам ніколи жорстко прописувати код у випадку з локальними адресами та скриптами, для цієї мети є функції, про які йтиметься далі.
$deps (Опціональний параметр). Досить корисний, т.к. дозволяє вказати масив залежностей для конкретного скрипта або таблиці стилів, а також забезпечує завантаження цих залежностей до того, як завантажено сам скрипт або стиль.
$ver (Опціональний параметр). Тут ви вказуєте конкретну версію скрипта, який ви використовуєте. Корисний цей параметр тим, що ви завжди знатимете, що для сайту використовується коректна версія плагіна або коду незалежно від того, що раніше зберігалося в кеші браузера. Також ви можете додатково оптимізувати роботу сайту за даним параметром за рахунок невеликого "фокусу" з встановлення динамічних номерів для версій плагінів або коду.
$in_footer (опціональний параметр тільки для скриптів). Зазвичай скрипти розміщують усередині тегів.голова>; але часом даний параметр використовується для приміщення конкретного скрипта всередині тегатіло>. Якщо ви хочете виводити результат роботи скрипта в "підвалі" сайту, то вам треба просто помістити функцію wp_footer() у потрібному місці в рамках вашої теми.
$media (Опціонально, тільки для стилів). Використовується для визначення медіа-контенту, для якого визначено конкретну таблицю стилів (Приклад: 'всі','екран','портативний','друк').
Зведемо всі перелічені параметри на один практичний приклад:
<?php
function tuts_register_stuff() {
wp_register_script( 'my-script', get_template_directory_uri() . '/js/my-script.js', array( 'jquery' ), 1.0, true );
wp_register_style( 'my-style', get_template_directory_uri() . '/style.css', array(), 1.0, 'screen' );
}
add_action( 'wp_enqueue_scripts', 'tuts_register_stuff' );
?>Якщо коротко, то ми маємо JavaScript, який ми викликаємо з папки з нашою темою оформлення, і він залежить від jQuery-запиту в версії 1, а результат виводиться у нижній частині сторінки. Також у нас є файл стилів style.css, який ми викликаємо з папки з поточною темою, у нього немає залежностей, у нього версія 1.0 і він з'являється на екрані. Також важливо пам'ятати, що нам треба виконувати всі ці скрипти послідовно з використанням коду, який активує їхню дію. У цьому випадку для цієї мети використовується wp_enqueue_scripts, що рекомендовано стандартами Кодекс.
Все досить просто і легко, якщо привчити себе до такого стилю роботи з кодом.
Залишіть складну роботу для WordPress
Ми зареєстрували наші скрипти та стилі та вказали їх призначення та шляхи у явному вигляді для WordPress, а тепер ми можемо використовувати їх на практиці. Повертаючись до функцій wp_enqueue_script () и wp_enqueue_style(), можу сказати, що ви можете включити використання стилів та скриптів, які ми зареєстрували на попередньому етапі. Скрипти та стилі будуть працювати аналогічно до зареєстрованих функцій. Основна різниця полягає в тому, що тепер WordPress виводитиме JavaScript або певний стиль на ту сторінку, яка згенерована в результаті виконання тієї чи іншої функції.
<?php
function tuts_enqueue_stuff() {
wp_enqueue_script( 'my-script' );
wp_enqueue_style( 'my-style' );
}
add_action( 'wp_enqueue_scripts', 'tuts_enqueue_stuff' );
?>Запит до раніше зареєстрованих скриптів та стилів відбувається досить легко. Вся принадність цього методу полягає в тому, що ми викликаємо певні скрипти, функції та стилі тільки тоді, коли вони нам потрібні, а не запитуємо їх постійно і безперервно. Ось як це виглядає на практиці:
<?php
function tuts_scripts_and_styles() {
wp_register_script( 'global', get_template_directory_uri() . '/js/global.js', array( 'jquery' ), 1.0, true );
wp_register_script( 'home-page', get_template_directory_uri() . '/js/home-page.js', array( 'jquery' ), 1.0, true );
wp_register_style( 'global', get_template_directory_uri() . '/style.css', null, 1.0, 'screen' );
wp_register_style( 'sliders', get_template_directory_uri() . '/css/sliders.css', null, 1.0, 'screen' );
if ( is_home() ) {
wp_enqueue_script( 'home-page' );
wp_enqueue_style( 'sliders' );
}
wp_enqueue_script( 'global' );
wp_enqueue_style( 'global' );
}
add_action( 'wp_enqueue_scripts', 'tuts_scripts_and_styles' );
?>Ми коректно зареєстрували наші скрипти та стилі та створили до них цільові запити. І ми маємо скрипт і стиль лише для головної сторінки, які запитуються заданим твердженням лише тоді, коли вони нам потрібні.
Перед вами — чудовий приклад подолання однієї з самих великих помилок, які можна зустріти, переглядаючи теми та плагіни, створені іншими авторами-розробниками. Вивчивши кілька простих функцій для WordPress, ви зможете завантажувати свої стилі та скрипти набагато надійніше і при цьому зберегти пов'язані з ними залежності. А якщо хтось скачав ваш скрипт і хоче використовувати його самостійно, то у нього не знадобиться багато часу та зусиль на налаштування даного скрипта чи плагіна під свої потреби. Все, що знадобиться — просто скопіювати ваш CSS у свою тему, заново зареєструвати інший стиль оформлення та використовувати код на своєму сайті!
Щоразу, коли ви використовуєте свою бібліотеку JavaScript, у світі гине 1 кошеня
&amp;lt;script src=&quot;//ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js&quot;&amp;gt;&amp;lt;/script&amp;gt;
Хіба що таким твердженням можна змусити розробників НЕ додавати рядок коду, який наведено вище. Ми вже раніше обговорили важливість реєстрації та створення цільових запитів до ваших скриптів і стилів, так навіщо всю зроблену роботу зводити на нуль?
WordPress поставляється з тонною скриптів, які можна використовувати, просто створивши цільові запити до них. Ви звичайно можете зняти реєстрацію з скрипта, що поставляється "з коробки" і зареєструвати власний скрипт. Може, вам потрібна для роботи версія під Google CDN. Але якщо ви використовуєте таке рішення не для свого власного сайту, а на сторонньому сайті, то дотримуйтесь тих бібліотек, які вже є у встановленому движку. Сторонні плагіни можуть вийти з ладу, працювати некоректно, а теми можуть "зламатися", якщо ніхто не дотримуватиметься правил роботи з кодом та його інтеграції.
Нещодавно ми виявили 3-4 різних версії jQuery на різних сайтах просто тому, що люди неправильно реєструють та запитують плагіни, створюють авторські версії стандартних плагінів тощо. Надайте послугу собі та іншим: дотримуйтесь же певних стандартів!
Попереджаємо: Плагіни та теми, які використовують бібліотеки, що не входять до постачання движка, будуть відхилені при спробі додати їх до каталогів ThemeForest и wordpress.org!
І коротко відзначимо пару важливих моментів щодо jQuery. Ці скрипти масово використовує безліч людей, багато тем та плагінів побудовані на даному коді. А проблема в тому, що дуже часто він використовується некоректно. Бібліотека jQuery постачається у складі WordPress у режимі ніякого конфлікту. Це дозволяє цій бібліотеці працювати нормально паралельно з іншими бібліотеками під час використання їх у WordPress. Але режим no-conflict не підтримує роботу ярликів $, і тому його замінили дещо довшим jQuery.
$(document).ready(function() {
$(#myfuntion) ...
});Наведений вище код треба переписати, щоб він працював коректно, і найпростіше це зробити з використанням наступного коду:
jQuery(document).ready(function($) {
$(#myfunction) //Now $() works as an alias for jQuery() inside this function!
});Проблема використання зовнішньої версії jQuery полягає в тому, що він може не підтримувати завантаження в режимі no-conflict, призвести до поломки інших скриптів та конфлікту правил написання різних скриптів на основі JavaScript. Завжди спробуйте спочатку в роботі встановлені в поставці бібліотеки, а також намагайтеся створювати код JavaScript/jQuery в безконфліктному режимі!
Тут ви можете прочитати про те, як правильно використовувати WordPress та jQuery відповідно до вимог Codex.
Розберіться в шляхах та адресах
Як ви отримуєте адресу до папки з вашою темою? Як ви перенаправляєте людей на головну сторінку вашого сайту? Безліч розробників досі не знають таких базових речей у роботі з WordPress. Наведемо лише базові правила:
Адреса до розташування теми
Якщо ви використовуєте TEMPLATEPATH або bloginfo( 'template_directory'), то вистачить вже це робити! Вам варто використати вкрай корисний параметр get_template_directory(). Усього є 4 варіанти цієї функції:
- get_template_directory() - Повертає шлях до вашої папки з темою. Корисно використовувати у складі PHP-функцій та вкладень.
- get_template_directory_uri() - Вказує адресу папці з темою. Підходить для створення запитів та реєстрації скриптів та стилів, а також якщо ви хочете увімкнути графіку або вкладення.
- get_stylesheet_directory() — Вказує шлях до папки з таблицею стилів. Завжди буде вказувати на дочірню темуякщо така використовується, де get_template_directory() завжди вказуватиме на батьківську тему.
- get_stylesheet_directory_uri() дає адресу до папки з таблицею стилів. Також вказуватиме на дочірню тему за її наявності.
Переконайтеся, що ви використовуєте правильну функцію, якщо бажаєте, щоб користувачі бачили дочірню тему замість батьківської.
Розташування плагінів
Тут можна використати 2 різних функцій:
- plugin_dir_url() - Видає URL самого плагіна.
- plugin_dir_path() - Видає шлях до папки, що містить плагін.
З плагінами завжди краще відразу задати константи, а потім використовувати їх у подальшій роботі.
<?php if ( ! defined( 'MY_PlUGIN_URL' ) ) define( 'MY_PLUGIN_URL', plugin_dir_url( __FILE__ ) ); if ( ! defined( 'MY_PLUGIN_PATH' ) ) define( 'MY_PLUGIN_PATH', plugin_dir_path( __FILE__ ) ); require_once( MY_PLUGIN_PATH . '/my-file.php' ); ?>
Отримання адреси вашого сайту
Ви хочете задати просте посилання на вашу домашню сторінку? Перестаньте використовувати для цієї мети bloginfo(). Нижче приклад того, як це зробити правильно:
<a href="<?php echo home_url( '/' ); ?>">This is a link to our home page</a>
Якщо ви в чомусь сумніваєтеся, відкрийте та почитайте Кодекс. Використання коректних функцій у вашому WordPress — запорука того, що жоден із плагінів, фрагментів коду і жодна з тем не конфліктуватиме з іншими під час виконання. Немає нічого гіршого, ніж розгрібати баги та збої, породжені встановленням чергового плагіна, який не відповідає правилам!
Плагін чи тема?
Навколо цього дискусія не згасає у спільноті розробників уже давно. Чи варто поміщати основну функціональність у саму тему чи плагіни? На це питання є дуже проста відповідь: чи буде працювати бажана функціональність, якщо ви зміните тему оформлення? Ви додали інший тип роботи з постами або вікон для перегляду / прокручування зображень - чи буде воно працювати в будь-якій іншій темі, крім даної, в яку ви додали? Немає нічого гіршого, ніж убити купу часу на кастомізацію контенту та додавання нової функціональності, щоб змінивши тему оформлення на нову, виявити, що все відійшло в небуття.
Отже правило просте: якщо можете зробити плагін - зробіть плагін і в нього вкладіть все, що вам потрібно змінити у візуальній структурі чи дизайні сайту. Плагіни власними силами за функціональність не відповідають. Найчастіше достатньо перевірити, що і як відображають плагіни на сторінках вашого сайту. При цьому ви можете змінити вигляд сайту без необхідності кардинально перекроювати обрану тему оформлення і без ризику втратити ваш контент. Якщо всю функціональність розбити на блоки і помістити їх у вигляді окремих сніпетів коду, то ваш користувач завжди може вибрати, що йому треба з функціональності/візуального оформлення, а що можна/потрібно йому відключити. Наприклад, якщо їм не подобаються запропоновані за замовчуванням кнопки для соц. мереж, дайте їм можливість відключити ці кнопки або замінити їх на власні і т.д. Більше плагінів — менше складних налаштувань у темі оформлення: все просто!
Фільтри коду для дій та готові коди — чому ви досі не використовуєте їх?
Ще один момент, якого хотілося б торкнутися — це практичні посібники зі створення фільтрів для дій та поведінки користувача, сценаріїв тощо. Не має значення, який вид розробки під WordPress ви практикуєте, раджу докладно вивчити можливості сценаріїв дії та фільтрів. У WordPress відмінне API для тем і розробки плагінів, і розробку можна вдосконалити за рахунок використання інструментів, які пропонує WordPress. Плагіни дозволяють можливості фільтрів та дій шляхом кастомізації, що досить просто зробити.
Приклад - WooCommerce від WooThemes. Майже все в цій темі можна вимкнути або налаштувати під свої потреби, просто застосувавши фільтри до дій або вимкнувши певні дії. Їхній підхід Action and Filter Reference Досить прогресивний і дозволяє вам робити з темою практично все, що завгодно. Звичайно, від вас не потрібно власні проекти робити такими ж гнучкими і прогресивними в плані сценаріїв користувача та можливих дій з налаштування теми сайту, але якщо ваш код можна легко кастомізувати без необхідності бути "блогохакером", то люди охочіше будуть використовувати вашу тему оформлення і рекомендувати її іншим. Користувальницькі сценарії дій і фільтри - одна з найважливіших "штук", яким варто повчитися в роботі з WordPress, і витрачений час окупиться - ось побачите!
Висновок
У цій статті ми обговорили багато тем, і сподіваюся, що це допоможе. Підіб'ємо коротко підсумки щодо того, що вам потрібно робити:
- Дотримуйтесь стандартів написання коду для WordPress.
- Зберігайте цілісність коду та єдність стилю.
- Використовуйте документацію та зробіть Codex своєю "Біблією розробника".
- Використовуйте функції для вирішення багатьох завдань.
- Двічі подумайте над тим, де ви розміщуєте свій код.
- Використовуйте сценарії дій та фільтри.
Коли копіюєте та додаєте код, знайдений за допомогою Google, постарайтеся викроїти хвилинку, прочитати код і застосувати до нього одну або кілька перелічених вище порад. Чи відповідає цей код стандартам Кодекс? Чи він використовує коректні функції? Що в ньому робить jQuery? І наступного разу, коли виявите помилку, виправте її.
Джерело:WP.tutsplus.com
Коментарі до запису: 6
КОД
КОД
КОД
=)))
Будь ласка, додайте приклади коду
Виправили!
Найголовнішу функцію забули trailingslashit(), у виведенні всіх шляхів
Можна використовувати jQuery з гугла, але щоб не вмирали кошенята.
Просто замінити jQuery вордпресу на гугловський:
if (!is_admin()) {
wp_deregister_script('jquery');
wp_register_script('jquery', («http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js»), false);
wp_enqueue_script('jquery');
}
Правильно, головне, щоб кошенята були цілі! ))