Linkoln

12.07.2022 в 13:22, AlexDW сказал:

хостера не мучайте, это баг с сессиями в самом движке

 

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

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 все установлено.  У меня совсем уже нет идей, подскажите пожалуйста, если кто-нибудь сталкивался или есть мысли куда копать

29.05.2022 в 16:20, buslikdrev сказал:

Покажите, какой код был у кастомного модуля, чтобы знать, как нельзя делать.

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

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

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

08.05.2022 в 19:04, halfhope сказал:

Если события не регистрируются, то делайте трассировку от регистрации событий до самих данных из БД. Вот путь:

0. engine/loader.php 

1. engine/event.php->register

2. conroller/startup/event.php->index();

3. model/setting/event.php->getEvents();

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

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

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

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

08.05.2022 в 18:10, halfhope сказал:

 

1. Рекомендую вспомнить изменения в коде сайта предшествующие проблеме.

2. Можно сделать трассировку. Просмотреть зарегистрированные события для текущей сессии можно в файле engine/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.
У меня совсем закончились мысли, что это может быть. Получается в одном месте значение ссессии устанавливается, в другом читается, а в третьем и в базе все еще предыдущее. Если у кого-нибудь есть мысли по этому поводу прошу поделиться

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

02.03.2022 в 18:25, mpn2005 сказал:

По приведённому описанию, вам заочно никто не поможет.

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

Может это просто недоработка в установленной версии. В текущей версии это может быть уже и и справлено.

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

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

02.03.2022 в 18:21, mpn2005 сказал:

Это пиратский ресурс, который продаёт и распространяет краденое ПО. Вот модуль от автора.

https://www.opencart.com/index.php?route=marketplace/extension/info&extension_id=7382

 

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

Всем добрый день. Есть сайт 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'] устанавливается, думал, может где-то под капотом ставится - ничего подобного. Если кто-нибудь сталкивался или понимает в чем может быть дело, прошу помочь

Отписал в ЛС

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

4 hours ago, niger said:

Исходя из вот этого - у вас 0.5 и 1кг это разные товар. Значит разные артикулы - вот и сделайте опциям артикулы и обновляйте опциям остатки по артикулам. 

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

1 hour ago, Tom said:

В опциях из коробки есть значение "вес".

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

Нет. Это один товар и одна опция со значением 3000 гр.

Вы описали пример с товаром весом 500 гр. Я и предложил сделать опции с этим шагом

500 гр

10000 гр

1500 гр 

итд.

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

11 hours ago, Tom said:

Не знаю , как именно работает ваша CRM+1C, но опции опенкарт , то что они должны понимать. У опций есть поле для указания надбавки к цене. Сделайте новый вид опции Вес, укажите тип Список (Select), для экономии места. Ну а так как сам опенкарт работает с опциями и ведёт их учёт в админке, может и ваша связка црм-1с, поймут эти данные.

Был когда то модуль для 2.3, который бы возможно был вам полезен 

 

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