Как создать 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 может быть шаблон Observer . Это повысит барьер для сторонних разработчиков, но может привести к улучшению кода с обеих сторон.