Il negozio si apre e riceve visite, ma un rinnovo non parte, gli avvisi ai clienti restano fermi o il gestionale non riceve alcuni aggiornamenti.
Una parte delle operazioni WooCommerce viene eseguita in background attraverso azioni programmate. Per capire se la coda è bloccata occorre collegare stato, orario e registri a un caso concreto. Svuotare la lista o rilanciare tutto può nascondere la causa e ripetere operazioni già avvenute.
Indice della guida
Individua quale operazione commerciale si è fermata
Parti da un esempio verificabile: il rinnovo di un abbonamento previsto questa mattina, l’avviso di un prodotto tornato disponibile o un ordine che il gestionale non ha ricevuto. Annota identificativo, orario atteso, risultato osservato e ultimo passaggio riuscito. “Ci sono tante azioni” è una descrizione troppo generica per decidere come intervenire.
La documentazione WooCommerce sulle azioni programmate descrive attività eseguite in background e gli strumenti per controllarle. Non tutte le funzioni del sito passano però dalla stessa coda: l’assenza di una specifica email, per esempio, richiede anche di verificare come il relativo componente la invia.
Distingui un’operazione mai iniziata da una avviata e rifiutata dal servizio esterno. Se la banca ha respinto un pagamento, l’automazione potrebbe aver funzionato correttamente. Per il secondo caso usa anche la guida ai pagamenti WooCommerce non riusciti. Questa guida si concentra invece sul percorso che dovrebbe avviare e completare il lavoro programmato.
Apri la coda e leggi stato, orario e registro
Accedi con un account autorizzato e apri WooCommerce → Stato → Azioni programmate. L’interfaccia di Action Scheduler può essere disponibile anche in Strumenti. Filtra la lista e cerca l’identificativo del caso quando compare negli argomenti dell’azione. I nomi delle voci possono cambiare con la traduzione e la versione.
- In attesa con data futura: può essere un’attività regolare che deve ancora partire.
- In attesa con data superata: confronta il ritardo con l’orario atteso e verifica se la coda avanza.
- In corso: controlla da quanto tempo risulta avviata e cosa riporta il registro, senza avviarne un’altra copia.
- Fallita: apri il log per leggere quando si è interrotta e quale errore è stato registrato.
- Completata: verifica anche il risultato nel processo interessato, come ordine, messaggio o aggiornamento ricevuto.
Salva ID dell’azione, nome tecnico dell’operazione, gruppo, orario e messaggio di errore. Confronta il fuso orario mostrato prima di concludere che vi sia un ritardo. Conserva i dettagli in un canale riservato di assistenza: gli argomenti e i registri possono contenere riferimenti a clienti o sistemi aziendali.
Collega l’errore al componente che genera le azioni
Il nome tecnico, chiamato hook, aiuta a risalire alla funzione che ha creato l’azione. Non è però sempre sufficiente per attribuire la causa: un’estensione può interrompersi perché il servizio collegato non risponde o perché il server termina l’esecuzione. Chiedi al tecnico di associare hook e gruppo al componente effettivamente installato.
Cerca un andamento: falliscono tutte le operazioni dello stesso gruppo, soltanto gli ordini con una particolare caratteristica oppure azioni di più estensioni? Confronta l’inizio del problema con aggiornamenti, cambi di hosting, modifiche alle credenziali o interventi su firewall e cache. Una coincidenza temporale è un indizio da verificare, non una prova definitiva.
Per esempio, se falliscono solo gli invii al gestionale mentre altre azioni recenti si completano, controlla la risposta dell’integrazione prima di cambiare l’intera pianificazione. Se molti gruppi non avanzano, diventa più utile una verifica del sistema che avvia la coda. Riporta al fornitore il testo preciso dell’errore, evitando di ridurlo a “non funziona”.
Confronta ordini e pagamenti prima di ripetere un tentativo
Apri l’ordine o l’abbonamento coinvolto e leggi note, stato e riferimenti delle operazioni. Se è previsto un pagamento, confronta anche ciò che risulta nel pannello del fornitore di pagamento; se è previsto un invio al gestionale, cerca lì il numero d’ordine. Un errore registrato dopo una risposta incerta non dimostra che dall’altra parte non sia avvenuto nulla.
WooCommerce documenta che rinnovi sovrapposti e interventi manuali durante un rinnovo in attesa possono generare ordini duplicati. Controlla quindi gli ordini collegati allo stesso periodo e gli altri tentativi programmati. Un addebito già presente va riconciliato prima di autorizzarne un altro.
Esempio: l’azione relativa al rinnovo 2841 risulta fallita, ma il servizio di pagamento mostra una transazione riuscita. Il percorso corretto è ricostruire l’associazione con l’ordine e capire dove si è fermato l’aggiornamento. Premere nuovamente “Esegui” senza questo confronto potrebbe aggiungere un problema al guasto iniziale.
Se hai già due ordini o due addebiti, segui anche la guida agli ordini duplicati in WooCommerce. Conta le operazioni commerciali reali, non soltanto le righe della coda.
Fai verificare cron, richieste interne e limiti del server
Nella configurazione ordinaria WP-Cron controlla le attività temporizzate quando vengono caricate le pagine. Non è un processo continuamente attivo: con poco traffico possono verificarsi ritardi. Se è stato sostituito con una pianificazione del server, il tecnico deve verificarne percorso, frequenza ed esecuzioni effettive.
Fai controllare Salute del sito, registri del server e richieste con cui il sito avvia le elaborazioni interne. Un blocco delle connessioni interne, un errore PHP o l’esaurimento di una risorsa richiedono interventi diversi. Il controllo deve mostrare quale passaggio fallisce e a quale ora, confrontandolo con i log delle azioni.
Evita di aumentare memoria, frequenza o numero di processi senza misurare il limite raggiunto. Avviare più lavoro contemporaneamente può peggiorare un sovraccarico. Allo stesso modo, non disabilitare la pianificazione esistente senza aver verificato il meccanismo sostitutivo. Concorda con hosting e tecnico una modifica alla volta e conserva il risultato prima e dopo.
Correggi la causa e prepara una prova isolata
Quando l’errore riguarda una specifica estensione, controlla versione, requisiti e indicazioni del fornitore. Per i conflitti usa il percorso descritto da WooCommerce per le prove fra plugin e tema, partendo da una copia di prova e da un backup recuperabile. La disattivazione sul negozio aperto può interrompere altre funzioni commerciali.
Una copia del sito deve essere preparata per non spedire comunicazioni reali, elaborare rinnovi effettivi o trasmettere ordini di prova al magazzino. Verifica modalità di test dei pagamenti, recapiti usati e integrazioni collegate prima di eseguire il caso. Copiare il database non rende automaticamente innocue le automazioni.
Riproduci il problema con dati dimostrativi, applica la correzione e controlla l’intero percorso. Un errore di autenticazione richiede credenziali e permessi corretti; un conflitto può richiedere un aggiornamento compatibile; un limite del server va affrontato con l’hosting. Annota la modifica che ha cambiato l’esito, così da poterla applicare al sito pubblico con un piano preciso.
Organizza la ripartenza senza rilanciare tutta la coda
Dopo aver corretto la causa, separa le operazioni ancora necessarie da quelle già completate, sostituite o non più pertinenti. Il tecnico e il responsabile degli ordini devono concordare quali casi recuperare, in quale ordine e con quale controllo. Non usare l’eliminazione delle azioni fallite come prova di risoluzione.
- Scegli un caso riconciliato e verifica che non abbia già un tentativo in corso o una nuova azione equivalente.
- Usa il percorso di recupero indicato dal componente responsabile: non tutte le estensioni gestiscono i tentativi nello stesso modo.
- Controlla il log e l’esito esterno della prima operazione prima di ampliare il recupero.
- Procedi per gruppi concordati, monitorando carico del server, errori nuovi e operazioni duplicate.
- Interrompi il recupero se ricompare lo stesso errore o se il risultato differisce da quello previsto.
Se serve un intervento manuale su un ordine, registra chi lo ha eseguito e come sarà gestita l’azione automatica corrispondente. La cancellazione di una voce, quando appropriata e documentata dal fornitore, non annulla necessariamente un pagamento o un invio già effettuato.
Verifica i risultati e controlla il ciclo successivo
Una coda più corta è un segnale utile, ma la verifica finale riguarda il lavoro del negozio. Controlla che l’ordine corretto sia arrivato una sola volta al gestionale, che il rinnovo abbia un solo esito valido e che la notifica raggiunga il destinatario previsto. Per le email verifica anche il recapito, oltre alla generazione del messaggio.
Ripeti il controllo alla successiva scadenza automatica: una singola esecuzione manuale riuscita non prova che la pianificazione sia tornata stabile. Mantieni un breve registro con numero di azioni scadute, età della più vecchia, gruppi coinvolti, nuovi errori e casi commerciali ancora aperti. La soglia di attenzione deve seguire il servizio: un ritardo accettabile per una pulizia non lo è necessariamente per un rinnovo.
Chiudi l’intervento con causa individuata, modifica applicata, operazioni recuperate e responsabilità del monitoraggio. Se il guasto torna, questo riepilogo permette di ripartire dai riscontri già raccolti. Per un problema limitato alla velocità dell’amministrazione, approfondisci invece la guida al pannello WordPress lento.
Domande frequenti
Tutte le azioni In attesa indicano un problema?
No. Le attività con una data futura possono essere regolari. Per quelle con orario superato, confronta il ritardo con il processo interessato e verifica se la coda avanza, quali gruppi coinvolge e cosa riportano i registri.
Posso eliminare tutte le azioni fallite per risolvere il blocco?
Eliminare le righe non corregge la causa e può togliere informazioni utili. Prima identifica il componente, conserva i registri e ricostruisci le operazioni ancora necessarie. Concorda eventuali pulizie solo dopo la diagnosi e il recupero.
È sicuro eseguire di nuovo tutte le azioni in ritardo?
Non senza una verifica. Alcune azioni possono avviare pagamenti, notifiche o invii già effettuati. Confronta ordini e servizi esterni, escludi tentativi equivalenti in corso e usa il percorso di recupero previsto dal componente.
Perché il sito funziona mentre i rinnovi non partono?
Le pagine pubbliche e i processi in background possono avere esiti diversi. Controlla la pianificazione, i registri delle azioni e quelli dell’estensione responsabile del rinnovo, distinguendo un mancato avvio da un pagamento rifiutato.
Quali informazioni inviare all’assistenza?
Prepara ID e orario dell’azione, hook, gruppo, errore del registro, ordine o abbonamento coinvolto e ultimo caso riuscito. Aggiungi le modifiche recenti e il riscontro del servizio esterno, condividendo i dati attraverso un canale riservato.