¿Cómo crear una API para mi complemento?

He estado desarrollando complementos para WordPress, la mayoría de los complementos que he desarrollado utilizan dos o tres clases, por lo tanto, no son tan grandes como Buddypress o WooCommerce.

Estoy planeando desarrollar dos complementos de código abierto para entregar algún tipo de sistema complejo (no puedo compartir detalles en este momento, pero más tarde durante el desarrollo) donde otros desarrolladores pueden personalizar las funciones y el sistema para ellos debe ser el mismo que Buddypress y WooCommerce .

Cuando reviso esos archivos de complementos y me doy cuenta de que han registrado sus propias acciones y filtros que los desarrolladores pueden modificar según las necesidades. Sin embargo, mi problema es no poder entender completamente cómo debo escribir un complemento donde otros tengan la flexibilidad de anular funciones y agregar las propias.

Sé que es difícil dar una respuesta definitiva, pero necesito algún tipo de guía de inicio para poder ir en la dirección correcta. ¿Necesito registrar mis propias acciones y filtros? Si es así, ¿cómo? si no, ¿cuáles son mis opciones?

Tu consejo me ayudará mucho ... Gracias

La API que ofrece en un complemento o un tema depende de la lógica de ese código específico. Probablemente no haya una guía que se aplique a todas las situaciones.

Soy colaborador de múltiples complementos con API, y lo que he aprendido hasta ahora es:

1. No ofrezca una API hasta que realmente sepa cómo las personas usan su código.

   Lanza las primeras dos o tres versiones sin ninguna API. Sin acciones o filtros personalizados, sin métodos o funciones públicas (y nunca con variables globales) si es posible. Espere las solicitudes de sus usuarios, pero no agregue el código hasta que sepa que su estructura interna de código funcionará a largo plazo.

   Mantener la compatibilidad con versiones anteriores de una API es difícil . Puede evitar las mejoras necesarias en otros lugares. Piense en todas las variables globales que WordPress no puede eliminar hoy en día. Esa es una API incorrecta, y estamos atrapados con ella durante muchos años, porque la gente ya la usa .

2. Considere separar su API del resto del código (consulte el enlace anterior para obtener una idea).
   Su API debería ser útil no solo para desarrolladores de terceros, sino también para usted. No agregue restricciones para usted si no es necesario.

3. Come tu propia comida para perros.
   Si ofrece ganchos personalizados, úselos en su código. Esto le dará a otros desarrolladores ejemplos útiles, y pronto podrá ver posibles fallas.
   Si el núcleo de WordPress usara internamente la llamada API de configuración , no tendríamos este lío hoy. Tal vez.

4. Predicar con el ejemplo.
   Use las partes buenas de la API principal de WordPress en su complemento. Evite objetos anónimos , constantes, variables globales y cualquier tipo de código impredecible .

5. Asegúrese de utilizar un esquema de nomenclatura coherente (no tan complicado ) y coloque todo bajo su propio espacio de nombres.

6. Escriba la documentación primero. Lanza una nueva (parte de una) API más adelante.
   Crea ejemplos útiles para todo. Te sorprenderá ver cuántos agujeros y redundancias encontrarás.

7. Evite el infierno de devolución de llamada.
   Ofrezca herramientas específicas para depurar su API cuando las cosas no funcionan como deberían (incluidas las secuencias de comandos y las hojas de estilo no minimizadas). He escrito un ejemplo de cómo depurar AJAX , solo para ilustrar cuán creativo puede ser aquí. Nuevamente, estas herramientas deben explicarse en su documentación antes de lanzarlas.

8. Una alternativa al paradigma de devolución de llamada de WordPress podría ser el patrón Observador . Esto elevaría la barrera para los desarrolladores de terceros, pero podría resultar en un mejor código en ambos lados.