WooCommerce tas ir kļuvis par ļoti izmantotu moduli arvien vairāk un vairāk Žurnāls tiešsaistēApvidū SEO, produktu un krājumu pārvaldība, tīrs un intuitīvs kods, vienkāršs administrēšanas interfeiss un tūkstošiem Woo izstrādāto spraudņu ir tikai daži no iemesliem, kāpēc tas ir pelnījis iespēju, domājot par tiešsaistes veikala izveidi.

Tāpat kā jebkura CMS, arī Woo nav atbrīvots no dīvainībām, kas var parādīties dažādos lietošanas scenārijos vai mijiedarbībā ar citiem WordPress spraudņiem.
Uz servera ar resursiem aparatūra diezgan dāsni, es to pamanīju datu bāzes pakalpojums (mysqld) sāk pieprasīt gandrīz 80– 90% RAM. Diezgan nopietna problēma, jo es vienkārši nesapratu, no kurienes periodiski rodas kļūda 110 (110: savienojuma noildze).
Rūpīgāk izpētot SQL procesus, atklāju, ka vienā datu bāzē ir divas tabulas ar diezgan ievērojamiem apjomiem: wp_actionscheduler_actions un wp_actionscheduler_logsApvidū

Normālā režīmā plānotās darbības bet WooCommerce darbību plānotājs tie ir automātiski jāizdzēš pēc to izpildes. Tas ne vienmēr notiek, un tie paliek bloķēti failā wp_actionsscheduler_actions ar statusu: neizdevās, atcelts, gaida vai pabeigtApvidū

Augšējā attēlā tabulas “wp_actionsscheduler” viņiem ir tikai nedaudz vairāk par 15 MB. Man žēl, ka nebiju iedvesmots uzņemt ekrānuzņēmumu, kad viņi to izdarīja1,2 GB. Tomēr 15 MB ir diezgan daudz tabulai, kurā ir ieplānotas WooCommerce darbības.
Šīs tabulas “PIEPPUTS” tas izriet no apm WP-Cron neizdzēš ierakstus aprūpe vai statuss “neizdevās“, “atcelts” un “pabeigt“. Parasti šie ieraksti ir automātiski jāizdzēš no datu bāzes.
Ieprogrammētās darbības un to statusu var ļoti viegli redzēt WooCommerce →Statuss →Plānotās darbībasApvidū

Kā mēs tīrām notekcaurules? “neizdevās“, “atcelts” un “pabeigt” Nowp_actionscheduler_actions un wp_actionscheduler_logs

Mēs piekļūstam datu bāzei caur phpMyAdmin, tad SQL mēs pēc kārtas izpildām komandrindas:

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

DZĒST NO `wp_actionscheduler_actions` WHERE `status` = 'pabeigts'

DELETE FROM `wp_actionscheduler_actions` WHERE `status` = 'neizdevās'

Kad šī tabula ir notīrīta, tas nenozīmē, ka problēma ir atrisināta. Kā jau teicu iepriekš, galvenais iemesls ir WP-Cron pakalpojuma deaktivizēšana dažādu iemeslu dēļ. Tādējādi ieraksti ar statusiem “zombijs” tos vairs nevar izdzēst.
Ir ļoti svarīgi zināt, ka, ja jums ir tiešsaistes veikals vietnē WooCommerce un tas ir savienots ar Facebook veikaliem, izmantojot spraudni. “Facebook paredzēts WooCommerce“, tas automātiski sinhronizē WooCommerce produktus ar jūsu Facebook veikalu kontu. Un viņš to dara ik pēc 15 minūtēm. Ja šie SQL ieraksti netiek kontrolēti, varat iegūt vairākus simtus tūkstošu rindu “wc_facebook_regenerate_feed” iekšā “wp_actionscheduler_actions“Apvidū

Šis intervāls ir ok veikaliem, kuriem ir liels pasūtījumu skaits un nepieciešams, lai preču krājumi Facebook veikalos tiktu pastāvīgi papildināti. Ja jūs joprojām domājat, ka šīs sinhronizācijas starp Facebook un jūsu veikalu var veikt reizi 24 stundās, zemāk esošā koda rinda var jums palīdzēt.

Atveriet WordPress/WooCommerce motīva failu functions.php, kurā darbojas jūsu veikals, un pievienojiet:

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

Tālāk mēs varam iestatīt vienas nedēļas intervālu automātiskai tīrīšanai:

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

Kad šīs izmaiņas ir saglabātas, jums vairs nebūs problēmu ar milzīgām tabulām “wp_actionscheduler_actions”Apvidū