Come creare un'API per il mio plugin?

Ho sviluppato plugin per WordPress, la maggior parte dei plugin che ho sviluppato utilizza due o tre classi, quindi non è così grande come Buddypress o WooCommerce.

Sto progettando di sviluppare due plugin open source per fornire una sorta di sistema complesso (al momento non posso condividere i dettagli ma in seguito durante lo sviluppo) in cui altri sviluppatori possono personalizzare le funzioni e il sistema per loro deve essere uguale a Buddypress e WooCommerce .

Mentre controllo quei file plug-in e mi rendo conto che hanno registrato le proprie azioni e filtri che gli sviluppatori possono modificare in base alle necessità. Tuttavia, il mio problema è di non riuscire a capire completamente come scrivere un plugin in cui gli altri hanno la flessibilità di ignorare le funzioni e di aggiungere le proprie.

So che è difficile dare una risposta definitiva, ma ho bisogno di una sorta di guida all'avvio per poter andare nella giusta direzione. Devo registrare le mie azioni e i miei filtri? Se si come? in caso contrario, quali sono le mie opzioni?

Il tuo consiglio mi aiuterà molto ... Grazie

L'API che offri in un plugin o in un tema dipende dalla logica di quel codice specifico. Probabilmente non esiste una guida valida per tutte le situazioni.

Sono un collaboratore di più plug-in con API e quello che ho imparato finora è:

1. Non offrire un'API fino a quando non sai davvero come le persone usano il tuo codice.

   Rilascia le prime due o tre versioni senza API. Nessuna azione o filtro personalizzato, nessun metodo o funzione pubblica (e mai variabili globali) se possibile. Attendi le richieste dei tuoi utenti, ma non aggiungere il codice fino a quando non sai che la struttura del codice interno funzionerà a lungo termine.

   Mantenere la retrocompatibilità di un'API è difficile . Potrebbe impedire i miglioramenti necessari in altri luoghi. Pensa a tutte le variabili globali che WordPress non può rimuovere al giorno d'oggi. Questa è una cattiva API e ne siamo bloccati per molti anni, perché la gente lo usa già .

2. Prendi in considerazione la possibilità di separare l'API dal resto del codice (vedi il link precedente per un'idea).
   La tua API dovrebbe essere utile non solo per sviluppatori di terze parti, ma anche per te. Non aggiungere restrizioni per te stesso se non è necessario.

3. Mangia il tuo cibo per cani.
   Se offri hook personalizzati, utilizzali nel tuo codice. Ciò fornirà ad altri sviluppatori esempi utili e vedrai presto possibili difetti.
   Se il core di WordPress usasse internamente la cosiddetta API delle impostazioni , oggi non avremmo questo casino. Può essere.

4. Dare l'esempio.
   Usa le parti buone dell'API principale di WordPress nel tuo plugin. Evita oggetti anonimi , costanti, variabili globali e qualsiasi tipo di codice imprevedibile .

5. Assicurati di utilizzare uno schema di denominazione coerente (non un tale disordine ) e metti tutto nel tuo spazio dei nomi.

6. Scrivi prima la documentazione. Rilasciare una nuova (parte di un'API) in un secondo momento.
   Crea esempi utili per tutto. Sarai sorpreso di vedere quanti buchi e ridondanze troverai.

7. Evita l'inferno di richiamata.
   Offri strumenti specifici per eseguire il debug dell'API quando le cose non funzionano come dovrebbero (inclusi script e fogli di stile non minimizzati). Ho scritto un esempio di come eseguire il debug di AJAX , solo per illustrare come si può essere creativi qui. Ancora una volta, questi strumenti dovrebbero essere spiegati nella documentazione prima di rilasciarli.

8. Un'alternativa al paradigma di callback di WordPress potrebbe essere il modello Observer . Ciò aumenterebbe la barriera per gli sviluppatori di terze parti, ma potrebbe comportare un codice migliore su entrambi i lati.