Opencart3 и MYSQLI_Memcached (Memcached Speed Booster) драйвер проблемы

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

 

А что тут переписывать то? Открываем \catalog\model\catalog\product.php
Смотрим то что посоветовали выше и видим часть запроса, например и меняем на такое

PHP:

$select_id = (0 <= stripos($sql, 'SELECT p.product_id, (SELECT AVG(rating)') ) ? sha1($sql) : false;

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

 

замена на этот запрос не дала желаемого результата.
зайти в Профиль по-прежнему не дает.

хотя каким-то образом один раз из 10-15 повторов получается.

есть еще мысль одна у меня:
столкнулся с тем, что OpenCart 3 не реагирует на настройки PHP хостинга, по крайней мере в отношении времени точно.
в настройках хостинга время у меня везде стоит Europe/Kiev, а тут поставил модуль рассылки СМС и он в СМС высылал время по UTC. пока в system/config/default.php вместо текущего UTC не исправил на Europe/Kiev.

вот думаю может тут тоже какая-то закавыка с этими параметрами.
к примеру из-за этих строк:

PHP:

        $this->_link->set_charset("utf8");
        $this->_link->query("SET SQL_MODE = ''");

 

Установите все тоже самое на движок той же версии, но без установки темы журнал. Если все работает, то пишем автору темы, мольбы о помощи. Если все так же, то отписываемся в теме.

 

поставил чистый OpenCart 3.0.3.2
https://www.computersystems.fun

после подключения mysqli_memcached не дает зайти в профиль в магазине

регистрироваться дает, а после регистрации не пускает.


P.S. кстати на чистом OpenCart видно одно отличие:
на нем не показывает, что пользователь сделал вход.
в логе активности нет ни одной записи.

 

Скажите, что вы добиваетесь?

 

хочу последовать вашему совету и кэшировать важны(нужные) запросы, а не все.
сейчас в драйвере прописано

PHP:

$select_id = (0 <= stripos($sql, 'SELECT p.product_id, (SELECT AVG(rating)') ) ? sha1($sql) : false; 

но проблема указана, даже при таком подходе не дает войти в профиль

 

вставил в код функцию для записи запросов в лог

PHP:

error_log('memcached: '. $sql, 3, DIR_LOGS . 'error.log');

и увидел, что время сессий отличается от реального. уже сталкивался с этим на OpenCart 3.0

потом посмотрел детали модулей php date , которые установлены там где OpenCart 2.3.0.2 и OpenCart 3.0.3.2

OpenCart 2.3.0.2 php module date
date/time support enabled
timelib version 2016.02
"Olson" Timezone Database Version 2018.5
Timezone Database external
Default timezone Europe/Kiev

OpenCart 3.0.3.2 php module date
date/time support enabled
timelib version 2017.09
"Olson" Timezone Database Version 2018.9
Timezone Database internal
Default timezone Europe/Kiev


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

т.е. mysqli_memcahed драйвер ставит время сессии и запросов по UTC (смотря в internal Timezone Database ), а менеджер сессий берет время от хостинга, где оно установлено в Europe/Kiev и соответсвенно сразу получается, что сессия просрочена и менеджер сессий ее закрывает!

подскажите каким образом можно прописать внутри mysqli_memcahed обращение к времени хостинга к примеру?

 

Возможно и это. По поводу времени, что хостер вам ответил?
Вот по mysql есть синхронизация https://www.opencart.com/index.php?...o&extension_id=16023&filter_search=time mysql
а по memcahed незнаю...

 

"финты" с timezone не помогли.

зато увеличение параметра expire до 14400 (с 3600) решило задачу добавления товаров в корзину в гостевой сессии (т.е. кроме того, что не давало входить в аккаунт, так еще и товар в корзину не добавлялся)

но в аккаунт по-прежнему не пускало.

замена session_engine на file решило проблему со входом в аккаунт - теперь пускает.

но хотелось бы найти более корректное решение, чем такие "костыли".

 

А почему это костыль?

 

ну костыль скорее всего 14400 вместо 3600

хотя

PHP:

session_engine = file

тоже "костыль", ведь я как бы за производительность сайта борюсь.

хостер дает храгить сессии и в redis, нашел драйвер сессий для redis - но там тоже пришлось писать expire = 14400

вот хотелось бы все же исправить как-то более грамотно это "отставание во времени"


ну и как бы хотелось решить проблему "внутри" драйвера, а не перелопачиванием параметров всей системы в "десяти" местах.

 

попытался обсудить с хостером проблему со временем.

в ответ получил интересную ссылку
https://stackoverflow.com/questions/19023978/should-mysql-have-its-timezone-set-to-utc/19075291#19075291

Код:

Internally a MySQL timestamp column is stored as UTC but when selecting a date MySQL will automatically convert it to the current session timezone.

но вопрос пока остался открытым:
- почему OpenCart 2.3 c mysqli_memcached делает это корретно
- а OpenCart с mysqli_memcached отдает время некорректно

 

У вас косяк в сессиях, а 2.3 и 3.0 сессии хранят по разному. В 2.3 по умолчанию "нативный" вариант см. \system\library\session.php

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

 

вы можете подсказать, чем вариант:

PHP:

public function __construct($adaptor = 'native') {

отличается от

PHP:

public function __construct($adaptor, $registry = '') {

и откуда оба они берут время expire для сессий?

ну и для меня менеджер сессий как бы является частью движка.

 

тем что по умолчанию хранит сессии в файлах, а в 3х в бд

 

таки да
у OpenCart 2.3 ни в system/config/default.php ни system/config/catalog.php нет переменных session_engine вообще!

и получается по умолчанию включен режим хранения сессий в file

у OpenCart 3.0
по умолчанию в
system/config/default.php
system/config/catalog.php

PHP:

$_[session_engine] = 'db';

 

Необходимо исключить запись запросов к таблице сессий

PHP:

if (stripos($sql, 'FROM `' . DB_PREFIX . 'session'))  $select_id = false; 

У меня работает. Проверил на Redis

 

да, я тоже уже добавил.
на рабочем сайте уже трудится.

под Redis вы имеете в виду, что mysqli_redis себе сделали?

теперь борюсь в админке, не дает, зараза, редактировать заказы - пишет что нет прав доступа к API.
пока редактирую из Мобильного приложения.

 

lда, под редис переделал.

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