Це остання стаття серії. Якщо ви тільки що прийшли, я раджу вам познайомитися з двома попередніми статтями. В них ми висвітлили наступні питання:

Поради з розробки додатків для WordPress

  • стандарти коду WordPress;
  • як уникнути конфліктів імен в глобальному просторі імен (префікси і класи);
  • коментарі в коді;
  • безпека.

Більше порад по розробці додатків для WordPress

  • правильний спосіб додавання скриптів і стилів (register, enqueue і localize);
  • AJAX-виклики;
  • фільтри та події.

У цій заключній, статті циклу я розповім про три важливі речі, які вкрай важливі для написання якісного коду, хоч і не впливають на нього безпосередньо.

1. Налагодження

Найперше, що ви повинні зробити, перш ніж почати писати код плагіна – дозволити налагодження, як це рекомендує документація WordPress. Так ви побачите все, що відбувається в системі: помилки, попередження, інформацію інтерпретатора.

Щоб дозволити налагодження, додайте в ваш файл wp-config.php наступний код:

define(‘WP_DEBUG’, true);

Перезавантаживши сторінку, ви побачите докладну зведення потенційних проблем, включаючи попередження про використання застарілих функцій WordPress. Якісний плагін зобов’язаний показувати користувачеві одну і ту ж картинку незалежно від того, чи включений режим відладки або вимкнений: жодних попереджень, зауважень і т. д.

Якщо ви хочете зберегти дані про помилки у файлі замість їх виведення в браузер, ви можете додати до оголошення WP_DEBUG наступні директиви:

// all errors will be saved to a debug.log log file inside the /wp-content/ directory
define(‘WP_DEBUG_LOG’, true);
// not display errors in HTML
define(‘WP_DEBUG_DISPLAY’, ‘false’);

Інша опція режиму відладки, яку я часто використовую, зберігає всі запити до бази даних у масив. Вона виглядає так:

define(‘SAVEQUERIES’, true);

Зазвичай я використовую всі ці налаштування (особливо останній) спільно з плагінами Debug Bar і Debug Bar Console. Якщо ви ще не знаєте про них, спробуйте відразу їх встановити і почати використовувати при налагодженні плагіна або теми. Ви побачите, як це спростить роботу.

Тут ви можете ознайомитися з повним списком плагінів, які я використовую при розробці.

2. Документація

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

Я рекомендую розділяти документацію на секції або розділи, найважливішими з яких повинні висвітлювати такі питання:

  • установка;
  • настроювання;
  • короткий посібник по використанню;
  • часто виникають питання;
  • вимоги.

Потім, в залежності від специфіки вашого плагіна, ви можете додати інші секції або розділи документації. Вивчення документації до існуючим продуктам дозволить вам зрозуміти, що я маю на увазі.

Якщо ваш плагін створює фільтри або функції зворотного виклику, їх опис краще винести на окремі сторінки.

Вкладки

Вкладки в довідці – відмінний спосіб допомогти користувачам в роботі з плагіном або темою, не переводячи їх на інший сайт. Зазвичай інформація в цих вкладках залежить від контексту поточної сторінки:

Наприклад, один з моїх плагінів, Social PopUP, використовують вкладку довідки, щоб пояснити використання шорткодов:

Завершальні поради з розробки додатків для WordPress

Якщо ви хочете відображати інформацію про класах, використовуваних у вашому плагіні, на сторінці створення публікації користувальницького типу, то можете використовувати такий код:

/**
* Initialize the plugin by loading admin scripts & styles and adding a
* settings page and menu.
*
* @since 1.0.0
*/
function __construct(){
[…]
//Help Tab
add_action( ‘load-post.php’, array( $this, ‘my_admin_add_help_tab’) );
}
/**
* Add help tab to the spucpt post type
* @since 1.0
* @return void
*/
function my_admin_add_help_tab () {
$screen = get_current_screen();
if( ‘spucpt’ != $screen->id ) {
return;
}
// Add my_help_tab if post type is spucpt
$screen->add_help_tab( array(
‘id’ => ‘my_help_tab’,
‘title’ => __( ‘Shortcodes’ ),
‘content’ => ‘Hello content goes here’,
) );
}

Важливо упевнитися, що ідентифікатор екрана відповідає користувача типом публікації. В іншому випадку ця довідка буде з’являтися скрізь.

Для додавання довідки на сторінку опцій ви можете скористатися кодом, який наведено як зразок у кодексі WordPress:

add_help_tab( array(
‘id’ => ‘my_help_tab’,
‘title’ => __( ‘My Help Tab’ ),
‘content’ => ‘

‘. __( ‘Descriptive content that will show in My Help Tab-body goes here.’ ) . ‘

‘,
) );
}
?>

Як мені здається, користувачі рідко звертають увагу на вкладки довідки. Деякі взагалі не знають про їх існування. Тому не завадить помістити короткі підказки безпосередньо в інтерфейс плагіна.

3. Інтернаціоналізація

Інтернаціоналізація (AKA i18n, тому що між першою «i» і останній «n» в слові «Internationalization» поміщається рівно 18 літер) – це вишенька на торті, що символізує якісний програмний продукт.

WordPress використовується людьми у всьому світі, так що перед випуском плагіна або теми необхідно переконатися в тому, що при бажанні люди зможуть перевести їх на свою рідну мову.

У чому різниця між інтернаціоналізацією і локалізацією?

Інтернаціоналізація (i18n) – це процес побудови програмного продукту, який може бути легко перекладений на інші мови. Локалізація (l10n) – власне процес перекладу.

Як WordPress підтримує переклад?

WordPress використовує популярну бібліотеку gettext, роботу якої можна стисло описати так:

  • розробники обертають перекладні рядка виклик спеціальної функції;
  • спеціальні утиліти розбирають код, виділяють з нього рядки, які потребують перекладі, і зберігають їх у файлах формату POT (Portable Object Template);
  • перекладачі працюють з POT-файлами, а результат їх роботи виражається в PO-файлів (той же POT, тільки з перекладом);
  • PO компілюється в бінарний формат MO для прискорення доступу до рядків під час виконання програми.

Як створювати складні рядки?

Насамперед, вам потрібно вибрати ідентифікатор text-domain, який буде використовуватися для пошуку і огортання перекладаються рядків. Цей номер повинен збігатися з слагом плагіна.

Є кілька способів створити складні рядки в залежності від способу їх використання: використовується рядок як змінна, що виводиться на екран за допомогою echo і т. д. Найбільш часто використовуваними функціями-обгортками є __() і _e(). Давайте розглянемо їх застосування на конкретних прикладах:

// creating a variable
$hello = __( ‘Hello, Im a translatable string’, ‘my-text-domain’ );
echo ‘

‘. __( ‘Hello, Im a translatable string’, ‘my-text-domain’ ) . ‘

‘;
// to do an echo you can use
_e( ‘Hello, Im a translatable string’, ‘my-text-domain’ );
// When you have variables in the string you do:
printf( __( ‘We deleted %d posts.’, ‘my-text-domain’ ), $count );
// Or multiple variables
printf( __( ‘Your name is %1$s, and your last name is %2$s.’, ‘my-text-domain’ ), $name, $lastname );

Інша корисна функція – _n() – використовується для множини. Ця функція приймає 4 аргументу:

  • singular – форма однини;
  • plural – форма множини;
  • count – кількість об’єктів, яке визначає, яка форма буде використана;
  • text domain – ідентифікатор text-domain.

Якщо повернутися до попереднього прикладу, то переписати його з застосуванням _n() можна наступним чином:

printf( _n( ‘We deleted one post.’, ‘We deleted %d posts.’, $count, ‘my-text-domain’ ), $count );

Якщо вам доведеться переводити рядки, використовувані в JavaScript, ви можете передати їх туди за допомогою функції wp_localize_script(), яку ми обговорювали у другій статті цього циклу:

wp_enqueue_script( ‘script-handle’, … );
wp_localize_script( ‘script-handle’, ‘objectL10n’, array(
‘alert’ => __( ‘This is an alert message’, ‘my-text-domain’ ),
‘submit’ => __( ‘Submit’, ‘my-text-domain’ ),
) );

Включення перекладу плагіна

Ми вже розмістили обгортки для всіх перекладаються рядків. Саме час включити переклад. Для цього ми помістимо функцію ініціалізації плагіна наступний код:

function myplugin_init() {
$plugin_dir = basename( dirname( __FILE__ ) );
load_plugin_textdomain( ‘my-text-domain’, ‘false’, $plugin_dir );
}
add_action( ‘plugins_loaded’, ‘myplugin_init’ );

Цей код буде намагатися завантажити з каталогу вашого плагіна MO-файл з ім’ям my-text-domain-{locale}.mo. Частина {locale} буде замінена на код мови в залежності від мовних налаштувань файлу wp_config.php. Наприклад, якщо моя мова налаштований так:

define (‘WPLANG’, ‘es_ES’);

файл, який WordPress спробує завантажити, буде називатися my-text-domain-es_ES.po. З темами справа йде приблизно так само, плюс необхідно додати в файл functions.php такий код:

load_theme_textdomain( ‘my_theme_textdomain’ );

Основна відмінність полягає в тому, що система буде шукати файл {locale}.mo замість my-text-domain-{locale}.mo, як у попередньому прикладі.

Додаткові відомості про i18n містяться в Кодексі WordPress.

Висновок

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

Я намагався зібрати всю інформацію, яка була б важлива для мене тодішнього, здебільшого переробляючи і підсумовуючи голови з Кодексу WordPress. Я міг багато чого втратити, але, тим не менш, мені здається, що викладеної інформації цілком достатньо для використання початківцям розробником в якості фундаменту.

Буду радий, якщо ви приймете участь в обговоренні цієї серії статей.

Переклад статті «Final Tips for Best Practices in WordPress Development» був підготовлений дружною командою проекту Сайтостроение від А до Я.