Перейти к публикации
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...

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


Evgenka
 Поделиться

Рекомендованные сообщения

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

$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

 

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

Ссылка на комментарий
Поделиться на других сайтах

так тогда меняйте статус через addOrderHistory, а не прямым вмешательством в базу

Ссылка на комментарий
Поделиться на других сайтах

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

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

Ссылка на комментарий
Поделиться на других сайтах


 $data = array(
    'order_status_id' => 5,
    'notify' => false,
    'comment' => false
    );

$this->model_sale_order->addOrderHistory('3993', $data);

 

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

Ссылка на комментарий
Поделиться на других сайтах


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 запуске ещё не сталкивался с отсутствием чего либо).

Ссылка на комментарий
Поделиться на других сайтах


Не передергивай.
Ты категорично сказал, что wget пользоваться низзя!

Вот и весь сыр бор
 

Ссылка на комментарий
Поделиться на других сайтах

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

 

Конечно, если есть возможность переписать под 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 пользователей

    • Нет пользователей, просматривающих эту страницу.
×
×
  • Создать...

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.