Modulo 7 · 7.3

Italiano

Nederlands English Deutsch Français Español Italiano Polski Hrvatski

Cron, Action Scheduler e staging

Modulo 7: Visibilità e hosting · Tempo di lettura: 10 minuti

Obiettivo della lezione: Al termine di questa lezione Lei saprà spiegare come WooCommerce esegue i compiti in background, controllare le azioni programmate e ripristinarle in caso di problemi, e configurare un ambiente di staging per un negozio online in modo che clienti, pagamenti e ordini reali non vengano coinvolti.

Concetti chiave: WP-Cron, cron reale, DISABLE_WP_CRON, Action Scheduler, azioni programmate, in attesa, completato, non riuscito, pulizia, staging per un negozio online, modalità di test del fornitore di pagamento, email disattivate, webhook, integrazioni, non ripristinare il database sopra la produzione

Che cosa succede quando nessuno guarda

Un negozio online svolge molto lavoro che non dipende direttamente dal clic di un visitatore:

annullare gli ordini non pagati quando è scaduto il tempo per Mantieni le scorte (lezione 3.4);
inviare email dopo un cambio di stato e webhook alle integrazioni;
aggiornare report e statistiche nella bacheca;
eliminare le sessioni scadute e i dati temporanei;
applicare i periodi di conservazione impostati in Account e privacy (lezione 2.3);
con abbonamenti o integrazioni contabili: addebitare i pagamenti e trasmettere i dati.

Per questo WordPress utilizza WP-Cron e WooCommerce vi aggiunge l’Action Scheduler. Se non funzionano bene, Lei non se ne accorge subito. Se ne accorge quando gli ordini non pagati continuano a trattenere le scorte, i report restano vuoti o un’integrazione accumula giorni di ritardo.

WP-Cron e cron reale

Come funziona WP-Cron e perché un cronjob reale è migliore è spiegato nel corso su WordPress, lezione 6.3: WP-Cron si avvia con le visite, non con un orologio, ed è quindi inaffidabile con pochi visitatori e pesante con molti. La soluzione: DISABLE_WP_CRON in wp-config.php e un cronjob nel Suo pannello di hosting che esegue wp-cron.php ogni pochi minuti.

Per un negozio online non si tratta di un’ottimizzazione, ma di un requisito:

Di notte, quando le visite sono poche, gli ordini non pagati devono comunque essere annullati in tempo.
Durante una promozione con molto traffico, è proprio da evitare che un compito pesante in background si agganci alla richiesta di pagina di un cliente che sta per pagare.

Con WebOké Lei crea questo compito in DirectAdmin in Processi Cron (DA 15.1, KB 48), con /usr/local/bin/php come percorso di PHP; presso altri provider funziona in modo simile nella loro schermata cron. Per un negozio online scelga un intervallo da uno a cinque minuti, piuttosto che dieci. Un compito che si avvia ogni minuto e non ha nulla da fare non costa quasi nulla.

Action Scheduler: la coda di WooCommerce

L’Action Scheduler è una coda per i compiti in background, fornita insieme a WooCommerce e utilizzata anche da molti altri plugin (abbonamenti, integrazioni contabili, email marketing). Ogni compito è un’azione con un orario e uno stato. La coda viene elaborata tramite un compito WP-Cron (action_scheduler_run_queue), quindi anche qui vale la stessa regola: senza un cron affidabile la coda resta indietro.

Trova tutto in WooCommerce > Stato > Azioni programmate (Scheduled Actions). Ci sono schede per ogni stato:

Stato	Significato	Che cosa fare
In attesa (Pending)	Deve ancora essere eseguita	Se ce ne sono centinaia con un orario nel passato, la coda è in ritardo: controlli il Suo cron
In corso (In-progress)	In esecuzione ora	Se un’azione resta bloccata a lungo, consulti il log accanto
Completato (Complete)	Eseguita	Nulla; vengono eliminate automaticamente
Non riuscito (Failed)	Ha restituito un errore	Legga il messaggio di errore nella colonna Log; spesso si tratta di un plugin o di un’integrazione non raggiungibile
Annullato (Canceled)	Volutamente non eseguita	Di solito nulla

Secondo il codice sorgente, l’Action Scheduler elimina per impostazione predefinita le azioni completate e annullate dopo un mese, quelle non riuscite dopo tre mesi. Se la tabella cresce comunque molto, probabilmente ci sono molte azioni che falliscono di continuo o vengono create di nuovo; individui quale plugin le crea (la colonna Gruppo e il nome dell’hook aiutano), invece di limitarsi a svuotare la tabella.

Un esempio pratico presso Theehuis Example: dopo un cambio di password, l’integrazione con il programma di contabilità metteva in coda ogni ordine come azione non riuscita. Dopo una settimana c’erano 400 azioni non riuscite e mancavano 60 fatture (lezione 5.6). Dopo aver ripristinato l’integrazione, l’amministratore ha potuto rieseguire le azioni una per una con Esegui (Run).

Staging per un negozio online

Che cos’è lo staging, come crearne uno e come proteggerlo (password, noindex) è spiegato nel corso su WordPress, lezione 8.3. Con WebOké è possibile clonando in Installatron (DA 13.7, KB 232) e con una cartella protetta da password (DA 15.9); altri provider offrono strumenti simili. Per un negozio online si aggiungono alcuni punti, perché una copia di un negozio contiene dati reali dei clienti e può eseguire azioni reali.

Subito dopo la clonazione, prima di fare qualsiasi altra cosa:

Fornitore di pagamento in modalità di test, con chiavi di test. Uno staging con chiavi live può ricevere pagamenti reali o eseguire rimborsi.
Email disattivate o deviate. Altrimenti una copia invia conferme, promemoria ed email per carrelli abbandonati a clienti reali. Usi un plugin che blocca tutte le email o le invia a un unico indirizzo di test.
Integrazioni e webhook disattivati. Contabilità, sincronizzazione delle scorte, etichette di spedizione, email marketing: altrimenti lo staging registra fatture o spedisce pacchi. Controlli anche WooCommerce > Impostazioni > Avanzate > Webhook e le chiavi API.
Verificare le azioni programmate. Anche la coda è stata copiata. Altrimenti le azioni in attesa (un’email di promemoria, il pagamento di un abbonamento) vengono eseguite una seconda volta sullo staging.
Limitare i dati personali. Se per i test non Le servono dati reali dei clienti, li elimini o li anonimizzi sullo staging. Uno staging rientra nel GDPR ed è spesso meno protetto (lezione 5.5).

E la regola più importante per il ripristino: non ripristini mai il database dello staging sopra un negozio online in funzione. Tra il momento della clonazione e quello del ripristino si sono aggiunti ordini, clienti, movimenti di magazzino e pagamenti, che andrebbero persi. Ripeta le modifiche sulla produzione (ora sa che funzionano), oppure sincronizzi solo i file. Se deve comunque includere il database, lo faccia solo con il negozio in modalità di manutenzione, subito dopo un backup recente e con uno strumento che esclude ordini e clienti.

Testare un aggiornamento sullo staging

Un percorso tipico per un aggiornamento importante di WooCommerce o di un plugin di pagamento:

Crei uno staging nuovo (clone della produzione) e sistemi i cinque punti indicati sopra.
Esegua l’aggiornamento sullo staging e l’aggiornamento del database se WooCommerce lo richiede.
Effettui un ordine di prova in modalità di test: pagamento, pagamento non riuscito, rimborso (lezione 4.5).
Controlli in Azioni programmate e nel log degli errori se ci sono nuovi errori.
Aggiorni poi la produzione in un momento tranquillo, con un backup eseguito poco prima (lezione 6.2).

Riepilogo

WooCommerce svolge molto lavoro in background, che viene eseguito tramite WP-Cron e l’Action Scheduler.
Per un negozio online utilizzi sempre un cronjob reale (ogni uno-cinque minuti) invece di WP-Cron attivato dalle visite.
Controlli WooCommerce > Stato > Azioni programmate: molte azioni in attesa arretrate o non riuscite indicano che il cron o un’integrazione non funziona.
Sullo staging: fornitore di pagamento in modalità di test, email e integrazioni disattivate, azioni programmate verificate, dati personali limitati.
Non ripristini mai un database di staging sopra un negozio online in funzione; ripeta le modifiche sulla produzione.

Quiz

Esercizio

Esercizio A7.3: Il Suo ambiente di staging è protetto? Si tratta dello stesso controllo dell’esercizio A8.3 del corso su WordPress. Prima Le serve una prova di proprietà del Suo dominio (un record TXT _weboke-cursus.<domein> oppure un file /.well-known/weboke-cursus-<code>.txt con il codice che riceve). Inserisca poi l’indirizzo del Suo negozio e l’indirizzo del Suo staging (un host sotto lo stesso dominio). Il programma richiede la homepage dello staging, senza credenziali di accesso, e quella della produzione. Verde se lo staging chiede una password (401), oppure se ha noindex e usa il proprio indirizzo (l’accesso REST punta all’host di staging), mentre la produzione non ha noindex. Arancione se lo staging ha noindex ma nessuna password, oppure nessun certificato valido. Rosso se lo staging è aperto e indicizzabile, se lo staging punta ancora all’indirizzo della produzione, oppure se la produzione ha noindex per errore.

Domande per Lei (non verificate): sul Suo staging il fornitore di pagamento è in modalità di test? Le email sono disattivate o deviate? Integrazioni e webhook sono disattivati? Quante azioni in attesa e non riuscite ci sono ora in Azioni programmate sulla produzione?

Per saperne di più

Questi articoli descrivono i passaggi nei pannelli di WebOké; in altri pannelli funzionano in modo simile.

Cookie su WebOké

Impostazioni cookie

Necessari

Marketing