Cron, Action Scheduler и staging

Модул 7: Откриваемост и хостинг · Време за четене: 10 минути

Учебна цел: След този урок ще можете да обясните как WooCommerce изпълнява задачи във фонов режим, да проверявате планираните действия и да ги възстановявате при проблеми, както и да настроите staging среда за онлайн магазин така, че да не бъдат засегнати реални клиенти, плащания или поръчки.

Основни понятия: WP-Cron, истински cron, DISABLE_WP_CRON, Action Scheduler, планирани действия, изчакващи, завършени, неуспешни, почистване, staging за онлайн магазин, тестов режим на доставчика на плащания, изключена поща, webhooks, интеграции, без връщане на базата данни върху продукционната среда

Какво се случва, когато никой не гледа

Онлайн магазинът върши много работа, която не е пряко свързана с кликване на посетител:

• анулира неплатени поръчки, когато времето за задържане на наличност изтече (урок 3.4);
• изпраща имейли след промяна на състоянието, както и webhooks към интеграции;
• обновява отчетите и статистиките в администрацията;
• почиства изтекли сесии и временни данни;
• прилага сроковете за съхранение от Профили и поверителност (урок 2.3);
• при абонаменти или интеграции със счетоводни програми: събира плащания и препраща данни.

За това WordPress използва WP-Cron, а WooCommerce добавя към него Action Scheduler. Ако те не работят добре, няма да го забележите веднага. Ще го забележите, когато неплатени поръчки продължават да задържат наличност, отчетите остават празни или някоя интеграция изостава с дни.

WP-Cron и истински cron

Как работи WP-Cron и защо истинският cron job е по-добър, е обяснено в курса за WordPress, урок 6.3: WP-Cron се стартира при посещения, а не по часовник, което е ненадеждно при малко посетители и натоварващо при много посетители. Решението: DISABLE_WP_CRON в wp-config.php и cron job във Вашия хостинг панел, който стартира wp-cron.php на всеки няколко минути.

За онлайн магазин това не е оптимизация, а изискване:

• През нощта, когато посещенията са малко, неплатените поръчки все пак трябва да се анулират навреме.
• По време на натоварена промоция не искате тежка фонова задача да се изпълнява заедно със заявката на клиент, който иска да плати.

При WebOké създавате такава задача в DirectAdmin в Cron Jobs (DA 15.1, KB 48), с /usr/local/bin/php като път до PHP; при други доставчици на хостинг това работи по подобен начин в техния екран за cron. За онлайн магазин изберете интервал от една до пет минути, а не десет. Задача, която се стартира всяка минута и няма какво да прави, не струва почти нищо.

Action Scheduler: опашката на WooCommerce

Action Scheduler е опашка за фонови задачи, която се доставя заедно с WooCommerce и се използва и от много други плъгини (абонаменти, интеграции със счетоводни програми, имейл маркетинг). Всяка задача е действие с час и състояние. Опашката се обработва чрез задача на WP-Cron (action_scheduler_run_queue), така че и тук важи същото: без надежден cron опашката изостава.

Всичко виждате в WooCommerce > Състояние > Планирани действия (Scheduled Actions). Има раздели за всяко състояние:

Според изходния код Action Scheduler по подразбиране почиства завършените и отказаните действия след един месец, а неуспешните след три месеца. Ако таблицата въпреки това расте бързо, вероятно има много действия, които многократно се провалят или се създават отново; разберете кой плъгин ги създава (колоната Група и името на hook помагат), вместо просто да изпразвате таблицата.

Пример от практиката при Theehuis Example: след смяна на парола интеграцията със счетоводната програма поставяше всяка поръчка в опашката като неуспешно действие. След седмица имаше 400 неуспешни действия и липсваха 60 фактури (урок 5.6). След възстановяване на интеграцията администраторът можеше да стартира действията отново едно по едно с Run now (Run).

Staging за онлайн магазин

Какво е staging, как се създава и как се защитава (парола, noindex), е обяснено в курса за WordPress, урок 8.3. При WebOké това става чрез клониране в Installatron (DA 13.7, KB 232) и папка с парола (DA 15.9); други доставчици на хостинг имат подобни инструменти. За онлайн магазин към това се добавят някои неща, защото копието на магазина съдържа реални данни на клиенти и може да извършва реални действия.

Веднага след клонирането, преди да направите каквото и да е друго:

1. Доставчикът на плащания в тестов режим, с тестови ключове. Staging с live ключове може да получава реални плащания или да извършва възстановявания на суми.
2. Изключена или пренасочена поща. Иначе копието изпраща потвърждения, напомняния и имейли за изоставена количка на реални клиенти. Използвайте плъгин, който спира цялата поща или я изпраща на един тестов адрес.
3. Изключени интеграции и webhooks. Счетоводство, синхронизация на наличности, етикети за доставка, имейл маркетинг: иначе staging осчетоводява фактури или изпраща пратки. Проверете също WooCommerce > Настройки > Разширени > Webhooks и API ключовете.
4. Проверка на планираните действия. Опашката също е копирана. Иначе изчакващите действия (имейл с напомняне, плащане по абонамент) ще се изпълнят още веднъж на staging.
5. Ограничаване на личните данни. Ако не Ви трябват реални данни на клиенти за тестване, изтрийте ги или ги анонимизирайте на staging. Staging средата също попада под GDPR и често е по-слабо защитена (урок 5.5).

И най-важното правило при връщане: никога не връщайте базата данни от staging върху работещ магазин. Между момента на клониране и връщането са се появили нови поръчки, клиенти, промени в наличностите и плащания; тогава ще ги загубите. Направете промените отново на продукционната среда (вече знаете, че работят) или синхронизирайте само файловете. Ако все пак трябва да се направи с базата данни, правете го само с магазин в режим на поддръжка, веднага след свежо резервно копие и с инструмент, който пропуска поръчките и клиентите.

Тестване на актуализация на staging

Типичен път за голяма актуализация на WooCommerce или на плъгин за плащания:

1. Създайте свежа staging среда (клонинг на продукционната) и настройте петте точки по-горе.
2. Актуализирайте на staging и изпълнете актуализацията на базата данни, ако WooCommerce я поиска.
3. Направете тестова поръчка в тестов режим: плащане, неуспешно плащане, възстановяване на сума (урок 4.5).
4. Проверете в Планирани действия и в дневника за грешки дали има нови грешки.
5. След това актуализирайте продукционната среда в спокоен момент, с резервно копие точно преди това (урок 6.2).

Обобщение

• WooCommerce върши много работа във фонов режим; тя се изпълнява чрез WP-Cron и Action Scheduler.
• За онлайн магазин винаги използвайте истински cron job (на всеки една до пет минути) вместо WP-Cron при посещения.
• Проверявайте WooCommerce > Състояние > Планирани действия: много просрочени изчакващи или неуспешни действия са знак, че cron или някоя интеграция не работи.
• На staging: доставчикът на плащания в тестов режим, изключени поща и интеграции, проверка на планираните действия, ограничаване на личните данни.
• Никога не връщайте staging база данни върху работещ магазин; направете промените отново на продукционната среда.

Тест (quiz)

Задача

Задача A7.3: Защитена ли е Вашата тестова среда (staging)? Това е същата проверка като задача A8.3 от курса за WordPress. Първо Ви е необходимо доказателство за собственост на Вашия домейн (TXT запис _weboke-cursus.<domein> или файл /.well-known/weboke-cursus-<code>.txt с кода, който получавате). След това въведете адреса на Вашия магазин и адреса на Вашата staging среда (хост под същия домейн). Програмата зарежда началната страница на staging средата без данни за вход, както и тази на продукционната среда. Зелено, ако staging средата иска парола (401) или ако има noindex и използва собствения си адрес (REST входът сочи към staging хоста), докато продукционната среда няма noindex. Оранжево, ако staging средата има noindex, но няма парола, или няма валиден сертификат. Червено, ако staging средата е отворена и може да се индексира, ако staging средата все още сочи към адреса на продукционната среда или ако продукционната среда по погрешка има noindex.

Въпроси към Вас (не се проверяват): в тестов режим ли е доставчикът на плащания на Вашата staging среда? Изключена или пренасочена ли е пощата? Изключени ли са интеграциите и webhooks? Колко изчакващи и неуспешни действия има в момента в Планирани действия на продукционната среда?

Прочетете още

Тези статии описват стъпките в панелите на WebOké; в други панели те работят по подобен начин.

• Ръководство за DirectAdmin 15.1: Cron Jobs: автоматично изпълнение на задачи
• Създаване на cronjob или задача (и какво да направите, ако не се изпълнява)
• Създаване на WordPress staging среда
• Ръководство за DirectAdmin 13.7: Клониране и създаване на тестова среда (staging)
• Ръководство за DirectAdmin 15.9: Защитени с парола директории
• Безплатен курс по WordPress 8.3: Staging: безопасно тестване
• Безплатен курс по WordPress 6.3: Изображения, PHP и други подобрения в скоростта
• Action Scheduler (actionscheduler.org, на английски): https://actionscheduler.org/
• WooCommerce Статус и Планирани действия: откриване на проблеми
• Тестова среда (staging) за Вашия онлайн магазин