Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

Изменение статуса заказа по CRON


Evgenka

Recommended Posts

Добрый вечер, форумчане. Делаю небольшое дополнение для себя и столкнулся с очередной проблемой. На данном этапе суть состоит в том, что бы при определенных условиях, по крону, менялся статус заказа. Вроде бы ничего сложного, сделал элементарно таким образом 

$query = $db->query("UPDATE `" . DB_PREFIX . "order` SET order_status_id = '5', date_modified = NOW() WHERE order_id = '" . (int)$resulti2['order_id'] . "'");
$query = $db->query("INSERT INTO " . DB_PREFIX . "order_history SET order_id = '" . (int)$resulti2['order_id'] . "', order_status_id = '5', notify = '0', comment = '', date_added = NOW()");

Все вроде бы и ничего, кроме одного НО, который я не учел.

На данный статус (order_status_id = '5') заточены различные модули, например начисление бонусных баллов и, естественно, ББ при смене статуса таким образом не начисляются. При изменении статуса заказа через админку все обрабатывается через ajax, как я понял (возможно конечно и не правильно понял).

Собственно вопрос, как добиться правды, что бы при вызове php-скрипта через крон обновлялся статус заказа со всеми вытекающими последствиями?

Буду крайне благодарен за любой совет и помощь (перед тем как обратиться естественно попытался найти информацию поиском, но так ничего дельного и не нашел).

Спасибо!

Надіслати
Поділитися на інших сайтах


2 минуты назад, Evgenka сказал:

На данный статус (order_status_id = '5') заточены различные модули,

тут такая штука, ведь не зря было сделано api

 

и вам возможно, нужно это все учесть

Надіслати
Поділитися на інших сайтах

22 минуты назад, Evgenka сказал:

Как вызвать функцию  addOrderHistory?

Понятно, что $this->model_sale_order->addOrderHistory($this->request->get['order_id'], $data); не тот случай

ПочемУ?
Заполняйте массив $data

 

Надіслати
Поділитися на інших сайтах

17 минут назад, Evgenka сказал:

Как вызвать эту функцию не из класса?

Не понятен вопрос
Подключайте модель и вызывайте

Надіслати
Поділитися на інших сайтах

7 часов назад, Evgenka сказал:

Вызовом    wget https://site.ru/admin/update.php 

Никогда не запускайте локальные скрипты через wget! Таким образом вы используете лишние ресурсы, создаёте лишнюю задержку, упираетесь во все лимиты, которые используются для запросов через браузер.

 

Что у вас внутри update.php?

Надіслати
Поділитися на інших сайтах


29 минут назад, Dotrox сказал:

Никогда не запускайте локальные скрипты через wget!

не аргументировано.
Зато все необходимые ресурсы задействованы.

Надіслати
Поділитися на інших сайтах

4 минуты назад, chukcha сказал:

не аргументировано.

Аргументы в следующем предложении.

Совсем недавно, кстати, была тема, где при запуске через wget скрипт сначала упёрся в лимиты nginx, потом в ещё что-то.

 

5 минут назад, chukcha сказал:

Зато все необходимые ресурсы задействованы.

Какие ресурсы?

Единственное, что приходит в голову - это получения домена из запроса, но это актуально только в случае мультимагазина, да и то в каких-то экзотических ситуациях, ибо не могу представить крон скрипт для мультимагазина, которому нужен домен из запроса.

Надіслати
Поділитися на інших сайтах


Это не важно... важно, то что доступны все нужные ресурсы,

 

32 минуты назад, Dotrox сказал:

Совсем недавно, кстати, была тема, где при запуске через wget скрипт сначала упёрся в лимиты nginx,

Это уже другой вопрос, но к запуску через wget это не относится

Кстатит, можешь посмотреть что Даниель там лепит с кроном

Надіслати
Поділитися на інших сайтах

2 hours ago, Dotrox said:

Никогда не запускайте локальные скрипты через wget! Таким образом вы используете лишние ресурсы, создаёте лишнюю задержку, упираетесь во все лимиты, которые используются для запросов через браузер.

С таким же успехом можно советовать никогда не заходить в админку броузером, ведь при этом вы используете лишние ресурсы и упираетесь в лимиты, если упираетесь.

  • +1 1
Надіслати
Поділитися на інших сайтах


14 часов назад, chukcha сказал:

важно, то что доступны все нужные ресурсы

Я всё же не понимаю о каких ресурсах идёт речь, которые доступны только через wget. Я, например, для запуска по крону использовал всегда модифицированную версию index.php и никогда при запуске через cli не чувствовал нехватки чего-либо.

 

14 часов назад, chukcha сказал:

Это уже другой вопрос, но к запуску через wget это не относится

А относится к любому варианту запуска через tcp. В этом стеке куча лимитов, в том числе и объективных (например, количество портов), не говоря уж про всякие таймауты.

 

13 часов назад, rb2 сказал:

С таким же успехом можно советовать никогда не заходить в админку броузером, ведь при этом вы используете лишние ресурсы и упираетесь в лимиты, если упираетесь.

А ещё можно посоветовать не печатать на клавиатуре пальцами, ибо от этого стираются надписи на клавишах. :) И это будет такой же глупый пример, как и с админкой - админка предназначена для браузера и других вариантов работы с ней и нет, а крон скрипт для браузера никак не предназначен. И то, что его можно запускать таким образом не значит, что нужно.

 

Помимо того, о чём я уже написал выше, есть и другие особенности wget/curl: например, при переезде на другой хостинг можно забыть отключить на старом крон и до тех пор, пока там не закончится оплаченный период wget будет дёргать скрипт на новом, что будет приводить к двойным запускам и долгим попыткам найти причину.

На моём опыте был более смешной пример: в магазине внезапно отвалилась автовыгрузка, которая запускалась кроном и заказчик уверял, что ничего не трогал уже давно. Как оказалось, за пол года до того был переезд и на новом хостинге на крон ничего не ставили, а выгрузку дёргал wget со старого хостинга пока, вероятно, там оплата не истекла. В результате получилась часовая бомба. Конечно, cli бы не спас от забывчивости заказчика, но выгрузка отвалившаяся сразу после переезда, а не через пол года - существенно упростила бы поиск причины.

 

Да и вообще, делать доступными крон скрипты из браузера - это плохая идея. Особенно в случае модулей, когда путь известен и кто-то может захотеть побаловаться.

 

Собственно, я уже привёл различного рода аргументы, почему wget/curl - зло по сравнению с cli, но так и не услышал ни одного аргумента против cli или в пользу wget/curl (про ресурсы я пока понять не могу, поскольку при cli запуске ещё не сталкивался с отсутствием чего либо).

Надіслати
Поділитися на інших сайтах


А никто и не спрашивал аргументы за или против, что лучше или что предпочесть. Было чётко и однозначно сказано, что вгет нельзя только потому, что он толще на размер апача и жрёт ресурсы. Ай, какая беда. Вот и весь ответ.

 

Конечно, если есть возможность переписать под CLI - почему бы и нет. Но иногда хочется использовать именно готовое, а не писать велосипед. По разным причинам. Иногда - готовый доступ к переменным окружения или POST, чтобы не переписывать это всё с нуля и заново для принятия этих данных из командной строки или конфиг файла. Иногда - чтобы не плодить две копии кода фичи, которая ещё развивается, и аккуратно сопровождать их непонятно ради какой причины. И заявлять "вгет нельзя, потому что ресурсы" - как минимум странно. Потому что есть инструмент, и есть области применения - иногда можно так, иногда так, иногда удобней одно, иногда другое.

Надіслати
Поділитися на інших сайтах


 

11 часов назад, rb2 сказал:

толще на размер апача и жрёт ресурсы

Не только Апача (и не всегда именно его), а толще на весь веб стек (который несёт кучу ограничений и узких мест)!  И там не было "потому что", там был просто список из различных недостатков такого метода, чтоб непосвящённым было понятно, чем этот вариант хуже.

 

 

11 часов назад, rb2 сказал:

готовый доступ к переменным окружения или POST

Люди, умеющие отправлять POST данные через wget, думаю, достаточно продвинуты, чтоб фильтровать информацию с форумов и понимать, когда им действительно необходим wget, а когда он не будет иметь никаких преимуществ перед cli, а только лишь недостатки.

А люди задающие вопросы на этом форуме умудряются даже копипастя готовые редиректы зачем-то вносить в них правки, которые приводят к смешным результатам. И давая советы я пытаюсь это учитывать.

 

 

11 часов назад, rb2 сказал:

заявлять "вгет нельзя, потому что ресурсы" - как минимум странно

Странно, что вы увидели в списке недостатков только ресурсы :) Список содержал все недостатки, которые пришли в голову, чтоб картина была более полной и информативной, но реально самый ощутимый недостаток, на который натыкаются люди довольно часто - это таки лимиты (различные таймауты, лимиты памяти, воркеров и т.д.), от nginx и до php включая всё, что между ними.

 

 

12 часов назад, rb2 сказал:

есть инструмент, и есть области применения - иногда можно так, иногда так, иногда удобней одно, иногда другое.

И с этим глупо было бы спорить. Но смысл это имеет только для тех, кто вообще понимает разницу между wget и cli, а не просто использует то, что первым нагуглилось. А кто понимает разницу, и без меня хорошо знает обо всех недостатках запуска через wget.

 

Надіслати
Поділитися на інших сайтах


Ой, да сколько там ресурсов.
крон крутится раз в час, раз в день, раз в месяц, если не говорить о системных задачах.
Но если мне нужны все ресурсы (валюта, язык, налоги и прочее_ то мне проще запустить и через wget
Кроме того, такую задачу, я могу запустить и чрез web ручками, если нужно это сделать срочно, до выполнения задачи кроном.

Надіслати
Поділитися на інших сайтах

3 минуты назад, chukcha сказал:

если мне нужны все ресурсы (валюта, язык, налоги и прочее_ то мне проще запустить и через wget

Вот этого момента я всё никак не могу понять - что ты такое запускаешь через cli, что там нет доступа к валюте, языку и всему остальному?

Как я уже писал выше, я для cli использую немного модифицированный index.php (в тех версиях, где он был толстым) и в результате имею доступ абсолютно ко всему, что доступно при обычном заходе на сайт через браузер (конечно, помимо данных, которые передаёт сам браузер).

 

11 минут назад, chukcha сказал:

такую задачу, я могу запустить и чрез web ручками, если нужно это сделать срочно, до выполнения задачи кроном.

Мой вариант тоже так можно запустить. Правда. я обычно добавляю проверку на тип окружения, чтоб как раз из браузера никто не запускал. Но при необходимости можно проверку закомментировать и запустить.

 

13 минут назад, chukcha сказал:

крон крутится раз в час, раз в день, раз в месяц, если не говорить о системных задачах.

Но там могут быть разные задачи. Например, почтовая рассылка, которая вполне может длиться час. Если запускать такое через wget, то и в таймауты упрётся, и воркер Apache или php-fpm всё это время будет забит. На ukraine.com.ua, например, дают 10 воркеров Apache на весь аккаунт (а не на отдельный сайт).

Надіслати
Поділитися на інших сайтах


@Dotrox хе-хе в лимиты хостера упрется и cli

Ты приводишь уникальный пример с рассылкой
Я тебе привожу простейший пример задачи крона. где нужно поменять статусы
Я такие кроны еще защищаю секретным ключом.

 

Надіслати
Поділитися на інших сайтах

9 минут назад, chukcha сказал:

в лимиты хостера упрется и cli

Ну, прежде всего, его единственные лимиты - это лимиты непосредственно php. Кроме того, с ними обычно всё не так жёстко: например, max_execution_time для cli по дефолту 0, что означает отсутствие таймаута. И, как показывает практика, далеко не каждый хостер с этим что-то делает.

 

 

18 минут назад, chukcha сказал:

Ты приводишь уникальный пример с рассылкой

Не уникальный, а просто достаточно красноречивый.

Ещё можно привести примеры различных генераций. Например, генерация выгрузки для Я.Маркет довольно часто упирается в таймауты, если товаров много. То есть, оно в браузере просто перестаёт открываться и задача крона как раз решить эту проблему, а с wget ничего он не решит, а получит тот же результат (отсутствие результата).

 

Надіслати
Поділитися на інших сайтах


Створіть аккаунт або увійдіть для коментування

Ви повинні бути користувачем, щоб залишити коментар

Створити обліковий запис

Зареєструйтеся для отримання облікового запису. Це просто!

Зареєструвати аккаунт

Вхід

Уже зареєстровані? Увійдіть тут.

Вхід зараз
  • Зараз на сторінці   0 користувачів

    • Ні користувачів, які переглядиють цю сторінку

×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.