WooCommerce è diventato un modulo molto utilizzato da sempre più persone rivista in linea. Seo, gestione dei prodotti e delle scorte, codice pulito e intuitivo, interfaccia di amministrazione semplice e le migliaia di plugin sviluppati per Woo, sono solo alcuni dei motivi per cui merita una possibilità quando si pensa di sviluppare un negozio online.
Come ogni CMS, Woo non è esente dalle stranezze che possono apparire nei diversi scenari di utilizzo o interazione con altri plugin di WordPress.
Su un server con risorse hardware piuttosto generoso, l'ho notato servizio di banca dati (mysqld) inizia a richiederne quasi 80– 90% della RAM. Un problema piuttosto serio, perché semplicemente non ho capito da dove provenga periodicamente l'errore 110 (110: Connessione scaduta).
Dopo un esame più attento dei processi SQL, ho scoperto che un database ha due tabelle con volumi piuttosto considerevoli: wp_actionscheduler_actions E wp_actionscheduler_logs.
Nella modalità normale azioni programmate Ma Pianificatore di azioni WooCommerce dovrebbero essere cancellati automaticamente dopo essere stati eseguiti. Ciò non accade sempre e rimangono bloccati in wp_actionsscheduler_actions con lo stato: fallito, annullato, in attesa di O completare.
Nell'immagine sopra, le tabelle “wp_actionsscheduler” hanno solo poco più di 15 MB. Mi dispiace di non aver avuto l'ispirazione di fare uno screenshot quando l'hanno fatto1,2GB. Anche così, 15 MB sono molti per una tabella che contiene azioni WooCommerce pianificate.
Questi tavoli “GONFIATO” risulta da ca WP-Cron non cancella le voci cura dello stato “fallito“, “annullato” E “completare“. Normalmente queste voci devono essere cancellate automaticamente dal database.
Le azioni programmate e il loro stato possono essere visualizzati molto facilmente in WooCommerce →Stato →Azioni pianificate.
Come puliamo gli scarichi? “fallito“, “annullato” E “completare” DAwp_actionscheduler_actions E wp_actionscheduler_logs
Accediamo al database tramite phpMyAdmin, quindi in SQL eseguiamo a turno le righe di comando:
DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'canceled'
DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'complete'
DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'failed'
Una volta pulita questa tabella, ciò non significa che il problema sia risolto. Come dicevo sopra, la causa principale è la disattivazione del servizio WP-Cron per vari motivi. Quindi le voci con stati “zombie” non possono più essere cancellati.
È molto importante sapere che se hai un negozio online su WooCommerce, ed è collegato a Facebook Shops tramite il plugin “Facebook per WooCommerce“, sincronizza automaticamente i prodotti WooCommerce con il tuo account Facebook Shops. E lo fa ogni 15 minuti. Se queste voci SQL non vengono controllate, puoi ottenere diverse centinaia di migliaia di righe “wc_facebook_regenerate_feed” In “wp_actionscheduler_actions“.
Questo intervallo va bene per i negozi che hanno un numero elevato di ordini ed è necessario che lo stock di prodotti nei Facebook Shops sia costantemente aggiornato. Se ritieni ancora che queste sincronizzazioni tra Facebook e il tuo negozio possano essere eseguite una volta ogni 24 ore, la riga di codice seguente può aiutarti.
Apri il file Functions.php del tema WordPress/WooCommerce su cui è in esecuzione il tuo negozio e aggiungi:
add_filter( 'wc_facebook_feed_generation_interval', function(){ return HOUR_IN_SECONDS * 24; } );
Successivamente, possiamo impostare un intervallo di una settimana per la pulizia automatica:
add_filter( 'action_scheduler_retention_period', 'wpb_action_scheduler_purge' );
function wpb_action_scheduler_purge() {
 return WEEK_IN_SECONDS;
}
Una volta salvate queste modifiche, non avrai più problemi con le tabelle giganti “wp_actionscheduler_actions”.
 
			



@Stealth
Grazie per l'aiuto Mi salvi la giornata e fai acquisti. L'ho scoperto solo dopo un crash del mio negozio online. Molti plugin hanno iniziato a scaricare il loro output in quella tabella e questa si riempie… Il wooping del tavolo da 9,2 GB ha costretto il mio host a rinunciare al suo tempo di opp altrimenti buono. Ora rifilo con il bel codice!
Solo una domanda sulla corda anticaduta di questo tavolo “wpb_action_scheduler_purge” è un'impostazione predefinita nel db o devo rinominarla in qualcosa nel mio (per impostazione predefinita il mio db non si chiama 'wp_’ ) o è forse una funzione?
Grazie per l'aiuto e l'articolo super carino
Saluto
Netzie