Avvio di un wiki della comunità per raccogliere best practice oggettive per lo sviluppo di plugin. Questa domanda è stata ispirata dai commenti di @ EAMann sugli hacker di wp .

L'idea è di collaborare su quali potrebbero essere le migliori pratiche oggettive in modo da poterle eventualmente utilizzare in alcuni processi di revisione della collaborazione della comunità.

AGGIORNAMENTO: Dopo aver visto le prime risposte diventa chiaro che dobbiamo avere solo un'idea / suggerimento / best practice per risposta e le persone dovrebbero rivedere l'elenco per assicurarsi che non ci siano duplicati prima di pubblicare.

Usa azioni e filtri

Se ritieni che le persone vorrebbero aggiungere o modificare alcuni dati: fornisci apply_filters () prima di tornare .

PS Una cosa che trovo un po 'deludente e che la tua domanda riguarda la percentuale di plugin progettati solo per gli utenti finali, cioè che non hanno hook propri. Immagina se WordPress fosse progettato come la maggior parte dei plugin? Sarebbe inflessibile e una soluzione di nicchia.

Forse le cose sarebbero diverse se WordPress avesse la possibilità di installare automaticamente plugin da cui dipendevano altri plugin? Dato che in genere devo scrivere molte funzionalità di cui ho bisogno da zero perché i clienti vogliono le cose in un certo modo e i plugin disponibili, mentre il 90% lì, non mi consente la flessibilità di aggiornare il restante 10%.

Vorrei davvero che coloro che guidavano la community di WordPress identificassero un modo per garantire che i plug-in venissero premiati per aver seguito le migliori pratiche (come l'aggiunta di hook per altri sviluppatori) proprio come le buone risposte sono ricompensate su un sito StackExchange.

Facciamo un esempio da un'altra domanda :

Esempio: voglio fare qualcosa nel mio plugin quando qualcuno ritwittano un articolo. Se ci fosse un gancio personalizzato in qualunque sia il popolare plug-in di retweet su cui potrei collegarmi e sparare, sarebbe fantastico. Non esiste, quindi posso modificare il loro plugin per includerlo, ma funziona solo per la mia copia e non voglio provare a ridistribuirlo.

Relazionato

• Offri moduli estensibili

Carica script / CSS con wp_enqueue_scriptewp_enqueue_style

I plugin non devono caricare / tentare di caricare versioni duplicate dei file JS / CSS, in particolare jQuery e altri file JS inclusi in WP Core.

I plugin dovrebbero sempre usare wp_enqueue_scripte wp_enqueue_stylequando si collegano file JS e CSS e mai direttamente tramite <script>tag.

Relazionato

• Riutilizzare le funzioni esistenti

Supporto I18n

Tutte le stringhe di output devono essere collegate a un dominio di testo appropriato per consentire l'internazionalizzazione da parte delle parti interessate, anche se lo sviluppatore non ha interesse a tradurre il proprio plug-in.

Si noti che è molto importante caricare i file della lingua durante l' initazione in modo che l'utente possa agganciarsi all'azione.

Vedi il codice: I18n per sviluppatori WordPress

E anche questo articolo: caricamento corretto dei file in lingua WP .

Da WordPress 4.6+

WP 4.6 ha cambiato l'ordine di caricamento e le posizioni controllate, lo ha reso molto più semplice per sviluppatori e utenti.

Considerando un plug-in con un dominio di testo "my-plugin", WordPress cercherà ora PRIMA di cercare un file di traduzione in:
/wp-content/languages/plugins/my-plugin-en_US.mo

Se non riesce a trovarne uno, ne cercherà uno in cui il plug-in gli dice di apparire (normalmente nella cartella 'language' di Pluigns se segue il codice):
/ wp-content / plugins / my-plugin / languages ​​/ my- plugin-en_US.mo

Infine, se non viene trovato alcun file di lingua, verrà controllata la posizione predefinita di:
/wp-content/languages/my-plugin-en_US.mo

Il primo controllo è stato aggiunto in 4.6 e offre agli utenti un posto definito per aggiungere un file di lingua, poiché prima avrebbero dovuto sapere dove lo sviluppatore aveva aggiunto il file di lingua, ora l'utente deve solo conoscere il dominio di testo del plugin: / wp-content / lingue / plugins / TEXTDOMAIN-LOCAL.mo

Di seguito è riportato il vecchio modo (non pertinente dal WP 4.6+)

[...]
Infine, vorrei sottolineare che è importante caricare file di lingua utente personalizzati da WP_LANG_DIR prima di caricare i file di lingua forniti con il plug-in . Quando vengono caricati più file mo per lo stesso dominio, verrà utilizzata la prima traduzione trovata. In questo modo i file di lingua forniti dal plugin serviranno da fallback per le stringhe non tradotte dall'utente.

public function load_plugin_textdomain()
{
    $domain = 'my-plugin';
    // The "plugin_locale" filter is also used in load_plugin_textdomain()
    $locale = apply_filters( 'plugin_locale', get_locale(), $domain );

    load_textdomain( 
            $domain, 
            WP_LANG_DIR . '/my-plugin/' . $domain . '-' . $locale . '.mo' 
    );
    load_plugin_textdomain( 
            $domain, 
            FALSE, 
            dirname( plugin_basename(__FILE__) ) . '/languages/' 
    );
}

Assicurati che i plugin non generino errori con WP_DEBUG

Metti sempre alla prova i tuoi plug-in con l'opzione WP_DEBUGattivata e idealmente li hai attivati ​​durante tutto il processo di sviluppo. Un plugin non dovrebbe generare QUALSIASI errore con WP_DEBUGon. Ciò include avvisi obsoleti e indici non controllati.

Per attivare il debug, modifica il wp-config.phpfile in modo che la WP_DEBUGcostante sia impostata su true. Vedi il Codice su Debug per maggiori dettagli.

Primo utilizzo delle funzioni esistenti in WordPress Core

Se puoi: usa le funzioni esistenti incluse nel core di WordPress invece di scriverne di tue. Sviluppa funzioni PHP personalizzate solo quando non esiste una funzione preesistente appropriata nel core di WordPress.

Uno dei vantaggi è che è possibile utilizzare "avvisi obsoleti di registro" per monitorare facilmente le funzioni che devono essere sostituite. Un altro vantaggio è che gli utenti possono visualizzare la documentazione delle funzioni nel Codex e comprendere meglio cosa fa il plugin anche se non sono sviluppatori PHP esperti.

Relazionato

• Supporto I18n
• Carica script / CSS con wp_enqueue_script e wp_enqueue_style
• Offri moduli estensibili

La disinstallazione dovrebbe rimuovere tutti i dati di un plugin

Dopo essere stato rimosso da un'installazione di WordPress, un plug-in dovrebbe eliminare tutti i file, le cartelle, le voci del database e le tabelle che ha creato, nonché i valori delle opzioni che ha creato.

I plugin possono offrire un'opzione per esportare / importare le impostazioni, in modo che le impostazioni possano essere salvate al di fuori di WordPress prima della cancellazione.

Relazionato

• La disattivazione non dovrebbe provocare perdita di dati

Prevenire l'iniezione SQL con dati di input

Un plug-in dovrebbe disinfettare tutti gli input dell'utente recuperati direttamente o indirettamente (ad es. Tramite $_POSTo$_GET ) prima di utilizzare i valori di input per interrogare il database MySQL.

Vedi: Formattazione delle istruzioni SQL .

Prefisso tutti gli elementi dello spazio dei nomi globale

Un plugin dovrebbe anteporre correttamente TUTTI gli elementi globali dello spazio dei nomi (costanti, funzioni, classi, variabili, anche cose come tassonomie personalizzate, tipi di posta, widget, ecc.). Ad esempio, non creare una funzione chiamata init(); invece, chiamalo qualcosa di simile jpb_init().

Il suo comune dovrebbe usare un prefisso di tre o quattro lettere prima dei nomi o per utilizzare la funzione dello spazio dei nomi PHP . Confronto: prefisso a lettera singola per costanti della classe PHP?

Relazionato

• Lo spazio dei nomi globale è una risorsa limitata

Utilizzare un codice PHP5 orientato alla classe e agli oggetti

Non c'è motivo di non scrivere codice PHP5 pulito e orientato agli oggetti. Il supporto di PHP4 verrà eliminato dopo la prossima versione (WP 3.1). Ovviamente, puoi aggiungere il prefisso a tutti i nomi delle tue funzioni per finire con infinitamente_long_function_names_with_lots_of_underscores, ma è molto più semplice scrivere una semplice classe e raggruppare tutto in essa. Inoltre, inserisci la tua classe in un file separato e denominalo di conseguenza in modo da poterlo estendere e mantenere facilmente:

// in functions.php
require 'inc/class-my-cool-plugin.php';
new MyCoolPlugin();

// in inc/class-my-cool-plugin.php
class MyCoolPlugin {
    function __construct() {
        // add filter hooks, wp_enqueue_script, etc.

        // To assign a method from your class to a WP 
        // function do something like this
        add_action('admin_menu', array($this, "admin"));
    }

    public function admin() {
        // public methods, for use outside of the class
        // Note that methods used in other WP functions 
        // (such as add_action) should be public
    }

    private function somethingelse() {
        // methods you only use inside this class
    }
}

La disattivazione non dovrebbe provocare perdita di dati

Un plugin non dovrebbe cancellare nessuno dei suoi dati dopo la disattivazione .

Relazionato

• La disinstallazione dovrebbe rimuovere tutti i dati del plugin

Includi solo i file che ti servono ...

Se sei nel front-end, non includere il codice relativo all'area di amministrazione.

Annunciare la perdita di dati durante la disinstallazione del plug-in

Al momento della disinstallazione, un plug-in dovrebbe richiedere all'utente che cancellerà i suoi dati e ricevere una conferma che l'utente è d'accordo con l'eliminazione dei dati prima di farlo e un plug-in dovrebbe anche consentire all'utente di conservare i dati al momento della disinstallazione. (Questa idea di @EAMann.)

Relazionato

• La disinstallazione dovrebbe rimuovere tutti i dati del plugin
• La disattivazione non dovrebbe provocare perdita di dati

Consenti di modificare il nome della cartella del plug-in

/ plugins / pluginName / {} varie

Il "pluginname" utilizzato per la cartella deve essere sempre modificabile.

Questo viene normalmente gestito definendo le costanti e usandole in modo coerente in tutto il plugin.

Inutile dire che molti plugin popolari sono peccatori.

Relazionato:

• plugins_url() per un facile collegamento alle risorse, incluso con il plugin.

Usa WordPress (integrato) Gestione degli errori

Non solo return;se alcuni input dell'utente erano sbagliati. Fornire loro alcune informazioni su è stato fatto male.

function some_example_fn( $args = array() ) 
{
    // If value was not set, build an error message
    if ( ! isset( $args['some_value'] ) )
        $error = new WP_Error( 'some_value', sprintf( __( 'You have forgotten to specify the %1$s for your function. %2$s Error triggered inside %3$s on line %4$s.', TEXTDOMAIN ), '$args[\'some_value\']', "\n", __FILE__, __LINE__ ) );

    // die & print error message & code - for admins only!
    if ( isset( $error ) && is_wp_error( $error ) && current_user_can( 'manage_options' ) ) 
        wp_die( $error->get_error_code(), 'Theme Error: Missing Argument' );

    // Elseif no error was triggered continue...
}

Un errore (oggetto) per tutti

È possibile impostare un oggetto di errore globale per il tema o il plugin durante l'avvio:

function bootstrap_the_theme()
{
    global $prefix_error, $prefix_theme_name;
    // Take the theme name as error ID:
    $theme_data = wp_get_theme();
    $prefix_theme_name = $theme_data->Name;
    $prefix_error = new WP_Error( $theme_data->Name );

    include // whatever, etc...
}
add_action( 'after_setup_theme', 'bootstrap_the_theme' );

Successivamente è possibile aggiungere errori illimitati su richiesta:

function some_theme_fn( $args )
{
    global $prefix_error, $prefix_theme_name;
    $theme_data = wp_get_theme();
    if ( ! $args['whatever'] && current_user_can( 'manage_options' ) ) // some required value not set
        $prefix_error->add( $prefix_theme_name, sprintf( 'The function %1$s needs the argument %2$s set.', __FUNCTION__, '$args[\'whatever\']' ) );

    // continue function...
}

Quindi puoi recuperarli tutti alla fine del tuo tema. In questo modo non interrompi il rendering della pagina e puoi comunque generare tutti i tuoi errori per lo sviluppo

function dump_theme_errors()
{
    global $prefix_error, $prefix_theme_name;

    // Not an admin? OR: No error(s)?
    if ( ! current_user_can( 'manage_options' ) ! is_wp_error( $prefix_error ) )
        return;

    $theme_errors = $prefix_error->get_error_messages( $prefix_theme_name );
    echo '<h3>Theme Errors</h3>';
    foreach ( $theme_errors as $error )
        echo "{$error}\n";
}
add_action( 'shutdown', 'dump_theme_errors' );

È possibile trovare ulteriori informazioni a questo Q . Un ticket correlato per correggere il "lavorare insieme" di WP_Errore wp_die()è collegato da lì e ne seguirà un altro. Commenti, critiche e simili sono apprezzati.

Riduci a icona i nomi aggiunti allo spazio dei nomi globale

Un plug-in dovrebbe ridurne il più possibile l'impatto minimizzando il numero di nomi che aggiunge allo spazio dei nomi globale .

Questo può essere fatto incapsulando le funzioni del plugin in una classe o usando la funzione degli spazi dei nomi PHP . Il prefisso di tutto può aiutare anche ma non è così flessibile.

Accanto a funzioni e classi, un plugin non dovrebbe introdurre variabili globali. L'uso delle classi normalmente li oscura e semplifica la manutenzione dei plugin.

Relazionato

• Prefisso correttamente

Commenta usando PhpDoc

Le migliori pratiche sono vicine allo stile PhpDoc. Se non usi un IDE come "Eclipse", puoi dare un'occhiata al Manuale di PhpDoc .

Non devi sapere esattamente come funziona. Gli sviluppatori professionisti possono comunque leggere il codice e hanno solo bisogno di questo come riepilogo. I programmatori e gli utenti di Hobby potrebbero apprezzare il modo in cui lo spieghi allo stesso livello di conoscenza.

Utilizzare l'API delle impostazioni prima di add_option

Invece di aggiungere opzioni al DB tramite la funzione add_option, dovresti memorizzarle come un array usando l' API Impostazioni che si occupa di tutto per te.

Utilizzare l'API di modifica del tema prima di add_option

L' API delle modifiche è un costrutto piuttosto semplice e un modo sicuro che consente di aggiungere e recuperare opzioni. Tutto viene salvato come valore serializzato nel database. Facile, sicuro e semplice.

Proteggi la privacy degli utenti dei plug-in

(In precedenza: comunicazione API anonima)

Se un plug-in comunica con un sistema o API esterno (ad esempio un servizio Web), dovrebbe farlo in modo anonimo o fornire all'utente un'opzione anonima che assicuri che nessun dato relativo all'utente del plug-in vada a una seconda parte incontrollata.

Plugin host su WordPress.org

Utilizzare il repository SVN fornito su WordPress.org per l'hosting di plug-in. Rende l'esperienza utente più semplice da aggiornare e se non hai mai usato SVN prima d'ora, ti fa capire davvero usandolo in un contesto che lo giustifica.

Fornire il controllo di accesso utilizzando le autorizzazioni

In molti casi, gli utenti potrebbero non desiderare che tutti abbiano accesso alle aree create dal plug-in, in particolare con plug-in che eseguono più operazioni complesse, un singolo controllo della capacità codificato potrebbe non essere sufficiente.

Per lo meno, disponi di adeguati controlli di capacità per tutti i diversi tipi di procedure per cui il tuo plugin può essere utilizzato.

Importa / esporta impostazioni plugin

Non è così comune tra i plugin, ma se il tuo plugin ha (alcune) impostazioni, dovrebbe fornire l'importazione / esportazione di dati come la configurazione e l'input dell'utente .

L'importazione / esportazione migliora l'usabilità di un plugin.

Un plug-in di esempio che ha una tale funzionalità di importazione ed esportazione (e anche un meccanismo di annullamento) è Breadcrumb NavXT (Wordpress Plugin) (divulgazione completa: un po 'di codice da parte mia, la maggior parte è stata fatta da mtekk).

Relazionato

• La disinstallazione dovrebbe rimuovere tutti i dati del plugin
• La disattivazione non dovrebbe provocare perdita di dati

Organizza il tuo codice

È sempre difficile leggere il codice che non è scritto nell'ordine in cui viene eseguito. Prima includi / richiedi, definisci, wp_enqueue_style & _script, ecc., Quindi le funzioni di cui ha bisogno il plugin / tema e infine il builder (es. Schermata di amministrazione, elementi che si integrano nel tema, ecc.).

Prova a separare cose come css e js nelle loro cartelle. Prova anche a farlo con funzioni che sono solo aiutanti, come gli spianatori di array e simili. Mantenere il file "principale" il più pulito e di facile lettura è un modo che aiuta gli utenti, gli sviluppatori e te, quando si tenta di aggiornare in un anno e non si vede il codice da più tempo.

È anche bello avere una struttura che ripeti spesso, in modo da trovare sempre la tua strada. Sviluppare in una struttura nota su diversi progetti ti darà il tempo di renderlo migliore e anche se il tuo client passa a un altro sviluppatore, non sentirai mai "ha lasciato il caos". Questo costruisce la tua reputazione e dovrebbe essere un obiettivo a lungo termine.

Muori con stile

morire in modo decente Tutte le funzioni di un plug-in (e persino di temi) dovrebbero essere utilizzate wp_die()in luoghi critici per offrire all'utente alcune informazioni su ciò che è accaduto. Gli errori di php sono fastidiosi e wp_diepossono dare all'utente un messaggio in stile su ciò che il plugin (o loro) ha fatto di sbagliato. Inoltre, se l'utente ha disattivato il debug, il plug-in si interromperà.

L'utilizzo wp_die()aiuta anche a rendere i tuoi plugin / temi compatibili con testpress di wordpress .

• Usa la gestione degli errori WP

Fornire schermate di aiuto per gli utenti

È più bello dire RTFM (fare clic sulla guida) come risposta piuttosto che dover rispondere più volte alla domanda.

/**
  * Add contextual help for this screen
  * 
  * @param $rtfm
  * @uses get_current_screen
  */ 
  function ContextualHelp( /*string*/ $rtfm) 
  { 
     $current_screen = get_current_screen();
     if ($current_screen->id == $this->_pageid) 
     {
        $rtfm .= '<h3>The WordPress Plugin - Screen A</h3>';
        $rtfm .= '<p>Here are some tips: donate to me ' .
     }
     return $rtfm; 
  }
add_action('contextual_help', array($this,'ContextualHelp'),1,1);

update / note: (vedi commenti da kaiser): l'esempio sopra deve essere usato in una classe

Offri moduli estensibili

Quando un plug-in offre la possibilità di inserire dati, dovrebbe sempre avere un hook alla fine, proprio prima del pulsante "invia" e / o "ripristina", in modo che gli sviluppatori possano facilmente estendere il modulo con non solo campi, ma anche pulsanti.

Vedi: API delle impostazioni

Relazionato

• Usa azioni e filtri
• Riutilizzare le funzioni esistenti
• Supporto I18n

include la funzione sempre tramite Hook, non direttamente.

Esempio:

• Non utilizzare per includere la classe del plugin tramite new senza hook

• Utilizzare Hook plugins_loaded

  // add the class to WP                                   
  function my_plugin_start() {                                                               
      new my_plugin();   
  }                                                        
  add_action( 'plugins_loaded', 'my_plugin_start' );

Aggiornamento: un piccolo esempio dal vivo: Plugin-svn-trunk-page e uno pseudo esempio

//avoid direct calls to this file where wp core files not present
if (!function_exists ('add_action')) {
        header('Status: 403 Forbidden');
        header('HTTP/1.1 403 Forbidden');
        exit();
}

if ( !class_exists( 'plugin_class' ) ) {
    class plugin_class {

        function __construct() {
        }

    } // end class

    function plugin_start() {

        new plugin_class();
    }

    add_action( 'plugins_loaded', 'plugin_start' );
} // end class_exists

Puoi anche caricare tramite mu_plugins_loaded su installazione su più siti, vedi il codice per riferimento all'azione: http://codex.wordpress.org/Plugin_API/Action_Reference Anche qui vedi come includere wP con questo hook: http: // adambrown. info / p / wp_hooks / hook / plugins_loaded? versione = 2.1 & file = wp-settings.php Lo uso molto spesso e non è così difficile e precoce, meglio di una nuova classe difficile ();

Plugin di licenza con licenza compatibile GPL

I plug-in e i temi devono essere concessi in licenza con una licenza compatibile con WordPress. Ciò consente loro di essere ridistribuiti con WordPress come "programma". Una licenza consigliata è la GPL . Assicurarsi che tutte le librerie di codici incluse con il plug-in siano compatibili con la stessa licenza.

(Questo è stato un problema e un serio punto di discussione sia nel passato che nel presente .)

La descrizione del tuo plugin dovrebbe dettagliare con precisione le funzioni del tuo plugin. Ci sono 10 plugin post in primo piano. Tutti mostrano post in primo piano, ma molti hanno funzionalità diverse. Dovrebbe essere facile confrontare il tuo plugin con plugin simili leggendo la descrizione.

Dovresti evitare di vantarti di quanto sia semplice il tuo plugin a meno che non sia davvero molto semplice. È necessario includere collegamenti utili nella descrizione come il collegamento alle impostazioni.

Ridurre al minimo gli effetti collaterali di origini dati remote e servizi web

Un plug-in dovrebbe cache / Shield Webservice e / o XMLRPC / SOAP richieste attraverso un livello di cache / provider di dati se li usi in modo da non effettuare richieste frontali in attesa di una risposta (lenta) del servizio web.

Ciò include il download del feed RSS e di altre pagine. Progetta i tuoi plug-in in modo che richiedano dati in background.

Un possibile STEP è (prendi la pubblicazione su ping.fm come esempio): crea una tabella buffer, diciamo: ping_fm_buffer_post (data, ora, messaggio, submit_time, status)

1. Per ogni volta che desideri inviare un aggiornamento a ping.fm, aggiungilo a questa tabella.
2. Ora, dobbiamo creare un plug-in per gestire questi dati. Questo plugin verrà eseguito tramite crontab per verificare la presenza di aggiornamenti non ancora inviati
3. Poiché disponiamo di questa tabella, possiamo anche elencare tutti i messaggi inviati a Ping.fm e controllare lo stato di ogni post. Nel caso in cui ci sia un problema da parte di Ping.fm, possiamo inviarlo nuovamente.

Prova il tuo plugin

Dovremmo avere definitivamente alcuni strumenti di test nel nostro ambiente di sviluppo plugin.

Sulla base di questa risposta di Ethan Seifert a una domanda di test, queste sono buone pratiche da seguire:

• Il tuo test unitario dovrebbe testare la minima quantità di comportamento che una classe può eseguire.
• Quando arrivi al livello di test funzionali, è qui che puoi testare il tuo codice con le dipendenze di Wordpress.
• A seconda di ciò che fa il tuo plugin - considera l'utilizzo di test basati sul selenio che verificano la presenza di dati nel DOM usando gli ID