Engel side

Так як це мій перший досвід перекладу великих технічних текстів, ляпи є. Будь-які виправлення будуть прийняті з радістю;)

Переклад під катом.

написання плагіна

Аж до версії WordPress 1.2, якщо ви хотіли змінити його поведінку, вам потрібно було редагувати (або «хакати») вихідний код WordPress. Однак, в більшості поточних версій WordPress ви можете з легкістю модифікувати функціональність ядра WordPress або додавати нову за допомогою «плагінів». Основна ідея використання розширюється архітектури полягає в тому, щоб при збереженні ядра відносно простим, але досить гнучким, кожен аспект його введення і виведення міг бути змінений за допомогою плагінів. Ось визначення:

Плагін WordPress - це програма або набір функцій, написаних на PHP, які додають певний набір можливостей або сервісів до блогу на WordPress, які легко об'єднуються з системою управління та методами WordPress за допомогою Plugin Application Program Interface (API).

Plugin Resources - всеосяжний список статей та засобів для розробників плагінів, що включає в себе розгорнуті статті з написання плагінів, і статті на специфічні «вузькі» теми.

Інший хороший шлях вивчити пристрій плагінів - це дивитися в вихідні PHP-коди добре написаних плагінів, таких як Hello Dolly. плагін, який входить в базову поставку WordPress.

Якщо ви написали плагін до WordPress, прочитайте Plugin Submission and Promotion. щоб дізнатися, як поширити ваш плагін.

створення плагіна

Ця частина статті дасть вам зрозуміти, які кроки ви повинні зробити для створення гарного плагіна.

Імена, файли, і розташування файлів

ім'я плагіна

Перше завдання при створенні плагіна - подумати, що плагін буде робити, і придумати для нього ім'я (бажано унікальне). Перевірте Plugins і інші сховища, щоб переконатися в тому, що придумане вами ім'я - унікальне; ви можете також погуглити за обраним вами імені. Більшість розробників плагінів вибирають імена, які відображають функціональність їх плагіна; наприклад, плагін для відображення погоди може мати в назві слово «погода». Назва може складатися з декількох слів. (Природно, ваш плагін повинен мати назву англійською мовою. - прим. Перекладача)

файли плагіна

Наступний крок - створення файлу PHP з ім'ям, похідним від назви плагіна. Наприклад, якщо ваш плагін буде називатися «Fabulous Functionality», ви можете назвати ваш файл fabfunc.php. Знову ж, спробуйте створити унікальне ім'я. Люди, які встановлять ваш плагін, покладуть цей файл в свою директорію для плагінів wp-content / plugins /, і два плагіна, які людина використовує, можуть мати однакове ім'я файлу.

У цій статті «PHP файл плагіна» означає головний PHP-файл, який знаходиться в директорії для плагінів або в її піддиректорії.

Файл «Прочитай мене» (Read me)
Домашня сторінка

Також, дуже зручно створити веб-сторінку, яка відіграє роль «домашньої сторінки» вашого плагіна. Ця сторінка повинна пояснювати, як встановити плагін, що він робить, з якими версіями WordPress сумісний, що змінювалося від версії до версії вашого плагіна, і як використовувати плагін.

заголовки файлів

Саме час дати деяку інформацію з приводу вашого головного файлу PHP.

Стандартна інформація про плагін

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

(Природно, все повинно бути по-англійськи - прим. Перекладача)

Мінімальна інформація, яка потрібна WordPress, щоб виявити ваш плагін - його назва (Plugin Name). Решта інформації (якщо вона є) використовується для створення таблиці плагінів на сторінці управління плагінами. Порядок рядків неважливий.

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

програмування плагіна

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

«Пастки» (Hooks) плагіна

Безліч плагінів виконують свої завдання за допомогою з'єднання з одного або більше «пастками». «Пастки» працюють в той час, поки WordPress запущений. WordPress перевіряє, чи мають кілька плагінів однакові зареєстровані функції, і якщо це так, функції запускаються. Ці функції змінюють стандартну поведінку WordPress.

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

Інший приклад - «діюча пастка» під назвою «wp_footer». Перед кінцем HTML-сторінки, яку генерує WordPress, він перевіряє, чи мають якісь плагіни зареєстровану функцію «wp_footer», і запускає її.

Ви можете дізнатися більше про те, як реєструвати функції для фільтрів і «пасток», і які «пастки» доступні в WordPress, в Plugin API. Якщо ви знайшли місце в коді WordPress, де ви хотіли б мати дію або фільтр, але в WordPress його немає, ви можете запропонувати нові «пастки» (пропозиції в основному приймаються); як це зробити, ви можете дізнатися в Reporting Bugs.

Теги шаблонів

Інший шлях додавання функціональності за допомогою плагіна - створення Тегів шаблонів. Той, хто хоче використовувати ваш плагін, може додати ці теги в свою тему, в панель, в секцію вмісту поста, або в інше відповідне місце. Наприклад, плагін, який додає географічні теги до постів, може визначатися функцією тега шаблону під назвою geotag_list_states () в панелі, який складає список усіх посад, помічених гео-тегами, з посиланням на архів сторінок плагіна.

Щоб оголосити тег шаблону, просто напишіть функцію php, і інвентаризують її для користувачів плагіна на вашій сторінці, присвяченій плагіну і / або в головному файлі плагіна. Гарна ідея, документуючи функцію, наводити приклад виконання містить , який потрібно додати в тему для отримання результату.

Збереження даних плагіна в базу

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

Механізм налаштувань (Options) WordPress

WordPress має механізм для збереження, відновлення і вилучення індивідуально названих масивів даних (налаштувань), що зберігаються в базі WordPress. Щоб отримати установки можуть бути рядками, масивами або об'єктами PHP (вони будуть серіалізовані або сконвертовані в рядок перед записом, і разсеріалізовани перед витяганням). Назви налаштувань - рядки, і вони повинні бути унікальними, щоб не конфліктувати з WordPress або іншими плагінами.

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

add_option ($ name, $ value, $ description, $ autoload);

Створює нову настройку; не робить нічого, якщо опція вже існує.

  • $ Name - обов'язковий (рядок). Ім'я настройки.
  • $ Value - необов'язковий (рядок), за замовчуванням порожній рядок. Значення настройки.
  • $ Description - необов'язковий (рядок), за замовчуванням порожній рядок. Щодо встановлення, яке знаходиться в базі, щоб хто-небудь, що переглядає базу, розумів, що це за настройка.
  • $ Autoload - необов'язковий, за замовчуванням - «так» ( «так» або «ні»). Якщо встановлено «так», настройки автоматично витягуються функцією get_alloptions.

Витягує значення настройки з бази.

  • $ Option - обов'язковий (рядок). Ім'я настройки, значення якої потрібно отримати.

Оновлює або створює значення настройки в базі (примітка: add_option не може бути викликана без використання $ description або $ autoload параметрів).

  • $ Option_name - обов'язковий (рядок). Ім'я настройки для оновлення.
  • $ Newvalue - обов'язковий. Нове значення настройки.
панелі адміністрування

За умови, що ваш плагін має якісь опції, що зберігаються в базі WordPress (див. Розділ вище), ви, ймовірно, захочете мати адміністративну панель, яка дозволить користувачам дивитися і редагувати налаштування вашого плагіна. Методи створення панелей описані в Adding Administration Menus.

інтернаціоналізація плагіна

Після того, як ви закінчили писати ваш плагін, його необхідно інтернаціоналізованних (за умови, що ви плануєте поширювати ваш плагін). Інтернаціоналізація - це процес налаштування програмного забезпечення під локалізацію; локалізація - це процес перекладу на різні мови відображуваного програмою тексту. WordPress використовується по всьому світу, і інтернаціоналізація та локалізація вбудовані в його структуру, в тому числі, і локалізація плагінів. WordPress використовує "GNU gettext" для локалізації (див. Translating WordPress).

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

  • Виберіть ім'я для простору перекладу вашого плагіна. Зазвичай воно таке ж, як ім'я головного файлу вашого плагіна (тільки без .php). Ім'я повинно бути унікальним.
  • Скрізь, де ваш плагін використовує рядки тексту, які будуть показані користувачеві (відомі як «повідомлення»), укладіть їх в одну з двох gettext-функція WordPress. Зауважте, що у вашому плагін ви повинні використовувати другий аргумент - ім'я простору перекладу, яке ви вибрали (в ядрі WordPress цей аргумент залишається порожнім).

Перекладає $ message, використовуючи поточну локаль для $ domain. Помістіть рядки, які збираєтеся використовувати в розрахунках, в цю функцію.

Перекладає $ message, використовуючи поточну локаль для $ domain. Помістіть в цю функцію рядки, які збираєтеся показувати користувачеві.

$ Fabfunc_domain = 'fabfunc';
$ Fabfunc_is_setup = 0;
function fabfunc_setup ()
global $ fabfunc_domain, $ fabfunc_is_setup;
if ($ fabfunc_is_setup) return;
>
load_plugin_textdomain ($ fabfunc_domain, 'wp-content / plugins');
>

Якщо ваш плагін знаходиться у власній піддиректорії, надішліть листа з її ім'я до другого аргументу функції load_plugin_textdomain.

Поради по розробці плагіна

Це остання частина статті, що включає в себе різні поради по розробці плагіна.

  1. Код плагіна повинен відповідати стандартам розробки WordPress (WordPress Coding Standards). Будь ласка, візьміть до уваги стандарти Inline Documentation.
  2. Всі функції вашого плагіна повинні мати унікальні імена, відмінні від імен функцій ядра WordPress, інших плагінів або тем. З цієї причини, хороша ідея - використовувати унікальний префікс для імен функцій вашого плагіна. Інша можливість - оголошувати ваші функції всередині класу (який теж повинен мати унікальне ім'я).
  3. Не використовуйте явно префікс бази WordPress (зазвичай wp_) в вашому плагін. Замість цього використовуйте змінну $ wpdb-> prefix
  4. Читання бази - легкий процес, а ось запис в базу - складний. Бази виключно хороші при складанні даних і їх видачі, ці операції зазвичай виконуються швидко. Внесення змін до бази - більш комплексний процес, отже більш ресурсномісткий. В результаті, постарайтеся зменшити кількість записів в базу. Тримайте все готовим в коді, тоді ви зможете робити тільки ті записи в базу, які дійсно потрібні.
  5. Вибирайте з бази за допомогою SELECT тільки те, що вам потрібно. Навіть незважаючи на те, що бази витягують дані досить швидко, ви можете зменшити навантаження на базу, вибираючи тільки ті дані, які вам потрібні. Якщо вам потрібно підрахувати кількість рядків у таблиці, не використовуйте SELECT * FROM, тому що всі дані всіх рядків будуть займати пам'ять. Подібно до цього, якщо вам потрібні тільки post_id і post_author в вашому плагін, вибирайте SELECT'ом тільки конкретні поля, щоб зменшити навантаження. Пам'ятайте: сотні інших процесів можуть звертатися до бази одночасно з вами. База і сервер можуть тільки розподіляти ресурси між процесами. Вивчіть, як мінімізувати звернення вашого плагіна до бази, щоб гарантувати, що ваш плагін не зловживає ресурсами.

Ну що, наступний переклад з ALA? ;) Просимо-просимо ...

Ти мене експлуатіруешь :)

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

"Hooks" має багато варіантів перекладу - "гачок", "захоплення".
У win api програмуванні "Hooks" перекладається, як "хук" або "пастка" і ось його визначення: механізм в Windows який дозволяє додатку проводити обробку деяких повідомлень до того, як вони будуть передані на обробку.

Велике спасибі за пояснення! Я в англійському технічному словнику визначення знайшла, а от в російських словниках - тиша - (

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

да, це було перше, що прийшло мені в голову.

В переклад примітки до update_option ($ option_name, $ newvalue);
закралася помилка через яку даний опис вступає в явне протиріччя з вищеописаним add_option ($ name, $ value, $ description, $ autoload) ;, де параметри $ description і $ autoload вказані як необов'язкові. За логікою, переклад повинен бути такий: "Зауважте, що add_option не потрібно викликати, якщо ви не хочете використовувати $ description і $ autoload параметри"

Збираюся написати свій плагін. Ваша інформація була найцікавішою. Дякуємо.

Так, інформація корисна. Думаю це правильний підхід - писати плагіни, а не те що я роблю (курочіть WP зсередини) ... :)

спасибі, пішов писати :)

Всенда хотів написати свій плагін, прочитав статтю ... і зрозумів не впораюся :(

Спасибі за відмінний матеріал Вам! Буду у Вас частим гостем)

function widget_freshnews ($ postcat)
global $ wpdb;

register_sidebar_widget ( 'Свіжі Новини', 'widget_freshnews');

віджети прописуються і регістрів в functions.php дизайну, подлючается віджет в дизайн-віджети

Нарешті, перший тлумачний мануал по створенню полігонів російською мовою.

Дуже пізнавально. Дякуємо.

І не соромно? здерла всю статтю з перекладеного codex.wordpress. Тобі -1.

Ну какбе там мій переклад :)

переклад не дуже, видно буржуйський говір

Ну я не перекладач і не претендую.

але все таки у тебе хороші статті, мені свого часу допомогли))

А у тебе випадково немає перекладу на створення адмінській частини плагіна?

$ Value = "hello-world";
$ Name = "hwlink";
add_option ($ name, $ value, null, "yes");

Якщо я виконую цю функцію, вона не заносить нове значення в БД. Чи не знаеш в чому може бути помилка, або може я в параметрах що то не так поставив?

На жаль не знаю. Я вже дуже давно не займаюся Вордпресс.

Вона там є, тому що туди поклали цей мій переклад. Я написанням плагінів давно не займаюся, так що гугл вам на допомогу.

Спасибі, давно теж хотів написати свій плаги для wp

Поправте помилку в перекладі на сайті codex.wordpress.org: «Принцип її дії полягає в тому ...»

Дрібниця, але очі ріже. Соррі, якщо вже писали. Чи не знав куди писати - відписався тут.

resurtm, на жаль, в кодекс переклад додавала не я, і у мене немає прав на його зміну.

Дякую за виконану роботу з перекладу такої цінної інформації. Оч допомогло :)

Схожі статті