FIX HUGE SQL tables: wp_actionscheduler_actions & wp_actionscheduler_logs [WooCommerce Tips]

WooCommerce a ajuns un modul foarte utilizat de tot mai multe magazine online. SEO, managementul produselor, stocurilor, codul curat si intuitiv, interfata de administrare simpla si miile de plugin-uri dezvoltate pentru Woo, sunt doar cateva din argumentele pentru care merita o sansa atunci cand va ganditi sa dezvoltati un magazin online.

Ca orice CMS, nici Woo nu face exceptii de la ciudateniile care pot sa apara in diferite scenarii de utilizare sau de interactiune cu alte plugin-uri de WordPress.
Pe un server cu resurse hardware destul de generoase, am observat ca serviciul bazei de date (mysqld) incepe sa solicite aproape 80  – 90% din memoria RAM. O problema destul de serioasa, pentru ca pur si simplu nu intelegeam de unde vine periodic eroarea 110 (110: Connection timed out).
La o verificare mai atenta a proceselor SQL, am descoperit ca o baza de date are doua tabele cu volume destul de considerabile: wp_actionscheduler_actions si wp_actionscheduler_logs.

In mod normal actiunile programate ale WooCommerce Action Scheduler ar trebui sa se stearga automat dupa ce sunt executate. Nu se intampla mereu acest lucru, iar ele raman blocate in wp_actionsscheduler_actions cu statusul: failed, canceled, pending sau complete.

In imaginea de mai sus, tabelele “wp_actionsscheduler” nu au decat putin peste 15 MB. Imi pare rau ca nu am fost inspirat sa fac un screenshot cand aveau 1.2 GB. Chiar si asa, 15 MB este destul mult pentru un tabel care contine actiunile programate ale WooCommerce.
Aceste tabele “umflate” rezulta din cauza ca WP-Cron nu sterge intrarile care au status “failed“, “canceled” si “complete“. In mod normal aceste intrari trebuie sa fie sterse automat din baza de date.
Actiunile programate si starea lor putem sa o vedem foarte usor si in WooCommerce →  Status →  Scheduled Actions.

Cum curatam inrarile “failed“, “canceled” si “complete” din wp_actionscheduler_actions si wp_actionscheduler_logs

Accesam baza de date prin phpMyAdmin, apoi la SQL executam pe rand liniile de comanda:

DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'canceled'

DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'complete'

DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'failed'

Odata curatat acest tabel, nu inseamna si ca problema este rezolvata. Asa cum am spus mai sus, principala cauza este dezactivarea din diverse motive a serviciului WP-Cron. Astfel intrarile cu statusuri “zombie” nu mai pot fi sterse.
Este foarte important de stiut ca daca aveti un magazin online pe WooCommerce, iar acesta este conectat la Facebook Shops prin plugin-ul “Facebook for WooCommerce“, acesta sincronizeaza automat produsele din WooCommerce cu contul dvs. de Facebook Shops. Si o face cam la 15 minute. Aceste intrari in SQL daca nu sunt controlate, puteti obtine cateva sute de mii de linii “wc_facebook_regenerate_feed” in “wp_actionscheduler_actions“.

Acest interval este ok pentru magazinele care au un numar mare de comenzi si este nevoie ca stocul produselor din Facebook Shops sa fie actualizat constant. Daca totusi considerati ca aceste sincronizari dinre Facebook si magazinul dvs. se pot face odata la 24 de ore, linia de cod de mai jos va poate ajuta.

Deschideti fisierul functions.php al temei de WordPress / WooCommerce pe care ruleaza magazinul dvs. si adaugati:

add_filter( 'wc_facebook_feed_generation_interval', function(){ return HOUR_IN_SECONDS * 24; } );

In continuare putem seta un interval de o saptamana pentru curatare automata:

add_filter( 'action_scheduler_retention_period', 'wpb_action_scheduler_purge' );
function wpb_action_scheduler_purge() {
 return WEEK_IN_SECONDS;
}

Odata salvate aceste modificari nu veti mai avea probleme cu tabele gigant pentru “wp_actionscheduler_actions”.