Як створити API для мого плагіна?

Я розробляв плагіни для WordPress, більшість розроблених я плагінів використовують два-три класи, отже, не такі величезні, як Buddypress або WooCommerce.

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

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

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

Ваша порада мені дуже допоможе ... Дякую

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

Я є дописувачем для декількох плагінів з API, і це я дізнався до цього часу:

1. Не пропонуйте API, поки ви дійсно не дізнаєтесь, як люди використовують ваш код.

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

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

2. Подумайте про відокремлення вашого API від решти коду (див. Попереднє посилання для ідеї).
   Ваш API повинен бути корисним не тільки для сторонніх розробників, але і для вас. Не додайте обмежень для себе, якщо цього не потрібно.

3. Їжте власну собачу їжу.
   Якщо ви пропонуєте власні гачки, використовуйте їх у своєму коді. Це дасть іншим розробникам корисні приклади, і ви зможете побачити можливі недоліки досить скоро.
   Якби ядро ​​WordPress використовувало б так званий API настройки всередині, ми не мали б цього безладу сьогодні. Можливо.

4. Подавати приклад.
   Використовуйте хороші частини основного API WordPress у своєму плагіні. Уникайте анонімних об'єктів , констант, глобальних змінних та будь-якого непередбачуваного коду .

5. Переконайтеся, що ви використовуєте послідовну схему іменування (не такий безлад ), і покладіть все під власний простір імен.

6. Спершу напишіть документацію. Пізніше випустіть новий (частину) API.
   Створіть корисні приклади для всього. Ви будете здивовані, побачивши, скільки дірок і надмірностей ви знайдете.

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

8. Альтернативою парадигмі зворотного виклику WordPress може бути шаблон спостерігача . Це може поставити бар'єр для сторонніх розробників, але це може призвести до кращого коду з обох сторін.