Evgenka

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

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

Evgenka    1

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

$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-скрипта через крон обновлялся статус заказа со всеми вытекающими последствиями?

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

Спасибо!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
chukcha    822
2 минуты назад, Evgenka сказал:

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Evgenka    1

Версия 1.5.5.1.1, к сожалению его там нет (

Изменено пользователем Evgenka

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
chukcha    822

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Evgenka    1

понял, спасибо! Сейчас почитаю, каким образом это реализовать

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Evgenka    1

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Evgenka    1

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
chukcha    822
22 минуты назад, Evgenka сказал:

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
chukcha    822
17 минут назад, Evgenka сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Evgenka    1

Через $this->load->model('sale/order'); подключить не удается 

PHP Fatal error:  Using $this when not in object context

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
chukcha    822

хе, а как вы выполняете cron task? как cli?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Evgenka    1

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dotrox    314
7 часов назад, Evgenka сказал:

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
chukcha    822
29 минут назад, Dotrox сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dotrox    314
4 минуты назад, chukcha сказал:

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

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

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

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
chukcha    822

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

 

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
rb2    390
2 hours ago, Dotrox said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dotrox    314
14 часов назад, chukcha сказал:

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

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

 

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

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

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

 

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

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

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

 

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
chukcha    822

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
rb2    390

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dotrox    314

 

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

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

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

 

 

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

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

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

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

 

 

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

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

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

 

 

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
chukcha    822

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dotrox    314
3 минуты назад, chukcha сказал:

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

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

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

 

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

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

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
chukcha    822

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Dotrox    314
9 минут назад, chukcha сказал:

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

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

 

 

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

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

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

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

 

Поделиться сообщением


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

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти


  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу