У цій серії статей ми плануємо розглянути основні моменти, які слід враховувати при розробці плагіна або теми WordPress.
Метою цього посібника є представити вам набір передових практик, які будуть корисними як для початківців, так і для досвідчених фахівців-розробників, які починають працювати з WordPress.
Однак! Якщо ви вже давно займаєтеся розробкою плагінів WordPress, не поспішайте закривати цю сторінку, вирішивши, що це керівництво не для вас. Я впевнений, що і ви знайдете в ньому щось корисне для себе. Зрештою, кожному з нас є чим поділитися з іншими, чимось унікальним.
Більшість з описаних у цій серії підходів вже висвітлені в Кодексі, але я знаю, що Кодекс містить так багато інформації, що для новачків може бути важко зорієнтуватися в ньому.
У цій статті ми розглянемо такі теми:
Стандарти кодування WordPress;
Як уникнути конфлікту назв функцій;
Код коментарів;
Поради щодо безпеки.
Ми постараємося в цій серії бути як можна більш конкретними, тому в статті будуть включені як приклади ефективного застосування методів, так і приклади типових помилок. Це дасть вам чітке уявлення того, як в WordPress працюють певні речі.
Зверніть увагу, що не все описане в цій серії обов’язково застосовувати при розробці плагінів. Однак якщо ви вже приступаєте до навчання, чому б навчитися робити це правильно?
Я постараюся, щоб статті цієї серії були легкими для розуміння. Я буду включати в статті деякі приклади правильно складеного коду і приклади помилок. Не все описане тут є обов’язковим при створенні плагіна, але якщо ви починаєте роботу з WordPress, чому б не зробити це правильно?
Після того, як це увійде у вас в звичку, ви автоматично будете дотримуватися стандартів, і вам простіше буде вберегтися від помилок.
Стандарти кодування WordPress
Чесно кажучи, це один з моїх самих серйозних недоліків. Якщо ви розробляєте інструменти для WordPress, ви повинні просто слідувати Стандартам кодування WordPress. Це допомагає підвищити читаність коду і уникнути поширених помилок.
WordPress є CMS з публічним використанням і підтримкою, що передбачає таку просту річ, що всі пишуть коди, які прості для читання, редагування і підтримки всіма учасниками процесу.
На початку вам, можливо, буде важко змінити стиль кодування, до якого ви звикли, але, в кінцевому рахунку, ви зрозумієте, що це стає вашою другою натурою, а ваш код стає чистіше і набагато читабельний.
У Керівництві WordPress стандарти діляться по чотирьом основним використовуваним мов:
Стандарти кодування CSS
Стандарти кодування НTML
Стандарти кодування JavaScript
Стандарти кодування PHP
Приклади
Нижче я покажу вам декілька простих прикладів PHP— коду, щоб ви отримали загальне уявлення, про що йде мова.
Другий приклад коду набагато більше читаємо, чи не так? У Посібнику стандартам кодування багато прикладів, які допоможуть вам зробити код чистіше. Ви будете вражені тим, як же просто за допомогою декількох пропусків і відступів значно підвищити читаність коду.
У той час як я займався написанням цієї статті, я якраз купив тему для одного свого клієнта і, коли захотів трохи змінити її код, я був вражений, як же важко це зробити.
Знову ж таки, в залежності від даних, які ви маєте, існують різні функції, які можуть вам допомогти. Для JavaScript ви можете використовувати esc_js.
Крім перевірки самих даних, не забудьте перевірити і дату.
Запобігання прямого доступу до файлів
Більшість хостів забезпечують прямий доступ до файлів. Для вашого плагіна це означає, що, швидше за все, будуть мати місце деякі помилки PHP, і ці помилки стануть цінною інформацією для зловмисників.
Щоб запобігти цьому, ви можете розмістити у верхній частині вашого скрипта дуже простий код:
// Вихід, якщо надано прямий доступ
if ( ! defined( ‘ABSPATH’ ) ) exit;
Це в цілому завадить виконати скрипт, якщо доступ до нього отримано не через WordPress.
Видаліть всі попередження та повідомлення
Зловмисники можуть скористатися не тільки помилками PHP — сповіщення та попередження також включають в себе багато цінного для них інформації. Кожен плагін повинен бути закодований з використанням режиму DEBUG.
Це також дасть зловмисникам обчислити застарілі функції у вашому плагіні. Щоб включити режим DEBUG просто знайдіть рядок у файлі wp-config.php та встановіть значення TRUE:
define( WP_DEBUG, true );
Поряд з цим, я рекомендую використовувати відмінний плагін Debug Bar. Змінивши цю рядок, ви також будете мати можливість аналізувати всі запити до бази даних.
Використовуйте значення Nonce
Nonce-значення — це скорочення від numbers used once (одноразово використані числа), вони використовуються для захисту від помилкових запитів між сайтами, або CSRF.
Іншими словами, це несанкціоновані або дубльовані запити, які можуть призвести до постійних небажаним або навіть незворотних змін на веб-сайті, зокрема в базі даних. Це може статися з вини зловмисників або внаслідок помилок довірених користувачів.
В залежності від того, де вам потрібно застосувати значення Nonce, ви можете створювати його по-різному.
Якщо ви подивитеся на наведений вище приклад, то побачите, як я використовую wp_localize_script (про яку мова піде в наступній статті), щоб включити nonce в блок коду JavaScript. Я роблю це, тому що пізніше планую використовувати JQuery для виконання запиту AJAX, і ви теж завжди повинні включати nonce в виклики AJAX.
Після цього в скрипті, просто для перевірки nonce, використовуйте наступний код:
Завжди перевіряйте, чи можете ви зробити те, що вам потрібно, з допомогою базових функцій і бібліотек WordPress. Таким чином, ваші скрипти будуть менш уразливі, і, якщо в них будуть зафіксовані небезпечні місця, розробники WordPress дізнаються про це і сповістять користувачів.
В якості одного з найбільш відомих прикладів, що ілюструють цю ситуацію, можна навести випадок з бібліотекою TimThumb, яку багато років використовували тисячі плагінів та тем. Одного разу, в 2011 році в ній була виявлена уразливість. Тепер для її усунення ми можемо використовувати вбудовану функцію add_image_size().
Інші поширені функції, укладені в ядрі WordPress, такі як cURL, можуть бути легко замінені на wp_remote_get і wp_remote_post, які не тільки кодують дані, але також пропонують резервні варіанти, якщо cURL працює з помилками.
Ще один приклад — використання get_template_part() замість функцій РНР require() або include().
Хоча вони в основному роблять теж саме, але перша функція вже знає, де розміщується ваша тема, і вона буде шукати потрібний файл у папці цієї теми, вона не буде видавати попередження або помилку, якщо запитуваний файл не існує, вона може шукати інші відповідні файли, якщо запитуваний файл не знайдений, і вона розпізнає дочірні теми і батьківські теми.
Ядро WordPress містить багато скриптів, які ми можемо використовувати в своїх плагінах або темах. Тому завжди пробуйте використовувати їх, перш ніж додавати нові бібліотеки.
Переклад статті «Tips for Best Practices in WordPress Development» був підготовлений дружною командою проекту Сайтостроение від А до Я.
Відвідувачі приходять на Ваш сайт? Якщо Ви веб-майстер www.yandex.ru або www.nike.com відповідь проста: з інших сайтів. Домогтися гарного положення в пошукових машинах і каталогах за силу не всім.