Utilizzo di WordPress Hooks per ripulire il codice, attivarlo e disinstallarlo
Pubblicato: 2015-01-23Gli autori di plug-in dedicano così tanto tempo ed energia alla funzionalità principale dei loro prodotti, che consentono a cose meno importanti di cadere nel dimenticatoio.
Prendi l'attivazione e la disattivazione, ad esempio. Sebbene gli hook di attivazione siano diffusi – molti plugin devono aggiungere alcune opzioni, svuotare le regole di riscrittura, magari creare una tabella di database o controllare le differenze di versione sull'installazione – gli hook di disattivazione e disinstallazione sono molto meno comuni.
Il punto qui? Molti autori di plugin non si prendono il tempo di ripulire se stessi. L'installazione di WordPress ha davvero bisogno della tabella personalizzata che hai creato dopo aver rimosso il plug-in? Perché non cancellare alcune opzioni esclusive del plug-in prima di eliminarlo?
In questo articolo, ti mostrerò come utilizzare gli hook di attivazione, disattivazione e disinstallazione per inizializzare il tuo plug-in e ripulire le cose più facilmente dopo che gli utenti hanno finito con il tuo prodotto.
- Il gancio di attivazione
- La sequenza di installazione
- Regole di riscrittura del lavaggio
- Creazione di tabelle di database
- Controlli di dipendenza
- Il gancio di disattivazione
- Il gancio di disinstallazione
- Sicurezza aggiuntiva
- È ora di ripulire
Nota: se hai intenzione di sfogliare questo articolo, ti consiglio vivamente di dare un'occhiata alla sezione "Sicurezza aggiuntiva" alla fine, che integra il codice con alcuni preziosi controlli di sicurezza. Inoltre, se hai bisogno di aiuto con gli hook dei plugin di WordPress, ecco un rapido aggiornamento sull'utilizzo degli hook di WordPress e su come attivare una funzione in WordPress.
Il gancio di attivazione
Sebbene l'hook di attivazione sia abbastanza semplice, installarlo è un caso un po' speciale, quindi dovremo prestare attenzione alla sequenza degli eventi. Prima di addentrarci in tutto questo, ecco un semplice esempio:
La chiave di tutto è la funzione register_activation_hook() . Il primo parametro è il percorso del file principale del plugin; il secondo parametro definisce la funzione da eseguire. Internamente, la funzione register_activation_hook() è un wrapper per l'azione “activate_[plugin_name]”, ma poiché è un po' più facile da usare, è insolito vedere l'hook nei plugin.
La sequenza di installazione
Comprendere la sequenza di installazione è importante perché impedisce l'utilizzo di metodi a cui potresti essere abituato. register_activation_hook() viene chiamato tra l'utente che fa clic sul collegamento di attivazione e di conseguenza vede l'avviso di attivazione. Viene eseguito su una pagina intermedia, che reindirizza immediatamente prima che qualsiasi hook possa avere la possibilità di essere eseguito.
Diamo un'occhiata a un esempio per vedere perché questo è un enorme delusione:
Regole di riscrittura del lavaggio
Un certo numero di plugin crea tipi di post personalizzati. Svuotare le regole di riscrittura all'attivazione per assicurarsi che gli utenti non ricevano un errore 404 quando visitano un post dal nuovo tipo di post personalizzato è una mossa intelligente.
Il codice seguente sembra logico ma fallirà.
Sembra perfettamente a posto. Viene creato il tipo di post personalizzato e all'attivazione, scarichiamo le regole di riscrittura. Il problema è che i tipi di post personalizzati non sono ancora stati creati quando scarichiamo le regole di riscrittura.
Ecco come appare il flusso di processo:
- L'utente installa il plugin.
- L'utente fa clic sul collegamento di attivazione.
- Una pagina intermedia esegue solo l'hook di attivazione, nient'altro. Questo svuota le regole di riscrittura.
- Il plugin è attivo e il codice viene eseguito normalmente. Il tipo di post personalizzato è registrato.
Una soluzione pubblicata su Stack Overflow, ufficialmente approvata dal Codice di WordPress, risolve il nostro piccolo problema. La soluzione prevede l'aggiunta di un'opzione per indicare che il plug-in è stato appena installato.
Se questa opzione esiste, eseguiamo le nostre operazioni di attivazione e quindi la cancelliamo.
Qualcosa come questo:
Personalmente, questa soluzione non mi piace molto. Il problema è che il controllo sulla riga otto viene eseguito su ogni singola pagina caricata. Non c'è nulla di cui preoccuparsi, in quanto non appesantirà i tuoi server e non rallenterà il sito Web per i tuoi utenti. È un controllo molto rapido con un impatto trascurabile sulle prestazioni. Tuttavia, non è necessario il 99,9% delle volte.
C'è una soluzione migliore menzionata nel Codex nella documentazione per la funzione flush_rewrite_rules() . In questa soluzione, utilizziamo la modularità delle nostre funzioni per registrare separatamente il tipo di post personalizzato all'attivazione:
Invece di fare affidamento su un controllo che deve essere eseguito continuamente, utilizziamo la funzione di attivazione per registrare i nostri tipi di post. Nota che una volta attivato il nostro plugin, i tipi di post verranno sempre registrati init .
Questo è un triste esempio del fatto che il Codice è dappertutto. In generale, WordPress ha una buona documentazione, ma se qualcosa sembra dispendioso o illogico, non aver paura di fare qualche ricerca per conto tuo.
Creazione di tabelle di database
Un'altra attività eseguita da alcuni plugin è la creazione di tabelle di database. Il più delle volte, questo non è necessario, ma ci sono alcuni casi d'uso legittimi.
Questo esempio tratto dall'articolo del Codex sulla creazione di tabelle mostra come è possibile utilizzare più chiamate di attivazione:
La prima funzione, jal_install() crea una nuova tabella di database. La seconda funzione, jal_install_data , aggiunge i dati iniziali alla tabella. Invece di usare register_activation_hook() per aggiungere una funzione contenente tutto questo codice, possiamo usare register_activation_hook più volte.
Questa è un'ottima pratica per la modularità. Da un lato, non è necessario aggiungere i dati di test iniziali – è semplice come rimuovere l'hook di attivazione – così puoi mantenere intatta la funzione. D'altra parte, sei libero di riutilizzare queste funzioni ovunque poiché sono separate.
Controlli di dipendenza
Un'altra attività comune per la funzione di attivazione è controllare le dipendenze. Il tuo plug-in può fare affidamento su una versione specifica di WordPress, un altro plug-in o anche una versione specifica di PHP.
Il codice seguente verifica una versione minima di WP e PHP e reindirizza l'utente (senza attivare il plug-in) se necessario:
Il gancio di disattivazione
Gli hook di disattivazione vengono eseguiti quando un utente ha disattivato un plug-in, ma prima che venga disinstallato (eliminato). Gli hook di disattivazione vengono utilizzati allo stesso modo degli hook di attivazione:
La disattivazione significa che l'utente ha solo disattivato il tuo plug-in, quindi non vorrai fare quanto faresti durante una disinstallazione. Potresti voler svuotare le regole di riscrittura, ma in questa fase non vorrai sbarazzarti di tutte le tue opzioni e della tua tabella del database (se ne hai una).
Questo è abbastanza semplice, ma presterò particolare attenzione allo svuotamento delle regole di riscrittura poiché, ancora una volta, queste sono problematiche.
Il codice consiglia di eseguirli come mostrato di seguito, ma questo non funziona :
Il motivo per cui non funziona è lo stesso di prima. L'esecuzione di una disattivazione esegue l' init hook, il che significa che mentre stiamo disattivando il nostro plug-in, stiamo anche registrando il nostro tipo di post personalizzato. Le regole di riscrittura vengono svuotate, ma tengono conto del tipo di post personalizzato.
Un biglietto Trac è in atto per affrontare questo, ma fino ad allora, non posso darti un ottimo modo per farlo. L'unico modo in cui ho scoperto che funziona è eliminare del tutto le regole di riscrittura:
Anche se questo ha funzionato per me in passato, non lo consiglierei. Introduce una maggiore incertezza rispetto al problema di avere alcune regole di riscrittura in più. Preferirei visualizzare una nota agli utenti chiedendo loro di visitare le impostazioni del permalink dopo la disattivazione, che cancellerebbe le regole di riscrittura. Fino a quando non verrà implementata una soluzione migliore, siamo bloccati con questo... scusa!
Il gancio di disinstallazione
Esistono due modi per eseguire il codice durante la disinstallazione di un plug-in. Puoi usare l'hook di disinstallazione tramite register_uninstall_hook() o puoi usare un file uninstall.php dedicato all'interno del tuo plugin. Ti mostrerò entrambi, ma il metodo preferito è utilizzare il file di disinstallazione.
Il problema principale con l'hook di disinstallazione è che "impedisce l'esecuzione del file del plug-in principale durante la disinstallazione, il che può essere problematico se il plug-in esegue il codice nello spazio globale. È anche meglio che il codice di disinstallazione sia centralizzato". – Scott Riley
Il codice seguente mostra il processo di disinstallazione utilizzando un hook di base:
Come discusso, questa non è la soluzione migliore. Un modo molto migliore per gestire le disinstallazioni è utilizzare il file uninstall.php . Tutto quello che devi fare è crearlo e verrà utilizzato se disponibile.
Come puoi vedere, questa è in realtà una soluzione più semplice. La cosa migliore è che è autonomo.
Sicurezza aggiuntiva
Non volevo complicare eccessivamente gli esempi mostrati finora con problemi relativi alla sicurezza, ma dovresti davvero prendere alcune misure per assicurarti che solo coloro che sono autorizzati a farlo possano eseguire queste azioni.
Utilizzare il seguente snippet per l'attivazione e la disattivazione:
Questo blocco di codice assicura che l'utente disponga delle autorizzazioni per eseguire questa azione e che l'azione sia stata originata nella pagina corretta. Questo dovrebbe proteggere dalla maggior parte dei tentativi dannosi.
Il processo di disinstallazione è speciale, quindi dovremo utilizzare un codice leggermente diverso:
È tempo di ripulire
Se il tuo plug-in aggiunge elementi a WordPress, è tuo dovere di sviluppatore rimuoverlo quando un utente decide di eliminare il tuo plug-in.
L'utilizzo dei metodi di attivazione, disattivazione e disinstallazione descritti sopra ti consentirà di creare un sistema che lo faccia in modo sicuro. Consiglio vivamente anche di leggere questo thread di Stackexchange, che delinea questi processi negli ambienti OOP.
Se non sei ancora un membro WPMU DEV, iscriviti oggi per una prova gratuita, completamente priva di rischi. In qualità di membro, avrai accesso a tutti i nostri fantastici plugin e al servizio di hosting velocissimo, oltre al supporto di esperti 24 ore su 24, 7 giorni su 7 per tutte le tue domande e problemi relativi a WordPress.
tag: