Lezioni apprese durante lo sviluppo di plugin per WordPress

Ogni sviluppatore di plugin per WordPress deve affrontare problemi difficili e codice difficile da mantenere. Passiamo la notte a supportare i nostri utenti e ci strappiamo i capelli quando un aggiornamento interrompe il nostro plug-in. Lascia che ti mostri come renderlo più facile.

In questo articolo, condividerò i miei cinque anni di esperienza nello sviluppo di plugin per WordPress. Il primo plugin che ho scritto è stato un semplice plugin di marketing. Visualizzava un pulsante di invito all'azione (CTA) con la frase di ricerca di Google. Da allora, ho scritto altri 11 plugin gratuiti e li conservo quasi tutti. Ho scritto circa 40 plugin per i miei clienti, da quelli davvero piccoli a uno che è stato mantenuto per oltre un anno.

Un buon sviluppo e supporto portano a più download. Più download significano più soldi e una migliore reputazione. Questo articolo ti mostrerà le lezioni che ho imparato e gli errori che ho commesso, in modo che tu possa migliorare lo sviluppo del tuo plugin.

1. Risolvi un problema

Se il tuo plugin non risolve un problema, non verrà scaricato. E 'così semplice.

Prendi il plug-in Advanced Cron Manager (oltre 8.000 installazioni attive). Aiuta gli utenti di WordPress che hanno difficoltà a eseguire il debug del proprio cron. Il plug-in è stato scritto per necessità: avevo bisogno di qualcosa che mi aiutasse. Non avevo bisogno di commercializzarlo, perché le persone ne avevano già bisogno. Ha graffiato il loro prurito.

D'altra parte, c'è il plug-in Bug: vola sullo schermo (oltre 70 installazioni attive). Simula casualmente una mosca sullo schermo. Non risolve davvero un problema, quindi non avrà un pubblico enorme. Tuttavia, è stato un plug-in divertente da sviluppare.

Concentrati su un problema. Quando le persone non vedono un buon rendimento del loro SEO, installano un plug-in SEO. Quando le persone vogliono velocizzare il proprio sito Web, installano un plug-in di memorizzazione nella cache. Quando le persone non riescono a trovare una soluzione al loro problema, trovano uno sviluppatore che scriva una soluzione per loro.

Come attesta David Hehenberger nel suo articolo sulla scrittura di un plug-in di successo, la necessità è un fattore chiave nella decisione dell'utente di WordPress se installare un plug-in particolare.

Se hai l'opportunità di risolvere il problema di qualcuno, cogli l'occasione.

2. Supporta il tuo prodotto

“3 americani su 5 cercherebbero un nuovo marchio o azienda per una migliore esperienza di servizio. 7 su 10 hanno dichiarato di essere disposti a spendere di più con aziende che ritengono forniscano un servizio eccellente".

— Nykki Yeager

Non trascurare il tuo supporto. Non trattarlo come un must, ma più come un'opportunità.

Un supporto di buona qualità è fondamentale per far crescere il tuo plugin. Anche un plugin con il codice migliore riceverà dei ticket di supporto. Più persone usano il tuo plugin, più biglietti otterrai. Una migliore esperienza utente ti farà ottenere meno ticket, ma non raggiungerai mai la casella di posta 0.

Ogni volta che qualcuno pubblica un messaggio in un forum di supporto, ricevo immediatamente una notifica e-mail e rispondo il prima possibile. Si paga. La stragrande maggioranza delle mie recensioni positive è stata ottenuta grazie al supporto. Questo è un effetto collaterale: un buon supporto spesso si traduce in recensioni a 5 stelle.

Quando fornisci un supporto eccellente, le persone iniziano a fidarsi di te e del tuo prodotto. E un plugin è un prodotto, anche se è completamente gratuito e open-source.

Un buon supporto è più complesso che scrivere una breve risposta una volta al giorno. Quando il tuo plugin prenderà piede, riceverai diversi biglietti al giorno. È molto più facile da gestire se sei proattivo e rispondi alle domande dei clienti prima ancora che chiedano.

Ecco un elenco di alcune azioni che puoi intraprendere:

• Crea una sezione FAQ nel tuo repository.
• Appunta il thread "Prima di chiedere" nella parte superiore del forum di supporto, evidenziando i suggerimenti per la risoluzione dei problemi e le domande frequenti.
• Assicurati che il tuo plugin sia semplice da usare e che gli utenti sappiano cosa dovrebbero fare dopo averlo installato. L'esperienza utente è importante.
• Analizza le domande di supporto e correggi i punti deboli. Crea una bacheca in cui le persone possono votare per le funzionalità che desiderano.
• Crea un video che mostri come funziona il plugin e aggiungilo alla pagina principale del tuo plugin nel repository di WordPress.org.

Non importa quale software utilizzi per supportare il tuo prodotto. Il forum di supporto ufficiale di WordPress.org funziona così come l'e-mail o il tuo sistema di supporto. Uso il forum di WordPress.org per i plugin gratuiti e il mio sistema per i plugin premium.

3. Non utilizzare il compositore

Composer è un software di gestione dei pacchetti. Un repository di pacchetti è ospitato su packagist.org e puoi scaricarli facilmente nel tuo progetto. È come NPM o Bower per PHP. Gestire i tuoi pacchetti di terze parti come fa Composer è una buona pratica, ma non usarla nel tuo progetto WordPress.

Lo so, ho sganciato una bomba. Lasciatemi spiegare.

Il compositore è un ottimo software. Lo uso da solo, ma non in progetti WordPress pubblici. Il problema sta nei conflitti. WordPress non ha alcun gestore di pacchetti globale, quindi ogni plugin deve caricare le proprie dipendenze. Quando due plugin caricano la stessa dipendenza, si verifica un errore irreversibile.

Non esiste davvero una soluzione ideale a questo problema, ma Composer lo peggiora. Puoi raggruppare la dipendenza nel tuo codice sorgente manualmente e controllare sempre se sei sicuro di caricarla.

Il problema del compositore con i plugin di WordPress non è ancora risolto e non ci sarà alcuna soluzione praticabile a questo problema nel prossimo futuro. Il problema è stato sollevato molti anni fa e, come puoi leggere nell'articolo di WP Tavern, molti sviluppatori stanno cercando di risolverlo, senza fortuna.

Il meglio che puoi fare è assicurarti che le condizioni e l'ambiente siano adeguati per eseguire il tuo codice.

4. Supporta ragionevolmente le vecchie versioni di PHP

Non supportano versioni molto vecchie di PHP, come 5.2. I problemi di sicurezza e la manutenzione non valgono la pena e non guadagnerai più installazioni da quelle versioni precedenti.

Scegli PHP 5.6 come requisito minimo, anche se il supporto ufficiale verrà abbandonato entro la fine del 2018. WordPress stesso richiede PHP 7.2.

C'è un movimento che scoraggia il supporto delle versioni precedenti di PHP. Il team di Yoast ha rilasciato la libreria Whip, che puoi includere nel tuo plug-in e che mostra ai tuoi utenti informazioni importanti sulla loro versione di PHP e sul perché dovrebbero essere aggiornate.

Dì ai tuoi utenti quali versioni supportate e assicurati che il loro sito Web non si rompa dopo che il tuo plug-in è stato installato su una versione troppo bassa.

5. Concentrarsi sul codice di qualità

Scrivere un buon codice è difficile all'inizio. Ci vuole tempo per imparare i principi e i modelli di progettazione "SOLID" e per cambiare le vecchie abitudini di codifica.

Una volta mi ci sono voluti tre giorni per visualizzare una semplice stringa in WordPress, quando ho deciso di riscrivere uno dei miei plugin usando migliori pratiche di codifica. Era frustrante sapere che ci sarebbero voluti 30 minuti. Cambiare mentalità è stato doloroso ma ne è valsa la pena.

Perché è stato così difficile? Perché inizi a scrivere codice che a prima vista sembra eccessivo e poco intuitivo. Continuavo a chiedermi: "È davvero necessario?" Ad esempio, devi separare la logica in classi diverse e assicurarti che ognuna sia responsabile di una singola cosa. Devi anche separare le classi per la traduzione, la registrazione del tipo di post personalizzato, la gestione delle risorse, i gestori dei moduli, ecc. Quindi, componi le strutture più grandi dai semplici piccoli oggetti. Si chiama iniezione di dipendenza. È molto diverso dall'avere classi "front end" e "admin", in cui riempi tutto il tuo codice.

L'altra pratica controintuitiva consisteva nel mantenere tutte le azioni e i filtri al di fuori del metodo del costruttore. In questo modo, non stai invocando alcuna azione durante la creazione degli oggetti, il che è molto utile per i test di unità. Hai anche un controllo migliore su quali metodi vengono eseguiti e quando. Vorrei saperlo prima di scrivere un progetto con un ciclo infinito causato dalle azioni nei metodi del costruttore. Questi tipi di bug sono difficili da rintracciare e difficili da correggere. Il progetto doveva essere rifattorizzato.

Quanto sopra sono solo alcuni esempi, ma dovresti conoscere i principi SOLID. Questi sono validi per qualsiasi sistema e qualsiasi linguaggio di codifica.

Quando segui tutte le best practice, raggiungi il punto in cui ogni nuova funzionalità si adatta perfettamente. Non devi modificare nulla o fare eccezioni al codice esistente. È fantastico. Invece di diventare più complesso, il tuo codice diventa semplicemente più avanzato, senza perdere flessibilità.

Inoltre, formatta correttamente il tuo codice e assicurati che ogni membro del tuo team segua uno standard. Gli standard renderanno il tuo codice prevedibile e più facile da leggere e testare. WordPress ha i suoi standard, che puoi implementare nei tuoi progetti.

6. Testa il tuo plugin in anticipo

Ho imparato questa lezione a mie spese. La mancanza di test mi ha portato a rilasciare una nuova versione di un plug-in con un errore irreversibile. Due volte. Entrambe le volte, ho ricevuto una valutazione di 1 stella, che non ho potuto trasformare in una recensione positiva.

Puoi testare manualmente o automaticamente. Travis CI è un prodotto di test continuo che si integra con GitHub. Ho creato una suite di test davvero semplice per il mio plug-in di notifica che controlla solo se il plug-in può essere avviato correttamente su ogni versione di PHP. In questo modo, posso essere sicuro che il plugin sia privo di errori e non devo prestare molta attenzione a testarlo in ogni ambiente.

Ogni test automatizzato richiede una frazione di secondo. Il completamento di 100 test automatizzati richiederà circa 10 minuti, mentre i test manuali richiedono circa 2 minuti per ciascun caso.

Più tempo investi nel testare il tuo plug-in in anticipo, più ti farà risparmiare a lungo termine.

Per iniziare con i test automatici, puoi utilizzare il comando WP-CLI \\`wp scaffold plugin-test\\`, che installa tutta la configurazione di cui hai bisogno.

7. Documenta il tuo lavoro

È un cliché che agli sviluppatori non piace scrivere documentazione. È la parte più noiosa del processo di sviluppo, ma un po' fa molto.

Scrivi codice autodocumentante. Presta attenzione ai nomi di variabili, funzioni e classi. Non creare strutture complicate, come cascate che non possono essere lette facilmente.

Un altro modo per documentare il codice è utilizzare il "blocco doc", che è un commento per ogni file, funzione e classe. Se scrivi come funziona la funzione e cosa fa, sarà molto più facile capire quando dovrai eseguirne il debug tra sei mesi. Gli standard di codifica di WordPress coprono questa parte costringendoti a scrivere i blocchi di documenti.

L'uso di entrambe le tecniche ti farà risparmiare tempo per scrivere la documentazione, ma la documentazione del codice non verrà letta da tutti.

Per l'utente finale, devi scrivere articoli di alta qualità, brevi e di facile lettura che spieghino come funziona il sistema e come usarlo. I video sono ancora migliori; molte persone preferiscono guardare un breve tutorial piuttosto che leggere un articolo. Non guarderanno il codice, quindi semplificatevi la vita. Una buona documentazione riduce anche i ticket di supporto.

Conclusione

Queste sette regole mi hanno aiutato a sviluppare prodotti di buona qualità, che stanno iniziando a essere un core business in BracketSpace. Spero che ti aiutino anche nel tuo viaggio con i plugin di WordPress.

Fammi sapere nei commenti qual è la tua regola di sviluppo d'oro o se hai trovato una delle precedenti particolarmente utile.