Linkoln

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

UPD: Залез в system/frimework.php в строчке, где устанавливаются куки setcookie($config->get('session_name'), $session->getId(), ini_get('session.cookie_lifetime'), ini_get('session.cookie_path'), ini_get('session.cookie_domain')); Пробовал вручную изменить session.cookie_lifetime, и заметил, если установить любое значение отлчиное от '0', то кука не приходит. Через phpinfo() посмотрел путь до загруженного php.ini, и увидел что он загружается из системных дирректорий хостинга. Почему не видит корневой .ini, не понятно. Завтра буду колоколить хостеру.

Народ, всем привет, прошу подсказать. Работаю по сайту, работает на 3.0.3.7, делал не я. суть проблемы - после закрытия окна браузера, корзина очищается. Ну понятно, сразу иду в устанавливаю session.cookie_lifetime = 120960. И ничего не происходит, проверяю в контроллере через var_dump(ini_get('session.cookie_lifetime')), а там 0 стоит. Пробежался grep-ом по всем файлам, нигде нет другого ini, нигде вроде не устанавливается. Пробую для теста принудительно в index.php установить ini_set('session.gc_maxlifetime', '120960'); ini_set('session.cookie_lifetime', '120960'); Проверяю, теперь значения нужные, но сессия не стартует вообще, то есть в браузере, после перезагрузки в куках нет OCSESSID. Проверил session.use_cookies все установлено. У меня совсем уже нет идей, подскажите пожалуйста, если кто-нибудь сталкивался или есть мысли куда копать

Если обработчик возвращает что-либо, то дальше события по этому триггеру не вызываются

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

Еще интересный момень, когда пытаюсь что-то залогировать в Loader, то логи начинает писать только после манипуляций с админкой (хоть перезагрузка страницы), когда на клиенте что-то делаешь, что-угодно, loader не срабатывает. Я так понимаю, это не нормально?

В общем, на втором шаге выяснил, что у меня регистрируются далеко не все события, которые возвращает model/setting/event.php->getEvents(). Я так понимаю, за получение пользовательских событий из базы и их регистрацию отвечает catalog/controller/startup/event.php. Пробовал на него навесить логи, но он будто и не вызывается вовсе, то есть - логи чистые вообще. Подскажите пожалуйста, а в каком файле он подключается?

Благодарю, буду пробовать

Хотя смысл, если у меня в зарегистрированных ничего не показывает. Хотя в базе они все есть. И админские работают же. Нет, тут какая-то другая причина скорее - всего

А как в engine/loader.php посмотреть вызываемые?

Если в event.php именно зарегистрированные, то у меня получается нет.. заргистрированных. Проверял я так: public function trigger($event, array $args = array()) { $log = new Log('events.log'); $log->write('Event fired: '.$event); foreach ($this->data as $value) { if (preg_match('/^' . str_replace(array('\*', '\?'), array('.*', '.'), preg_quote($value['trigger'], '/')) . '/', $event)) { $result = $value['action']->execute($this->registry, $args); $log->write('Action executed: '.$value['action']->getId()); $log->write('Action result: '.$result); if (!is_null($result) && !($result instanceof Exception)) { return $result; } } } }

ocStore 3.0.2.0

Всех приветствую, дорогие форумчане. Столкнулся со стандартной проблемой: сайт перестал отправлять email о заказе. Кинулся смотреть таблицу event - там все стандартно. Принялся дебажить событие mail/order вызываемое по триггеру catalog/model/checkout/order/addOrderHistory/before и тут вижу следующую картину: у меня вообще не срабатывают события каталога. Админские работают, а события каталога - совсем нет. 2 дня гуглил, но по этой теме инфы почти нет. Прошу подсказать, у кого какие есть идеи - почему события могут пропасть для фронта или хотя бы в какой стороне искать корень проблемы

P.S. На самом деле количество "удачных" и "неудачных" записей всегда разное, 5-6 я написал для примера, в действительности эта цифра всегда разная. Никакой системы я в этом не нашел. Порядок запросов одинаковый

Народ, 2 дня убил, уже и на redis пробовал перевести, думал с сессиями что-то, ничего не вышло. Провел следующий эксперемент: в контроллере, который вызывается первым: extension/quickcheckout/set добавил установку в сессию случайного значения, назвал его rand $rand = rand(10,99); $this->session->data['rand'] = $rand; var_dump('rand = ' . $rand ); В контроллере, который вызывается следующим: extension/quickcheckout/cart добавил просто вывод этой переменной из сессии var_dump('$this->session->data[\'rand\'] = ' . $this->session->data['rand'] ); При клике в корзине на кнопку "+" происходит отправлка данных на extension/quickcheckout/set там в сессию записывается значение, следом грузится extension/quickcheckout/cart (Очередность проверял, выводил время в милисекундах - все четко, порядок именно такой). И вот что мы получаем, где-то 1-5 раз в обоих случаях выводится верное значение, потом несколько раз в extension/quickcheckout/cart показывает предыдущее. Логично было предположить, что в первом контроллере не устанавливается значение, для того, что бы это проверить, я быстро набросал модель castom/custom с одним методом, котрый возвращает текущее значение $this->session->data['rand']. public funtion getRand(){ if(isset($this->session->data['rand'])){ return $this->session->data['rand']; } else { return 0; } } Теперь в extension/quickcheckout/set (котроллер, который вызывается первым) стал проверять текущее значении сессии, полученное из этой модели $this->session->data['rand'] = rand(10,99); var_dump( $this->session->data['rand'] ); // 1 $this->load->model('custom/custom'); $fromCustom = $this->model_custom_custom->getRand(); var_dump($fromCustom ); // 2 Значение в строке 1 и в строке 2 ВСЕГДА выводит одинаковое. Но если продолжить добавлять товар в корзину, то происходит эта долбанная магия: 5 раз значение показывается одинаковое во всех трех выводах (48, 21, 55, 74, 59). Затем, на 6-й раз в extension/quickcheckout/set в строке 1 и строке 2 показывает новое значение: 33, а в extension/quickcheckout/cart показывает предыдущее значение rand - 59 . Проверяю базу, в базе лежит 59. У меня совсем закончились мысли, что это может быть. Получается в одном месте значение ссессии устанавливается, в другом читается, а в третьем и в базе все еще предыдущее. Если у кого-нибудь есть мысли по этому поводу прошу поделиться

Спасибо, буду пробовать

Тогда может вы вкурсе, данные в сессию пишутся синхронно?

То есть, по-сути, у нас 2 ajax запроса, в первом после получения данных из модели устанавливается $this->session->data['shipping_methods'], Но в следующем запросе, значение уже другое. Как такое вообще может быть? Ну по-логике, оно где-то еще записывается, но я через grep -p все файлы прочесал, везде где нашел не имело никакого отношения. На скрине показан результат var_dump($this->session->data['shipping_method']['cost']); Цифрой указан порядок запроса

Да, я в курсе, но так уже вышло, что модуль этот ставили давно, и не я, а мне сейчас нужно чинить

Всем добрый день. Есть сайт https://test.fish2o.ru/ в качестве модуля корзины стоит quickcheckout от ***** (ставили давно, много на нем завязано, заменять симплой уже не вариант). И появился следующий баг: в настройках прописана сумма заказа, при которой меняется стоимость доставки. Например для Московских адресов, это 3499 руб. Если набрать в корзину на, допустим 3200, а потом через кнопку "+" увеличить количество, не всегда срабатывает эта настройка. При том, что модель отдает верный резултат, далее он записывается в $this->session->data['shipping_methods'], из него потом получается $this->session->data['shipping_method'] и уже в totals попадает $this->session->data['shipping_method'] ['cost']. Сам модуль состоить из нескольких контрллеров, как стандартный checkout. Пробовал выводить $this->session->data['shipping_method'] в каждом контроллере и вот что получаю: допустим в quickcheckout/shipping_method/index выдает правильное значение (по-сути, только что полученное из модели), далее идет запрос на quickcheckout/shipping_method/set, там тоже все верно, следующим же запросом идет quickcheckout/cart и там уже $this->session->data['shipping_method'] с другим значением. Я не могу уловить, где оно успело измениться. Какой-то логики в этом я не уследил. Через раз все срабатывает. Перерыл все контроллеры, где $this->session->data['shipping_method'] устанавливается, думал, может где-то под капотом ставится - ничего подобного. Если кто-нибудь сталкивался или понимает в чем может быть дело, прошу помочь

Отписал в ЛС

Добрый день, нашли исполнителя?

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

Хорошо, а как это с остатками синхронизировать?

Спасибо за наводку, но я не могу понять, как тогда настроить синхронизацию ? Допустим в остатках 3кг, это получается один товар с 3 опциями по 1 кг?