Come una delle funzionalità di WordPress meno utilizzate, WP-Cron spesso viene trascurato dagli sviluppatori. Le sue applicazioni, tuttavia, non fanno ridere. Dalla memorizzazione nella cache alle notifiche per la pulizia, la pianificazione dei lavori cron può funzionare per creare un netto vantaggio anche nel più semplice blog di WordPress. Partecipa mentre esploriamo importanti applicazioni di questo stesso sistema.
WP-Cron non è lo stesso del cron programmatore Unix?
Subito dopo aver visto la parola cron, Sono sicuro che hai preso una pugnalata al punto in cui siamo diretti: programmando eventi perfettamente sincronizzati da eseguire a intervalli specificati. Al contrario, WP-Cron non è lo stesso dello scheduler cron di Unix. La distinzione chiave sta nel modo in cui viene eseguita; A differenza di un processo in background, WP-Cron si attiva ogni volta che un visitatore apre il tuo sito basato su WordPress. In quanto tale, mantiene la caratteristica vitale di un tempo impreciso.
Sì, hai letto bene: tempi imprecisi. Sebbene le parole cron e accurate siano come due piselli in un pod, non si armonizzano nel sistema di WordPress. Ma questo è davvero un problema? Se considerato nel contesto dell'utente, questo diventa effettivamente una risorsa.
Facciamo l'esempio di un normale lavoro cron eseguito ogni cinque minuti per aggiornare alcune informazioni del database utilizzate su un sito web. Se nessun visitatore visita il sito per 40 minuti, qual è, allora, il punto di eseguire questo lavoro otto volte? Tutti i valori intermedi sarebbero entrambi obsoleti e inutilizzati. Se, al contrario, dovesse dare il via alla prima visita dell'utente dopo un minimo di cinque minuti, non solo realizzerebbe lo stesso lavoro, ma eviterebbe anche aggiornamenti non necessari. In altre parole, poiché WP-Cron è basato sull'utente, ha il vantaggio di funzionare solo quando i visitatori sono presenti.
Per applicare WP-Cron, consideriamo l'applicazione di gestione RSS spesso utilizzata, FeedBurner. Di gran lunga, una delle caratteristiche più popolari di questa applicazione è la sua capacità di contare gli abbonati RSS. Una volta indicizzato, è possibile accedere al conteggio degli abbonati di un sito tramite una semplice chiamata API. Ne consegue, quindi, che questa chiamata API può essere eseguita una volta per visualizzazione di pagina per fornire il conteggio degli iscritti ai visualizzatori. Questo, tuttavia, porta ad un problema.
Se l'API di FeedBurner è accessibile una volta per pagina, inevitabilmente porta a una richiesta HTTP aggiuntiva, per non citare quella di un altro dominio, per ciascun visitatore. Ciò aumenta il tempo di caricamento della pagina per gli utenti.
Per ovviare a questo problema, è importante fare una chiave di realizzazione su questo metodo di consegna: è improbabile che un conteggio degli iscritti RSS venga aggiornato su ogni singola visualizzazione della pagina. Infatti, FeedBurner aggiorna il proprio conteggio una volta al giorno. Anche se dovesse cambiare rapidamente, è davvero necessario visualizzare l'ultimo conteggio per ogni visitatore? È importante che il conteggio sia leggermente obsoleto, ma successivamente aggiornato in un giorno?
Per i nostri scopi, è del tutto inutile recuperare il conteggio degli iscritti RSS per ogni visualizzazione di pagina. Invece, se viene recuperato per un visitatore, può essere semplicemente riutilizzato per quelli futuri. Quindi, dopo che è trascorso un giorno, è possibile eseguire un aggiornamento di questo conteggio. Tale processo è noto come cache. Dopo essere stato aggiornato, il conteggio degli iscritti RSS viene memorizzato nella cache, conservato per uso futuro invece di essere ricalcolato, fino a quando non è trascorso un giorno. E con ciò entriamo nel mondo di WP-Cron.
Per capire WP-Cron, è importante sapere dove è disponibile la documentazione. WordPress.org fornisce i riepiloghi di ogni funzione cron nel suo Codex. Per completare il nostro compito definito in precedenza, avremo bisogno di guardare il wp_schedule_event
funzione, che richiede quattro parametri:
Il nostro evento si innescherà quando l'ora corrente soddisfa o supera il tempo passato a questa funzione, come prescritto da un futuro visitatore del sito. Riattiverà quindi in base al parametro di ricorrenza, che può essere impostato su orario, twicedaily, giornaliero o nessuno. Possono anche essere definite pianificazioni di ricorrenza personalizzate.
Per gestire l'evento, viene utilizzato un gancio. In breve, un hook di WordPress può essere considerato un segnaposto per un'azione. Le azioni possono essere assegnate agli hook tramite WordPress ' add_action
funzione. Più specificamente, per aggiungere un gestore di funzioni al gancio dato, si può chiamare:
add_action ('hook_name', 'function_name');
dove hook_name e function_name sono rispettivamente il nome della funzione di hook e di gestione.
Poiché FeedBurner si aggiorna una volta al giorno, verrà specificata una pianificazione giornaliera, come da codice riportato di seguito:
wp_schedule_event (time (), 'daily', 'feedburner_refresh');
Nota che tempo()
è il timestamp UNIX corrente in secondi. Se eseguito, il gancio "FeedBurner Update" si attiva immediatamente e quindi una volta al giorno in seguito. Si noti che se dovessimo inserirla nel nostro file functions.php di WordPress, programmerebbe un nuovo evento su ogni singola pagina caricata. Questa non è la nostra funzionalità desiderata; piuttosto, vogliamo solo programmare questo evento una volta. Il modo più semplice per farlo è semplicemente controllando se l'evento è già programmato. Questo può essere fatto attraverso il wp_next_scheduled
funzione, che restituirà false se l'evento non è impostato per il trigger in futuro o il momento del suo successivo trigger altrimenti:
if (! wp_next_scheduled ('feedburner_refresh')) wp_schedule_event (time (), 'daily', 'feedburner_refresh');
Se dovessimo mai annullare la pianificazione di questo evento, è semplice come chiamare il wp_unschedule_event
funzione, che prende gli stessi parametri, salvo per la ricorrenza-come wp_schedule_event
. Si noti che il tempo trascorso deve essere il tempo del successivo trigger, che può essere recuperato tramite wp_next_scheduled
:
if (false! == ($ time = wp_next_scheduled ('feedburner_refresh'))) wp_unschedule_event ($ time, 'feedburner_refresh');
Possiamo anche annullare la pianificazione di questo evento tramite il suo nome hook usando il comando wp_clear_scheduled_hook
funzione. Tieni presente che questa alternativa rimuoverà anche tutti gli altri eventi che utilizzano lo stesso hook.
wp_clear_scheduled_hook ('feedburner_refresh');
Ora che il nostro evento è programmato, dobbiamo aggiungere un gestore ad esso:
add_action ('feedburner_refresh', 'update_rss_subscriber_count');
Questo imposta la funzione denominata update_rss_subscriber_count
essere chiamato una volta il feedburner_refresh
il gancio è innescato. È giunto il momento di scrivere questa funzione.
Per recuperare il conteggio dell'abbonato nel update_rss_subscriber_count
funzione, possiamo effettuare una chiamata all'API di FeedBurner tramite l'URL
Ciò restituirà i dati XML nel seguente formato:
L'informazione che stiamo cercando è nell'attributo di circolazione. La seguente espressione regolare può facilmente analizzare i dati per questo valore: circolazione = "(. *?)"
.
Metti in inglese, la nostra espressione regolare corrisponde alla seguente:
circolazione =
- La parola circolazione seguita da un segno di uguale"(. *?)"
- Citazioni e tutto dentro Esecuzione di questo utilizzando il preg_match
la funzione recupererà una serie di corrispondenze che conterrà il numero di abbonati nella prima posizione dell'indice. Mettendo insieme queste informazioni si ottiene il seguente codice:
// trova l'url di FeedBurner e ottiene i dati da esso // cambia [NOME] al nome del tuo feed di FeedBurner $ url = 'https://feedburner.google.com/api/awareness/1.0/GetFeedData?uri= [ NOME]'; $ data = @file_get_contents ($ url); // @ verrà surpress error // usa un'espressione regolare per analizzare i dati $ regex = '% circulation = "(. *?)"%'; preg_match ($ regex, $ data, $ matches); // ottiene il conteggio risultante se disponibile $ count = false; if ($ corrisponde && $ corrisponde a [1]) $ count = (int) $ corrisponde a [1];
Ora che abbiamo recuperato il numero di iscritti, dovremo memorizzarlo per l'accessibilità; invece di rivedere i dati XML dell'API, i visitatori accedono semplicemente a questo valore memorizzato.
Piuttosto che creare un database o un file per scopi di archiviazione, possiamo utilizzare un'altra funzionalità di WordPress: le opzioni. Le opzioni di WordPress sono semplici modi per archiviare bit di dati e identificare i nomi. L'aggiunta, l'eliminazione e l'accesso alle opzioni sono semplici come le seguenti funzioni:
update_option ($ name, $ value)
- Aggiunge o aggiorna un'opzione con il nome nome $
e valore $ value
.delete_option ($ name)
- Elimina un'opzione con il nome nome $
.get_option ($ name)
- Ottieni il valore dell'opzione associato al nome nome $
. Sebbene il nostro numero di abbonati non sia tecnicamente un valore di configurazione, l'utilizzo delle opzioni di WordPress è uno dei modi più convenienti, se non il più conveniente, per archiviare tali dati semplici. Di conseguenza, per memorizzare il numero di abbonati, utilizzeremo il comando update_option
metodo, che non solo sovrascrive i valori precedenti, ma crea anche l'opzione in primo luogo:
// se non è possibile trovare un conteggio, non aggiornare //, invece, attenersi al conteggio precedente se ($ count! == false) update_option ('subscriber_count', $ count);
La nostra funzione è completa! Dopo aver impostato l'evento, richiamare i dati tramite l'API di FeedBurner e memorizzare il valore desiderato, tutto ciò che resta da fare è l'output! Il codice completo per la funzione di pianificazione e recupero, che puoi inserire in functions.php, può essere trovato di seguito:
// pianifica l'evento feedburner_refresh una sola volta se (! wp_next_scheduled ('feedburner_refresh')) wp_schedule_event (time (), 'daily', 'feedburner_refresh'); add_action ('feedburner_refresh', 'update_rss_subscriber_count'); function update_rss_subscriber_count () // trova l'url di FeedBurner e ottiene i dati da esso // cambia [NAME] al nome del tuo feed di FeedBurner $ url = 'https://feedburner.google.com/api/awareness/1.0/ ? GetFeedData uri = [NAME] '; $ data = @file_get_contents ($ url); // @ verrà surpress error // usa un'espressione regolare per analizzare i dati $ regex = '% circulation = "(. *?)"%'; preg_match ($ regex, $ data, $ matches); // ottiene il conteggio risultante se disponibile $ count = false; if ($ corrisponde && $ corrisponde a [1]) $ count = (int) $ corrisponde a [1]; // se non è possibile trovare un conteggio, non aggiornare //, invece, attenersi al conteggio precedente se ($ count! == false) update_option ('subscriber_count', $ count);
Il conteggio degli iscritti ora è solo una semplice funzione chiamata in qualsiasi file di modello:
echo get_option ('subscriber_count');
Il nostro conteggio degli iscritti RSS è ora ottimizzato; anziché essere recuperato per ogni richiesta, viene memorizzato nella cache con l'aiuto di WP-Cron, risparmiando tempo agli utenti e riducendo l'utilizzo della larghezza di banda. Perché si attiva solo quando il nostro sito riceve effettivamente un visitatore, la nostra funzione è pigra, un termine che può certamente essere considerato buono in questo contesto. Ma ahimè, abbiamo solo scoperto un'applicazione di WP-Cron qui; Il resto sta a voi.
Hai la tua applicazione innovativa di WP-Cron? Condividilo con noi nei commenti!