Woocommerce det har blivit en mycket använd modul av fler och fler tidskrift online. SEO, produkt- och lagerhantering, ren och intuitiv kod, enkelt administrationsgränssnitt och de tusentals plugins som utvecklats för Woo, är bara några av anledningarna till att det förtjänar en chans när du tänker på att utveckla en onlinebutik.

Som alla CMS är Woo inte undantagen från konstigheterna som kan dyka upp i olika scenarier för användning eller interaktion med andra WordPress-plugins.
På en server med resurser hårdvara ganska generöst, det märkte jag databastjänst (mysqld) börjar begära nästan 80– 90 % av RAM-minnet. Ett ganska allvarligt problem, eftersom jag helt enkelt inte förstod var felet 110 kommer ifrån periodvis (110: Anslutningen tog timeout).
Vid närmare granskning av SQL-processerna upptäckte jag att en databas har två tabeller med ganska stora volymer: wp_actionscheduler_actions och wp_actionscheduler_logs.

I mod normal schemalagda åtgärder men WooCommerce Action Scheduler de bör raderas automatiskt efter att de har körts. Detta händer inte alltid, och de förblir blockerade i wp_actionsscheduler_actions med statusen: misslyckades, avbruten, i avvaktan på eller komplett.

I bilden ovan, tabellerna “wp_actionsscheduler” de har bara lite över 15 MB. Jag är ledsen att jag inte blev inspirerad att ta en skärmdump när de gjorde det1,2 GB. Trots det är 15 MB ganska mycket för en tabell som innehåller schemalagda WooCommerce-åtgärder.
Dessa tabeller “UPPBLÅST” det härrör från ca WP-Cron tar inte bort poster vård eller status “misslyckades“, “avbruten” och “komplett“. Normalt måste dessa poster automatiskt raderas från databasen.
De programmerade åtgärderna och deras status kan mycket enkelt ses i Woocommerce →Status →Schemalagda åtgärder.

Hur rengör vi avloppen? “misslyckades“, “avbruten” och “komplett” FRÅNwp_actionscheduler_actions och wp_actionscheduler_logs

Vi kommer åt databasen genom phpMyAdmin, sedan i SQL kör vi kommandoraderna i tur och ordning:

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

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

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

När detta bord väl är rengjort betyder det inte att problemet är löst. Som jag sa ovan är huvudorsaken inaktiveringen av WP-Cron-tjänsten av olika anledningar. Alltså poster med status “zombie” de kan inte längre raderas.
Det är mycket viktigt att veta att om du har en webbutik på WooCommerce, och den är ansluten till Facebook Shops via plugin “Facebook för WooCommerce“, den synkroniserar automatiskt WooCommerce-produkter med ditt Facebook Shops-konto. Och han gör det var 15:e minut. Om dessa SQL-poster inte kontrolleras kan du få flera hundratusentals rader “wc_facebook_regenerate_feed” i “wp_actionscheduler_actions“.

Detta intervall är ok för butiker som har ett stort antal beställningar och det är nödvändigt att lagret av produkter i Facebook Shops uppdateras ständigt. Om du fortfarande tror att dessa synkroniseringar mellan Facebook och din butik kan göras en gång var 24:e timme, kan kodraden nedan hjälpa dig.

Öppna functions.php-filen för WordPress / WooCommerce-temat som din butik körs på och lägg till:

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

Därefter kan vi ställa in ett intervall på en vecka för automatisk rengöring:

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

När dessa ändringar har sparats kommer du inte längre att ha problem med gigantiska tabeller för “wp_actionscheduler_actions”.